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

Масштабируемая гибкая структура ( SAFe ) — это набор шаблонов организации и рабочих процессов, призванных помочь предприятиям в масштабировании бережливых и гибких практик. ^[1]^[2] Наряду с дисциплинированной гибкой доставкой (DAD) и S@S (Scrum@Scale), SAFe входит в число растущего числа фреймворков, направленных на решение проблем, возникающих при масштабировании за пределы одной команды. ^[3]^[4]

SAFe способствует согласованности, сотрудничеству и реализации результатов среди большого количества гибких команд. Он был разработан практиками и для практиков с использованием трех основных областей знаний: гибкой разработки программного обеспечения , бережливой разработки продуктов и системного мышления . ^[5]

Изначально основной целью масштабируемой гибкой структуры была разработка общей картины того, как работа проходит от управления продуктом (или других заинтересованных сторон ) через руководство , программы и группы разработки до клиентов . ^[6]^[7] В сотрудничестве с другими членами agile-сообщества это постепенно совершенствовалось, а затем впервые официально описано в книге 2007 года. ^[8]Рамочная основа продолжает разрабатываться и распространяться публично; с академией и схемой аккредитации, поддерживающей тех, кто стремится внедрить, поддержать или обучить других внедрению SAFe.

Начиная с первого выпуска в 2011 году, было выпущено шесть основных версий. ^[9] а последняя версия, версия 6.0, была выпущена в марте 2023 года. ^[10]

Хотя SAFe по-прежнему считается наиболее распространенным подходом к масштабированию гибких практик (30 процентов и продолжает расти), ^[11]^[12]^{[ нужна страница ]}, ^[13] его также критиковали за слишком иерархичность и негибкость. ^[14] Его также критикуют за то, что он дает организациям иллюзию принятия Agile , сохраняя при этом знакомые процессы. ^[15]

Проблемы масштабирования принципов и практик гибкой разработки [ править ]

длительными горизонтами планирования Как справиться с более

Команды разработчиков обычно уточняют свой резерв на две-три итерации вперед, но в более крупных организациях команде маркетинга продукта необходимо заранее планировать свои обязательства перед рынком и обсуждения с клиентами. ^[16] Они часто работают с планами очень высокого уровня, рассчитанными на 12–18 месяцев, а затем совместно с командами планируют три месяца работы. ^{[ нужна цитата ]} Команды разработчиков все равно будут вдаваться в детальную доработку на 2-3 итерации вперед, переходя только к детальным планам задач на следующую итерацию. ^{[ нужна цитата ]}

Сохранение гибкости на абстрактных уровнях ответственности [ править ]

Хотя команды разработчиков имеют ряд рамок, определяющих, как они должны быть гибкими, очень мало что описывает это для руководства. SAFe предоставляет многие из тех же принципов, таких как межфункциональные команды, группам, которые отвечают за более абстрактные уровни ответственности и планирования (продукт и портфель). ^{[ нужна цитата ]}

делегированными полномочиями Работа с

В Scrum ожидается, что владелец продукта возьмет на себя ответственность за полный жизненный цикл продукта , включая возврат инвестиций в решения по разработке, а также производительность на рынке. В случае крупномасштабных разработок организация хочет получить представление о невыполненных заданиях нескольких команд, например, предоставленное менеджером по продукту . ^[17] Хотя SAFe предполагает, что роль владельца продукта связана с управлением продуктом, его, тем не менее, критикуют за разделение владельцев продукта на организацию-разработчика. ^[18]

Синхронизация результатов [ править ]

Agile-фреймворки созданы для того, чтобы команда разработчиков могла быть автономной и свободной в проектировании своей работы. SAFe признает, что в масштабах многих десятков или сотен команд разработчиков полная самоорганизация становится все более хаотичной. ^[19] Таким образом, это накладывает на это некоторые ограничения: когда команды работают над одним и тем же продуктом, их результаты можно лучше синхронизировать для совместного выпуска, хотя это была одна из областей, в которой SAFe подвергался критике. ^[17]^[18]

