Список задач

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

Очень часто, можно восстановить список закрытых задач по проекту найдя их описание в логах системы контроля версий (например, через git log).

Номер задачи

Найти номер задачи, над которой велась работа, можно несколькими способами. Он может быть:

• указан в тексте сообщения коммита;
• быть частью имени ветки, в которую делается коммит;
• содержаться в название созданного PR;

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

Зная номер задачи

Зная номер задачи, даты коммитов и автора, мы можем сделать различные выводы:

• сколько времени ведется работа над задачей;
• сколько времени проходит от создания PR до его влития;
• вносятся ли правки в PR после создания;
• сколько в среднем задач в день делает программист;
• сколько максиму задач в день он делал;

Тип задачи

Найти тип задачи, можно несколькими способами. Он может быть:

• явно указан в тех же местах, где мы ищем номер задачи (например: в тексте сообщения или название ветки)
• или указан не явно. Тогда мы ищем ключевые слова, которые могут нам подсказать. Например, для типа refactor, это могут быть: refactor, refactoring, update, legacy и т.п.

Зная тип задачи

Зная тип задачи, даты коммитов и автора, мы можем сделать различные выводы:

• каково соотношение времени и денег потраченных на добавление новых фич и исправление старых;
• сколько времени выделяет команда на написание документации и рефакториг;
• есть ли сотрудники, которые делают только один тип задач;
• насколько разнообразны задачи в данном проекте;

Советы

На основание полученных данных, система может автоматически выдавать следующие типы советов:

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

История

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

Через пол года к нам пришел аудит. Судя по графикам мы потеряли около 100 задач и нам нужно было отчитаться об их статусе. Доступ в старую систему уже отсутствовал даже на просмотр.

Мы вытащили все номера задач из логов git и доказали аудиту, что все задачи были выполнены и влиты. А закрыть мы их не смогли в связи с тем, что в старую систему админы закрыли доступ.