LINUX.ORG.RU

Potracheno — система учёта технического долга

 , , , ,


2

3

Вышла и потихоньку развивается бета-версия системы учёта технического долга. Система сделана в виде баг-трекера, который устанавливается параллельно основному трекеру проекта (jira, redmine и т.д.) на любое устройство с доступом в сеть (тестовый сервер, ноутбук разработчика, кофеварка и т.п.). Однако, вместо времени, использованного для решения проблемы, она учитывает время, потерянное в силу того, что проблема всё ещё не решена.

Идея такова: команда разработчиков заводит тикеты, описывающие те или иные проблемы разрабатываемого продукта (плохой код, недостаток документации, проблемы производительности, убогость внутреннего инструментария и т.д.), после чего логирует время и предлагает возможные решения. Далее, в зависимости от вменяемости заказчика/менеджера, тикеты либо вносятся уже в нормальный багтрекер, либо тихой сапой включаются в «официальные» фичи.

Поддерживаемые на данный момент функции:

  • Заведение тикетов, смена статусов, комментарии;
  • Теги а-ля stackoverflow;
  • Учёт потраченного времени;
  • Предложения решений (solution proposals) с оценкой времени на реализацию;
  • Персональная настраиваемая лента событий и слежение за тикетами;
  • Разнообразные отчёты, в т.ч. по тикетам, из-за которых уже потеряли больше времени, чем нужно на их исправление.

Проект реализован на языке Perl и использует базу данных sqlite. По ссылке содержится подробная инструкция по установке, скриншоты, текущий вишлист и всё такое.

>>> Гитхаб

★★★★

Проверено: Shaman007 ()
Последнее исправление: Klymedy (всего исправлений: 3)

Ответ на: комментарий от mittorn

Оттуда и название... Ничего лучше не придумал, сорри.

lodin ★★★★
() автор топика
Ответ на: комментарий от anonymous

Кто много работал с легаси кодом, безусловно, найдёт в этом долю истины.

lodin ★★★★
() автор топика

УБИТ

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

Perl

Sovok-way во все поля.

anonymous
()
Ответ на: УБИТ от anonymous

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

Ну Вы как на поддержке никогда не работали. Каждый день мордой в говнокод, и если оставить как есть, то вообще жить противно, а если каждый раз переписывать, так у переписывалки эрекция пропадёт.

Ну вот и возникает вопрос - сколько вешать в граммах? Поскольку точное измерение сорта говна немного не мой профиль, замеряем что попроще - продолбанное время.

Perl

Выпадет месяцок свободный - перепишу на Java, как некоторые тут )

lodin ★★★★
() автор топика
Последнее исправление: lodin (всего исправлений: 1)
Ответ на: комментарий от lodin

Почему не влился в экосистему perl? Я имею в виду {meta}cpan, rt, etc. Там и тестеры может найдутся, и соучастники, и все такое прочее.

перепишу

В начале, попробуй использовать perl на всю катушку, со всеми профайлерами, анализаторами, перл-хакерами.

P.S. Годная затея. Заодно и фичреквест от анонима есть: «учитывать время, использованное для решения проблемы» :-D

P.P.S. Насчет системы код-ревью упомянули тож не зря. На Gerrit жалуются.

Deleted
()

Идея очень хорошая. Сейчас работаю на большом проекте с долгой историей и там это пришлось бы ко двору. Буду пробовать, спасибо.

Weres ★★★
()

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

А можно как-то две эти метрики объединить\сравнивать? Ну то есть - я каждый день теряю по 15 минут рабочего времени потому что X. Чтобы исправить X мне нужно потратить 1 час. Так как все время на решение X я не могу убить я буду им занимать по 15 минут в день. То есть четыре следующих дня я теряю уже по 30 минут в день (15 из-за X да плюс 15 на решение X), а потом все ништяк (за следующие 4 дня затраты окупаются). Цель - понять, действительно ли надо решать проблему, чтоб не получилось что сегодня мы тратим из-за нее лишние 15 минут в день, но чтоб решить ее нам на пол года придется вшиваться по 4 часа в день два года и вбухать олимпиард денег в инфраструктуру так что пока и так поживем, потому что пока оно «окупится» мою работу будут выполнять огромные небоевые человекоподобные роботы. Хотя это потерянные 15 минут ежедневно, да.

alozovskoy ★★★★★
()
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от alozovskoy

Все твои рассуждения имхо можно заменить ответом на один вопрос:
какие юкдут потери, если проблему не исправить?
В том числе и в отдельных, разовых ситуациях.

torvn77 ★★★★★
()

Potracheno

вы делаете наш день, озвучено и переведено)))

backbone ★★★★★
()

который устанавливается параллельно основному трекеру проекта <...> на любое устройство с доступом в сеть (<...> кофеварка и т.п.).

Проект реализован на языке Perl

Воу-воу, нехорошо отнимать нишу у Java!

X-Pilot ★★★★★
()

Прачечная-прачечная...

Potrachechnaya!!

ЗЫ вспомнился Генри Форд с его комнатой для слесарей.

mos ★★☆☆☆
()
Ответ на: комментарий от Deleted

Насчет системы код-ревью упомянули тож не зря. На Gerrit жалуются.

