×Закрыть

Potracheno — баг-трекер для учёта технического долга

С некоторой периодичностью наблюдаю на ДОУ топики про технический долг. Каждый раз буря комментариев, делящихся примерно поровну на два лагеря: (1) костыли и грабли зло, надо делать хороший код и (2) за хороший код никто не платит, надо выкатывать фичи здесь и сейчас.

Технический долг — это, конечно, плохо. Он тормозит разработку, демотивирует команду и порождает баги. Но возникает вопрос: насколько плохо? Как измерить? И на него есть ответ.

POTRACHENO

Потрачено — это специализированный баг-трекер для учёта технического долга. Как и в обычном баг-трекере, в нём есть тикеты, у которых в свою очередь есть статусы, комментарии и теги (как на Stackoverflow). Также есть возможность следить за тикетами и персональныая лента событий. В сущности, ничего особенного.

Как и в обычном баг-трекере, есть система учёта времени — но не затраченного на решение проблемы, а потерянного вследствие того, что она до сих пор не решена.

Ручная работа там, где можно автоматизировать; написание однотипного кода; фикс багов; поиски несуществующей документации; ожидание деплоймента и т. д. — всё заносится в систему, в тикеты, посвящённые соответствующим компонентам.

Также система даёт возможность предложить решение проблемы — solution — с обязательным указанием оценки времени, необходимого на его воплощение.

Наконец, есть сводный отчёт по тикетам с массой параметров, в том числе с возможностью выборки тех проблем, на устранение которых нужно меньше времени, чем тратится из-за них впустую.

Проект написан в виде веб-приложения на языке Perl с использованием базы данных SQLite (mysql также поддерживается), с минимальными зависимостями (DBD::SQLite, Text::Markdown и MVC::Neaf) и возможностью установки путём git clone на произвольное устройство с доступом в сеть (десктоп разработчика, тестовый сервер, кофеварку в офисе и т.д.).

Потрачено находится в глубокой бете, много чего не хватает, но, по крайней мере, заявленный функционал работает и, как надеется автор, даже и в таком виде может принести немалую пользу.

УСТАНОВКА

Скачать проект:

git clone https://github.com/dallaylaen/potracheno.git

* Установка зависимостей (предполагается, что perl уже установлен):

cpanm DBD::SQLite Text::Markdown MVC::Neaf

* Запустить инсталлятор, который сгенерирует конфигурацию по умолчанию и инициализирует базу данных:

perl Install.PL --install

* Запустить собственно приложение:

plackup bin/potracheno.psgi

Более подробная инструкция есть в README.md

НЕМНОГО ФИЛОСОФИИ

Автор исходит из примерно следующих вводных. Допустим, есть проект, изъеденный техническим долгом, и жаждущая рефакторинга всего и вся команда. Под рефакторингом здесь понимаются в максимально широком смысле любые изменения, улучшающие разработку, в т.ч. устранение багов, разработка внутреннего инструментария, переписывание отдельных компонентов и т.д.

Есть также заказчик (product owner), который хочет те самые фичи здесь и сейчас. Собственно, он для этого и поставлен — если бы он хотел чего-то другого, команда была бы на улице вместе с вылизанным, но никому не нужным продуктом.

Данный инструмент устанавливается в параллель с основным багтрекером проекта (если у вас его нет, технический долг — точно не самая большая проблема). Он позволяет выявить наиболее узкие места, наиболее болезненные для команды грабли и костыли. И либо презентовать решения заказчику уже в виде обычных тикетов, либо добавить втихомолку в другие задачи, затрагивающие те же части кода. Тут уж зависит от степени взаимопонимания заказчика и команды.

Автор убеждён, что 80% плохого настроения, битья головой о клавиатуру и сидения на ДОУ вместо работы порождаются небольшим набором проблем, которые могут быть взвешены, посчитаны и измерены — и отправлены на свалку истории. Подтвердить или опровергнуть сие суждение может только практика...

github.com/dallaylaen/potracheno

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Идея интересная, но никто не будет заполнять базу. Некогда, нужно выкатывать фичи. И потерянное время замерить так же просто, как дать эсимейт

Да, есть такая проблема. С другой стороны, джиру же и коммит-мессаджи как-то заполняют! Тут уже скорее вопрос организационный, а не технический.

К примеру, можно установить внутри команды, что на ретроспективе отмазки «почему так долго делал» принимаются только в письменной форме. Если в команде нет ретроспектив, то технический долг — не самая большая проблема :)

С эстимейтами, как минимум, можно поступать как описано на stackoverflow:


//
// Dear maintainer:
//
// Once you are done trying to ’optimize’ this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 42
//

То есть, если заявленный эстимейт на рефакторинг превышен — значит, предложенное решение невалидное, и следующая попытка будет в другой раз.

Интересно, один я прочитал название как portacheno?

Ждём нового продукта Nahujareno для сейлзов!

В нём обещанные кастомеру фичи будут постепенно уменьшаться, в конце концов сближаясь с тем, что на самом деле удалось реализовать.

А также нового инструмента для CI HH&P (Huajak Hujak and Production)

Эй, жду инструментов с этими названиями, обязательно заюзаю.

Я посмотрю подробнее, но пока что создаётся впечатление, что sonar, скорее, инструмент для анализа исходников. Что само по себе хорошо, но не даёт ответа на фундаментальный вопрос «сколько времени мы на самом деле продолбали из-за того, что [возможно, даже и не мы] решили сделать побыстрее».

Да, в основном Sonar занимается анализом, но не только исходников но и результатов выполнения тестов и т.д. Но кроме этого в нем также есть issues которые можно заводить вручную, привязывать к исходникам, назначать людей, указывать ориентировочное время и т.д.

Подписаться на комментарии