Статья посвящена вопросам подхода и проектирования и внедрения гибкой методологии управления проектами Agile. Описана многоаспектная стратегия внедрения agile в организации, основные этапы жизненного цикла проектов, а также преимущества и благоприятные условия для внедрения.
проектирование, внедрение, agile, жизненный цикл проекта, традиционный подход
В своем докладе «Transitioning To Agile» (James F. Carilli, 2015) приводит многоаспектную стратегию внедрения agile в организации, опишем некоторые из них:
1. Составление целевых планов и дорожных карт – определение последовательности действий и целевых показателей по переходу от существующих способов управления к гибким. Само организационное изменение должно рассматриваться и управляться как проект.
2. Расширение возможностей команды – огромную роль в agile играет именно команда. Она должна уметь самоорганизовать свою работу, принимать важные решения и добиваться их исполнения совместно.
Борис Вольфсон в книге «Гибкое управление проектами и продуктами» изображает проектный треугольник agile как отношение объема работы, срока и команды. Данная итерация представлена на рис. 1 [1].
На рис. 2 видно, что объем работ определяется длительностью итерации и компетенциями команды. К одной из важнейших компетенций я бы отнес способность и умение команды принимать решения.
Все команды можно разделить на четыре типа:
1. Предписывающие.
2. Продающие.
3. Участвующие.
4. Делегирующие.
Только команды четвертого уровня, руководитель которых может применять делегирующий тип управления, можно считать гибкими. Команды уровней ниже или нуждаются в руководителе, принимающем ключевые решения, или не хотят брать на себя ответственность.
Проблема ответственности также является одной из ключевых проблем в agile, так как коллективная ответственность команды не ведет к повышению эффективности реализации проекта, а может даже препятствовать, так как мотивация каждого участника становится ниже.
3. Налаживание взаимодействия – создание необходимых коммуникационных каналов внутри команды и за ее пределами. Огромную роль играет создание доверительных отношений между участниками команды, между командой и заказчиком.
4. Комбинирование методик – интеграция гибких принципов в существующую систему управления. Необходимость подобной интеграции вызвана недостатками каждого подхода по отдельности, с одной стороны, а с другой − спецификой бизнеса и особенностями организации.
К примеру, говоря об управлении государственными проектами, важно понимать контрактное законодательство и систему нормативного регулирования. Данные системы не противоречат методологии гибкого управления проектами, но затрудняют работу команде проекта в момент отчета перед контролирующими органами или при внесении ключевых принципов agile в контракт. Также возникают внутренние особенности коммуникаций с государственными служащими, отягчаемые низкой 68 мотивацией чиновников участвовать в проекте. Все это заставляет оптимизировать существующую методологию гибкого управления путем комбинирования методик.
5. Коучинг и тренинги – постоянное развитие и обучение команды и руководителя проекта, а также сотрудников смежных департаментов, влияющих на проект и высшего руководства.
6. Гибкие контракты – фиксация основных принципов гибкого управления в контракте, и, в первую очередь, участие заказчика в проекте.
7. Индикаторы эффективности – пути и способы анализа эффективности внедренных принципов и процессов. В целом, если говорить о традиционной оценке проектной зрелости организации, данное требование относится к 4 уровню зрелости, но использовать его при внедрении agile необходимо, чтобы по результатам оценки выявить целесообразность дальнейшего перехода.
8. Быстрые результаты небольшими усилиями – процесс перехода должен быть разделен на этапы, после каждого этапа должен быть проведен анализ эффективности перехода с учетом индикаторов. Только после этого ключевые решения о продолжении проекта внедрения могут приниматься.
Также проблемой может стать масштабирование agile на всю компанию.
С одной стороны, подход к масштабированию уже разработан, но об оценке его эффективности речи еще не идет.
Процесс масштабирования выглядит следующим образом:
Раз в неделю проводятся скрам-митинги скарм-мастеров, на которых они эскалируют проблемы своих команд на уровень высшего руководства. Уровней эскалации также может быть несколько.
Раз в неделю аналогичные митинги проводятся для владельцев продуктов, на которых высокоуровневые требования разбиваются на детальные, и наоборот, оценивается влияние изменения конкретного требования на достижение общих целей.
Традиционное проектное управление базируется на линейной структуре – процесс исполнения проекта разбивается на последовательные взаимозависимые этапы. Данный подход ориентирован на проекты, в которых есть строгие ограничения по последовательности выполнения задач. В качестве традиционного подхода к управлению проектами обычно используется PMBOK (Project Management Body of Knowledge) – свод знаний по управлению проектами выделяют 5 основных этапов жизненного цикла проектов [2]:
1. Инициация. Руководитель проекта и команда определяют требования к проекту. На данном этапе часто проводятся совещания и «мозговые штурмы», на которых определяется, что же должен представлять из себя продукт проекта.
2. Планирование. На данном этапе команда решает, как она будет достигать цели, поставленной на предыдущем этапе. На данном этапе команда уточняет и детализует цели и результаты проекта, а также состав работ по нему. На основании данной информации команда формирует календарный план и бюджет, оценивает риски и выявляет заинтересованные стороны.
3. Исполнение. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам, начинает создаваться содержание проекта, определенное ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.
4. Мониторинг. На данной стадии происходит оценка прогресса проекта и проводится мониторинг для обнаружения отклонений от плана управления проектом. В случае необходимости проводятся корректирующие действия для достижения целей проекта.
5. Завершение проекта. В зависимости от проекта данная фаза может состоять из простой передачи Заказчику результатов проекта или же из длительного процесса взаимодействия с клиентами по улучшению проекта и повышению их удовлетворённости, и поддержке результатов проекта. Последнее относится к проектам в области клиентского сервиса и программного обеспечения.
Стоимость и вовлечение персонала в проект невелики в начале, достигают пикового значения по мере выполнения работ и стремительно падают на этапе завершения проекта. Способность влиять на конечные характеристики продукта проекта без существенного влияния на стоимость имеет наивысшее значение в начале проекта и уменьшается по мере продвижения проекта к завершению. Стоимость изменений и коррекции ошибок, как правило, существенно возрастает по мере приближения к завершению проекта.
Одним из основных существенных недостатков традиционного подхода к управлению проектами является именно нетолерантность к изменениям. Данный недостаток может оказывать небольшое влияние в том случае, если проект выполняется в относительно стабильной среде. Однако в настоящее время множество организаций функционирует в гиперконкурентной среде – в связи с этим значительно возрастает частота внесения изменений в проект. Таким образом, в проектной деятельности значительно повышается цена ошибки – небольшой просчёт на начальных стадиях проекта может привести к многократно большим затратам на поздних стадиях.
Внедрение методологий гибкой разработки может повысить эффективность деятельности проектных групп, а также повысить качество работы по отдельным направлениям. Помимо непосредственного внедрения этих методологий компании могут также прибегнуть к использованию общих принципов гибкой разработки для повышения общей эффективности работы персонала, снижения издержек и поддержки творческого подхода.
Для внедрения методологий гибкой разработки от руководства организации требуется чёткое понимание необходимости внесения кардинальных изменений в организационные и управленческие процессы компании. Однако гибкая разработка не является универсальным и простым средством решения всех проблем организации. В деятельность организации, не связанную с осуществлением проектов или основанную на строгой последовательности выполнения работ, внедрение методологий гибкой разработки может оказаться затруднительным – или, более того, лишним и даже вредным [3].
Agile можно использовать в следующих случаях:
− требования к результатам проекта не проработаны, и на их детальную проработку заказчик проекта не готов выделить отдельный этап проекта и потратить на него несколько месяцев;
− разработку результатов проекта можно вести через прототипы, проверяя на них, насколько команда угадала ожидания заказчика. При этом стоимость разработки прототипов относительно невелика (в строительстве дома, к примеру, прототипы создавать слишком дорого);
− заказчик проекта готов управлять приоритетами требований к результатам проекта и, главное, готов отказаться от их части, при этом понимая, что без них продукт проекта все равно будет иметь ценность для его потребителей;
− заказчик проекта готов участвовать в проекте не менее 2−4 часов каждую неделю.
1. Вольфсон Б. Гибкое управление проектами и продуктами. - Санкт-Петербург: Питер, 2015. − 144 с.
2. Чуланова О.Л. Технология управления проектами и проектными командами на основе методологии гибкого управления проектами Agile // Вестник Евразийской науки. - 2018. − №1. https://esj.today/PDF/65ECVN118.pdf (время обращения 30.10.2017).
3. Project Management Institute. «Agile: практическое руководство»: Олимп-Бизнес; Москва, 2018.
