Часть 3. Почему это возможно и даже необходимо
Рассмотрим случай создания составной части сложной технической военной или гражданской системы. Общий график, связанный с временем получения, с затратами и отслеживанием выполнения для целевой системы (самолет, вертолет, корабль или АЭС, к примеру) формируется в результате переговоров между Заказчиком и Генеральным подрядчиком. При этом между заказчиком и Генеральным подрядчиком могут возникать дополнительные бюрократические и финансовые прослойки, но это не меняет картины. Эти договоренности включают в себя последовательное выполнение этапов, периодическое подведение итогов между этапами и внутри этапов (контракт определяет график окончания этапов и промежуточных подведений итогов, «ворот качеств», рассмотрений и других отчетных моментов).
Ген. подрядчик выступает в качестве интегратора целевой системы, и зачастую либо не занимается проектированием, либо занимается этим на очень высоком уровне (разбиение целевой системы на составные части). Работы по созданию составных частей и Заказчик и Ген. подрядчик совершают титанические усилия для сведения воедино постоянно расползающихся графиков кооперации, иногда результатом очередных подведений итогов бывает отказ от одних поставщиков/исполнителей и замена их другими. Все это выполняется в рамках waterfall, с той неизбежной гибкостью и непредсказуемостью возникающих затрат, которую привносит жизнь. Это – планирование и контроль на макроуровне. Добавьте в него щепотку agile, и хаос (которого и так хватает) затопит всю программу.
Уровнем-двумя ниже, там, где заканчиваются интеграторы, и начинаются разработчики, планирование достигает микроуровня. Распределение работ доходит до уровня подразделений организации. Если же следовать канонам системной инженерии и проектного управления, то иерархическая декомпозиция работ продолжается до определения пакетов работ, внутри которых работы распределяются персонально.
На этом уровне применение agile-подходов может быть не только возможным, но и весьма продуктивным. Применение гибких подходов и автоматизация процессов может значительно компенсировать затраты времени, связанные с обязательным выполнением отдельных процессов системной инженерии и создание доказательных сведений, которых требуют отраслевые стандарты.
Что это будет за agile – OpenUP, SCRUM, kanban или их совмещение – определяется как опытом участников проекта, желанием улучшить эффективность и качество своей работы, так и особенностями уже имеющихся в организации нормативных документов. Из собственного опыта могу сообщить, что канбан-визуализация продвижения задач и ежедневные пятиминутные установочные совещания могут принести пользу независимо от того, agile или не agile.
Что касается ценностей agile, которые мы рассматривали в прошлой статье, то применительно к микроуровню их можно было бы переформулировать следующим образом:
Резюме: для критических систем на макроуровне, там, где идет планирование целевой системы и распределение работ над ее составными частями agile противопоказан. На микроуровне – agile может быть весьма полезен. Впрочем, дихотомия waterfall/agile остро проявилась на западе, где соблюдение методологии, процессов и инструкций является во многих организациях жестко проводимой политикой. Жесткая политика waterfall вызвала к жизни манифест agile. У нас же, в России – что греха таить, – на микроуровне в проектах и так уже наполовину agile, его только необходимо упорядочить и визуализировать.