Предоставление времени для инноваций и планирования [ править ]

Цикл планирования SAFe рекомендует включать дополнительную итерацию после выпуска, что позволяет командам улучшить свои методы и быть готовыми к следующему этапу планирования. В более ранних выпусках SAFe это также было задумано как итерация ужесточения , а именно, для стабилизации или ужесточения продукта перед его выпуском. Это было обусловлено сложностью работы с большими интеграционными средами, где зависимости не позволяли протестировать некоторые вопросы до самого конца. SAFe подвергся критике за это, потому что он представлял собой анти-agile или водопадный элемент, но соответствовал бережливым 90-дневным приращениям, что составляет 13 недель, а если вы выполняете двухнедельные спринты, вам нужно шесть из них плюс однонедельное планирование или цикл закалки. ^[20] Это не включено в последние выпуски SAFe.

Реализация [ править ]

Основополагающие принципы SAFe [ править ]

По мнению авторов, SAFe основан на десяти основных концепциях, которые вытекают из существующих принципов бережливости и гибкости, а также наблюдений: ^[21]

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

SAFe критиковали за объединение слишком большого количества разрозненных практик. ^[22]

Структура SAFe [ править ]

В SAFe версии 5.1 предусмотрено четыре конфигурации: базовая, портфельная, крупное решение и полная: ^[23]

Essential SAFe — это самая базовая конфигурация. В нем описаны наиболее важные необходимые элементы, и он предназначен для обеспечения большинства преимуществ структуры. Он включает в себя уровень команды и программы (который называется поездами гибкого выпуска или ART).
Крупное решение SAFe позволяет координировать и синхронизировать несколько программ, но без учета портфеля. В более ранних версиях SAFe этот уровень назывался потоком создания ценности .
Портфель SAFe включает в себя заботы о стратегическом направлении, инвестиционном финансировании и бережливом управлении.
Полный SAFe объединяет три других уровня.

Сертификаты [ править ]

Scaled Agile предоставляет сертификаты , охватывающие различные области и уровни знаний. ^[24]

См. также [ править ]

Скрам из схваток

Ссылки [ править ]

