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

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

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

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

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

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

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

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

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

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

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

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

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

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

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