Agile и классическое проектное управление: в чем разница?

23 Авг 2019

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

Классический подход

Давайте вспомним основные принципы классического и гибкого подходов.
Классический проектный подход (еще называют «каскадная модель», «водопадная модель») заключается в том, что вы последовательно реализуете этапы проекта. Например, планирование, разработку, тестирование и поставку результатов работ Заказчику. Присутствует вертикаль управления — Руководителю проекта делегированы полномочия, он управляет командой и ресурсами, отчитывается Заказчику и Куратору (Спонсору) проекта. Руководитель проекта составляет план проекта, который утверждается Заказчиком, и команда действует согласно ему. Только в конце проекта готовый продукт передается Заказчику.

Классический подход

Agile или Гибкий подход

Об истории применения и развития гибких подходов можно почитать в нашей статье «Неизвестная история Agile»

Напомним ключевое:

Еще с 30-х годов XX века практики и теоретики менеджмента искали пути повышения эффективности работы и избавления от потерь. Появился цикл Деминга (PDCA), бережливые методы производства в Тойоте, понимание негативного влияния простоев, перепроизводства, неравномерной работы, перегрузки сотрудников, накопления запасов и др.

В 1986 году опубликована статья японских исследователей Икуджиро Нонака и Хиротака Такеучи «New New Product Development Game», в которой иллюстрировались потери времени и информации при передаче продукта последовательно от проектировщика разработчику, от разработчика тестировщику и так далее. Авторы статьи рекомендовали специалистам последующих стадий включаться в работу раньше, даже если продукт еще не полностью разработан, чтобы сэкономить время на создание продукта. По сути, предлагается кроссфункциональная команда.

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

Рассмотрим более подробно, как поставляется продукт в Agile. Начнем с инкрементального подхода – это быстрое создание продукта с ограниченным, но работающим функционалом. Такой подход позволяет быстро проверять и корректировать гипотезы относительно создаваемого продукта и быстро корректировать направления дальнейшей разработки. Например, если Заказчик просит у нас портрет «Моны Лизы», мы делим холст целиком на участки, и каждый участок создаем последовательно. Такой формат не предполагает доработок уже созданных фрагментов, но каждый фрагмент является целостным и его уже можно показывать заказчику, не дожидаясь окончания проекта.

Инкрементальный подход

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

Итеративный подход

Оба подхода используются при разработке продуктов. Agile предполагает нахождение баланса между обоими подходами. Для портрета Моны Лизы художник сначала создает набросок всей картины (весь продукт в минимальном качестве — итерация) и фрагмент в цвете (инкремент). Затем уточняет весь эскиз и при этом добавляет следующий фрагмент, и так далее. Совмещается два подхода, художник разрабатывает продукт итеративно-инкрементально. В этом примере совмещаются инкрементальный и итеративный подходы.

Итеративно-инкрементальный подход

Еще пример. Если нам необходимо соединить дорогой два населенных пункта (для нашего примера опустим пока законодательные ограничение, правила реализации строительных проектов и особенности дорожной отрасли). Как это можно сделать с использованием итеративно-инкрементального подхода: строим вначале грунтовую дорогу между обоими населенными пунктами по всей длине (это – итерация) и заасфальтируем первый участок асфальта (это — инкремент). Мы можем в ограниченном режиме запустить автомобильное сообщение и получить обратную связь – где требуется улучшения, какие участки необходимо заасфальтировать в какой последовательности — инкременты нашего продукта. Затем дорогу необходимо обеспечить освещением, разметкой, знаками по всей протяженности – провести еще итерацию разработки продукта.

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

Резюме

Классическое проектное управление («водопад») основано на последовательности выполнения этапов работ и передаче заказчику готового продукта в конце проекта.

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

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

Характеристика Классический подход Agile
Поставка ценности (работающего результата) Происходит в конце проекта Осуществляется по мере реализации проекта в виде работающих элементов продукта. Используется итеративно-инкрементальный подход.
Проверка гипотез Как правило, выполняется на предпроектной стадии, до старта проекта Выполняется командой в ходе проекта для улучшения продукта. Часть гипотез может быть признана несостоятельными
Планирование Детальное, до конца проекта. Для оценки сроков используется Метод критического пути. В проектах с высокой неопределенностью используется метод «набегающей волны». Эмпирическое, на основе исторических данных о реализованных элементов продукта
Стиль менеджмента, руководства Вертикаль управления: Управляющий комитет -> Куратор, Заказчик -> Руководитель проекта Самоорганизация внутри команды. Плоская команда без внутренней иерархии.
Отношение к изменениям Как правило имеет негативный характер – изменения как следствия реализации рисков и наступления проблем. Требует формального процесса по анализу последствий и пересчету критического пути проекта, анализа альтернатив. Изменения являются частью процесса разработки. Источником изменений является в т.ч. более лучшее понимание продукта на основе опыта.
Тип мышления, отношений Как правило определяется культурой организации, зачастую фиксированный mindset Необходим гибкий mindset для успешной работы в среде с высокой неопределенностью
Метрики проекта % реализации, отклонение от плана, Метод освоенного объема, прогнозная дата завершения проекта Диаграмма сгорания задач (Burn down chart), Накопительная диаграмма реализованных функций (Burn Up Chart), Дата выхода на рынок (Time to market)
Наличие руководств, методик Хорошо структурированы, детально описаны (PMBoK, PRINCE2). Отраслевые стандарты и практики. Верхнеуровневые фреймворки (например, Скрам). Множество отдельных практик (ежедневное собрание, ретроспектива, спринт и др.)
Область эффективного применения «Сложные системы» по модели Киневин (Cynefin) – много работ, агентов (стейкхолдеров). Продукт и требования к нему известны, состав работ может быть описан и зафиксирован. Границы проекта фиксированы. «Запутанные системы» по модели Киневин (Cynefin) – не знаем продукт и/или процесс его создания. Состав работ проекта не определен. Границы проекта размыты

В следующей статье мы планируем рассказать о модели Киневин (Cynefin) для определения к какой группе относится ваш проект.

 

 

Смотрите также:


Яндекс.Метрика