Эволюция проектного расписания
| July 27, 2012 | Posted by admin under Практики, Статьи |
Автор: Mike Cottmeyer
http://www.leadingagile.com/2008/11/evolution-of-a-project-schedule/
Перед тем как начать, я хочу кое-что объяснить. Я использовал MS Project для создания серии иллюстраций, которые описывают, как традиционный проектный график может эволюционировать в agile проектный график. Давайте внесем ясность: я не рекомендую вам использовать MS Project для управления agile проектами. Я не хочу, чтобы кто-то говорил, что один agile-ист рекомендует MS Project для agile проектов. Это не тот случай.
Причина, по которой я выбрал MS Project, – большинство менеджеров проектов понимают язык диаграммы Ганта. Когда agile сообщество объясняет agile классическим менеджерам, нужно начинать с тех инструментов, которые люди понимают. Не то, чтобы невозможно управлять agile проектом, используя MS Project, просто парадигма, лежащая в основе диаграммы Ганта, здесь не работает. Этот инструмент не был разработан для взаимодействия.
Классический план водопада
Многие менеджеры проектов начинают с этого уровня понимания плана разработки ПО. В этом есть смысл… Вы понимаете, что вы собираетесь построить … Вы решаете, как вы будете это строить… Вы делаете это… Вы тестируете это… Вы видите, понравилось ли это заказчик… И если это так, вы устанавливаете это. Просто, да?
Я управлял проектами этим способом, и успешно. Чтобы добиться успеха в таких проектах, должна быть высокая степень определенности, знание о том, что же нужно построить. Изменения не дружат с проектом типа водопад. Также требуется стабильность проектной команды. Люди не должны приходить и уходить из проекта, их не должны переводить на другие работы.
Обычно это значит, что вашему проекту нужно находиться среди наивысших приоритетов организации.
Часто реальность такова, что требования меняются и люди работают над другими проектами. Из-за этого проекты отстают от графика и становятся непредсказуемыми. Еще более тревожно то, что мы узнаем об отставании от графика и превышении бюджета слишком поздно, когда сделать уже ничего нельзя. Нам нужно двигаться предсказуемо, делать более короткие циклы поставки, и поставлять продукт на рынок быстрее. Нам нужно изменить то, как мы думаем о поставке, и изменить подход к управлению проектами.
Первый шаг в эволюции плана проекта-водопада – разбить проект на более короткие фазы.
Пофазовая поставка
Этот подход разработан, чтобы сделать наши проекты меньше и быстрее поставлять продукт на рынок. Меньше – почти всегда лучше, но пофазовый план страдает от тех же самых проблем, что и план-водопад. Для того, чтобы этот подход работал, вам все же нужны стабильные требования и очень предсказуемая проектная команда. Этот подход не решает проблему полностью, но хотя бы помогает вам осознать ее быстрее.
Одна из ключевых трудностей с пофазовым подходом, так же как и с классическим водопадом, заключается в том, что люди на чем-то специализируются, и эта специализация не требуется на все 100% в течение жизни проекта. Это приводит к матричным проектным командам и матричному управлению. Когда люди начинают работать в других проектах и задерживаются там надолго, бывает трудно вернуть их в ваш проект обратно в нужный момент.
Для решения проблем с пофазовым подходом нужно не только делать короткие циклы поставки, нужно, чтобы люди оставались в проекте надолго.
Перекрытие проектных фаз
Вот где появляется подход с перекрытием проектных фаз. Умный менеджер старается уменьшить время простоя в проекте и сделать так, чтобы активности перекрывались по времени. Это хороший шаг, это удерживает людей в проекте, они остаются заняты, и их менее вероятно переключат на другие инициативы.
Из иллюстрации также видно, что такое перекрытие фаз может иметь серьезное влияние на временные рамки проекта. Обычно это позволяет выполнить работы раньше. Этот подход – шаг в верном направлении (с точки зрения использования ресурсов), но он не решает проблему с хрупкими проектными планами, плохо приспособленными к изменениям.
Сокращение фаз, итерации
Следующий шаг – это эволюция модели проектного планирования, но это не решает никакие фундаментальные проблемы с расписанием. Это позволяет нам больше сфокусироваться на поставке, и получить новые знания из поставки работающего ПО. Если более короткие фазы это хорошо, и перекрытие ускоряет работу, то стоит активно воспользоваться этим.
Так мы приходим к итеративной и инкрементальной разработке. Когда я как менеджер проекта столкнулся с этим, то понял итеративную и инкрементальную поставку как серию коротких и перекрывающихся проектов-водопадов. Я должен был управлять перекрытием и быть уверенным, что люди понимают, над чем мы работаем, и когда они должны быть доступны.
Даже несмотря на такое сложное планирование, улучшения с использованием ресурсов и сокращение времени выполнения проекта в целом, мы понимали, что проекты серьезно страдают при изменениях требований, и это выбивает нас из первоначальных планов. Нам удалось решить некоторые проблемы с ресурсами и приоритетами, но в процессе этого возникла сеть взаимозависимостей, которая только усложняет нашу реакцию на изменения. В каком-то смысле наши проектные расписания стали еще более хрупкими, чем раньше.
Делаем итерации кроссфункциональными
Итеративная и инкрементальная разработка не должна быть серией перекрывающихся водопадов. Задача итераций – задействовать навыки всех членов команды на пути к достижению общей цели итерации. У каждой итерации есть цель и набор функциональности, которую нужно поставить. Когда все сконцентрированы на поставке общего результата, мы способны справиться с изменениями внутри итерации … никто не уходит на другие проекты … не надо никого возвращать обратно.
Все зависимости находятся внутри и каскадные эффекты можно свести к минимуму.
Временные рамки итераций фиксированы и не перекрываются. Команда работает над функциональностью, запланированной на итерацию, и все вместе делают ревью результатов итерации. Это возможность поучиться на ошибках и предпринять корректирующие шаги перед следующей итерацией. Если проект сталкивается с изменениями, они планируются на следующую итерацию, и влияние этих изменений идет каскадом вниз по проекту.
Большинство команд, начинающих использовать agile, обычно находятся на этом уровне зрелости. Они уже используют итеративную и инкрементальную разработку, но не ввели некоторые другие организационные изменения, необходимые для того, чтобы это работало. На этом шаге мы еще не решили проблему с «вытаскиванием» людей из проекта. У нас остался риск соревнующихся приоритетов… мы не можем работать сплоченной командой.
Этот подход не слишком гибкий. Нам все равно необходимо делать серьезный предварительный дизайн, проводить традиционное управление изменениями, и стараться предвидеть ситуацию заранее. Мы признаем, что это шаг в верном направлении, но это еще не agile.
Намного более короткие итерации и фокус на ценности
Для перехода от итеративного и инкрементального к чему-то, что уже выглядит как agile, вам нужно еще сильнее сократить циклы разработки и создать кроссфункциональные команды, которые на 100% задействованы в ваших проектах.
Сокращая циклы разработки, менеджер проекта может меньше фокусироваться на том, как происходит разработка, и больше на том, что нужно поставить и насколько быстро. Команда становится более ответственной за достижение целей поставки, и у нее появляется больше возможностей решать, что делать и когда. Команда может принимать решения о том, как лучше использовать свое время для достижения целей итерации. У менеджера проекта появляются реальные эмпирические данные о том, как продвигается проект, исходя из работающего ПО.
Когда люди на 100% задействованы в проекте, менеджеру нужно меньше фокусироваться на последовательности действий, это можно делегировать команде. Это позволяет команде проявлять больше творчества в решении проблем. Теперь их ответственностью является не выполнение задач, а поставка ценности и достижение поставленных целей. Менеджеры проектов больше фокусируются на отслеживании потока ценности, удалении препятствий с пути, коммуникациях и взаимодействию с организацией.
На этом уровне зрелости, менеджеры проектов все еще мыслят с точки зрения предвидения. Они стараются предсказать поток ценности и запланировать все итерации заранее, и идут к модели планирования, концентрирующейся на ценности, а не к модели планирования, базирующейся на активностях.
Agile проектный план
Расписание agile проекта – это просто последовательность проектных релизов и итераций. Оно показывает основу того, как команда решила организовать поставку продукта. Фичи размещены в баклоге и запланированы итерация за итерацией, базируясь на том, что мы узнали о развивающемся продукте. Менеджеры проектов измеряют поток поставки фич, итерация за итерацией, чтобы отчитываться о том, как продвигается работа команды.
Если возникает изменение, оно добавляется в баклог, как и любая другая фича. Команда тесно взаимодействует с людьми из бизнеса, и делает переприоритезацию фич. Мы фокусируемся на поставке работающего ПО на очень коротких циклах, и бизнес принимает решение о том, когда продукт должен выйти на рынок.
Бесстыдная реклама VersionOne…
С чисто структурной точки зрения, инструмент вроде MS Project можно использовать для управления agile проектом. Когда команды пытаются делать это, они обычно находятся на этапе предшествующем полномасштабному использованию agile. Они все еще стараются предвидеть порядок разработки фич, вместо того, чтобы управлять потоком ценности в тесном сотрудничестве с бизнесом.
Agile инструмент управления проектом типа VersionOne Enterprise больше концентрируется на создании пространства для взаимодействия команды, планировании коротких циклов, измерении и оценке прогресса. Agile инструменты мало уделяют внимания предварительному планированию, они больше фокусируются на коммуникациях внутри команды и между командой и бизнесом.
В заключение
Часто довольно сложно объяснять agile классическим менеджерам проектов. Вы можете пройтись по ключевым идеям, но временами вы видите пустые взгляды и «стеклянные» глаза. Они умные люди, не то, чтобы они не понимают ваши слова… они пытаются изменить свое мышление. Им не очень ясно, почему то, что они всегда делали, не всегда применимо.
Надеюсь, эта статья поможет вам понять, как и почему быстро меняющиеся проекты отличаются от традиционных, и почему ими нельзя управлять с помощью традиционных подходов. И не думайте об agile, как о некоторой замене того, что вы уже знаете, это дополнение, добавление новых инструментов к вашему набору, чтобы помочь вам справиться перед лицом неопределенности.
-
My
