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

Scaled agile framework
Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

В Масштабируемая гибкая структура (Безопасный) представляет собой набор шаблонов организации и рабочего процесса, предназначенный для руководства предприятиями в масштабирование худой и гибкий практики.[1][2] Вместе с масштабный Scrum (Меньше), дисциплинированная гибкая доставка (DAD) и Nexus, SAFe - одна из растущего числа фреймворков, которые стремятся решить проблемы, возникающие при масштабировании за пределы одной команды.[3][4] SAFe предоставляется бесплатно компанией Scaled Agile, Inc., которая сохраняет авторские права и зарегистрированные торговые марки.[5]

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

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

Начиная с его первого выпуска в 2011 году было выпущено уже пять основных версий.[10] а последняя редакция, версия 5.0, была выпущена в январе 2020 года.[11]

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

Проблемы масштабирования гибких принципов и практик

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

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

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

В то время как команды разработчиков имеют ряд структур, которые определяют, как они должны быть гибкими, для руководства это очень мало. SAFe предоставляет многие из тех же принципов, например, кросс-функциональные группы, группам, которые занимаются более абстрактными уровнями ответственности и планирования (продукт и портфель).[19] SAFe также подвергается критике за объединение слишком большого количества разрозненных практик.[20]

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

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

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

Фреймворки Agile предназначены для того, чтобы дать команде разработчиков возможность быть автономной и свободной для разработки того, как они работают. SAFe признает, что в масштабе многих десятков или сотен команд разработчиков полная самоорганизация групп становится все более хаотичной.[23] Таким образом, это накладывает некоторые ограничения на это, так что, когда команды работают над одним и тем же продуктом, их результаты могут быть лучше синхронизированы для совместного выпуска, хотя это была одна из областей, в которой SAFe подвергался критике.[21][22]

Оставляя время на инновации и планирование

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

Выполнение

Основные принципы SAFe

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

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

Фреймворк SAFe

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

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

Сертификаты

Scaled Agile обеспечивает сертификаты которые охватывают разные области и уровни знаний.[27]

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

Рекомендации

  1. ^ Хейс, Уилл; Лэпхэм, Мэри Энн; Миллер, Сюзанна; Врубель, Эйлин; Капелл, Питер (2016). Масштабирование гибких методов для программ Министерства обороны. Институт программной инженерии. CMU / SEI-2016-TN-005.
  2. ^ Атроу, Дезире (29 января 2015 г.). «Почему непрерывная доставка - ключ к ускорению разработки программного обеспечения». TechRadar. Получено 2017-11-27.
  3. ^ Линдерс, Бен (22 января 2015 г.). «Масштабирование Agile с помощью дисциплинированной гибкой среды доставки». InfoQ. Получено 2017-11-27.
  4. ^ ван Хаастер, К. (2014). Agile в целом: от парадокса к парадигме. Неопубликованная статья из Университета Чарльза Стерта.
  5. ^ "Часто задаваемые вопросы о разрешениях". Масштабируемая Agile. Получено 13 июля 2018.
  6. ^ Король, Майкл (2017). «Обслуживание федеральных клиентов с помощью концепций SAFe» (PDF). Возможности имеют значение Материалы конференции.
  7. ^ Бриджуотер, Адриан (7 августа 2013 г.). «Настоящая гибкость означает, что все гибки». Доктора Добба. Получено 2017-11-27.
  8. ^ Линдерс, Бен (28 августа 2014 г.). «Смерть от планирования в гибком усыновлении». InfoQ. Получено 2017-11-27.
  9. ^ Леффингуэлл, Дин (2007). Масштабирование гибкости программного обеспечения: лучшие практики для крупных предприятий. Эддисон-Уэсли. ISBN 978-0321458193.
  10. ^ «О Scaled Agile Framework - Краткая история SAFe». Scaled Agile Inc. Получено 12 августа 2020.
  11. ^ "Каковы ключевые даты запуска SAFe 5.0?". Получено 2020-02-05.
  12. ^ «13-й ежегодный отчет о состоянии гибкой разработки». Состояние Agile Survey. CollabNet VersionOne. 2019 г.. Получено 2019-08-27.
  13. ^ Ссылка, P; Леврик, М. (29 сентября 2014 г.). «Гибкие методы в новой области управления инновациями» (PDF). Конференция "Наука для бизнеса".
  14. ^ Баптиста, Роберто (28 января 2015 г.). "Profissionais brasileiros e o interesse por treinamentos de especialização". Computerworld Бразилия. Получено 28 января 2015.
  15. ^ Швабер, Кен (2013-08-06). "unSAFe на любой скорости". Говорить так, как есть. Получено 2017-11-11.
  16. ^ Eklund, U; Olsson, H; Стрём, Н. (2014). Промышленные проблемы гибкого масштабирования в массовых встраиваемых системах. Гибкие методы. Масштабная разработка, рефакторинг, тестирование и оценка. Издательство Springer International. ISBN 9783319143583.
  17. ^ Хойссер, Мэтт (23 сентября 2014 г.). «Гибкие методы тестирования для нескольких команд». SearchSoftwareQuality. Получено 2017-11-27.
  18. ^ Стеттина, C; Хорц, Дж (2015). «Гибкое управление портфелем: эмпирический взгляд на практику в использовании». Международный журнал управления проектами. 33 (1): 140–152. Дои:10.1016 / j.ijproman.2014.03.008.
  19. ^ Лаанти, М. (2014). Характеристики и принципы Scaled Agile. Мастерские XP 2014. Издательство Springer International.
  20. ^ Эльсамадиси, Амр. "Разве SAFe сломал большую гайку Agile Adoption?". InfoQ. Получено 2017-11-11.
  21. ^ а б Вайдья, А (2014). Папа лучше всех знает, что лучше делать - LeSS или просто быть в безопасности? Адаптация гибких практик масштабирования к предприятию. Выдержка из протоколов PNSQC 2014. С. 8–9.
  22. ^ а б Максимини, Доминик (11 сентября 2013 г.). «Критический взгляд на SAFe - Scrumorakel - Блог». Скрам Oracle. Получено 2017-11-27.
  23. ^ Стаффорд, янв (9 декабря 2013 г.). «Масштабирование Agile-разработки требует определенных практик, - говорит консультант». SearchSoftwareQuality. Получено 2017-11-27.
  24. ^ Киллик, Нил (21 марта 2012 г.). "Ужас масштабной гибкой структуры". Agile, Scrum, Kanban, Lean и все, что между ними. Получено 2017-11-27.
  25. ^ «Принципы SAFe Lean-Agile». Получено 19 февраля 2016.
  26. ^ Роуз, Дуг (2018). Гибкость предприятия для чайников. Джон Вили и сыновья. С. 87–89. ISBN 9781119446095.
  27. ^ «Сертификация». Масштабируемая Agile. Получено 19 февраля 2016.

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

внешняя ссылка