Технический груминг
Backlog Grooming — понятие из scrum, смысл которого в том, что команда собирается и решает что будет делать дальше и ставит эстимейты задачам. Проводится 1–2 раза в спринт в назначенное время. Но к сожалению, у нас, в какой-то момент возникли проблемы с PR:
- Эстимейты задач ставились на угад и бизнесу было сложно планировать спринты;
- Стали появляться большие RP. Сложность ревьювинга возрастала, а качество проекта падало;
- Возникали ситуации, когда разработчик написал код, а потом оказалось, что алгоритм не верный и (или) есть решение проще. В результате чего код переписывался, а время шло;
- Время выполнения задачи возрастало, а так же (лично у меня) появляется фрустрация и прокрастинация при работе над большими и сложными задачами;
Решение проблем оказалось банальным, появились “technical groomings” (название взято из головы, если вы знаете как этот процесс называется официально — пишите в личку). Смысл в том, чтобы позволить технической стороне обсудить формальный алгоритм задачи, разбить задачи на атомарные задачи и заэстимейтить каждую из задач.
Формальный алгоритм
Идея в том, чтобы у разработчиков было понимание того, как задача будет сделана. Тут спасает что угодно, текст с пошаговым выполнением задачи, блок схемы или просто рисунки в блокноте. Главное, что стоит держать в голове — нет понимания бизнес цели — не будет работающего алгоритма. Поэтому не спешите и задавайте вопросы бизнесу, даже если есть хоть малейшее недопонимание задачи.
Разбивка на атомарные задачи Правила, которых стараюсь придерживаться:
- 1 задача == 1 RP;
- Работающий код, потом рефакторинг;
Также, планируйте рефакторинг и закрытие технических долгов либо перед началом работы, либо после. Если одна задача из списка блокирует другую — стоит задуматься и попробовать вынести то, что блокирует — в отдельную задачу. Яркий пример такой задачи: добавить эндпоинт для фронтенда. Минимум два варианта, так решить проблему:
- 1 большой PR в котором будет и логика и эндпоинт. Много кода и сложно ревьювить;
- 2 PR-а. быстро сделать “пустой” эндпоинт для фронтенда, а потом потратить время на логику. Так разработчик разблокирует коллег, потом сделает остальную работу;
Плюсы
С таким подходом будет проще сделать документацию по проекту, а также, больше разработчиков будет понимать логику приложения. Кроме того, плохие решения будут отсеиваться быстрее, а значит цена ошибки будет меньше.
Так как результат такого груминга — проработанный алгоритм выполнения задачи, написание кода превращается в рутину. А составленный список минимальных задач помогает побороть фрустрацию и прокрастинацию перед неизведанным.
Минусы
Главная проблема — трата времени на обсуждение задачи. Этого могут не понять менеджеры, которые считают “нет кода — нет работы”. Старайтесь говорить с менеджерами и объяснять смысл таких обсуждений.
Такой подход не работает в команде из одного человека. А сам процесс груминга энергоемок, поэтому не ждите, что сможете загрумить все за один день.
И главное — груминг требует командной дисциплины.
Советы
- Ведите записи. А в конце задачи выделяйте время на обновление документации. Это поможет в поддержке документации к проекту;
- Начните с культуры и помощи коллегам. Не везде практикуются подобные обсуждения. Хотите исправить это — подойдите и предложите поговорить о задаче коллеги. После чего попросите помощи сами;
- Один груминг — одна тема. Также, желательно ограничивать обсуждения по времени и количеству участников. Не тащите команду, хватит только тех, кто будет работать над задачей;
- Делайте груминги по необходимости. Не тратьте время коллег в пустую;
Запомнить
- Технический груминг это черепаха из рассказа о зайце и черепахе. Медленно начнешь, быстрее закончишь;
- Если проблемы с ревью или этап разработки затягивается — стоит подумать об обсуждении кода перед его написанием;
- Технический груминг включает в себя обсуждение алгоритма, создание атомарных задач и эстимейты;
- Старайтесь в первую очередь разблокировать коллег;
Ссылки
