Опубликован: 24.02.2017 | Уровень: для всех | Доступ: платный
Лекция 6:

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

< Лекция 5 || Лекция 6: 123 || Лекция 7 >
Аннотация: Начальные этапы в разработке информационных систем считаются стадиями, определяющими успех создаваемого программного продукта. На их уровне устанавливают не только ключевые пожелания и основные высокоуровневые требования к результатам реализации продукта, но и целесообразность его создания и последующей эксплуатации, а также определяют необходимые ресурсы и сроки работ. Практическим итогом такой деятельности становится план или программа действий по реализации информационной системы. При использовании Scrum в качестве основной методологии при разработке программных продуктов необходимо четко представлять, что классические подходы планирования и работы с планом неэффективны, более того, губительны. Таким образом, обозначается необходимость в применении эффективных методик, на основе которых возможно оптимальное управление и сопровождение гибких процессов разработки информационных систем. В данной главе мы обсудим подобные техники и процесс их сопровождения, поговорим об атрибутах, на основе которых обсуждаемые методики могут быть внедрены в операционную деятельность Scrum-команд.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< Лекция 5 || Лекция 6: 123 || Лекция 7 >
Владислава Шевелкина
Владислава Шевелкина

Добрый день!
Предполагается ли выдача сертификата на английском языке?
В разделе сертификат только на русском.

Грета Березовская
Грета Березовская
Денис Бочаров
Денис Бочаров
Россия
Анна Небеснюк
Анна Небеснюк
Россия, Софрино-1, Майская средняя, 2012