Поскольку заказчики и подрядчики, ввиду пандемии 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 будет строиться по остаточным стори поинтам пользовательской истории.
В заключение
Какой подход вы бы ни выбрали, следует помнить, что важна лишь закрытая пользовательская история, так как инкремент продукта и ценность для заказчика несёт именно она. Частично закрытые подзадачи пользовательской истории, которые нельзя передать в релиз, являются информационным мусором.
