stringtranslate.com

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

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

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

Первоначально основным ориентиром для масштабируемой гибкой структуры была разработка общей картины того, как работа перетекает от управления продуктом (или других заинтересованных сторон ) через управление , программу и команды разработки к клиентам . [6] [7] При сотрудничестве других членов сообщества гибкой разработки она постепенно совершенствовалась, а затем впервые была официально описана в книге 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 базируется на десяти базовых концепциях, которые вытекают из существующих принципов Lean и Agile, а также наблюдений: [21]

  1. Посмотрите с экономической точки зрения
  2. Применяйте системное мышление
  3. Предполагать изменчивость; сохранять варианты
  4. Развивайте постепенно с помощью быстрых интегрированных циклов обучения
  5. Базовые контрольные точки на объективной оценке работающих систем
  6. Визуализируйте и ограничивайте объемы незавершенной работы, уменьшайте размеры партий и управляйте длиной очередей
  7. Применить каденс (тайминг), синхронизировать с междоменным планированием
  8. Раскройте внутреннюю мотивацию работников умственного труда
  9. Децентрализовать принятие решений
  10. Организуйте вокруг ценности

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

Структура SAFe

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

Сертификаты

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

Смотрите также

Ссылки

  1. ^ Хейс, Уилл; Лэпхэм, Мэри Энн; Миллер, Сюзанна; Врубель, Эйлин; Кейпелл, Питер (2016). Масштабирование гибких методов для программ Министерства обороны . Институт программной инженерии. CMU/SEI-2016-TN-005.
  2. ^ Athrow, Desiree (29 января 2015 г.). «Почему непрерывная поставка является ключом к ускорению разработки программного обеспечения». TechRadar . Получено 27.11.2017 .
  3. ^ Линдерс, Бен (22 января 2015 г.). «Масштабирование Agile с помощью Disciplined Agile Delivery Framework». InfoQ . Получено 27 ноября 2017 г.
  4. ^ van Haaster, K (2014). Agile in-the-large: Getting from Paradox to Paradigm . Неопубликованная статья из Университета Чарльза Стерта.
  5. ^ Кинг, Майкл (2017). «Обслуживание федеральных клиентов с помощью концепций SAFe» (PDF) . Материалы конференции Capability Counts .[ мертвая ссылка ‍ ]
  6. ^ Бриджуотер, Адриан (7 августа 2013 г.). «Настоящий Agile означает, что все Agile». Доктор Доббс . Получено 27 ноября 2017 г.
  7. ^ Линдерс, Бен (28 августа 2014 г.). «Смерть от планирования в Agile-адаптации». InfoQ . Получено 27.11.2017 .
  8. ^ Леффингвелл, Дин (2007). Масштабирование гибкости программного обеспечения: лучшие практики для крупных предприятий . Addison-Wesley. ISBN 978-0321458193.
  9. ^ "О Scaled Agile Framework - Краткая история SAFe". Scaled Agile Inc. Получено 12 августа 2020 г.
  10. ^ "Say Hello to SAFE 6.0". Scaled Agile Inc. Получено 16.03.2023 .
  11. ^ "13-й ежегодный отчет о состоянии Agile". Опрос о состоянии Agile . CollabNet VersionOne. 2019. Получено 27.08.2019 .
  12. ^ Линк, П.; Льюрик, М. (29 сентября 2014 г.). «Гибкие методы в новой области управления инновациями» (PDF) . Конференция по маркетингу «От науки к бизнесу» .
  13. ↑ Баптиста, Роберто (28 января 2015 г.). «Бразильские профессионалы и интерес к специальному обучению». Компьютерный мир Бразилия . Проверено 28 января 2015 г.
  14. ^ Швабер, Кен (2013-08-06). "unSAFe на любой скорости". Telling It Like It Is . Получено 2017-11-11 .
  15. ^ Готельф, Джефф (2021-10-05). "SAFe не Agile" . Получено 2023-05-21 .
  16. ^ Эклунд, У.; Олссон, Х.; Стрём, Н. (2014). Промышленные проблемы масштабирования гибкой разработки в серийно выпускаемых встраиваемых системах . Springer International Publishing. ISBN 9783319143583. {{cite book}}: |work=проигнорировано ( помощь )
  17. ^ ab Vaidya, A (2014). Does DAD Know Best, Is it Better to do LeSS or Just be SAFe? Адаптация масштабирования Agile-практик в Enterprise . Выдержка из материалов PNSQC 2014. С. 8–9.
  18. ^ ab Maximini, Dominik (11 сентября 2013 г.). "Критический взгляд на SAFe - Scrumorakel - Блог". Scrum Oracle . Получено 27.11.2017 .
  19. ^ Стаффорд, Ян (9 декабря 2013 г.). «Масштабирование Agile-разработки требует определенных практик, говорит консультант». SearchSoftwareQuality . Получено 27.11.2017 .[ мертвая ссылка ‍ ]
  20. ^ Киллик, Нил (21 марта 2012 г.). «Ужас масштабируемой Agile-структуры». Agile, Scrum, Kanban, Lean и все, что между ними . Получено 27.11.2017 .
  21. ^ "SAFe Lean-Agile Principles" . Получено 19 февраля 2016 г.
  22. ^ Элсамадиси, Амр. «Расколол ли SAFe большой орех внедрения Agile?». InfoQ . Получено 11 ноября 2017 г.
  23. ^ Роуз, Дуг (2018). Enterprise Agility For Dummies. John Wiley & Sons. С. 87–89. ISBN 9781119446095.
  24. ^ "Сертификация". Scaled Agile . Получено 19 февраля 2016 г.

Дальнейшее чтение

Внешние ссылки