Гибридное управление проектами: Лучшее из Agile и традиционных методов

Немного найдется слов, более подходящих для описания ИТ, чем "быстро". Руководители проектов и разработчики пишут код с бешеной скоростью, стараясь выпустить свой продукт как можно быстрее. Это настолько укоренилось в нашей культуре, что мы даже имеем понятия о последствиях поспешной разработки.

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

Agile-команды: Вакцина или пластырь?

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

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

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

В обоих случаях основной проблемой является жесткость. В рамках этой парадигмы структура важна для процесса разработки, но она может и сковывать его. Линейные модели работали в 70-е годы, потому что рынки тогда были более медленными (приходилось буквально ездить в офис клиента с кассетами или дискетами в руках).

Скорость XXI века, напротив, требует иного, поэтому многие разработчики перешли на парадигму agile-команд, т.е. небольшой группы очень независимых людей с достаточным набором навыков и скелетной структурой плюс итеративный процесс разработки.

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

Клиенты более активно участвуют в agile-разработке, постоянно тестируя программное обеспечение и давая обратную связь по мере опробования различных сборок. В некотором смысле они являются активными участниками процесса. Это происходит в том случае, если у клиента есть время для работы бок о бок с agile-командой.

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

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

Гибридные команды - третий путь

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

Давайте сделаем краткий обзор ролей:

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

Процесс разработки происходит примерно так:

1. Анализ: Менеджер проекта проводит опрос клиента и формирует список требований к проекту.
2. План: PM собирается вместе с командой и создает WBS с примерным графиком проекта. На этом этапе происходит официальное назначение первого скрам-мастера.
3. Проектирование: Начинается фаза проектирования, в ходе которой планируется первая спринтерская сессия, закладываются цели и основы процесса разработки.
4. Спринт: Скрам-мастер берет на себя управление и начинает кодирование. Обычно этот процесс длится от 4 до 6 недель, в течение которых готовится тестовый продукт для клиента.
5. Тестирование: Клиент пробует продукт и дает обратную связь руководителю, чтобы тот передал ее команде.
6. Спринт: Новый Скрам-мастер может быть назначен, так как начинается вторая фаза спринта с учетом обратной связи с клиентом. Следует помнить, что на этом этапе спринты уже не планируются заранее, как это было на первом этапе. Здесь команда действует как agile-команда.
7. Итерация: Продолжайте переходить от спринта к тестированию, пока не достигнете конца проекта.

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

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

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