Под Эджайл (Agile) я буду понимать гибкий подход к управлению ИТ-проектами, как правило, связанными с разработкой программного обеспечения. Данный подход широко известен, оценен профессионалами, признан Международным институтом управления проектами (Prodject Management Professional — PMI) и имеет немало последователей. Однако эта тема, на мой взгляд, недостаточно освещена в специальных изданиях и поэтому имеет все признаки мифологии. В настоящей статье сделана попытка создать дискуссию вокруг этого подхода и увязки его с классическим пониманием управления проектом.

Эджайл шагает по стране

В последнее время тема использования Эджайл/Agile и разновидности этого подхода Скрам/Scrum стала весьма популярной не только в среде разработчиков, но и в ИТ-департаментах крупных организаций, включая коммерческие банки и производственные компании. Причем проникновение этих идей в Екатеринбурге по моим наблюдениям идет синхронно со столицами. Я сужу об этом по количеству специальных мероприятий, по уровню цитируемости в местных кругах и росту числа сертифицированных специалистов.

Знаковым мероприятием на данную тему в Екатеринбурге стало совместное заседание Екатеринбургского филиала Московского отделения PMI и Клуба профессионалов АСУ Урала в феврале 2011 года. Это событие состоялось в форме управленческого поединка «Agile против Waterfall». Формат мероприятия предусматривал дискуссию между экспертами — последователями гибкого подхода к управлению проектами (Agile) и классического подхода (который был назван схемой «водопада», или Waterfall). Мероприятие доказало, что Agile имеет кучу сторонников и активных практиков в известных компаниях. Сторонники Agile выдвигали тезис о значительных преимуществах данного подхода в условиях динамично меняющихся требований клиента. Мероприятие завершилось бурной дискуссией, продемонстрировавшей, что классический подход также жив и широко используется.

Горизонт ближайших событий в области управления проектами в Екатеринбурге показывает, что тема Agile не исчерпана. В ноябре текущего года запланировано обучение владельцев продуктов (Scrum Product Owner) — это одна из ключевых ролей в подходе Agile, а в конце ноября пройдет семинар Agile в забавном формате Pecha Kucha.

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

Даже PMI, который многие оценивают как организацию консервативную, но самую влиятельную в области управления проектами в мире, в прошлом году разработал специальную сертификацию на роль руководителя проектов с активным использованием Agile-практики. Сертификация эта официально называется PMI Agile Certified Practitioner (PMI-ACP)SM, и отрадно отметить, что в нашей стране есть специалисты, успешно ее прошедшие. Один из ключевых руководителей PMI Крис Картрайт в своем недавнем интервью выразил мнение, что методика Agile является очень полезной для проектов типа «блуждание в тумане». Подобные отклики PMI показывают серьезность намерений и широту возможных для использования подходов в области современного управления проектами.

Резюмируя данный раздел и обозревая свою книжную полку, на которой размещены десятки книг на тему Agile и Scrum, могу сказать, что данный подход пустил достаточно прочные корни в российской бизнес-практике. Осталось только обсудить критерии использования этого подхода, чтобы руководитель ИТ-проекта мог полноценно использовать Agile/Scrum в своем арсенале.

IT-project doesn`t matter?

Перефразируя название книги Николаса Карра «IT doesn`t matter», я хотел выразить мысль, что для проектов в области информационных технологий в настоящее время разработано довольно много инструментов и подходов. Известный в Интернете ежегодный отчет об успешности проектов в области ИТ показывает диаграмму в разрезе четырех подходов:

  • итерационный;
  • Agile;
  • Ad-Hoc;
  • традиционный.

На рис. 1 представлена диаграмма успешности проектов в 2010 году.

Фактически рисунок резюмирует, что руководители ИТ-проектов используют целую гамму подходов к управлению ими. Причем этот внушительный арсенал имеет очевидные плюсы и минусы.

С точки зрения плюсов есть возможность использовать методику управления проектом, которая наиболее точно отвечает совокупности внутренних и внешних факторов. То есть корпоративной культуре, практи­­ке аналогичных проектов, видению руководства, динамике заказчиков проекта, организационной структуре, уровню требований законодательных органов и т. п. Так, крупный системный интегратор в Екатеринбурге, работающий с крупными федеральными заказчиками, успешно реализует проекты на основании советского ГОСТ 34, предусматривающего тщательное оформление технического задания и разработку технического проекта. Другой пример: ИТ-компания, работающая на динамичном высококонкурентном рынке, с успехом использует методологию Agile по причинам изменения требований заказчиков и отслеживания действий конкурентов. Компаниям, которые используют традиционные подходы к управлению проектами, например, с назначением руководителя проекта и подготовкой плана проекта — несть числа.

