Agile и классическое проектное управление: в чем разница?
Всем привет!
По многочисленным просьбам мы начинаем цикл вводных статей по Agile (гибким подходам) и сегодня рассмотрим, чем отличается методология Agile от классических подходов проектного управления.
Давайте вспомним основные принципы классического и гибкого подходов.
Классический проектный подход (еще называют «каскадная модель», «водопадная модель») заключается в том, что вы последовательно реализуете этапы проекта.
Например, планирование, разработку, тестирование и поставку результатов работ Заказчику. Присутствует вертикаль управления — Руководителю проекта делегированы полномочия, он управляет командой и ресурсами, отчитывается Заказчику и Куратору (Спонсору). Руководитель составляет план проекта, который утверждается Заказчиком, а команда действует согласно ему. Только в конце проекта готовый продукт передается Заказчику.
Классический подход
Agile или Гибкий подход
Инкрементальный подход
Метод итераций заключается в повторении операций для улучшения результатов предыдущего этапа (итерации). В примере с Моной Лизой мы вначале создаем черновик картины целиком, затем постепенно, слой за слоем, итерация за итерацией, приближаемся к итоговому результату. При этом результаты каждой итерации можно продемонстрировать Заказчику, а на основе обратной связи внести корректировки.
Итеративный подход
Оба подхода используются при разработке продуктов. Гибкий подход Agile предполагает нахождение баланса между обоими подходами.
Для портрета Моны Лизы художник сначала создает набросок всей картины (весь продукт в минимальном качестве — итерация), фрагмент в цвете (инкремент). Затем уточняет весь эскиз, при этом добавляет следующий фрагмент, и так далее. Совмещается два подхода, художник разрабатывает продукт итеративно-инкрементально.
В этом примере совмещаются инкрементальный с итеративным подходом.
Итеративно-инкрементальный подход
Еще пример метода итерации. Если нам необходимо соединить дорогой два населенных пункта (для нашего примера опустим пока законодательные ограничение, правила реализации строительных проектов и особенности дорожной отрасли). Как это можно сделать с использованием итеративно-инкрементального подхода: строим вначале грунтовую дорогу между обоими населенными пунктами по всей длине (это – итерация) и заасфальтируем первый участок асфальта (это — инкремент).
Мы можем в ограниченном режиме запустить автомобильное сообщение и получить обратную связь – где требуется улучшения, какие участки необходимо заасфальтировать в какой последовательности — инкременты нашего продукта. Затем дорогу необходимо обеспечить освещением, разметкой, знаками по всей протяженности – провести еще итерацию разработки продукта.
Важно, что каждый метод итерации и инкремент продукта в рамках выделенного промежутка времени, который часто называют спринтами, по времени небольшие (в Скрам – от недели до месяца). При этом у нас появляется работающий продукт, мы получаем обратную связь от заказчика и пользователей и можем гибко доработать продукт (проверить наши гипотезы). В случае классического проектного управления мы бы получили продукт в конце, но его характеристики могут не устроить заказчика или пользователей, а для доработки потребуется дополнительныеи ресурсы.
Резюме
Классическое проектное управление («водопад») основано на последовательности выполнения этапов работ и передаче заказчику готового продукта в конце проекта.
Гибкий подход к управлению Agile предлагает выстроить работу в другом формате: короткими спринтами поставлять заказчику продукт, который уже имеет для него ценность, пусть и ограниченную, и быстро получать обратную связь для корректировки направления работы.
Оба подхода имеют свою зону эффективного применения. На основе своего опыта мы сформулировали различия подходов и сформировали таблицу:
Характеристика;Классический подход;Agile
Поставка ценности (работающего результата);Происходит в конце проекта;Осуществляется по мере реализации проекта в виде работающих элементов продукта. Используется итеративно-инкрементальный подход.
Проверка гипотез;Как правило, выполняется на предпроектной стадии, до старта проекта;Выполняется командой в ходе проекта для улучшения продукта. Часть гипотез может быть признана несостоятельными
Планирование;Детальное, до конца проекта. Для оценки сроков используется Метод критического пути. В проектах с высокой неопределенностью используется метод «набегающей волны».;Эмпирическое, на основе исторических данных о реализованных элементов продукта
Стиль менеджмента, руководства;Вертикаль управления: Управляющий комитет -> Куратор, Заказчик -> Руководитель проекта;Самоорганизация внутри команды. Плоская команда без внутренней иерархии.
Отношение к изменениям;Как правило имеет негативный характер – изменения как следствия реализации рисков и наступления проблем. Требует формального процесса по анализу последствий и пересчету критического пути проекта, анализа альтернатив.;Изменения являются частью процесса разработки. Источником изменений является в т.ч. более лучшее понимание продукта на основе опыта.
Тип мышления, отношений;Как правило определяется культурой организации, зачастую фиксированный mindset;Необходим гибкий mindset для успешной работы в среде с высокой неопределенностью
Метрики проекта;% реализации, отклонение от плана, Метод освоенного объема, прогнозная дата завершения проекта;Диаграмма сгорания задач (Burn down chart), Накопительная диаграмма реализованных функций (Burn Up Chart), Дата выхода на рынок (Time to market)
Наличие руководств, методик;Хорошо структурированы, детально описаны (PMBoK, PRINCE2). Отраслевые стандарты и практики.;Верхнеуровневые фреймворки (например, Скрам). Множество отдельных практик (ежедневное собрание, ретроспектива, спринт и др.)
Область эффективного применения;«Сложные системы» по модели Киневин (Cynefin) – много работ, агентов (стейкхолдеров). Продукт и требования к нему известны, состав работ может быть описан и зафиксирован. Границы проекта фиксированы.;«Запутанные системы» по модели Киневин (Cynefin) – не знаем продукт и/или процесс его создания. Состав работ проекта не определен. Границы проекта размыты
Скачайте бесплатный мини-курс по Agile, Scrum и Kanban
Заполняя данную форму , вы даете согласие на обработку своих персональных данных, соглашаетесь с Политикой конфиденциальности и подписываетесь на новостную рассылку
Хотите лучше разобраться в Scrum и Kanban?
Тогда приходите к нам на тренинг Agile Certified Professional и научитесь правильно применять Scrum и Kanban на практике, чтобы сделать рывок в карьере или бизнесе! На курсе вы систематизируете знания по Agile, освоите Scrum и Kanban на практике, чтобы повысить производительность и научиться организовывать работу Agile-команд!
17 онлайн-уроков с отработкой навыков на практике
шаблоны для эффективной работы с проектами и командами
углубленные модули для будущих Скрам-мастеров и Канбан-коучей
международный сертификат от ICAgile и сертификаты от Канбан Стандарт и Product Focus
Заказать обучение по Agile, Scrum, Kanban для своей команды
Заполняя данную форму , вы даете согласие на обработку своих персональных данных, соглашаетесь с Политикой конфиденциальности и подписываетесь на новостную рассылку
Результаты обучения
Узнаете принципы Agile и откроете для себя мир гибкого управления
Сможете улучшить процессы своей команды и ускорить разработку продуктов
Научитесь пользоваться Scrum и Kanban
Пройдете аттестацию и получите международный сертификат ICAgile Certified Professional (ICP)
Узнаете, как внедрить Agile в своей компании, чтобы все поддержали вас
Автор статьи расскажет о разнице между output и outcome, о том, какую роль эти термины играют в OKR, а также поделится примером Целей и Ключевых Результатов с Outcome и ответит на часто задаваемые вопросы по теме.
Это седьмая, финальная статья из цикла «Введение в Agile». В ней мы расскажем о Канбан-методе: инструменте, который позволяет плавно улучшать процессы в организации, повышая их прозрачность, скорость и предсказуемость. В статье описана область применения Канбан-метода, его выгоды и ограничения, основные принципы работы поточных систем и 6 практик Канбан-метода.
Все, кто занимается Agile, слышали про Scrum и Kanban. Но не все четко понимают разницу между ними. Первый шаг к пониманию этой разницы — понять, что Канбан — это не просто доска. Канбан — это структура, методика, процесс (называйте как хотите), а доска — это просто инструмент.
Это третья статья из серии «Введение в Agile». В предыдущих статьях мы рассказали, чем отличается Agile от классического проектного управления, и в каких проектах стоит применять Agile.
Это вторая статья из цикла вводных статей по гибким подходам. В первой статье мы разобрались, чем отличается Agile от классических подходов проектного управления. Как обещали, сегодня расскажем, в каких проектах имеет смысл применять Agile и что такое модель Киневин (Cynefin).
Автор статьи расскажет о поведенческой концепции продавцов и покупателей, об Эффекте наделения и Эффекте 9х. А также объяснит, как построить баланс между продуктом и поведенческим изменением, чтобы новый продукт не потерпел крах после запуска.
В данной статье мы расскажем, что такое Scrum, какие у него принципы, для каких команд подходит и как работает. А также поделимся чек-листом по внедрению Scrum!