Правила работы с трекером. Синопсис вебпосиделок клуба иФБ

Из ленты: 255 ступеней

Правила, приведенные ниже были озвучены на “вебпосиделках” Клуба иФБ в мае 2018. Работали по модели первой фазы мозгового штурма. По очереди высказывали правила, которые на взгляд участника наиболее важны. Фазы критики не было. Т.е. это пока материал для обсуждения. Кроме того, участники предлагали эти правила не для крохотных проектов, а имели в голове производство со сложным гетерогенным продуктовым ландшафтом на 100+ систем. Так что, вполне возможно, вам эти правила не подойдут. И да, это, естественно, не все правила. Времени на обсуждения было мало.
Приятного чтения.

1. Инструмент ничего не значит.
Проблема не в том, что кто-то работал в багзилле, но не работал в Jira, которая используется на текущем проекте. Переучить с одного трекера на другой — один час. Настоящая проблема заключается в том, что огромное число людей не умеют работать с трекером. В частности не понимают принципов управления задачами. И стаж не играет никакой роли. Мы видели множество людей, которые имея стаж в четверть века по прежнему не умеют управлять задачами.

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

3. Необходима декомпозиция до атомарных задач.
Минимальная Фича — то, что приносит деньги. Это группирующая задача. А атомарная — это не более одного артефакта, находящегося под версионным контролем, не более одного исполнителя и не более полунедели (с учетом вариаций достаточно, чтобы исполнитель делал от 10 атомарных задач в месяц).

4. Все статусы в трекере должны быть понятны.
И чем меньше статусов, тем лучше.

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

6. Существует несколько типов задач.
Для них различается набор полей и статусов. В рамках одного типа может быть несколько подтипов. Типы:

  • Задача  связанная с изменением любого артефакта находящегося под версионного контролем. В репозитории кода. Такая задача не может быть закрыта с резолюцией “Сделано”, только при наличии ссылки хотя бы на один коммит в репозитории. Как правило, для такого типа достаточно 4-5 статусов. В идеале для этого типа задач должна быть выполнена инспекция кода / другого артефакта.
  • Задача не связанная с изменением любого артефакта находящегося под версионного контролем (подготовить ноутбук новому сотруднику, дать доступы к средствам коллективной работы).
  • Задача, которая ставится самому себе. Himself — два статуса.
  • Группирующая задача. Имеется ввиду, что нужно в явном виде разделять управление задачами для бизнеса и управление задачами на уровне исполнителей. Типичным примером группирующей задачи в джире может служить эпик. Но для этой цели эпик служит плохо.

7. Нет задачи в трекере — нет кода.
И никакие поручения устно или через почту не должны отменять этого правила. Именно поэтому недавно в Jira появилось разделение на автора задачи (заказчика) и сотрудника физически внесшего задачу в трекер. Хотя необходимость этого была очевидна еще до начала работ над Jira. Очевидна тем, кто понимает как управлять задачами. Задача в трекере является отличным комментарием к коду. И когда очередной инженер будет разбираться с тем, “Зачем же это сделали?!” переход в трекер очень ему поможет. Верно и обратное. Если есть инструмент для codeCoverage, то можно убедиться, что весь измененный код был покрыт тестами в рамках тестирования. Точно тоже самое касается проведения ревью кода. Очень удобно “шагать от задачи”.

8. Финансовые показатели и метрики производства должны быть разнесены.
К метрике производства относится time2market. И он считается трекером автоматически, при условии, что сотрудники не забывают изменять статусы задач.

9. Оценка трудозатрат и учет трудозатрат должны быть преданы анафеме.
Результаты эксперимента показывают, что сам факт наличия оценки трудоемкости приводит к увеличению трудоемкости в 1.5 — 2 раза (смотри стр 48 книги Peapleware ISBN 5-93286-061-8). Теоретическое обоснование этому дают Деминг в эксперименте “Воронка и мишень” и Голдратт в книге “критическая цепь”. Учет же трудозатрат с неумолимостью ведет к другой проблеме, сформулированной Голдраттом: “Чем ближе вы к балансу, тем ближе вы к банкротству”. При наличии разделения труда часть сотрудников должна простаивать. В противном случае фирма несет неоправданно большие убытки.

10. Чем меньше полей, тем лучше.
Почти на каждом проекте у кого то начинает зудеть и чесаться: “А давайте еще вот такое поле добавим. А давайте у нас будет не просто описание, а отдельно шаги, отдельно реакция системы и отдельно фактический результат”. Не надо. Не надо превращать форму создания задачи в систему управления подводной лодкой.

11.Сначала устаканиваем процесс, потом настраиваем трекер.

Настройка трекера должна соответствовать ДТР (дереву текущей реальности). Не будущей, а именно текущей. Не надо настраивать трекер “про запас”.

12. Трекер задач должен быть один!
Существуют фирмы и даже проектные команды использующие сразу несколько трекеров. Мы были свидетелями, как одна небольшая проектная команда использовала сразу четыре списка задач. Это приводило к неимоверному бардаку и уход домой в час ночи был регулярной практикой. Так же необходимо различать системы управления задачами, системы управления проектами/продуктами и системы управлениями знаниями. Использование каждой из этих систем может порождать жуткие химеры.

PS. Перепосты данного синопсиса крайне приветствуются. Правила:

  • Не спрашивать разрешения на перепост.
  • Не указывать линк откуда утащили синопсис.
  • Указать, что это “Синопсис вебпосиделок клуба иФБ”.

Источник