Однако многообразие подходов приводит к дриблингу позиций. Если не разобраться в преимуществах определенной методологии, то это аналогично увеличению рисков проекта со всеми вытекающими последствиями. Проблема заключается также в том, что на практике часто допускается смешение подходов, индивидуальное для организации, которое образует методику «здравый смыл + накопленный опыт + некоторые стандарты в области ИТ». Смею утверждать, что по этому рецепту выполняет ИТ-проекты большинство организаций в России.

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

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

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

Успех ИТ-проекта

Давайте рассмотрим, от каких факторов зависит успех проекта, так как считаем, что именно в этом случае будет реализована миссия руководителя. Под успехом проекта принято понимать ситуацию, когда все заинтересованные стороны получают результаты, оправдывающие их ожидания, которые были сформулированы в виде целей и требований. Известная компания Standish Group в 2011 году провела крупное исследование факторов, влияющих на успешное завершение проекта, и выделила десять таких факторов, которые представлены на рис. 2.

Обращаем внимание, что на схеме представлено 10 факторов, причем в ходе исследования был определен сравнительный вес каждого из них. Для российского глаза удивительно, что на первом месте оказался фактор «Вовлечение заинтересованных сторон в проект» с весом в 19 баллов, тогда как фактор «Наличие ресурсов» стоит лишь на восьмом месте с весом в 6 баллов.

Данное исследование охватило несколько сот руководителей проектов в разных отраслях промышленности по всему миру. В плане моей статьи эти исследования интересны с точки зрения поиска нужной методики управления ИТ-проектом. Учитывая вес каждого критерия, необходимо соотнести его с окружением конкретного проекта, и тогда можно делать выводы по предполагаемой методике проектного управления, если, конечно, вы как руководитель проекта готовы их поддер­живать.

Интересен анализ этих факторов с точки зрения выбора методологии Agile или Waterfall. Ниже мной предпринята попытка такого разбора и определения соответствующего подхода.

Итак, комментирую факторы по порядку.

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

2. Поддержка руководства/спонсора. Зависит не от методологии, а от других факторов, включая глоссарий спонсора, его толерантность по отношению к риску и т. п.

3. Однозначный список требований. Логичнее использовать Waterfall. Это безусловно классический подход к управлению проектами, когда вы оперируете зафиксированными требованиями и можете построить сквозной последовательный процесс управления проектом.

4. Правильное планирование. Скорее Waterfall, так как именно этот подход принято называть plan-driven (управляемый в соответствии с планом), в отличие от Agile, который называют value-driven (управляемый в соответствии с приносимой ценностью).

5. Реалистичные ожидания. Скорее Agile, так как на их формирование влияют используемые в Agile регулярные коммуникации с заказчиком.

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

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

8. Наличие ресурсов. Не зависит от методологии, так как важно для любого проекта. Подход Agile позволит начать проект с минимальным количеством ресурсов, добавляя ресурсы в команду по мере роста объема требований заказчика.

9. Четкое видение и измеримые цели. Подход Agile выступает здесь с позиции подхода, с большей степенью ориентированного на видение, чем на измеримые цели. С другой стороны, если у проекта есть измеримые цели, например, отвечающие методологии SMART, то логичней использовать подход Waterfall.

10. Нацеленность на результат. Agile: этот подход подразумевает использование мотивированной команды проекта, которая «видит цель, верит в себя и не замечает препятствий».

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

Пусть расцветает сто цветов

Бесспорно, Agile является эффективным практичным подходом к управлению проектами с учетом ряда особенностей, которых я коснулся выше. Фактически этот подход можно отнести к третьему поколению управления проектами, ориентированному больше на миссию, чем на план. К этому же поколению относится японская методология управления проектами P2M, с которой у Agile есть некоторые пересечения, например, общее ментальное пространство проектной команды.

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

Взглянем на этот вопрос с позиции национального стандарта. Общепризнанно, что в настоящее время в нашей стране нет стандарта по управлению проектами, который учитывал бы национальные особенности и стал бы российским путеводителем в области проектного менеджмента. В области ИТ нам скорее нужен не стандарт, а некий отечественный тезаурус, который описывал бы предметную базу в соответствии с лучшими практиками. Буду с удовлетворением считать, что предложенная статья и дискуссия вокруг нее — вклад в этом направлении.