Различия между SAFe и традиционным Project management

SAFe#0. Что такое SAFe и чем он отличается от традиционного проектного управления?

Приветствую Вас. Для начала определимся с понятиями.  Под традиционным проектным управлением в этой статье понимается управление проектами, программами, портфелями проектов на основе классических подходов, например, по PMBoK, PRINCE2 и т.д. 

Что же такое SAFe?

SAFe – Scaled Agile Framework.  

Как следует из названия SAFe – это фреймворк, т.е. архитектурный каркас, платформа для масштабирования Agile на уровень корпорации или достаточно большой организации.

SAFe – это база знаний, сборник лучших практик для внедрения гибких подходов в масштабе всей организации для обеспечения быстрой поставки качественного бизнес-решения потребителю.

SAFe cодержит обширный набор знаний, описывает роли, обязанности, мероприятия необходимые для реализации развития Agile на уровне компании.

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

Теперь несколько ассоциаций)))

Если компанию можно ассоциировать с

Большая компания

Т.е. поставка Решения (он же Продукт или Услуга) для потребителя идет медленно и дорого, компания один большой механизм, а хочет стать (доросла до этого желания сама, созрела так сказать) чем-то таким:

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) предсказуемо поставляется каждую программную итерацию, которые четко определены по длительности.

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *