Здравствуйте, друзья!

Сегодня я хочу осветить такую сложную и неоднозначную тему, как планирование в Agile. Когда в Скрамтреке я проводил тренинги Certified Agile Professional, этот вопрос был один из самых частых.

И так, что же такое планирование в Agile? Из каких шагов оно состоит? И вообще кому оно нужно? Разберемся со всем последовательно.

Кому нужно планирование в Agile?

1. Руководителям Agile-проектов (как ни странно).
2. Скрам-мастерам.
3. Владельцам продуктов.
4. Бизнесу.
5. Руководителям отделов.

Зачем?

У каждой из этих ролей свой запрос для планирования.

1. Руководителю проекта нужно дать ответ Заказчику, когда проект будет реализован.
2. Скрам-мастеру – помочь Владельцу продукта рассчитать (или, что чаще бывает, рассчитать за Владельца продукта и сообщить ему) время релиза.
3. Владельцу продукта – спланировать дату релиза и подготовить все необходимые мероприятия (маркетинг, продвижение, реклама, коммуникации и т.д.).
4. Бизнесу просто нужно знать, когда будет релиз. И неважно – это agile или водопад, или какой-то любой другой подход.
5. Очень часто руководители отделов вместе с административными и функциональным обязанностями также отвечают за реализацию проектов внутри компании, связанных со своей функцией или сервисом. Или участвуют в реализации проекта, затрагивающего всю компанию, и вынуждены давать сроки по своим этапам работы.

Как раньше планировали IT-проекты и релизы?

В этой статье будет очень важным вспомнить, как раньше планировали время реализации IT-проекта или релиза.

Ответственный руководитель проекта получал поручение реализовать проект (дальше я умышленно пропускаю ряд подготовительных шагов из PMBOK, они не важны для этой темы), определял объём необходимых работ, получал (или что чаще бывало находил) исполнителей для реализации проекта, делал запрос на оценку предстоящих работ, получал от исполнителей оценку в часах, складывал это время в общую временную ленту и получал конечный срок.

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

Абсолютная оценка – это оценка работы в единицах времени: минуты, часы, дни, недели, месяцы.

Но вот пришла эпоха Agile, а вместе с ней – относительные оценки.

Что такое относительная оценка?

Относительная оценка – это оценка в условных единицах. Например, в Agile для этого часто используется такая условная единица, как «стори поинт». О них я писал в статье про грумминг.

Для непосвященных в Agile лучше привести пример с размерами одежды. Эта техника также используется для оценки сложности работы. Ее называют «майки задач».

Мы все хорошо знакомы с системой размеров одежды S, M и L. Когда мы идем в магазин покупать себе новую ветровку на летний сезон, нам не нужно помнить точный рост, объем груди и охват плеч. Вместо этого достаточно помнить свой размер: S, M или L. Подобрав себе размер один раз, в дальнейшем нам проще выбирать одежду. Иногда это настолько легко (особенно если у вас стандартная фигура), что можно даже сделать выбор по Интернету.

Суть относительных оценок в том, что они сравниваются между собой. Их задача – продемонстрировать разницу между объектами ( или рабочими элементами).

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

Если перекладывать такой подход на IT-проекты, здесь это правило то же работает. Команде разработчиков гораздо проще договориться об относительном размере какого-то рабочего элемента, чем точно оценить его разработку в часах. Конечно же при условии, что у них есть эталонная задача (эталонное здание).

Как теперь планировать проекты и релизы в Agile?

Как вы уже догадались, для планирования в Agile нужно использовать оценку в условных единицах.

Вот мы оценили проект и поняли, что он, например, равен 150 условным единицам. Или это проект размера L. Что делать дальше?

Дальше дело техники, как говорится. Если вы работаете по Agile, то у вас наверняка есть команда. И еще с высокой долей вероятности вы используете итеративно-инкрементальный подход. В начале каждой итерации вы планируете работу, в конце команда поставляет инкремент.

Теперь ваша задача накопить статистику скорости работы команды. В Agile для этого используется термин velocity – или скорость работы команды, которая измеряется количеством выполненных условных единиц за спринт.

Для наглядности используется график скорости команды. Или по-английский Velocity Chart (рис. 1).

Обладая статистикой скорости работы команды, вы можете просчитать примерное время выполнения проекта. Если команда выполняет 30 условных единиц за итерацию, а весь проект оценен командой в 150 условных единиц, следовательно для реализации проекта вам потребуется 5 итераций. Если длина ваших итераций 2 недели, получаем срок реализации проекта – 10 недель или два с половиной месяца.

Также для контроля выполнения проекта точно в срок в Agile используется диаграмма сгорания или Burndown Chart (рис. 2).

Она наглядно демонстрирует, как «сгорает» работа в проекте после каждой итерации.

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

Красиво? Не то слово. Удивительно? Еще бы. К сожалению, в таком подходе много «если». Он работает, если:

1. В вашей команде есть все компетенции для реализации проекта.
2. Вы и только распоряжаетесь ресурсами команды. Никто не может забрать у вас людей на другие проекты.
3. В процессе работы у вас нет внешних блокировок, которые мешают реализации проекта.
4. В процессе работы в вашем проекте не появляется новых дополнительных требований от Заказчиков. Вы и только вы контролируете объем проекта.
5. Команда отлично знает среду проекта, поэтому на старте смогла достаточно точно оценить проект в условных единицах.

