Когда-то, я писал о Разноцветном Бэклоге, т.е. о применении идеи цветовых маркировок для разных типов элементов Бэклога. Да-да, не удивляйтесь, Бэклог Продукта может содержать элементы разного типа — это иногда оказывается «новостью» для тех, кто только начинает практиковать Scrum и прочел только несколько статей или короткую книжку 😉 Одна только работа с Бэклогом содержит много нюансов, о которых я рассказывал во время онлайн курса или уже неоднократно писал. Так что если вы хотите больше узнать, то почитайте мои статьи на эту тему.

Другой вопрос, который я получаю сразу после того, как читатели, или слушатели тренинга, разобрались с идеей разных элементов Бэклога: «Как их учитывать при планировании Спринтов или целых выпусков?». Иногда просто так и спрашивают: «Как оптимально планировать итерацию?». Ответ прост, как и все из того, что применяется в Agile методах и о чем я рассказываю в этом блоге. 

Для того, чтобы разобраться, давайте быстренько вспомним, о каких видах Элементов Бэклога мы говорили:
1. Требования — Истории Пользователя или другое описание видимой пользователю и ценной функциональности.
2. Архитектурные улучшения — инфраструктура, фреймворки, общие компоненты, библиотеки — все, что ценно, так как может облегчить разработку Требований, но зачастую не видно пользователям.
3. Дефекты — все, что работает не так, как хочет пользователь, или не так как ожидалось — почти как Требования, только с негативной ценностью.
4. Технический долг — ненамеренно (слабый дизайн, copy&paste решения, плохой код) или намеренно (приоритет ближайшему выпуску, а не долгосрочному развитию) отложенное решение, которое в будущем усложняет разработку новых Требований.

Кстати, каждый элемент выделен на основе обширного опыта и исследований и под собой имеет достаточно солидное обоснование. Мой опыт явного применения этих типов уже достаточно большой и, наверное, каждый элемент может послужить темой отдельных статей.

Возвращаемся к вопросу, который я озвучил вначале: «Как оптимально планировать итерации и более долгие выпуски, даже с учетом этих четырех видов Элементов Бэклога

Очевидно, что каждый из этих элементов несет в себе долю риска, которые собственно и нужно учесть при планировании. В Скрам методологии в частности и подходах к управлению проектами в целом, есть мощный способ защиты от рисков — это буфер. В Agile проектах, можно говорить о буфере из того, что мы запланировали (scope) и буфере времени на то, что мы запланировали.

Если учесть, что Спринт — это забег, ограниченный по времени, за который мы обещаем сделать определенную функциональность, то лучше стараться обещать то, что мы можем сделать. Несмотря на то, что буквально в прошлой статье я говорил о том, что нужно быть готовым пересмотреть такие обещания — все-таки Скрам-команда должна учиться планировать в Спринт ровно столько, сколько вы действительно можете сделать. Соответственно, вам остается только использовать буфер времени.

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

How Backlog types affect buffer in the sprint

Вот вам и первый тип буфера — заложите время на погрешность в оценках. Не планируйте работу на максимальное количество часов, которые есть у вашей команды. Лучше от общей суммарной «мощности» (capacity) отнять какой-то процент и это будет ваш общий буфер для всей команды. А дальше, при учете, что у вас нет явного «эффекта хомячков» вы всегда сможете более оптимально перераспределить работу в течении Спринта.

Другим источником проблем являются ошибки. Иногда это простые баги, которые нашли при проверке той функциональности, которую вы делаете в конкретной итерации. Просто то, что написали программисты, ведет себя не так как ожидается 🙂 Иногда же, выясняются отдельные пласты странного поведения, которое приходится заводить в Бэклоге Продукта в виде Дефекта (см. выше).

Для простых багов, которые мы хотим исправить прямо в течении Спринта нам и понадобиться второй тип буфера: время на исправление багов.

По сути, если вы при планировании начнете закладывать время на эти два типа погрешностей, вы уже можете достичь хороших результатов и на этом остановиться. А вот если вы действительно работаете над своим постоянным развитием, то вы наверняка хотите «избавляться от долгов» и постепенно перерабатывать особо тяжелые «наследственные» куски. Именно для таких переработок и нужен третий тип буфера: время на выплату технического долга и улучшение системы.

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

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

Буду рад услышать комментарии читателей о собственном опыте применения подобных техник. Оставайтесь с нами, следите за нашим RSS.

Когда подстилать соломку или планирование Спринта с учетом вашей реальности
Tagged on:                     

3 thoughts on “Когда подстилать соломку или планирование Спринта с учетом вашей реальности

Comments are closed.