Управление продуктом. Российская практика. Юлия БилинкисЧитать онлайн книгу.
функций.
Для каждой истории (либо в условных единицах – Story Points, либо в человеко-часах) выставляется оценка, которую дают разработчики. Поинты обозначают уровень сложности или трудоемкости реализации элементов бэклога продукта (пользовательской истории): один поинт – простую задачу, два – сложнее и т. д., однако для того, чтобы начать их использовать, необходим накопленный командой опыт разработки. Часто на этом этапе важно дробить истории, чтобы получить более точные оценки.
Для лучшего понимания нужно рассмотреть концепцию скорости работы (velocity). В конце каждого спринта команда суммирует оценки усилий, связанные с пользовательскими историями, которые были завершены за время спринта. Эта сумма называется скоростью: это количество поинтов, которое команда реализует за спринт. Таким образом, в начале вы как бы предполагаете или оцениваете, сколько поинтов вы можете набрать за спринт, но после пары спринтов вы сможете усреднить количество поинтов, а затем сделать вывод, что в среднем ваша команда может, например, набрать 15 поинтов за спринт. Это и есть скорость работы.
Для составления бэклога спринта команда берет пользовательские истории из бэклога продукта и обязуется доставить их за спринт. Это самый нижний уровень, на котором команды устанавливают приоритеты. В релиз (выпуск функциональности для пользователей) обычно попадают истории нескольких спринтов. Календарный план релизов представляет собой дорожную карту, которая часто выглядит как диаграмма Ганта с датами релизов.
Отдельно необходимо поднять вопрос качества планирования спринтов и релизов. Оно измеряется соблюдением сроков и соответствием требованиям пользовательской истории. При этом важно отслеживание качества не только в конце спринта, но и в процессе, а также проведение ретроспективного анализа. Этим тоже занимается владелец продукта.
Рис. 1.3. Пример Burndown Chart
Если скорость команды начинает падать, значит, она неправильно оценивает свои истории: берет на себя слишком много работы или кто-то заставляет ее это делать. Но если команда неожиданно обнаруживает, что у нее появляется много свободного времени, значит, ей следует сделать переоценку своих трудозатрат. Важный инструмент для налаживания темпа и прогнозирования скорости разработки – диаграмма сгорания задач, или Burndown Сhart.
Как следует из названия, диаграмма сгорания задач – это инструмент, показывающий, как быстро команда работает с пользовательскими историями. Они эффективны за счет того, что прогресс оценивается не в контексте потраченного времени, а в контексте оставшейся работы. Рекомендуется, чтобы оставшаяся работа уменьшалась более-менее равномерно по ходу спринта.
Один из популярных вопросов на собеседованиях: «Что делать, если команда отстает от графика?» Это головная боль владельца продукта и менеджера проекта. Тут можно вспомнить известный треугольник ограничений проекта, также называемый тройным