Приветствую Вас. Для начала определимся с понятиями. Под традиционным проектным управлением в этой статье понимается управление проектами, программами, портфелями проектов на основе классических подходов, например, по PMBoK, PRINCE2 и т.д.
Что же такое SAFe?
SAFe – Scaled Agile Framework.
Как следует из названия SAFe – это фреймворк, т.е. архитектурный каркас, платформа для масштабирования Agile на уровень корпорации или достаточно большой организации.
SAFe – это база знаний, сборник лучших практик для внедрения гибких подходов в масштабе всей организации для обеспечения быстрой поставки качественного бизнес-решения потребителю.
SAFe cодержит обширный набор знаний, описывает роли, обязанности, мероприятия необходимые для реализации развития Agile на уровне компании.
SAFe – это не только про ИТ. Это про бизнес в целом. Там есть и про стратегические темы, и про бюджет, и про связь всего этого с конкретными работами отдельной команды. Это про подходы к достижению целей «большого» бизнеса через быстрое, качественное Решение (продукт, услуга), которое получает потребитель.
Теперь несколько ассоциаций)))
Если компанию можно ассоциировать с
Т.е. поставка Решения (он же Продукт или Услуга) для потребителя идет медленно и дорого, компания один большой механизм, а хочет стать (доросла до этого желания сама, созрела так сказать) чем-то таким:
Т.е. нужны гибкие, эффективные команды для поставки Решений (продуктов, услуг) до потребителя быстро и с нужным качеством, то SAFe вам в помощь!
Вот так выглядит этот SAFe:
Теперь давайте посмотрим на основные различия между традиционным проектным управлением и SAFe
| Традиционное проектное управление | SAFe: Lean-Agile управление | |
| Модель руководства | Централизованные команды и контроль, операционное руководство | Самоорганизация, децентрализация, руководство через служение, доверие, дальновидность, оказание услуг другим (Servant LeaderShip) |
| Содержание | Границы проекта четко определены. Все изменение через запросы на изменение и управление изменениями. Проводится проверка содержания в основном по вехам. | Есть Видение продукта, ценности для потребителя и дорожная карта реализации. Частая корректировка списка верифицированных задач (backlog). Проверка по факту работоспособного продукта на каждой итерации программы |
| Архитектура | Описывается в самом начале и блокируется для изменений | Достаточно направления для реализации ближайщей функциональности. Сохраняется возможность изменения на основе проверенной практики |
| Планирование работ | В качестве ограничений выступают функциональные требования. Централизованные проектные планы создаются с учетом оценок по стоимости и срокам. | Видение ценности управляет возможными характеристиками и оценками. В качестве ограничений выступают стоимость и сроки. Список приоритизированных задач (Epics), дорожная карта для 3-4 ближайших инкрементов программы, постоянный продолжающийся поток поставки ценности |
| Финансирование | Финансирование проектов целиком и план на год. Акуент на соблюдение плана по затратам | Финансирование потоков создания ценностей (Value Streams), производящихся каждой отдельной сборной, самодостаточной командой (Agile Release Train). |
| Риски | Идентификация рисков перед запуском проекта. Планирование реагирования на риски. Контроль и мониторинг рисков. РП держатель рисков. | Идентификация рисков, их анализ, работа с ними каждую итерацию на любом уровне управления (team, program, portfolio). Вся команда является держателем рисков. |
| Качество | Проводится оценка в конце проекта, когда продукт проекта уже сделан. Акцент на соблюдение начальных требований. Анализ ошибок, уроков в конце проекта. | Проводится инкрементально, на каждом цикле путем тестирования и получения обратной связи. Акцент на адаптации решения к потребностям потребителя. |
| Распределение ресурсов | Мультизадачное, мультипроектное. Люди пришли на работу. Акцент на наиболее полное использование людей для оптимизации их стоимости. | Специальные команды. Работа пришла к команде. Акцент на соращение простоев для увеличения производительности. |
| Отслеживание прогресса | По вехам плана проекта, во главе угла — затраты и использользование ресурсов. | Работающая часть продукта (Features and Capabilities) предсказуемо поставляется каждую программную итерацию, которые четко определены по длительности. |
