Опубликован: 24.02.2017 | Доступ: свободный | Студентов: 1015 / 150 | Длительность: 10:06:00
Лекция 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 >
Александр Борисенко
Александр Борисенко

Мне кажется, или курс сыроват. При прочтении обнаруживается ощущения размытости, неточностей и прочего в том же роде. Например - "ЦФО - центр финансовых затрат" в пункте 2.4. Это как понимать? "О" - это расшифровывается как "затрат"? Как-то довольно много воды. Кстати, почему нет ссылок на глоссарий? Только сейчас обратил внимание, что он есть. Поначалу очень удивился почему столько английских терминов без расшифровки

Анна Жарикова
Анна Жарикова
Россия, Калуга, МГТУ им. Н.Э.Баумана, 2012