А phabricator чем не устраивает?

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от alozovskoy

Именно так и работает. Сначала предлагаете решение в комментах (fix estimate): «я знаю, как решить это за час (способ решения)».

https://github.com/dallaylaen/potracheno/blob/master/html/screenshot/shot-fix...

Потом выбираем «solutions ready to go» в отчёте:

https://github.com/dallaylaen/potracheno/blob/master/html/screenshot/shot-sol...

lodin ★★★★
() автор топика
Ответ на: комментарий от Deleted

На Gerrit жалуются.

А что не так? После Reviewboard сильно приятнее.

h4tr3d ★★★★★
()
Ответ на: комментарий от Deleted

Я пробовал отрефакторить в «модуль на CPAN + три строчки конфига», не получилось. В этом смысле проект неплохая иллюстрация самого себя.

Но кстати да, надо будет ещё попытку сделать.

lodin ★★★★
() автор топика

Идея занятная, и трекинг трекера для подсчета долга видита разумным, если исходным трекером пользуются по назначению... К сожалению, это не всегда так - например, в старой системе может быть накоплено много неудачных решений, которые всем портят жизнь, много срезанных углов - но в трекере об этом лишь косвенно напоминают 2-3 бага (или фичи), которые не закрыть (не реализовать) годами.

А так, штука классная, развивай дальше :-)

yoghurt ★★★★★
()

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

Т.е. вот ради этого все и писалось? Что мешает для этих же целей использовать основной багтрекер? Куча разных утилит только путаницу вносит.

Deleted
()
Ответ на: комментарий от torvn77

Меня интересует не что будет если не исправлять, а что будет если как раз таки исправлять будем.

alozovskoy ★★★★★
()
Ответ на: комментарий от anonymous

https://en.wikipedia.org/wiki/Technical_debt

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

Ну и вот тулза для различения случаев «пора переписать (данный конкретный) говнокод к такой-то матери» vs «сжать зубы и терпеть, овчинка не стоит выделки».

lodin ★★★★
() автор топика

fix UI

Во времена HTML5, Bootstrap и Material design видеть такой интерфейс уже глаза режет, идея тоже так себе, в том же Redmine можно завести отдельный трекер с названием Techinal debt и получится тоже самое.

Хоть бы какой намек на выравнивание полей по горизонтали http://imgur.com/sK4w2Z4

imho

arren
()

Проект реализован на языке Perl

Однострочник?

dmxrand
()
Ответ на: комментарий от torvn77

Все твои рассуждения имхо можно заменить ответом на один вопрос:
какие будут потери, если проблему не исправить?
В том числе и в отдельных, разовых ситуациях.

Только ответ на него возможен только в вероятностях. А для катастрофических последствий вероятности вообще не считаются. Это профанация.

Какова была расчетная вероятность событий, приведших к Фукусиме? Ноль. Считалось, что таких совпадений быть не может. После Фукусимы мнение сильно поменялось. ИЧСХ расчетная вероятность стала не нулевой.

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

VoDA ★★
()

Название прекрасно.

Deleted
()
Ответ на: fix UI от arren

Вы совершенно правы насчёт внешнего вида, он ужасен, а был ещё хуже, пока один добрый человек не сосватал мне тот же bootstrap. К сожалению, я очень плох в эстетике и эргономике, мне если текст есть на экране примерно там, где ожидалось, - и то хорошо. Так что вся надежда на багрепорты, или лучше патчи.

Что касается задумки - время покажет. Во многих компаниях админы штатного багтрекера работают по схеме «снег, зима, просить», и отдельный проект, тем более с нестандартными настройками, непросто будет пробить. А Потрачену уже закатали в докер добрые люди.

lodin ★★★★
() автор топика
Ответ на: комментарий от shkolnick-kun

😂

Ждем платформу для кодревью Zashquared!

Хочу!

Stil ★★★★★
()
Ответ на: комментарий от VoDA

Какова была расчетная вероятность событий, приведших к Фукусиме?

Насколько я знаю, авария произошла из-за разгильдяйства руководства и сотрудников станции.

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

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

Ещё вариант, делать небольшое, но критичное для проекта задание сегодня,
или отложить его выполнение на завтра, когда работы не будет,
а сегодня прийти пораньше домой и выспаться перед завтрашним днём?
А ведь шеф может пользуясь свободным временем собрать важное совещание, плавно переходящее в корпоратив, приехать важный груз, который должны принять именно вы лично, да мало ли что случится, что не даст вам сделать это важное для проекта задание завтра.
Как следствие сроки сдачи проекта послезавтра будут сорваны, будут выговоры, санкции и не устойки.
Можно было спрогназировать повышенную занятость на завтра?
Нельзя.
Но сделать всю работу сегодня, чтобы высвободить завтрашний день и не нести риск получить сверх убытки от срыва сроков может тоже стоило?
Скорее всего да, плюс полностью свободный завтрашний день позволит взять отгул и просто не выходить на работу :)

torvn77 ★★★★★
()
7 февраля 2017 г.
Ответ на: fix UI от arren

Спасибо за репорт, запилил выравнивание полей (пока в devel ветке только). Но вообще мне с UI, конечно, тяжело работать, мне если буквы нужные прочитались - уже почти ок.

lodin ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.