Лекция
Привет, Вы узнаете о том , что такое scaled agile framework , Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое scaled agile framework , safe, масштабированный гибкий фреймворк , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.
Scaled Agile Framework (англ. масштабированный гибкий фреймворк ), также известный как SAFe — гибкий фреймворк для разработки программного обеспечения, позволяющий использовать аgile-методологии в больших командах размером более 50 человек. Фреймворк был создан Дином Леффингуэллом в компании Scaled Agile .
Скрам, экстремальное программирование и другие гибкие методы разработки традиционно не выходят за пределы уровня команды. В отличие от них, SAFe предоставляет единый и унифицированный вид на выполняемые работы с точки зрения руководителей компании, позволяя углубляться в детали по мере необходимости для анализа и выявления закономерностей. SAFe состоит из трех уровней: командный уровень, программный уровень и уровень портфолио.
Команда в SAFe может состоять из 8—10 человек и является кросс-функциональной, то есть обладает всеми компетенциями, необходимыми для разработки программного обеспечения, начиная со сбора требований и заканчивая внедрением. Несколько команд создают то, что в SAFe называется «поездом релиза» (англ. release train), построенным вокруг одной программы. Этому проекту или программе проектов соответствует отдельная статья бюджета организации. Для руководителей организации это — небольшой проект, который можно обсуждать отдельно. Под портфелем или портфолио в SAFe подразумевается полный набор программ, на которые используется весь бюджет организации, выделенный для разработки программного обеспечения. Согласно SAFe, рекомендуется создавать единый офис управления портфелем, ответственный за стратегию развития, инвестиции и бюджетирование набора проектов .
В SAFe версии 4.0 добавилось разделение на два типа внедрения фреймворка — трехуровневый и четырехуровневый. Трехуровневый способ используется для команд меньшего размера, содержащих не более 100 человек, или же нескольких программ аналогичного размера, не требующих существенного взаимодействия. Четырехуровневый способ применим для решений, которые требуют вовлечение нескольких сотен специалистов, и помимо трех стандартных уровней включает четвертый уровень под названием «поток ценности» .
SAFe - это фреймворк . Это не набор жестких правил. Как и любой хороший фреймворк, он требует продуманной настройки под вашу конкретную ситуацию. Документация, доступная на Scaled Agile, четко подчеркивает эту динамику.
В SAFe есть один «жесткий» аспект, и это справедливо. 10 принципов SAFe считаются неизменными. Как упоминалось выше, эти принципы считаются лучшими практиками из мира Lean и Agile. Эти руководящие утверждения являются принципами, а не практикой . SAFe явно допускает индивидуализированные методы, пока не обременены принципами.
Scaled Agile Framework( SAFe ) представляет собой набор организации и документооборот модель предназначена для руководства предприятия в масштабировании постных и гибкие методов. Наряду с крупномасштабным Scrum (LeSS), дисциплинированной гибкой доставкой (DAD) и Nexus, SAFe является одной из растущего числа фреймворков, которые стремятся решить проблемы, возникающие при масштабировании за пределы одной команды. SAFe предоставляется бесплатно компанией Scaled Agile, Inc., которая сохраняет авторские права и зарегистрированные торговые марки.
SAFe способствует согласованности, сотрудничеству и доставке в большом количестве гибких команд. Он был разработан практиками и для практиков с использованием трех основных областей знаний: гибкой разработки программного обеспечения , бережливой разработки продуктов и системного мышления .
Первоначально основным ориентиром для масштабируемой гибкой среды была разработка общего представления о том, как работа перетекает от управления продуктом (или других заинтересованных сторон ) к клиентам через группы управления , программы и разработки . В сотрудничестве с другими участниками agile-сообщества это было постепенно уточняется, а затем впервые официально описано в книге 2007 года. Структура продолжает разрабатываться и публиковаться; с академией и схемой аккредитации, поддерживающей тех, кто стремится внедрить, поддержать или обучить других внедрению SAFe.
Начиная с первого выпуска в 2011 году, было выпущено уже пять основных версий [10], а последняя версия, версия 5.0, была выпущена в январе 2020 года. [11]
Хотя SAFe по-прежнему считается наиболее распространенным подходом к масштабированию гибких практик (на 30% и растет) , он также подвергся критике за то, что является слишком иерархичным и негибким. [15]
SAFe — это слоеный пирог из различных методик Agile. Об этом говорит сайт https://intellect.icu . На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. Хотя есть одно ключевое отличие. Команда перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. Т.е. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).
На следующем уровне у нас поезда — так называемые Agile Release Train. Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.
Над уровнем поездов у нас координация между отделами, директорами, и клиентом. Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Здесь проводится анализ экономической целесообразности изменений. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Для компаний менее миллиарда долларов — это может быть самый последний этаж. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.)
Над уровнем больших систем идет управление портфолио. Распределяются средства на различные направления в бизнесе. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Здесь принимаются решения о покупке или слиянии с другими компаниями. Создание новых направлений бизнеса, закрытие старых. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.
Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.
Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.
В SAFe нет ничего, что хотя бы отдаленно напоминало RUP. SAFe - это Agile на стероидах, масштабируемый для предприятия. RUP - это мост между Waterfall и Agile. В SAFe нет устаревших фаз или проверок ворот. Откровенно говоря, единственное, что объединяет SAFe и RUP, - это то, что они являются средами разработки продуктов, которые помогают командам добиться успеха. И это хорошо.
SAFe представляет собой передовое, развитое, зрелое Agile-мышление - для всего предприятия.
Команды разработчиков обычно уточняют свой бэклог до двух-трех итераций вперед, но в более крупных организациях команде продуктового маркетинга необходимо заранее планировать свои обязательства на рынке и обсуждения с клиентами. [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 основан на десяти основных концепциях, которые вытекают из существующих принципов бережливого производства и гибкости, а также на наблюдениях: [25]
В SAFe версии 5.0 есть четыре конфигурации: основная, портфолио, большое решение и полная: [26]
Scaled Agile предоставляет сертификаты , охватывающие разные области и уровни знаний. [27]
Scrum of Scrums
RUP (Rational Unified Process)
Scrums
Исследование, описанное в статье про scaled agile framework , подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое scaled agile framework , safe, масштабированный гибкий фреймворк и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Управление разработкой программных IT проектов
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Управление разработкой программных IT проектов
Термины: Управление разработкой программных IT проектов