В шапке
Совместить несовместимое:  сетевой график и планирование спринтов

Совместить несовместимое: сетевой график и планирование спринтов

Сетевые диаграммы используются в управлении проектами очень давно. Если верить статьям и книгам, то впервые сетевые диаграммы в бизнесе начали использовать в корпорации «Дюпон»  в 1956 г. для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы. Первоначально подход для расчета сроков проекта был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути  (Critical Path Method).

Чуть позже в США стартовал проект разработки ракетной системы «Поларис», начатый в 1957 году. Реализация проекта, объединявшего около 3800 основных подрядчиков и состоявшего из 60 тысяч задач, была поручена Главному управлению вооружений ВМС США. В целях управления реализацией этого проекта корпорацией «Локхид» и консалтинговой фирмой «Буз, Аллен энд Гамильтон» был создан специальный метод планирования работ на основании оптимальной логической схемы процесса, названный методом анализа и оценки программ PERT (Program Evaluation and Review Technique). Использование метода PERT позволило руководству программы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также вероятность своевременного завершения отдельных операций. Проект оказался успешным и метод PERT начали использовать в других проектах ВМС США.

С тех пор методы сетевого планирования начали использовать и в управлении промышленными проектами, например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1967 по 1976 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1974 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат.

Адепты Agile, а в частности, фреймворка Scrum, обычно не используют сетевые диаграммы при управлении проектом.  В Scrum используется другая техника планирования сроков проекта, которая предполагает управление приоритетами требований (историй)  и отбор самых приоритетных требований в следующий спринт. Зная скорость команды и плановые оценки сложности оставшихся в проекте требований, команда проекта может делать прогноз относительно того, какие требования будут закончены к дедалайну или сколько спринтов еще понадобится для того, чтобы реализовать все оставшиеся требования. При этом никакие сетевые графики не требуются.

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

Управляя проектами, я заметил, что зачастую заказчик проекта хочет видеть старую добрую диаграмму Ганта в качестве расписания проекта, при этом команда Исполнителя хочет работать итерациями (или спринтами) и планировать список требований на следующий спринт.

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

Замечу, что диаграмма Ганта легко строится на базе сетевого графика и является одним из способов представления (визуализации) сетевого графика.

Давайте разберемся, с какими сложностями столкнется команда проекта, решившая использовать для планирования проекта два подхода: сетевой график для верхнего уровня плана и планирование спринтов для планов на неделю (на две, три недели):

  • Задачи верхнего уровня плана, представленные в виде сетевого графика, могут иметь продолжительность свыше продолжительности одного спринта. Что в этом случае делать?
  • Задачи сетевого графика могут иметь плановые даты старта, не совпадающие с датами старта спринта или плановые даты финиша, не совпадающие с плановыми датами завершения спринта.
  • Закрывать акты по проекту с Заказчиком нужно по согласованному верхнеуровневому сетевому графику, а работать мы будем по спринтам. Как не запутаться с отслеживанием прогресса задач в сетевом графике?

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

Однако, если вдуматься, никакой особой сложности нет, т.к.  при создании верхнеуровнего плана работ по проекту команда проекта может взять за основу  создания иерархической структуры работ проекта результаты (продукты) проекта, а затем декомпозировать их на фичи (функции продукта) на втором уровне ИСР, после чего на третьем уровне детализировать фичи на требования пользователей и т.д. Таким образом, верхнеуровневый план проекта будет основан на продуктах проекта и пользовательских историях, а план спринтов будет состоять из задач, которые необходимо реализовать для получения ожидаемых результатов от реализации пользовательских историй.

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

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

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

Мой опыт использования симбиоза водопадной модели ЖЦ проекта вместе с ее диаграммами Ганта и сетевыми графиками и итерационной модели  со спринтами  показал, что сетевой график остается полезен скорее для Заказчика проекта, которому легче спится, когда он видит прогресс проекта на диаграмме Ганта. А команда начинает все же жить спринтами, изредка подглядывая в диаграмму Ганта, чтобы увидеть там незаконченные элементы работ.

А что если сетевую диаграмму использовать не только для верхнеуровнего плана , но и внутри спринтов? Ведь часто и внутри спринта есть задачи, старт которых зависит от финиша других задач.

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

Итак, сделаем выводы:

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

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

Комментарии (0)
Войти как