Чешуйчатая гибкая основа ( SAFe ) представляет собой набор организации и документооборот модель предназначена для руководства предприятия в масштабировании постных и гибкие методов. [1] [2] Наряду с крупномасштабным Scrum (LeSS), дисциплинированной гибкой доставкой (DAD) и Nexus, SAFe является одной из растущего числа фреймворков, которые стремятся решить проблемы, возникающие при масштабировании за пределы одной команды. [3] [4] SAFe предоставляется бесплатно компанией Scaled Agile, Inc., которая сохраняет авторские права и зарегистрированные торговые марки. [5]
SAFe способствует согласованности, сотрудничеству и доставке в большом количестве гибких команд. Он был разработан практиками и для практиков с использованием трех основных областей знаний: гибкой разработки программного обеспечения , бережливой разработки продуктов и системного мышления . [6]
Первоначально основным ориентиром для масштабируемой гибкой среды была разработка общего представления о том, как работа перетекает от руководства продуктом (или других заинтересованных сторон ) к клиентам через группы управления , программы и разработки . [7] [8] В сотрудничестве с другими участниками agile-сообщества, это было постепенно уточняется, а затем впервые официально описано в книге 2007 года. [9] Структура продолжает развиваться и публиковаться; с академией и схемой аккредитации, поддерживающей тех, кто стремится внедрять, поддерживать или обучать других внедрению SAFe.
Начиная с первого выпуска в 2011 году, было выпущено уже пять основных версий [10], а последняя версия, версия 5.1, была выпущена в феврале 2021 года [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]
- Взять экономический взгляд
- Применяйте системное мышление
- Предполагайте изменчивость; сохранить варианты
- Постройте постепенно с помощью быстрых интегрированных циклов обучения
- Основные этапы объективной оценки работающих систем
- Визуализируйте и ограничивайте незавершенные работы, уменьшайте размеры пакетов и управляйте длиной очереди
- Применяйте каденс (время), синхронизируйте с междоменным планированием
- Раскройте внутреннюю мотивацию работников умственного труда
- Децентрализовать принятие решений
- Организуйте вокруг ценности
Фреймворк SAFe
В SAFe версии 5.1 есть четыре конфигурации: основная, портфолио, большое решение и полная: [26]
- Essential SAFe - это самая базовая конфигурация. Он описывает наиболее важные необходимые элементы и предназначен для обеспечения большинства преимуществ фреймворка. Он включает в себя командный и программный уровень (который он называет Agile Release Train или ART).
- Большое решение SAFe обеспечивает координацию и синхронизацию нескольких программ, но без учета портфеля. В более ранних версиях SAFe этот уровень назывался потоком создания ценности .
- Портфель SAFe включает вопросы стратегического направления, инвестиционного финансирования и бережливого управления.
- Full SAFe объединяет три других уровня.
Сертификаты
Scaled Agile предоставляет сертификаты , охватывающие разные области и уровни знаний. [27]
Смотрите также
- Скрам схваток
Рекомендации
- ^ Хейс, Уилл; Лэпхэм, Мэри Энн; Миллер, Сюзанна; Врубель, Эйлин; Капелл, Питер (2016). Масштабирование гибких методов для программ Министерства обороны . Институт программной инженерии. CMU / SEI-2016-TN-005.
- ^ Атроу, Дезире (29 января 2015 г.). «Почему непрерывная доставка является ключом к ускорению разработки программного обеспечения» . TechRadar . Проверено 27 ноября 2017 .
- ^ Линдерс, Бен (22 января 2015 г.). «Гибкое масштабирование с помощью дисциплинированной гибкой среды доставки» . InfoQ . Проверено 27 ноября 2017 .
- ^ ван Хаастер, К. (2014). Agile в целом: от парадокса к парадигме . Неопубликованная статья из Университета Чарльза Стерта.
- ^ «FAQ по разрешениям» . Масштабируемый Agile . Проверено 13 июля 2018 .
- ^ Король, Майкл (2017). «Обслуживание федеральных клиентов с помощью концепций SAFe» (PDF) . Возможности важны Материалы конференции .
- ^ Бриджуотер, Адриан (7 августа 2013 г.). «Настоящая гибкость означает, что все гибки» . Доктора Добба . Проверено 27 ноября 2017 .
- ^ Линдерс, Бен (28 августа 2014 г.). «Смерть от планирования в гибком усыновлении» . InfoQ . Проверено 27 ноября 2017 .
- ^ Леффингуэлл, Дин (2007). Масштабирование гибкости программного обеспечения: передовой опыт для крупных предприятий . Эддисон-Уэсли. ISBN 978-0321458193.
- ^ «О Scaled Agile Framework - Краткая история SAFe» . Чешуйчатый Agile Inc . Проверено 12 августа 2020 .
- ^ «Что нового в SAFe 5.1 Big Picture» . Чешуйчатый Agile Inc . Проверено 10 февраля 2020 .
- ^ «13-й ежегодный отчет о состоянии гибкой разработки» . Состояние Agile Survey . CollabNet VersionOne. 2019 . Проверено 27 августа 2019 .
- ^ Ссылка, P; Леврик, М. (29 сентября 2014 г.). «Гибкие методы в новой области управления инновациями» (PDF) . Конференция по маркетингу "Наука для бизнеса" .
- ^ Баптиста, Роберто (28 января 2015 г.). "Profissionais brasileiros eo interesse por treinamentos de especialização" . Computerworld Бразилия . Проверено 28 января 2015 года .
- ^ Швабер, Кен (2013-08-06). «unSAFe на любой скорости» . Говорить так, как есть . Проверено 11 ноября 2017 .
- ^ Eklund, U; Olsson, H; Стрем, Н. (2014). Промышленные проблемы гибкого масштабирования в массовых встраиваемых системах . Гибкие методы. Масштабная разработка, рефакторинг, тестирование и оценка . Издательство Springer International. ISBN 9783319143583.
- ^ Хойссер, Мэтт (23 сентября 2014 г.). «Гибкие методы тестирования для нескольких команд» . Поиск программного обеспеченияКачество . Проверено 27 ноября 2017 .
- ^ Стеттина, C; Хорц, Дж (2015). «Гибкое управление портфелем: эмпирический взгляд на практику в использовании». Международный журнал управления проектами . 33 (1): 140–152. DOI : 10.1016 / j.ijproman.2014.03.008 .
- ^ Лаанти, М. (2014). Характеристики и принципы Scaled Agile . XP 2014 Мастерские . Издательство Springer International.
- ^ Эльсамадиси, Амр. «Разве SAFe сломал большую гайку для гибкого усыновления?» . InfoQ . Проверено 11 ноября 2017 .
- ^ а б Вайдья, А (2014). Папа знает лучше всего, что лучше делать LeSS или просто быть БЕЗОПАСНЫМ? Адаптация гибких практик масштабирования к предприятию . Выдержка из протоколов PNSQC 2014. С. 8–9.
- ^ а б Максимини, Доминик (11 сентября 2013 г.). «Критический взгляд на SAFe - Scrumorakel - Блог» . Scrum Oracle . Проверено 27 ноября 2017 .
- ^ Стаффорд, янв (9 декабря 2013 г.). «Масштабирование Agile-разработки требует определенных практик, - говорит консультант» . Поиск программного обеспеченияКачество . Проверено 27 ноября 2017 .
- ^ Киллик, Нил (21 марта 2012 г.). «Ужас масштабируемой гибкой структуры» . Agile, Scrum, Kanban, Lean и все, что между ними . Проверено 27 ноября 2017 .
- ^ «Принципы SAFe Lean-Agile» . Проверено 19 февраля +2016 .
- ^ Роуз, Дуг (2018). Гибкость предприятия для чайников . Джон Вили и сыновья. С. 87–89. ISBN 9781119446095.
- ^ «Сертификация» . Масштабируемый Agile . Проверено 19 февраля +2016 .
дальнейшее чтение
- Хойссер, Мэтью (17 июня 2015 г.), Введение в масштабируемую гибкую структуру , ИТ-директор , стр. 1-2. - содержит обзор плюсов и минусов методологии и делает вывод, что это промежуточный путь к полностью гибкой системе.
- Леффингуэлл, декан (2011 г.), Практика требований бережливого производства для команд, программ и предприятия , Addison-Wesley Professional, ISBN 978-0321635846
- Линдерс, Бен (15 января 2015 г.), Lean and Agile Leadership with the Scaled Agile Framework (SAFe) , InfoQ
Внешние ссылки
- Официальный веб-сайт