Блог

Подзадачи пользовательских историй. Как и зачем их считать?

Сен 21, 2021

Поскольку заказчики и подрядчики, ввиду пандемии COVID-19, продолжают работать из дома, считаем всё более важной и полезной возможность поделиться своим опытом удалённой работы и эффективного взаимодействия внутри распределённых команд. Несмотря на наличие сейчас множества разных инструментов для удалённой работы (Microsoft Teams, Slack, WebEx, Google Meet и т.д.), не менее важно иметь слаженный и выверенный рабочий процесс. В рамках данной статьи мы расскажем о своей работе над оценками, насколько точно они позволяют прогнозировать работу в рамках спринта.

Начинаем планирование нового спринта. Разработчики берут в бэклог спринта N-ое количество пользовательских историй. Каждая пользовательская история имеет оценку по времени. Суммарная оценка не превышает Capacity (общую возможную загрузку команды), и разработчики сообщают, что к концу спринта смогут реализовать весь функционал и достичь цели спринта.

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

Ещё на этапе планирования каждая пользовательская история, включенная в бэклог спринта, сразу же разбивается на подзадачи. Они помогают не только декомпозировать крупную пользовательскую историю на более мелкие части, но и распределить соответствующую работу среди разработчиков. Подзадачи также можно оценить, а затем использовать для построения так называемых информационных радиаторов, в частности это Sprint Burndown Chart. Рассматривая Sprint Burndown Chart, разработчики имеют возможность провести своевременную инспекцию в контексте достижения цели спринта. Предлагаем рассмотреть несколько примеров того, как и в чём можно оценивать подзадачи.

Оценка подзадач по времени, Burndown Сhart по времени

При планировании разработчики декомпозируют пользовательские истории на подзадачи и дают временну́ю оценку каждой из них. Для каждой пользовательской истории может получиться примерно такой список подзадач:

  • Рефакторинг (6 часов).
  • Внедрение компонента модуля ядра (4 часа).
  • Поиск метода для взаимодействия с базой данных (7 часов).
  • Правки пользовательского интерфейса (2 часа).
  • Написание автотеста (3 часа).

Сумма временны́х оценок подзадач попадает на Burndown Chart. По мере закрытия подзадач значение времени на Burndown-графике будет стремиться к нулю.

Плюсы такого подхода

  • Можно посмотреть разницу между начальной оценкой и фактической не только по пользовательской истории, но и по подзадачам.
  • Оценка отдельных, более мелких компонентов всегда даётся проще и точнее, чем оценка чего-то большего и общего.
  • Декомпозируя пользовательскую историю на подзадачи, можно ещё раз перепроверить изначальную оценку истории по времени.
  • Сама пользовательская история может оцениваться как в стори поинтах, так и в единицах времени.

Минусы

  • Подзадачи приходится оценивать дополнительно к пользовательской истории. Это приводит к дополнительным обсуждениям на планировании.
  • Незавершённые подзадачи надо переоценивать на дейликах. Это дополнительно отнимает время.
  • Оценка подзадач не важна заказчику. Его интересует либо изначальная оценка пользовательской истории, либо уже потраченное время по подзадачам.
  • Люди плохо дают точные оценки в абсолютных величинах.

Количественная оценка подзадач с использованием Burndown Chart

В одном из проектов мы используем следующий подход: оцениваем только родительскую историю (в стори поинтах или в единицах времени), а для Burndown-графика мы просто считаем количество открытых подзадач.
Приведём пример. На планировании, при разбивке пользовательских историй, мы договариваемся, что подзадачи будут соответствовать следующим критериям:

  • Они будут примерно одинаковы по трудозатратам.
  • Выполнение каждой из подзадач не должно занимать более одного дня.

По мере того как подзадачи закрываются, Burndown Chart стремится к нулю.

Плюсы такого подхода

  • Экономия времени. Не надо оценивать подзадачи на планировании. Не надо переоценивать подзадачи на дейликах.
  • Пользовательская история может оцениваться как в стори поинтах, так и в единицах времени.
  • Время, потраченное на выполнение подзадачи, может отмечаться также как и раньше.

Минусы

  • Подзадачи не сразу попадают под изначальные критерии. Первые 2–3 планирования разработчики будут учиться создавать примерно равные по трудозатратам подзадачи.
  • Оценка подзадач не важна заказчику. Его интересует либо изначальная оценка пользовательской истории, либо уже потраченное время по подзадачам.

Burndown Chart в стори поинтах, без оценки подзадач

Представим, что в бэклоге спринта есть пользовательская история, оценённая в 40 стори поинтов. На планировании разработчики также создали по ней подзадачи. Подзадачи не оценивались.

Далее во время Daily Scrum разработчики будут отмечать, какие подзадачи выполнены, и перекалькулировать стори поинты пользовательской истории. Burndown Chart будет строиться по остаточным стори поинтам пользовательской истории.

В заключение

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

Новое в блоге

Разработка через прототипирование

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

Современный подход к подготовке технической документации

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

Ряд тенденций, меняющих автомобильную промышленность

За прошедшее столетие автомобилизм охватил весь мир. Подобно многим другим инновациям, автомобиль изменил мировую экономику, а вместе с ней – жизни миллиардов людей во всем мире. В одной только Европе автомобильная промышленность насчитывает около 12 миллионов рабочих...