^ Хейс, Уилл; Лэпэм, Мэри Энн; Миллер, Сюзанна; Врубель, Эйлин; Капелл, Питер (2016). Масштабирование гибких методов для программ Министерства обороны . Институт программной инженерии. КМУ/СЭИ-2016-ТН-005.
^ Атроу, Дезире (29 января 2015 г.). «Почему непрерывная доставка является ключом к ускорению разработки программного обеспечения» . ТехРадар . Проверено 27 ноября 2017 г.
^ Линдерс, Бен (22 января 2015 г.). «Масштабирование Agile с помощью дисциплинированной гибкой среды доставки» . ИнфоQ . Проверено 27 ноября 2017 г.
^ ван Хаастер, К. (2014). Agile в целом: переход от парадокса к парадигме . Неопубликованная статья Университета Чарльза Стерта.
^ Кинг, Майкл (2017). «Обслуживание федеральных клиентов с помощью концепций SAFe» (PDF) . Материалы конференции, учитывающие возможности . ^{[ мертвая ссылка ]}
^ Бриджуотер, Адриан (7 августа 2013 г.). «Настоящая Agile означает, что все гибкие» . Доктор Добб . Проверено 27 ноября 2017 г.
^ Линдерс, Бен (28 августа 2014 г.). «Смерть от планирования в гибком внедрении» . ИнфоQ . Проверено 27 ноября 2017 г.
^ Леффингвелл, Дин (2007). Масштабирование гибкости программного обеспечения: лучшие практики для крупных предприятий . Аддисон-Уэсли. ISBN 978-0321458193 .
^ «О Scaled Agile Framework — Краткая история SAFe» . Scaled Agile Inc. Проверено 12 августа 2020 г.
^ «Передайте привет SAFE 6.0» . Scaled Agile Inc. Проверено 16 марта 2023 г.
^ «13-й ежегодный отчет о состоянии Agile» . Состояние Agile-опроса . CollabNet VersionOne. 2019 . Проверено 27 августа 2019 г.
^ Линк, П; Льюрик, М. (29 сентября 2014 г.). «Гибкие методы в новой области управления инновациями» (PDF) . Конференция по маркетингу от науки к бизнесу .
^ Баптиста, Роберто (28 января 2015 г.). «Бразильские профессионалы и интерес к специализации» . Компьютерный мир Бразилия . Проверено 28 января 2015 г.
^ Швабер, Кен (6 августа 2013 г.). «небезопасно на любой скорости» . Рассказывать всё так, как оно есть . Проверено 11 ноября 2017 г.
^ Готелф, Джефф (05 октября 2021 г.). «SAFe — это не Agile» . Проверено 21 мая 2023 г.
^ Эклунд, У; Олссон, Х; Стрём, Н. (2014). Промышленные проблемы масштабирования встраиваемых систем массового производства . Международное издательство Спрингер. ISBN 9783319143583 . {{cite book}}: |work= игнорируется ( помогите )
^ Перейти обратно: ^а ^б Вайдья, А (2014). ПАПА лучше всех знает: лучше заниматься LeSS или просто быть в безопасности? Адаптация гибких практик на предприятии . Отрывок из материалов PNSQC 2014. стр. 8–9.
^ Перейти обратно: ^а ^б Максимини, Доминик (11 сентября 2013 г.). «Критический взгляд на SAFe — Scrumorakel — Блог» . Скрам-оракул . Проверено 27 ноября 2017 г.
^ Стаффорд, Январь (9 декабря 2013 г.). «Масштабирование Agile-разработки требует определенных практик, — говорит консультант» . ПоискКачествоПрограммного обеспечения . Проверено 27 ноября 2017 г. ^{[ мертвая ссылка ]}
^ Киллик, Нил (21 марта 2012 г.). «Ужас масштабируемой Agile Framework» . Agile, Scrum, Kanban, Lean и все, что между ними . Проверено 27 ноября 2017 г.
^ «Принципы SAFe Lean-Agile» . Проверено 19 февраля 2016 г.
^ Эльсамадиси, Амр. «Расколол ли SAFe большой орешек внедрения Agile?» . ИнфоQ . Проверено 11 ноября 2017 г.
^ Роуз, Дуг (2018). Гибкость предприятия для чайников . Джон Уайли и сыновья. стр. 87–89. ISBN 9781119446095 .
^ «Сертификация» . Масштабируемый Agile . Проверено 19 февраля 2016 г.

Дальнейшее чтение [ править ]

Дингсойр, Торгейр; Фалесси, Дэвид; Пауэр, Кен (февраль 2019 г.), «Гибкая разработка в масштабе: следующий рубеж», IEEE Software , 36 (2): 30–38, arXiv : 1901.00324 , doi : 10.1109/MS.2018.2884884 , S2CID 57373760
Хойссер, Мэтью (17 июня 2015 г.), «Введение в масштабируемую гибкую структуру» , CIO , стр. 1–2 — содержит обзор плюсов и минусов методологии и приходит к выводу, что она является промежуточным этапом к полностью гибкой системе.
Леффингвелл, Дин (2011), Практика требований бережливого производства для команд, программ и предприятия , Addison-Wesley Professional, ISBN 978-0321635846
Линдерс, Бен (15 января 2015 г.), Бережливое и гибкое лидерство с помощью Scaled Agile Framework (SAFe) , InfoQ

Внешние ссылки [ править ]

Официальный веб-сайт

[1] Хейс, Уилл; Лэпэм, Мэри Энн; Миллер, Сюзанна; Врубель, Эйлин; Капелл, Питер (2016). Масштабирование гибких методов для программ Министерства обороны . Институт программной инженерии. КМУ/СЭИ-2016-ТН-005.

[2] Атроу, Дезире (29 января 2015 г.). «Почему непрерывная доставка является ключом к ускорению разработки программного обеспечения» . ТехРадар . Проверено 27 ноября 2017 г.

