Был давеча на круглом столе по обсуждению разных методологий разработки ПО. Говорили много и красиво о самих методологиях, о том, что некоторые методологии несут всякие  выгоды  компании и т.д. При этом  во время обсуждения поймал себя на мысли, что во время обсуждения методологий ни разу не поднимался вопрос о  критериях применимости конкретной методологии или практик к тому или иному проекту.

В данном посте, хотел бы собственно поговорить о применимости той или иной методологии к тому или иному проекту. Проще говоря, когда на проекте выстраивать процессы по RUP/CMMI, а когда использовать Agile практики?

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

Давайте рассмотрим какие существуют проекты разработки ПО с точки зрения бизнеса заказчика:

1. Заказная разработка системы с нуля
2. Создание дополнительного функционала для уже существующей системы/платформы
3. Продуктовая разработка (создаем коробочный продукт)

При этом надо еще учитывать, что заказчик может быть как внешний, так и внутренний.

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

Теперь коснемся каждого случая в отдельности:

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

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

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

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

Понятно, что в жизни так идеально не бывает, но подобная логика заказчика изначально присутствует практически всегда.

Как же ведется проект при подоьной схеме? Обычно он разбивается на две части, вначале идет мини-проект по сбору бизнес-требований (его кстати может выполнить и сторонний исполнитель, который пишет бизнес-требования, а потом они выносятся на тендер).  Далее происходит оценка объема работ, трудозатрат и выкатывается ком. предложение. Если обе стороны договорятся о сотрудничестве (подписывают контракт),  наступает полный сбор требований и создание архитектуры, на этом этапе происходит коррекция требований, после чего начинается работа. В большинстве своем такие проекты идут по fix price схеме.
В этой схеме для исполнителя работ особо важно на этапе сбора требований и создания архитектуры максимально их проработать и подписать у заказчика, что бы на сдаче приемке отбиться от   озарений в части хотелок и пожеланий заказчика.

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

К чему я клоню, а к тому что для проектов создания подобного ПО очень кстати подходят практики CMMI, их вооплощение в жизнь на проекте,  минимизирует риски превращения проекта из коммерческого в  "политический".

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

Здесь как раз пригодиться Agile. Разработка модуля во первых осуществляется уже не «большой командой для большой системы», во вторых быстрая демонстрация первичного функционала, его опробование на прототипной системе и получение фитбека от реальных пользователей для изменений в следующей итерации выгодна как заказчику, так и исполнителю, к тому же обычно на это стадии можно договориться об оплате работ по схемe  time-and-material.

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

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