Записаться

6.1. Принцип быстрого планирования

Планирование, вопреки всеобщему убеждению, - это фундаментальный аспект деятельности Scrum-команд.

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

Таким образом, при работе по Scrum появляется необходимость в планировании и реализации только наиболее значимых для бизнеса и владельца продукта функциональностей информационной системы. В ответ на это Scrum-команда должна не просто стремиться разработать вовремя рамки обозначенного инкремента, а взять на себя обязательство следовать намеченным планам внедрения. А это значит, что Scrum-команда должна стремиться работать над реализацией функциональных возможностей, имеющих наивысшую ценность. Команда и владелец продукта должны оценивать стоимость разработки той или иной функциональной возможности. В противном случае приоритизация работ осуществляется по субъективному критерию желательности. Также важно оценить продолжительность разработки той или иной функциональности в желаемом виде. Функциональность, которая не попадает в критичное "рыночное окно", будет обладать гораздо меньшей ценностью. Scrum-команда, достигшая состояния самоорганизованности, взявшая на себя обязательство работать в порядке приоритетности, должна соблюдать важность планирования. При этом команда получит достаточное количество информации для спокойной и продуктивной работы в течение одного или нескольких спринтов, а владелец продукта будет четко понимать, что и как реализует команда.

В итоге планирования должны быть известны:

• цель спринта;
• участники команды и степень их занятости;
• набор задач на текущий спринт;
• дата демонстрации полученных результатов.

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

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

Такой подход к планированию называется планированием методом "набегающей волны".

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

6.2. Поэтапное уточнение планов

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

Внедрение этой деятельности в этап планирования позволит:

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

Эта деятельность прекрасно сочетается с техникой планирования методом набегающей волны и в литературе называется поэтапным уточнением ранее намеченных планов. Суть метода состоит в том, что при итерационной работе возникает множество непредвиденных факторов различной природы возникновения, которыми необходимо управлять и обрабатывать для достижения намеченных результатов. Для этого команде необходимо "нащупать" общий ритм и следовать ему. Следование общему ритму работы поможет гарантировать устойчивую скорость работы, в которую закладываются временные интервалы на устранение внезапно возникающих проблем операционного характера, связанных с устранением неопределенностей. Но для того чтобы найти свой ритм, команда должна соблюдать следующие принципы:

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

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

• оставить дополнительный потенциал команды на форс-мажоры;
• высвободить часть ресурсов команды для творческого развития продукта;
• экспериментировать с производительностью и составом команды;
• постепенно выйти на новый уровень производительности с последующим повторением цикла стабилизации процесса.

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

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

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

Прогнозирование производительности труда на предстоящий период производится на основе:

• оцененного объема работ для реализации требуемого функционала;
• сравнения результатов работ по статистике подобных разработок, проведенных с использованием наиболее эффективных инженерных техник и методик;
• экспертной оценки реализации данной наиболее авторитетными членами команды разработки.

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

6.3. Техника Planning Poker

Если сказать наиболее просто, то Planning Poker (PP) - это коллективное обсуждение задачи или проблемы с целью выработки единой оценки по ее решению. Это вид техники оценки, который основан на достижении договоренности между всеми участниками команды, участвующими в процессе планирования. Он используется для оценки сложности предстоящей работы.

Методика PP имеет явные преимущества в сравнении со стандартными обсуждениями проблем, применяемыми в классических подходах к разработке программного обеспечения, которые сводились к следующим активностям:

• Инициатор обсуждения (руководитель / аналитик / team lead) собирал команду, состоящую из экспертов или людей, знакомых с объектом обсуждения.
• Проблема озвучивалась, начиналось активное обсуждение.
• Искалось разовое решение, которое должно было устраивать всех причастных к этой проблеме на протяжении всего периода разработки/эксплуатации программного продукта.

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

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

Для нивелирования указанных недостатков была разработана обозначенная методика PP. Суть подхода состоит в том, что оценка задач выполняется не в виде часов или альтернативных шкал, представляющих трудозатраты, а в виде сравнительной оценки, которая показывает относительный "размер" требований. Можно встретить Scrum-команды, которые оценивают работы в виде "пунктов", "попугаев", "маек", "грибов" и т. д. Важны относительные значения, и не может быть абсолютного эталона. Единицы измерения не имеют физического эквивалента.

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

