План agile планирование

ТЕМА 5. ПЛАНИРОВАНИЕ ПРОЕКТОВ
Лекция 5.2. Agile планирование
ПЛАН

1. 
   Agile планирование
   
2. 
   Техника вычисления.
   
3. 
   Моделирование расходов COCOMO
   

Основные понятия: планирование, фокусировка, подходящий размер, планы на фактах, резерв, модель СОСОМО.

	Неопределенность неудобна, определенность - глупа. Китайская поговорка
	Занимайтесь планированием, а о планах забудьте. Мэри Поппендик
	Звезды могут лгать, а цифры - никогда. Мэри Чапин Карпентер

1. 
   Agile планирование
   

Чтобы уяснить суть agile-подхода к планированию, необходимо ясно понимать цель планирования.
Планы помогают нам понять, кого нужно привлечь к работам по проекту в течение определенного периода. Планы помогают нам понять, как продвигается создание функциональности, которая нужна пользователям и получения которой они ожидают. Без планов мы открываем ворота для целого ряда проблем.
Процесс планирования, однако, сложен, а планы нередко получаются далекими от реальности. Как результат, команды зачастую впадают в одну из двух крайностей: они либо полностью отказываются от планирования, либо тратят столько сил на составление планов, что начинают верить в их правильность. Команды, которые отказываются от планирования, не могут ответить на такие фундаментальные вопросы, как «Когда это должно быть выполнено?» и «Можем ли мы ожидать выпуск продукта в июне?». Команда, затратившая слишком много сил на планирование, обольщает себя уверенностью в том, что план в принципе может быть «правильным». Ее план может быть тщательно проработанным, но вовсе не обязательно отличаться высокой точностью или полезностью.
Если оценка и планирование настолько трудны и если точную оценку невозможно получить вплоть до последней фазы выполнения проекта, то зачем этим заниматься? Конечно, очевидной причиной является то, что в организациях, где мы работаем, от нас нередко требуют предоставления оценок. Планы и графики могут требоваться для таких вполне понятных целей, как планирование маркетинговых кампаний, планирование релизов продукта и обучение внутренних пользователей. Это очень важные потребности, и трудность оценки проекта не может служить основанием для отказа от составления плана или графика, который организация может использовать для их удовлетворения. Вместе с тем помимо этих номинальных потребностей существует значительно более фундаментальная причина не жалеть сил на оценку и планирование. Оценка и планирование — это не просто определение сроков или календарных графиков. Планирование, особенно непрерывное планирование итераций, — это поиск стоимости. Планирование представляет собой попытку найти оптимальное решение всеобъемлющего вопроса разработки продукта: что мы должны создать? Для ответа на этот вопрос команда анализирует функциональность, ресурсы и сроки. Ответ на данный вопрос нельзя найти одномоментно. Его ищут итерационно, шаг за шагом. В начале проекта мы, например, можем решить, что продукт должен иметь определенный набор функций, а его выпуск должен состояться 31 августа. Однако в июне оказывается, что лучше выпустить продукт немного позднее, но с более полным набором функций. А может наоборот: лучше сократить набор функций, но выпустить продукт чуть раньше. Хороший процесс планирования поддерживает такой подход, обеспечивая: сокращение риска; снижение неопределенности; создание условий для принятия более качественных решений; формирование доверия; распространение информации.
Планирование — это вид деятельности. Agile-подход предполагает перенос акцента с планов на процесс планирования. Agile-подход позволяет сбалансировать вкладываемые в планирование усилия и трудозатраты с учетом того, что план будет пересматриваться в процессе осуществления проекта.
При определении agile-подхода к планированию установлено, что он:

• 
  фокусируется на планировании, а не на плане;
  
• 
  поощряет изменения;
  
• 
  приводит к составлению планов, легко поддающихся изменению;
  
• 
  распределяет процесс планирования по всему сроку осуществление проекта.
  

