Фреймворк Scaled Agile Framework (SAFe)

Scaled Agile Framework / SAFe – это agile-фреймворк для работы с больших командой от 50 человек.

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

История SAFe

В 2011 году структура SAFe получила признание в мире продуктов. Ветеран индустрии программного обеспечения Дин Леффингвелл, автор книги «Требования к гибкому программному обеспечению», первоначально называл фреймворк SAFe «общей картиной гибкого предприятия». «Общая картина» описывает, как использовать существующие гибкие структуры, такие как Lean, Kanban, Scrum и XP, и применять их в команде, программе и портфолио.

Сегодня весь каталог знаний и примеров успеха SAFe доступен бесплатно. SAFe остается одним из самых популярных гибких фреймворков.

Каковы принципы гибкой разработки SAFe?

Прежде всего, SAFe основывается на таких основополагающих принципах:

Управление проектами SAFe

Управление проектами в организации, использующей SAFe, происходит на трех уровнях. На уровне отдельных команд это в основном обычный Скрам.

У небольших команд есть определенные цели и зоны ответственности. Поэтому они выпускают итерации после каждого спринта. Более того, Скрам-мастер обычно возглавляет обвинение. Единственное существенное изменение состоит в том, что теперь эти небольшие команды объединяются в программы.

На программном уровне преимущества SAFe начинают проявляться. Именно здесь результаты каждой команды должны объединяться с результатами всех остальных во что-то взаимодополняющее, связное и последовательное.

Под руководством инженера Release Train они объединяются в Agile Release Train. Синхронность обеспечивает работу группы отдельных Scrum-команд. Примерно через пять спринтов потенциально доступный для доставки инкремент проходит полный цикл тестирования. Этот процесс представляет собой отход от более традиционных Scrum и Continuous Delivery. В этом случае код доставляется очень часто.

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

Масштабируемая Agile

Изначально Agile задумывался не с учетом масштаба. Цель заключалась в том, чтобы снять ограничения с разработчиков и инженеров, дать им возможность самостоятельно заниматься реализацией, исходя из собственных суждений, включая уроки из одной итерации в следующую.

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

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

Например, все различные приложения Microsoft Office хорошо выполняют свои индивидуальные функции, но еще более успешным пакет делает тот, насколько легко пользователи могут переходить от одной программы к другой с ограниченной кривой обучения благодаря общему UX. Если бы команда Word и команда Excel работали на 100% независимо, не прошло бы много времени, пока каждая из них вела бы себя совершенно по-разному.

Scaled Agile обеспечивает этот уровень управления и координации для создания сложных решений, которые слишком велики и сложны для одной команды Scrum. Это может быть вызвано срочностью вывода решения на рынок или просто тем, что сам продукт слишком велик и сложен.