Если какое-нибудь из условий нарушается, происходит то, что знакомо любому руководителю проектов – «поехали сроки».

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

Как прогнозировать сроки в Agile?

Здесь тоже есть несколько подходов.

Первый подход – с помощью диаграммы скорости команды

Об этом подходите часто рассказывает Алексей Пименов на тренинге Kanban System Design. Работает следующих образом. Берёте диаграмму скорости работы команды (рис. 3), берёте из нее самый худший статистический вариант (скорости работы за итерацию) и прогнозируете конечную точку завершения проекта по нему.

То есть при самых неблагоприятных условиях команда выполнит проект к такому-то времени. Потом можно взять некий средний, посчитать время завершения проекта при средней скорости. И далее взять самый лучший. То есть сойдутся звёзды, команда реализует этот проект или выпустит релиз за такое-то общее время.

И второй подход – с помощью статистики по завершенным проектам

Признаюсь честно, это мой самый любимый способ. Он не имеет никакого отношения к Agile и работает в любых сферах бизнеса.

Берем диаграмму распределения времени выполнения проектов размера L. Смотрим крайние точки, смотрим среднее значение и значение в медиане. Исходя из статистики называем вероятность завершения проекта за нужное время. Если нам нужно реализовать проект с вероятностью 100%, берем крайнее правое значение с графика.

Если таких жестких требований к реализации проекта точно в срок нет, можно взять вероятность поменьше. Например, 85% – довольно хорошая статистика по времени выполнения задачи.

Как сейчас «неправильно планируют» в Agile

Напоследок хочется рассказать, как неправильно планируют в Agile. Я неоднократно наблюдал данный алгоритм в разных компаниях.

Представьте себе планирование спринта. Скрам-мастер приходит на встречу с экселькой, в которой перечислен список элементов для оценки и планирования.

Идя сверху вниз по списку, скрам-мастер рассказывает, что нужно сделать в каждом элементе. Если на встрече присутствует Владелец продукта, он дает комментарии и отвечает на возникающие вопросы.

После того, как озвучены требования к элементу, начинается оценка. Скрам-мастер спрашивает у аналитика, сколько времени в часах ему потребуется на аналитику по рабочему элементу. Ответ в часах Скрам-мастер заносит в эксель в столбик «аналитика». Далее Скрам-мастер переходит с вопросом к разработчику, сколько времени ему потребуется на разработку этого элемента. Ответа в часах также вносится в эксель. В конце наступает очередь тестировщика. Его ответ в часах также заносится в эксель.

Одна из задач Скрам-мастера при таком подходе – утилизировать время команды. У него есть 60 человеко-часов от каждого участника команды (в двухнедельном спринте), которые он заполняет ответами с оценкой ребят.

Планирование завершается, когда заполнено все время.

Такой подход к планированию спринта еще называют спринт- тетрис-планированием. Как по мне – дикая дичь. Ни разу не видел на практике, чтобы такой подход приводил к результату в виде реализованной цели спринта. Зато всегда можно отчитаться, что все ребятам в команде заняты полезной работой на 100%.

Использовать такой подход к планированию или нет, решать вам.

Резюме: алгоритм планирования в Agile

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

1. Определяем, что планируем: проект, релиз, эпик/или фича.
2. Выбираем систему относительных оценок (я рекомендую стори-поинты).
3. Оцениваем объем предстоящей работы в стори поинтах (я рекомендую для декомпозиции использовать инструмент «Карта пользовательских историй» и делать это с командой).
4. Используем статистические данные скорости работы команды из диаграммы скорости (velocity chart), сколько стори поинтов команда делает за спринт.
5. На основании статистики даем прогнозируемый срок реализации проекта (переводим количество спринтов в календарные дни).
6. Приступаем к работе и используем диаграмму сгорания (Burndown chart) для контроля выполнения сроков.
7. Когда работа по проекту будет завершена на 85-90%, даем окончательный срок, который и должен стать дедлайном проекта.

Скачать алгоритм на флипчарте:

.

Послесловие

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

1. Вы хотите пообедать в офисе и делаете заказ через приложение в вашем любимом ресторане через дорогу. Ресторан принимает заказ. Вы примерно понимаете, как скоро вам привезут еду, но само приложение еще не называет точное время доставки.
2. Приложение ищет курьера. Вам еще не называют время доставки.
3. Приложение находит курьера и ресторан начинает готовить заказ. Вам еще не называют время доставки.
4. Курьер приходит в ресторан и ждет, когда ваш ланч будет готов. Вам всё еще не назвали точное время доставки.
5. Ресторан приготовил ваш ланч, упаковал и передал курьеру. И ровно в этот момент у вас в приложении появляется точное время доставки и запускается обратный отсчет по таймеру. Можно закрывать ноутбук, идти мыть руки и спускаться, встречать курьера. Теперь вы знаете точное время его прибытия.

Я хочу, чтобы вы подумали о таком подходе к планированию релиза или даты проекта.

В какой момент в вашем процессе вы сможете назвать точное время Заказчику? И стоит ли это делать слишком рано?

Удачи, друзья. До встречи в следующих статьях.