Вот тут и придет на помощь статистика результатов, которые команда достигала за последние несколько спринтов. Каждую выполненную задачу нужно идентифицировать, с тем чтобы каждый член команды понял, о чем идет речь. После этого необходимо выполнять сравнение запросов между собой для оценки их актуального размера. Затем задачи выкладываются в ряд по возрастанию достигнутых оценок по каждой задаче, и напротив каждой кладется соответствующая карта с оценкой. Теперь нужно сгруппировать требования вокруг чисел. Описанное мероприятие является действенным способом достижения общего понимания трудоемкости выполняемых задач. Его можно проводить периодически, когда команда "буксует" с выполнением оценки задач на PP.

Planning Poker обладает значимыми преимуществами по сравнению с аналогичными техниками планирования. К ним стоит отнести следующие:

• В планировании участвует вся команда.
• У каждого члена команды есть возможность высказаться, не испытав влияния более авторитетных коллег.
• Все члены команды берут на себя ответственность за сроки.
• Оценки, полученные PP, более точные в сравнении с оценками, полученными с помощью альтернативных методов оценок.

Правила, которым подчинена техника Planning Poker, достаточно просто запоминаются и легки в применении:

• Scrum-мастер не участвует, а только ведет общее собрание.
• Владелец продукта представляет краткие обзоры каждой из задач.
• Члены команды задают вопросы и ведут дискуссию о предложениях и рисках.

• Итог обсуждения записывается Scrum-мастером.

  

  Рис. 6.1. Атрибуты техники Planning Poker

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

Критичные для проведения процесса замечания:

• Не рекомендуется использовать числа больше 13 или 20.
• Не верьте в то, что бывает работа, не требующая никаких усилий.

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

Это будет наиболее эффективным способом оценки задач и старта активности PP, даже если потом окажется, что в начальном расчете были допущены незначительные ошибки.

Несмотря на то что практика Planning Poker все чаще входит в жизнь большинства современных Scrum-команд, этого оказывается недостаточно, чтобы команды научились делать оценки легко и быстро. Иногда, если людям дать только колоду карт со стандартными инструкциями, этого оказывается мало, и со временем команда перестает использовать этот механизм оценки. Роль и значимость Scrum-мастера для этого конкретного мероприятия, так же как и для большинства мероприятий, проводимых в Scrum, сложно переоценить.

6.4. Диаграмма сгорания работ

Один из самых важных артефактов, которые использует Scrum-команда для контроля за запланированными показателями выполнения работ в течение спринта, - диаграмма сгорания работ (Burndown Chart) (рис. 6.2).

Рис. 6.2. Диаграмма сгорания работ

Эта диаграмма показывает, сколько задач осталось до завершения запланированного периода времени на выполнение работ (спринта):

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

Цель каждой Scrum-команды - "сжечь" все взятые в спринт задачи до того, как приблизится конец намеченного срока. Если фактическая кривая отличается от идеальной, то по ситуации необходимо корректировать действия команды.

Оперативный анализ процесса сгорания задач должен проводиться по количеству оставшихся "пунктов" путем сравнения реального графика с идеальным:

• Если реальный график выше идеального - значит, команда отстает от плана.
• Если реальный график ниже идеального - команда опережает план.

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

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

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

Об отставании необходимо максимально оперативно сообщить владельцу продукта. Если команда сама не сможет выработать пути исправления ситуации, нужно, чтобы владелец продукта уменьшил объем спринта за счет задач пользователя с минимальным приоритетом.

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

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

• Диаграмма должна обновляться каждый день, по факту сделанной работы. В простой форме должна постоянно демонстрироваться динамика выполнения работ в спринте.
• График должен быть общедоступен. Любой член команды или заинтересованное лицо должны иметь к нему доступ.
• Любой член команды может сделать предложение по поводу оптимизации выполнения задач. Любой член команды может сделать предложение, которое не должно быть отвергнуто "просто так". Любое предложение воспринимается командой и обсуждается при первой возможности. Только команда в целом может принять конечное решение по каждому конкретному предложению.

6.5. Краткие выводы

В данной главе был подробно рассмотрен наиболее значимый и критичный для управления ожиданиями пользователей этап планирования процесса разработки программного обеспечения. Мы уделили внимание методам и профильным техникам планирования для работы с гибкими процессами. В частности, рассмотрели планирование методом "набегающей волны" и последующее поэтапное уточнение планов. Применение этих методик в Scrum позволит выстроить работу, начиная с "правильной" работы с менеджментом, на предмет однозначного понимания объема необходимых ресурсов для достижения поставленных результатов и заканчивая техниками оценки трудоемкости задач, к примеру, техникой Planning Poker.

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

В "Этапы и мероприятия Scrum" мы более подробно поговорим о контрольных мероприятиях, используемых в Scrum для управления процессом разработки программного обеспечения.