[3] Линдерс, Бен (22 января 2015 г.). «Масштабирование Agile с помощью дисциплинированной гибкой среды доставки» . ИнфоQ . Проверено 27 ноября 2017 г.

[4] ван Хаастер, К. (2014). Agile в целом: переход от парадокса к парадигме . Неопубликованная статья Университета Чарльза Стерта.

[5] Кинг, Майкл (2017). «Обслуживание федеральных клиентов с помощью концепций SAFe» (PDF) . Материалы конференции, учитывающие возможности . ^{[ мертвая ссылка ]}

[6] Бриджуотер, Адриан (7 августа 2013 г.). «Настоящая Agile означает, что все гибкие» . Доктор Добб . Проверено 27 ноября 2017 г.

[7] Линдерс, Бен (28 августа 2014 г.). «Смерть от планирования в гибком внедрении» . ИнфоQ . Проверено 27 ноября 2017 г.

[8] Леффингвелл, Дин (2007). Масштабирование гибкости программного обеспечения: лучшие практики для крупных предприятий . Аддисон-Уэсли. ISBN 978-0321458193 .

[History_of_SAFe-9] «О Scaled Agile Framework — Краткая история SAFe» . Scaled Agile Inc. Проверено 12 августа 2020 г.

[10] «Передайте привет SAFE 6.0» . Scaled Agile Inc. Проверено 16 марта 2023 г.

[11] «13-й ежегодный отчет о состоянии Agile» . Состояние Agile-опроса . CollabNet VersionOne. 2019 . Проверено 27 августа 2019 г.

[12] Линк, П; Льюрик, М. (29 сентября 2014 г.). «Гибкие методы в новой области управления инновациями» (PDF) . Конференция по маркетингу от науки к бизнесу .

[13] Баптиста, Роберто (28 января 2015 г.). «Бразильские профессионалы и интерес к специализации» . Компьютерный мир Бразилия . Проверено 28 января 2015 г.

[14] Швабер, Кен (6 августа 2013 г.). «небезопасно на любой скорости» . Рассказывать всё так, как оно есть . Проверено 11 ноября 2017 г.

[15] Готелф, Джефф (05 октября 2021 г.). «SAFe — это не Agile» . Проверено 21 мая 2023 г.

[16] Эклунд, У; Олссон, Х; Стрём, Н. (2014). Промышленные проблемы масштабирования встраиваемых систем массового производства . Международное издательство Спрингер. ISBN 9783319143583 . {{cite book}}: |work= игнорируется ( помогите )

[:2-17] Перейти обратно: ^а ^б Вайдья, А (2014). ПАПА лучше всех знает: лучше заниматься LeSS или просто быть в безопасности? Адаптация гибких практик на предприятии . Отрывок из материалов PNSQC 2014. стр. 8–9.

[:3-18] Перейти обратно: ^а ^б Максимини, Доминик (11 сентября 2013 г.). «Критический взгляд на SAFe — Scrumorakel — Блог» . Скрам-оракул . Проверено 27 ноября 2017 г.

[:1-19] Стаффорд, Январь (9 декабря 2013 г.). «Масштабирование Agile-разработки требует определенных практик, — говорит консультант» . ПоискКачествоПрограммного обеспечения . Проверено 27 ноября 2017 г. ^{[ мертвая ссылка ]}

[20] Киллик, Нил (21 марта 2012 г.). «Ужас масштабируемой Agile Framework» . Agile, Scrum, Kanban, Lean и все, что между ними . Проверено 27 ноября 2017 г.

[:0-21] «Принципы SAFe Lean-Agile» . Проверено 19 февраля 2016 г.

[22] Эльсамадиси, Амр. «Расколол ли SAFe большой орешек внедрения Agile?» . ИнфоQ . Проверено 11 ноября 2017 г.

[23] Роуз, Дуг (2018). Гибкость предприятия для чайников . Джон Уайли и сыновья. стр. 87–89. ISBN 9781119446095 .

[24] «Сертификация» . Масштабируемый Agile . Проверено 19 февраля 2016 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]