Применявшийся ранее водопадный поход (метод планирования Waterfall), в конечном счете, не оправдал себя и безнадежно устарел.
Причина в том, что в таком проекте разрабатывалась на столько подробная документация на весь программный продукт целиком, чтобы можно было досконально и точно спланировать проект его выпуска. Но к сожалению, на момент написания полной спецификации к продукту, куда ушло колоссальное количество энергии и времени, требования к продукту уже успевали стать неактуальными и устареть.
Гибкое планирование - это современный подход, который помогает командам разрабатывать продукт, максимально удовлетворяющий требованиям заказчика, и обладающий максимально полезными функциями, вовремя и в рамках бюджета.
Основу этого подхода составляют:
· журнал пользовательских пожеланий, он же бэклог пользовательских историй,
· приоритеты пользовательских историй,
· гибкая оценка - баллы (story points),
· скорость команды - velocity,
· итерации разработки - спринты.
Backlog
Прежде чем составить план гибкого проекта, нужно перечислить все функции, которые заказчик хочет видеть в готовом продукте.
Для этого предназначен семинар по сбору пользовательских истории (story-gathering workshop). На таком мероприятии нужно перечислить как можно больше функций. Не обязательно все из них надо будет реализовывать. Все это количество функций нужно, чтобы можно было охватить общий объем, с которым предстоит работать.
Его можно провести в таком формате: усевшись рядом с заказчиком, вы говорите о новом проекте, рисуете несколько картинок, схем и, по ходу беседы, записываете истории на карточки.
Не лишне будет также перечислить то, что не будет реализовано. Этот список явно показывает, что не войдет в проект.
Когда список будет готов, поищите элементы, которые случайно оказались продублированы, посмотрите, чего не достает и добавьте это, сгруппируйте логически близкие истории. Backlog готов.
Приоритеты
Далее заказчик расставляет приоритеты для отдельных историй.
Если клиент расставит в бэклоге приоритеты в соответствии с нуждами своего бизнеса, это гарантирует, что деньги будут вложены максимально выгодным образом.
Хотя последнее слово по поводу того, что и когда будет создаваться, остаётся за клиентом, команда должна выдвигать предложения относительно функций, которые следует реализовать в первую очередь, чтобы архитектура программы получилась более надежной. Хорошие кандидаты на раннюю разработку – истории, позволяющие испытать архитектуру.
Список пользовательских историй, отсортированных по приоритетам - это основа плана проекта.
Гибкая оценка
Научные исследования свидетельствуют о том, что относительная оценка удается любому представителю человеческого вида достаточно хорошо.
Если мы кладем рядом 2 камушка, то с достаточно большой точностью можем угадать, на сколько один камень больше другого.
Чтобы не работать с такими измерениями, как 1,3333 день или 2,1 дня, рекомендуется использовать для оценки бальную систему и не соотносить оценки с обычными календарными сроками.
При работе с бальной системой единицы измерения не имеют значения. Все что необходимо, так это выразить величину задачи в числовом виде относительно других задач.
Для оценки историй в баллах есть 2 метода:
· Триангуляция
· Покер-планирование
Триангуляция – это метод при котором берется несколько ориентировочных историй: маленькая, средняя большая, им назначаются баллы: например, 1,3 5, а остальные истории измеряют по ним, как по эталону.
Покер-планирование – это игра, в ходе которой члены команды сначала оцениваю истории индивидуально (в баллах), а затем сравнивают получившиеся результаты с результатами коллег. Если возникают различия, то команда обсуждает их, и когда приходит к общему мнению, выносит окончательную оценку.
Скорость работы команды
Скорость, с которой пользовательские истории преобразуются в готовую функциональность называется скоростью работы команды (team velocity).
Скорость работы команды = бальная оценка выполненных историй / Итерация.
В начале проекта, несколько спринтов, скорость команды может колебаться, но через 3-4 итерации скорость, как правило выравнивается.
Итерации разработки - спринты
В Agile рабочий процесс делится на спринты — это равные отрезки времени, в течение которых команда создает и совершенствует отдельную часть продукта.
Каждый спринт построен одинаково. В начале команда планирует задачи и проводит оценку предстоящей работы, и только после этого приступает к работе.
Обычно спринт длится от одной до трех недель. Такое деление на короткие отрезки сохраняет гибкость в процессах — команда всегда готова к изменениям условий и не слишком погружается в глобальную доработку. Еще соблюдение сроков спринта организует рабочий процесс, задает ритм и помогает разработчикам распределять время.
По итогам спринта должен получится или мини-продукт или отдельная часть системы, которая содержит самостоятельную функциональность, готовую к использованию.
Четыре вещи, которые необходимо сделать в ходе любой итерации:
- убедитесь, что подготовлена работа на следующую итерацию - проведено собрание по планированию историй.
- получена реакция на истории, выполненные в последней итерации - проведена демонстрация и презентация новой функциональности заказчику.
- проведите планирование следующей итерации
- ищите способ оптимизировать работу - мини-ретроспектива.
Прогноз плана проекта
Чтобы приближенно спрогнозировать сроки, в которые продукт будет готов, нужно взять общий объем работы по данному проекту, поделить его на предполагаемую скорость команды. Получается количество итераций, которые должны произойти до завершения проекта.
Например:
Количество итераций = 100 баллов/ 10 баллов в итерацию = 10 итераций
Очень важно понимать, что составленный план проекта - это не непреложное обещание, а прогноз. В начале проекта не известна скорость работы команды Уточнить ее можно лишь тогда, когда мы закончим работу над одним из компонентов и узнаем, сколько на него потребовалось времени.
Есть 2 способа примерно спланировать сроки работы:
· выполнять проект к определенному сроку (by date)
· до реализации основного набора функций (by feature set)
При выполнении к определенному сроку, когда обнаруживаются новые важные пользовательские истории, то более ранние, не менее объемные, но менее важные отбрасываются. Поэтому мы вынуждены принимать жесткие решения о компромиссах заранее (компромиссы буду касаться функциональности), но достаточно категорично даем понять, что дело не требует отлагательств.
Преимущество реализации до определенного набора функций заключается в том, что уже в самом начале проекта вы знаете, что именно нужно сделать обязательно, и можете оценить риски, связанные со сроками выполнения. Ваши клиенты и спонсоры определяют, приемлем ли для них этот риск.
Оригинал статьи размещен в VK по ссылке.