Страница контакты

РК, Алматы, пр. Абылай хана, 79, офис 306
+7 727 2793305
+7 727 2668693
РК, Астана, ул. Алматы, 1, БЦ "Асыл тау", 3 этаж, офис 304
+7 707 483 7268

Материалы

Давайте подискутируем на тему Эджайл

13.11.2012

 

В качестве эпиграфа «Есть ровно два способа построить корабль: можно спланировать и разделить работы, а можно заразить людей любовью к бескрайнему морю и тогда они сами построят корабль».
Антуан Де-сент Экзюпери

Под Эджайл (Agile) я буду понимать гибкий подход к управлению ИТ-проектами, как правило, связанным с разработкой программного обеспечения. Данный подход широко известен, оценен профессионалами, признан Международным институтом управления проектами (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 году.

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

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

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

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

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

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

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

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

Известная компания Standish Group в 2011 году провела крупное исследование факторов, которые влияют на успешное завершение проекта, и выделила 10 факторов, которые представлена на рис.2.

Рис.2 Исследование Standish Group факторов успешного выполнения проектов.

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

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

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

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

Вовлечение заинтересованных сторон в проект. Логичнее использовать Agile, так как эта методика предусматривает довольно частые и регулярные коммуникации со всеми стейкхолдерами проекта, учет их обратной связи в виде ожиданий и уровня удовлетворенности.
Поддержка руководства/спонсора. Не зависит от методологии, а зависит от других факторов, включая глоссарий спонсора, его толерантность по отношению к риску и т.п.
Однозначный список требований. Логичнее использовать Waterfall. Это безусловно классический подход к управлению проектами, когда вы оперируете зафиксированными требованиями и можете построить сквозной последовательный процесс управления проектом.
Правильное планирование. Скорее Waterfall, так как именно этот подход принято называть plan-driven (управляемый в соответствии с планом), в отличие от Agile, который называют value-driven (управляемый в соответствии с приносимой ценностью).
Реалистичные ожидания. Скорее Agile, так как на их формирование влияют используемые в Agile регулярные коммуникации с заказчиком.
Большое количество ключевых точек. Waterfall, как классический подход, в котором можно с большой долей вероятности составить иерархическую структуру работ с осязаемыми результатами после каждого этапа.
Компетентная команда проекта. Скорее Agile, поскольку акцент в этой методологии сделан на высокоорганизованную компетентную мотивированную команду проекта. Подразумевается, что именно команда будет принимать большинство ключевых решений в проекте.
Наличие ресурсов. Не зависит от методологии, так как важно для любого проекта. Подход Agile позволит начать проект с минимальным количеством ресурсов добавляя ресурсы в команду по мере роста объема требований заказчика.
Четкое видение и измеримые цели. Подход Agile выступает здесь с позиции подхода с большей степенью ориентированного на видение, чем на измеримые цели. С другой стороны, если у проекта есть измеримые цели, например, отвечающие методологии SMART, то логичней использовать подход Waterfall.
Нацеленность на результат. Agile. Этот подход подразумевает использование мотивированной команды проекта, которая «видит цель, верит в себя и не замечает препятствий».
Пример такого подхода поможет сориентироваться с использованием нужной методики управления ИТ-проектом, так как увязывают факторы, влияющие на результат проекта. В этом отношении руководители ИТ-проектов люди более счастливые, чем руководители строительных или инжиниринговых проектов. У руководителей ИТ-проектов целый арсенал вооружений!

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

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

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

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

Евгений Пикулев, исполнительный директор компании "Гибкие технологии".

Данная статья будет опубликована в ноябрьском номере журнала Intelligent Enterprise (www.iemag.ru)

Просмотров: 8908 Автор: Super User

РК, г. Алматы, пр. Абылай хана, 79, офис 306, +7 727 2793305, 2668693

РК,г.Астана, ул.Темирказык, 65, оф.5, +7 7172 729220

© 2014 Союз проектных менеджеров Республики Казахстан

The Registered Education Provider logo, the Registered Consultant Program logo, PMBOK, PMP, CAPM, PgMP, PMI-RMP, PMI-ACP, PfMP, PMI-SP, стандарты PMI являются зарегистрированными марками Института Управления Проектами