Цель планирования — получение оптимального ответа на глобальный вопрос разработки продукта — вопрос о том, чтó именно создавать. Ответ включает в себя описание функций, ресурсов, а также календарный график.
Правила применения agile-подхода к оценке и планированию
С учетом сказанного выше я составил список из 12 правил успешного применения agile-подхода к оценке и планированию.
1. В осуществлении проекта должна участвовать вся команда. За конкретные виды деятельности может отвечать один или несколько человек. Например, определение требований к приоритизации является функцией главным образом владельца продукта. Вместе с тем для создания наиболее ценного продукта при реализации проекта необходимо участие всей команды. Это следует, например, из того, что оценка лучше всего удается команде в целом, хотя работать с оцениваемой историей или задачей будет лишь один или два члена команды. Чем больше ответственности берет на себя вся команда, тем более успешно она действует.
2. Планируйте на разных уровнях. Ошибочно думать, что план релиза делает план итерации ненужным, или наоборот. План релиза, план итерации и дневной план имеют разные временные горизонты и разные уровни точности. Каждый из них служит своей цели.
3. Разделяйте оценки размера и сроков, используя разные единицы. Проще всего разграничить оценку размера и оценку срока с помощью использования разных единиц измерения, которые нельзя спутать. Оценка размера в пунктах и превращение размера в сроки с помощью скорости — отличный способ добиться этого.
4. Выражайте неопределенность при представлении либо функциональности, либо даты. Ни один план не является полностью определенным. Обязательно включайте выражение неопределенности в составляемые планы релизов. Если объем новой функциональности зафиксирован, представляйте неопределенность в виде диапазона дат («Мы завершим работу в третьем квартале» или «Мы завершим работу через 7–10 итераций»). Если зафиксирована дата, представляйте неопределенность через набор поставляемых функций («Мы завершим работу 31 декабря, и продукт будет содержать по меньшей мере вот эти функции, но, возможно, не более, чем те новые функции»). Используйте более крупные единицы (итерации, месяцы, кварталы, например) по мере роста неопределенности.
5. Часто пересматривайте планы. Перед началом каждой итерации не упускайте возможность оценить релевантность текущего плана релиза. Если план релиза строится на основе устаревшей информации или на допущениях, которые стали некорректными, обновите его. Пользуйтесь любыми возможностями пересмотретьпланы с тем, чтобы проект всегда был нацелен на создание наибольшей стоимости для организации.
6. Отслеживайте прогресс и информируйте о нем. Многие люди, имеющие отношение к проекту, крайне заинтересованы в получении информации о прогрессе. Обеспечьте их регулярное информирование путем публикации простых и понятных индикаторов прогресса команды. Для этой цели очень хорошо подходят диаграммы выгорания и прочие наглядные индикаторы прогресса в проекте.
7. Признавайте важность обучения. Поскольку проект во многом связан с генерированием новых знаний о добавлении возможностей в продукт, планы необходимо обновлять с учетом этих новых знаний. По мере того как мы узнаем больше о потребностях наших клиентов, мы добавляем в проект новые функции. По мере приобретения знаний об используемых технологиях и о своей работе в команде мы корректируем ожидания в отношении темпов прогресса и желаемого подхода.
8. Планируйте функции подходящего размера. Функции, которые будут добавлены в ближайшем будущем (в течение следующих нескольких итераций), необходимо разбивать на относительно небольшие пользовательские истории — обычно такие, реализация которых занимает один-два дня, в любом случае не более 10 дней. Мы лучше всего оцениваем работу, имеющую размеры одного порядка. Работа с пользовательскими историями в таком диапазоне размеров обеспечивает наилучшее сочетание затрат и точности. Подобный подход также приводит к получению сравнительно небольших историй, которые большинство команд могут реализовать за одну итерацию. Конечно, работа с небольшими пользовательскими историями может оказаться довольно сложной в условиях длительного проекта. Во избежание этого, если вы создаете план релиза, рассчитанный более чем на два-три месяца, либо напишите несколько крупных историй (которые называют эпопеями), либо оценивайте более отдаленную работу на уровне темы, чтобы не пришлось разбивать крупные истории на части задолго до того, как это потребуется.
9. Приоритизируйте функции. Работайте с функциями в таком порядке, который оптимизирует суммарную стоимость проекта. В дополнение к стоимости и себестоимости функций учитывайте при приоритизации обучение, происходящее в процессе работы, и снижение риска в ходе разработки функции. Если разработка конкретной функции на раннем этапе позволяет команде значительно углубить знания о продукте или об усилиях, необходимых для его создания, к ее реализации следует приступить как можно раньше.
10. Стройте оценки и планы на фактах. Когда возможно, стройте оценки и планы на реальной основе. Конечно, бывает, что в некоторых организациях приходится оценивать показатели вроде скорости, опираясь на очень узкую базу. В главе 16 «Оценка скорости» на этот случай представлены подходящие методики. Вместе с тем, когда возможно, оценки и планы должны строиться на реальных, наблюдаемых величинах. Это относится также и к оценке того, сколько функций реализовано. Несложно увидеть, что функция выполнена на 0% (в момент, когда с нею только начинают работать), и довольно легко определить, когда она выполнена на 100% (пройдены все тесты для всех условий удовлетворенности владельца продукта). Однако в промежутке между этими состояниями очень трудно сказать, на сколько реализована функция — на 50% или на 60%. Как результат, придерживайтесь того, что вам известно: 0% и 100%.
11. Оставляйте небольшой резерв. Особенно при планировании итерации не пытайтесь задействовать 100% времени каждого члена команды. Точно так же, как на шоссе возникает пробка при его загрузке на 100%, команда разработчиков начинает работать медленнее, когда время каждого члена команды полностью заполнено.
12. Координируйте работу команд с помощью опережающего планирования. В проекте с участием нескольких команд координируйте их работу, используя скользящее опережающее планирование. Заглядывая вперед и распределяя конкретные функции между конкретными итерациями, можно строить планы с учетом взаимозависимостей команд.