Как бизнесу работать по agile – комментарий Максима Якубовича к выступлению Германа Грефа

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

Выступление председателя Сбербанка России Германа Грефа на Гайдаровском форуме-2016 активно обсуждалось белорусскими пользователями соцсетей. Одна из тем – о пользе модели agile для успешного управления проектами, не только в ИТ-компаниях.

Мы попросили нашего эксперта, специалиста по управлению проектами Максима Якубовича рассказать простыми словами, как бизнесу работать с agile.

Базовые модели

– В управлении проектами существуют 2 базовые модели, которые описывают жизненный цикл проекта: водопадная модель (waterfall) и итеративная модель. Подробнее об этом я уже писал.

Вот ключевые отличия двух моделей жизненного цикла:

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

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

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

Если говорить об успешности проектов с использованием agile-подходов и водопадной модели жизненного цикла, можно использовать статистику успешности по ИТ-проектам от The Standish Group.

К сожалению, у меня нет возможности получить последнее исследование The Standish Group от 2015 года, но если верить краткому обзору, данные говорят в пользу agile-проектов:

Но отмечу: в управлении проектами за почти 70 лет с начала использования сетевых графиков было придумано большое количество методологий. И, по идее, это должно было привести к росту доли успешных проектов.

Несмотря на это, успешность, к примеру, ИТ-проектов, выполняемых во всем в мире, в последние 10 лет колеблется в диапазоне 29-39% (по статистике The Standish Group).

Что мне понравилось при работе по scrum

У меня есть опыт работы как по одному из подходов agile – фреймворку scrum, так и по водопадной модели.  Поделюсь, в чем достоинства scrum:

1. Заказчик более серьезно вовлечен в проект, чем при работе по водопадной модели, т.к. ему необходимо вместе с командой планировать итерации, принимать результаты работ по ним. Например, в scrum владелец продукта (по сути, представитель заказчика):

• Формирует очередность, в которой будет реализован функционал продукта проекта
• Принимает итоги работ по каждой итерации

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

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

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

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

Вот картинка, которые описывает подход к scrum для читателей, которые про него не слышали:

Таким образом, в проекте должны быть реализованы три роли:

1. Product Owner (владелец продукта) – отвечает за получение продукта проекта в виде, который позволит использовать его по целевому назначению.

2. Scrum master (скрам-мастер) – отвечает за внедрение процессов и ценностей scrum в команде проекта.

3. Team (команда) – отвечает за получение запланированного результата в рамках одной итерации (в scrum итерация называется спринтом).

Работа над проектом:

1. Весь проект нарезается на серию спринтов одинаковой длительности. Она выбирается командой совместно с владельцем продукта (от 1 до 4 недель) и в ходе проекта не изменяется.

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

3. Во время планирования спринта – Sprint planning meeting команда проекта, анализируя свою производительность и применяя специальный подход к оценке объемов работ, отбирает из журнала продукта столько пожеланий, сколько может реализовать за один спринт. Она помещает их в журнал спринта – Sprint backlog. Основное правило: список задач, отобранных на текущий спринт, не изменяется.4. В ходе спринта команда каждый день собирается на Daily scrum meeting и каждый отвечает только на три главных вопроса. Митинг проводится в течение 15 минут и все вопросы, требующие обсуждения, выносятся на отдельные совещания.

5. По окончании спринта команда демонстрирует владельцу продукта, что было сделано – Review. Результат демонстрации – владелец продукта понимает, как работает часть, которую показывала команда. После чего список его замечаний и пожеланий попадают в журнал продукта.

С каждым новым спринтом команда исправляет обнаруженные в прошлом спринте замечания и добавляет новые функции в продукт, реализуя самые важные пожелания.

6. Кроме того, по окончании каждого спринта команда встречается на специальном совещании – retrospective (ретроспективе). На нем формулируются проблемы в существующих процессах работы над проектом и происходит поиск решений.

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

В каких проектах, не связанных с ИТ, можно использовать agile?

Я считаю, что у agile есть широкий спектр применения. Например, в своей книге Scrum: «The Art of Doing Twice the Work in Half the Time», Дж. Сазерленд приводит примеры удачного использования scrum в образовании, медиа-бизнесе, телекоммуникациях. Я читал про использование agile в проектах автопроизводителей, в фармакологических проектах, в маркетинге.

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

При этом есть важное условие – стоимость разработки прототипов не должна быть большой, как, например, это происходит в строительстве.