что такое фреймворк agile
Agile Frameworks
Введение в Agile Frameworks
Понимание Agile Framework
Ниже приведен список некоторых из фреймворков, которые широко используются и наиболее популярны. Следует отметить, что между ними существует много общего, поскольку базовая структура является гибкой для всех из них. В конце концов, речь идет о том, какая структура более удобна с точки зрения реализации и подходит для решаемой проблемы.
Как работает Agile Framework?
Мы проанализируем и поймем, как работает каждая из вышеупомянутых структур
1. Методология Agile Scrum
Это простая структура, которая облегчает командную совместную работу над сложными программными проектами. Scrum подчеркивает командную работу в управлении проектами. Он подчеркивает ответственность и является итеративным прогрессом в достижении цели, которая уже предопределена и установлена. Scrum является частью гибкой разработки программного обеспечения.
Внутри Scrum есть две важные позиции или роли, которые нужно решить. Эти
2. Бережливая разработка программного обеспечения
Он опирается на быструю и надежную обратную связь между программистами и клиентами, он повышает производительность и эффективность, предлагая клиентам выбрать ценные функции, а затем расставить приоритеты этих функций, а затем работать над их предоставлением.
3. Kanban Разработка программного обеспечения
Это соответствует и в некотором роде основано на программном обеспечении Lean. Фактически, исследования показывают, что большой процент команд, практикующих Lean, использует Kanban для визуализации и активного управления созданием продуктов.
Канбан основан на 3 принципах
с. Улучшение потока: Когда что-то закончено, обрабатывается следующий элемент с наивысшим приоритетом.
В целом Kanban способствует постоянному сотрудничеству и поощряет активное постоянное обучение и улучшение.
4. Экстремальное программирование
Это подход, который направлен на предоставление высококачественного программного обеспечения, быстро и непрерывно. Он предназначен для улучшения качества и возможностей программного обеспечения. Он учитывает изменение требований клиента.
Он поддерживает и продвигает привлечение ваших клиентов, обеспечивает очень быструю обратную связь, постоянное тестирование, постоянное планирование и тесную работу с командами для поставки рабочего программного обеспечения с очень частыми интервалами, обычно каждые 1-3 недели.
Оригинальный метод экстремального программирования основан на четырех простых принципах:
5. Кристалл
С точки зрения других рамок кристалл отличается от других с точки зрения:
6. Метод разработки динамических систем (DSDM)
DSDM основан на восьми ключевых принципах, на которых сосредоточена работа команды над ним. Эти принципы служат для них основой, когда они работают с клиентами. Эти принципы в первую очередь:
Таким образом, общий DSDM развился, чтобы обеспечить всеобъемлющую основу для планирования, управления и выполнения Agile процесса.
7. Функциональная разработка (FDD)
Разработка, основанная на функциях, включает пять основных видов деятельности, ниже приведен список этих видов деятельности. Команда, работающая над функционально-ориентированной разработкой, использует эти действия в качестве эталона.
Зачем нам Agile Framework?
Вышеупомянутые гибкие фреймворки, каждая из которых обладает своими уникальными качествами, все они учитывают схожий процесс итеративной разработки и непрерывную обратную связь при работе с программным обеспечением. Agile защитники работают постепенно, совместно и гибко
Вывод
Рекомендуемые статьи
1.4 ФРЕЙМВОРКИ AGILE
Scrum, по определению его создателей, это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески создавать для клиентов продукты с максимально возможной ценностью. Scrum компактен и прост для понимания, но достаточно трудно овладеть им в совершенстве.
Нужно также учитывать следующие особенности:
Scrum, по определению его создателей, это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески создавать для клиентов продукты с максимально возможной ценностью. Scrum компактен и прост для понимания, но достаточно трудно овладеть им в совершенстве.
Нужно также учитывать следующие особенности:
Kanban, согласно одному из определений, это «популярный подход к реализации Agile-разработки ПО. Он предполагает обсуждение производительности в режиме реального времени и полную прозрачность рабочих процессов. Этапы работы визуально представлены на Kanban-доске, что позволяет членам команды видеть состояние каждой задачи в любой момент времени». Kanban обеспечивает прозрачность, понимание и вовлеченность членов команды, регулярную коммуникацию и обратную связь. Этот подход хорошо работает и приживается в организации независимо от корпоративной культуры, его можно использовать не только в проектных командах, но и для визуализации процесса работы с однородными процессными задачами. Данный подход может быть использован для наглядной демонстрации изменений и быстрых побед.
Кроме того, существует ряд фреймворков, связанных с масштабированием Agile-подходов, например в крупных компаниях или применительно к объемным проектам. На Западе они применяются несколько реже, чем основные Agile-подходы, а в РФ — значительно реже. На момент написания данного документа (май 2019 г.) практик внедрения данных фреймворков в российском госуправлении не было (но есть практики внедрений в крупных государственных и «около-государственных» компаниях, например в Центробанке, Сбербанке, «Газпромнефти»). Поскольку есть вероятность, что со временем такие практики появятся, мы кратко упоминаем об этих фреймворках. К наиболее известным фреймворкам такого плана относятся:
• Scaled Agile Framework (SAFe) — гибкий фреймворк для разработки продуктов для конечных клиентов, позволяющий использовать Agile-подходы в больших командах численностью более 50 человек. Уже существует SAFe for government — фреймворк SAFe, адаптированный именно для госуправления (западного).
SAFe или Scaled Agile Framework
Что такое SAFe?
Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.
Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?
Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.
Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Есть попытки использовать SCRUM на уровне управления SCRUM командами (так советует делать Jeff Sutherland — один из авторов Agile manifesto), есть Large Scale Scrum, есть Disciplined Agile Delivery, есть много еще что, но еще есть SAFe — Scaled Agile Framework.
SAFe — это фреймворк для управления компанией в которой требуется координация работы над некоторым проектом или связанными проектами для 5 или более SCRUM командами. Т.е. это некая надстройка над SCRUM позволяющая управлять коллективами из 100 и более человек
Выгода?
В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами. На эту тему неплохо высказался Dave Thomas (еще один из авторов Agile manifesto) На GOTO 2015 в своей презентации Agile is Dead
Во-вторую очередь отделы управления программами. Те, кто раньше занимался управлением проектами, получали PMP сертификации, рисовали диаграммы Гантта и реализовывали концепцию твердо-мягкого управления (мягкой стороной к руководству и твердой к исполнителям). Дело в том, что в типичном SCRUM для них нет функции, в SAFe — есть. То же самое относится к разного рода архитекторам. В SCRUM для них нет функции в SAFe — есть карьерный путь.
Далее — это может быть выгодно тем владельцам бизнеса, где управляющие работают над большими, пожирающими огромное количество человеко-часов проектами и не могут (иногда по объективным причинам) сделать эти проекты независимыми.
Множеству разработчиков с квалификацией ниже среднего, т.к. часто для того, чтобы что-то сделать их нужно экспоненциально больше чем тех самых опытных и замотивированных профессионалов.
В целом индустрии. Т.к. количество разработчиков удваивается каждые 5 лет (см. uncle bob’s future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.
SAFe — это слоеный пирог из различных методик Agile. На нижнем уровне находится практически традиционный 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 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.
Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.
Плюсы
Недостатки
Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.
Фреймворки масштабирования Agile на компанию
Отмечу, что ячейкой организации в любом случае является автономная самоорганизующаяся Agile-команда, поэтому совместимость способов управления с Agile-культурой является принципиальным требованием. Опыт показывает, что многие подходы менеджмента, основанные на уважении авторитета руководителя, полагаемого безусловным, или следовании за непогрешимым лидером не выдерживают столкновения с Agile-культурой: сотрудники могут просто уйти целой командой. И если руководство привыкло к такому стилю управления, то в Agile нет никакого смысла. С другой стороны, как я говорил в статьях «Три вызова цифрового мира» и «Цифровой мир: от физического труда — к умственному» методы регулярного менеджмента в цифровом мире перестают работать, а Agile-методы являются одной из работающих альтернатив, что подробно рассмотрено в статье «Agile – ответ IT на вызовы цифрового мира».
Фреймворки имеют разную сложность и рассчитаны на компании или подразделения разного размера. При этом большинство из них рассчитано на короткие цепочки создания ценности, когда одна кроссфункциональная команда делает продукт, поставляемый потребителям. Как я писал в статье «Место Agile-команд в компании», в условиях неопределенности и быстрого изменения условий работы компании в VUCA-мире короткие цепочки являются естественным способом организации труда, способным быстро реагировать на изменения, в отличие от стабильных условий функционирования, которые ведут к специализации и образованию длинных цепочек из функциональных подразделений.
Большинство фреймворков, о которых я буду говорить, ориентированы на обеспечение только основной операционной работы компании. Однако, следует учитывать, что границы ответственности команд могут быть существенно различны. Достаточно распространенной является практика, когда в ответственность команд передается найм и увольнение сотрудников, их обучение, а также финансовая ответственность за создаваемый продукт, то есть команда становится независимым подразделением.
В других случаях HR остаются независимым подразделением, так же как бухгалтерия и юридическая служба, и тогда их работа может быть организована как сервисная инфраструктура для команд, работающая по Kanban или одним из гибридных Agile-методов. Сохранение традиционной организации тоже возможно, однако, важно обеспечить хорошее качество сервиса и не служить препятствием для движения команд основного операционного контура.
И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.
Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.
Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.
Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.
Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.
Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.
Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).
Конструкция – очень сложная и многоплановая и во многом обусловленная контекстом компании. Spotify ей делится, но с предостережением: «используйте наши опыт, но не пытайтесь тупо скопировать, оно не взлетит, мы это точно знаем, потому что у нас самих конструкция развивается и растет». Но много попыток именно механического копирования, обычно неудачных. А вот идеи заложены плодотворные.
При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.
Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.
Однако, то что задача по реализации нового функционала делится на несколько, каждую из которых выполняет своя команда, сильно увеличивает количество необходимых синхронизаций и время разработки. Поэтому часто применяется и другой способ организации, кросс-функциональные команды, включающие специалистов по всем приложениям и делают все доработки для новой фичи. При этом возникает общее владение кодом, и надо дополнительно принимать меры для удержания целостности архитектуры каждого приложения, а также обучения и передачи опыта, потому что внутри команды такие специалисты не могут учиться. И это получается структура, похожая на клан в Spotify.
Компания ivi предоставляет чистый цифровой продукт. Однако, похожая бизнес-структура сейчас характерна и для банков и для туроператоров, потому что их продукты сейчас все больше и больше перемещаются в цифровую сферу. Но, насколько я знаю, быстро пересобираться таким образом они еще не умеют, да и для IT опыт ivi является передовым. И, думаю, это может дать хорошее представление о том, какова она – динамично развивающаяся и перестраивающаяся современная цифровая компания, насоклько быстро она умеет изменяться.
Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.
Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.
Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.
На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…
Что такое SAFe?
Узнайте о платформе SAFe, ее принципах и чем она отличается от других agile-платформ.
Просмотр тем
Scaled Agile Framework ® (SAFe ® ) — это набор организационных шаблонов и шаблонов рабочих процессов для реализации agile-методик в масштабе всей компании. Эта платформа представляет собой совокупность знаний, куда входят структурированное руководство по ролям и обязанностям, способы планирования работы и управления ею, а также соответствующие ценности.
Платформа SAFe применяется во множестве agile-команд, обеспечивая согласованность, помогая выполнять совместную работу и поставку. В ее основу легли три основных блока знаний: гибкая (agile) разработка программного обеспечения, «бережливая» (lean) разработка продукции и системное мышление.
SAFe предоставляет структурированный подход к масштабированию agile-методик по мере роста бизнеса. SAFe имеет четыре конфигурации, подходящие для различного масштаба применения: Essential SAFe, Large Solution SAFe, Portfolio SAFe и Full SAFe.
Дин Леффингвелл и Дрю Джемило выпустили платформу SAFe в 2011 году, чтобы помочь организациям разрабатывать более эффективные системы и программное обеспечение, которые лучше соответствовали бы меняющимся потребностям клиентов. В то время для поставки программного обеспечения команды использовали традиционные процессы управления проектами. Поскольку потребность в быстром реагировании на изменяющиеся условия рынка стремительно нарастала, появлялись новые платформы, помогающие бизнесу улучшать поставку решений в масштабах всей компании, в том числе и платформа SAFe. На сегодняшний день SAFe является одной из самых популярных масштабируемых agile-платформ поставки, а всемирное сообщество пользователей SAFe продолжает развивать ее.
Основные принципы и ценности
Основные ценности
Основные ценности SAFe описывают культуру, которую должно продвигать руководство, и поведение людей в этой культуре для эффективного использования данной платформы.
Соответствие
Платформа SAFe требует, чтобы компании устанавливали на всех уровнях организации последовательность планирования и рефлексии. Благодаря этому каждый сотрудник понимает текущее состояние бизнеса, цели и направление движения для достижения таких целей. Регулярная синхронизация людей и действий позволяет поддерживать согласованность всех уровней портфеля. Потоки информации своевременно движутся как вверх, так и вниз, в отличие от традиционных структур управления, где информация спускается сверху вниз.
Встроенное качество
В платформе SAFe гибкость никогда не должна достигаться за счет качества. SAFe требует, чтобы команды всех уровней определяли, в чем заключается «готовность» каждой задачи или проекта, и закрепляли качественные методы разработки в каждом соглашении о сотрудничестве. Согласно SAFe, существует пять основных показателей встроенного качества: процесс, качество архитектуры и дизайна, качество кода, качество системы и качество релиза.
Прозрачность
SAFe поощряет поведение, способствующее построению доверительных отношений, в том числе разбиение работы на пакеты сокращенного объема при планировании, чтобы быстрее выявлять проблемы, обеспечение в бэклоге наглядного представления прогресса по всем уровням в режиме реального времени, а также проверку и адаптацию ритуалов.
Выполнение программы
Выполнение программы лежит в основе SAFe и поддерживает все остальное на платформе. Команды и программы должны на регулярной основе доставлять качественное, работающее программное обеспечение и коммерческую ценность.
Руководство
SAFe требует от руководителей поведения, в котором сочетаются принципы бережливости и гибкости, поскольку только руководители могут изменить систему и создать среду, необходимую для внедрения всех ключевых ценностей.
Принципы SAFe
Принципы Scaled Agile Framework предусматривают улучшение компании в целом за счет принятия гибких и бережливых решений с охватом всех функциональных и организационных единиц. Эти принципы влияют не только на решения руководителей и менеджеров, но и на решения каждого сотрудника организации; они обуславливают необходимость перехода от традиционного мышления к мышлению, опирающемуся на методы гибкого и бережливого управления, которые применяются, к примеру, в практиках Lean Portfolio Management.
Принцип № 1. Смотрите с точки зрения экономики
Согласно теориям о процессе разработки продуктов, приводимым в бестселлерах Дональда Райнертсена, для достижения кратчайшего устойчивого времени выполнения нового заказа необходимо, чтобы каждый человек в цепочке принятия решений понимал экономические последствия задержек. Скорой и частой поставки не всегда достаточно. Согласно SAFe, по всей организации необходимо распределить следующие задачи: определение последовательности работ для получения максимальной выгоды, понимание экономических компромиссов и работу в рамках «бережливых» бюджетов. Многие концепции и инструменты опираются на теории Райнертсена о процессе разработки продуктов.
Принцип № 2. Применяйте системное мышление
Платформа SAFe создает условия для применения системного мышления в трех основных областях: собственно решение, компания, которая занимается разработкой системы, и потоки создания ценности. Решениями могут быть продукты, услуги или системы, поставляемые клиентам, как внутренним, так и внешним по отношению к предприятию.
Крупные решения имеют множество взаимосвязанных составных частей, поэтому участники команды должны обладать высокоуровневым представлением о том, как их часть вписывается в общую картину. При решении вопросов, которые касаются компании, занимающейся построением системы, платформа SAF рекомендует учитывать людей, менеджмент и процессы организации. Так, если организация стремится оптимизировать методы работы людей, ей может потребоваться устранить барьеры, стать межфункциональной и сформировать новые рабочие соглашения с поставщиками и клиентами. Наконец, компания должна четко определить, каким образом потоки создания ценности при разработке решения превращают ценность из концепции в измеримую прибыль. Руководителям и менеджменту необходимо добиться максимального увеличения потока создания ценности по всем функциональным и организационным единицам.
Принцип № 3. Допускайте вариативность; сохраняйте варианты
По умолчанию проектирование систем и программного обеспечения является занятием с неопределенным исходом. Данный принцип решает проблему неопределенности путем введения концепции вариативного проектирования (Set-Based Design), которое требует сохранять в цикле разработки множество требований и вариантов разработки на протяжении длительного времени. Вариативное проектирование опирается на эмпирические данные, чтобы к окончательному варианту разработки можно было переходить на более поздних этапах.
Вариативное проектирование помогает принимать обоснованные решения в периоды неопределенности путем выявления вариантов и ожидаемых конечных результатов; это похоже на стратегическую ставку. Важную роль в вариативном проектировании играют «контрольные точки обучения», которые связаны с крайним сроком принятия решения. Чем больше знаний команды обретают с течением времени, тем больше вариантов они могут исключить. Чем больше вариантов они исключат, тем легче будет определить оптимальный путь и достичь наилучшего из возможных результатов для клиентов.
Принцип № 4. Выполняйте инкрементальные сборки с быстрыми циклами обучения, интегрированными в процесс
Как и принцип № 3, этот принцип направлен на устранение рисков и неопределенности с помощью контрольных точек обучения. Недостаточно, чтобы работоспособность доказала каждая составляющая часть системы. Необходимо рассмотреть систему в целом, чтобы оценить возможность технической реализации текущих вариантов разработки. Чтобы ускорить циклы дальнейшего обучения, необходимо регулярно планировать последовательности точек интеграции. Эти точки интеграции являются примером цикла Уолтера Э. Шухарта планируй — делай — проверяй — корректируй, который является схемой для постоянного улучшения качества и механизмов контроля вариативности разработки. В SAFe часто используются работа Шухарта и другие работы, вдохновленные его трудами.
Принцип № 5. Контрольные точки должны основываться на объективной оценке работающих систем
Демонстрация действующей рабочей системы предоставляет более надежные основания для принятия решений, чем документ с требованиями или другая поверхностная оценка успеха. Заинтересованные стороны, с ранних этапов участвующие в принятии решений о технической реализации, способствуют построению доверительных отношений и поддерживают системное мышление.
Принцип № 6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей
Ограничение объема незавершенной работы помогает заинтересованным сторонам четко увидеть, как идет процесс.
Три элемента этого принципа демонстрируют основные способы максимального увеличения объема и скорости поставки ценности, т. е. реализации «потока». Как говорится, слона лучше есть по кусочкам.
Применительно к разработке программного обеспечения это означает ограничение количества параллельных работ, сложности каждого элемента работы и общего объема работы, выполняемой в данный момент времени. Небольшие задачи позволяют проводить постоянную проверку правильности хода работы и должным образом управлять длиной очереди.
Этот принцип служит ориентиром в оптимизации этих задач для достижения наилучших результатов.
Принцип № 7. Применяйте каденции, выполняйте синхронизацию с помощью кросс-доменного планирования
Agile-команды применяют каденции с помощью спринтов или итераций. Создание каденции для всех возможных работ позволяет уменьшить сложность, устранить неопределенность, выработать автоматизм, обеспечить качество и постепенно прививать сотрудничество. Синхронизация этих каденций позволяет людям и активностям перемещаться подобно винтикам механизма, где полученная информация сообщает о решениях и инкрементном планировании.
Принцип № 8. Раскройте внутреннюю мотивацию работников умственного труда
Этот принцип создан под влиянием идей консультанта по управлению Питера Друкера и автора Дэниела Пинка, и мы его очень любим! Речь идет о раскрытии потенциала команд и замене командно-административного мышления руководства на обучающий и помогающий подход к работе с командами.
Принцип № 9. Децентрализуйте принятие решений
Сокращение длины очередей и использование экономически эффективного подхода путем децентрализации процесса принятия решений дают командам независимость, необходимую для выполнения работы. Руководители должны сохранять свои полномочия по принятию решений по вопросам стратегической важности и позволять командам решать все остальные вопросы.
Как работает SAFe?
Организации, готовые внедрить платформу SAFe, обычно обладают поддержкой на уровне руководства, сильным намерением измениться и фундаментом в виде scrum.
Компания Scaled Agile, Inc. предоставляет дорожную карту внедрения SAFe, которая содержит подробные инструкции по началу работы и подготовке организации к проведению широкомасштабного применения платформы по всем портфелям. Внедрение SAFe состоит из следующих 12 шагов.
Чем SAFe отличается от других масштабируемых agile-платформ?
Несмотря на то, что платформа Scaled Agile Framework® (SAFe®) широко распространена среди предприятий с большими командами разработчиков программного обеспечения, с течением времени набрали популярность и другие масштабируемые agile-платформы. Все платформы для масштабирования agile объединяют пять основных компонентов: вдохновение от 12 принципов манифеста agile-методологии, последовательность действий, синхронизация, scrum и методы качественной разработки. Понимание происхождения других платформ, основных отличий и условий их успешного применения поможет организациям выбрать структуру, которая оптимально соответствует их потребностям.
Хотите познакомиться с предысторией некоторых основных масштабируемых agile-платформ? Прочтите обзор Agile-подход при любом масштабе на странице тренера по agile.
SAFe и Scrum@Scale
В Scrum@Scale (S@S) каждый сотрудник является частью взаимозаменяемой scrum-команды. В зависимости от целей сети scrum-команд объединяются, образуя экосистему. Платформа S@S предназначена для создания сети scrum-команд с помощью «немасштабируемой архитектуры», т. е. основные роли и события scrum масштабируются линейно, без введения в процесс новых движущих сил. Например, для очень сложного продукта с 25 scrum-командами одного Scrum of Scrum (SoS) может оказаться недостаточно, и тогда понадобится Scrum of Scrum of Scrums (SoSoS) и Scrum of Scrum of Scrums Master (SoSM).
Несмотря на то что платформа S@S в целом носит менее директивный характер, для определения готовности организации к масштабированию она предлагает ответить на один наводящий вопрос: если в систему добавить больше людей, производительность резко возрастет или ухудшится?
Как и SAFe, платформа S@S предлагает справочные материалы, доступные онлайн, в том числе набирающее популярность подробное руководство Scrum@Scale.
S@S приносит наибольшую пользу, когда:
SAFe и Large-Scale Scrum (LeSS)
Large-Scale Scrum (LeSS) применяет минималистический подход к ролям, структуре и артефактам. Там, где SAFe предлагает четыре конфигурации размещения все более крупных команд со все более сложными решениями, LeSS предлагает две: LeSS для организаций с 2–8 командами и LeSS Huge для организаций более чем с 8 командами. Согласно LeSS, владельцы продуктов должны обладать всеми полномочиями и стратегическим влиянием на контент, тогда как SAFe предлагает более демократичный подход. В то время как в SAFe многие факторы влияют на стратегию, LeSS опирается на клиентоориентированный подход с фокусом на клиентах, оплачивающих услуги.
Как и S@S, LeSS масштабируется на основе событий, артефактов и ролей scrum. И SAFe, и LeSS придают особое значение системному и бережливому мышлению, а также схожим руководящим принципам. Однако LeSS уделяет большое внимание сокращению отходов во всей организации с целью постоянной оптимизации.
LeSS приносит наибольшую пользу, когда:
SAFe и DA
В отличие от остальных описанных платформ, платформа Disciplined Agile (DA) представляет собой набор инструментов, который позволяет организациям решать, какой способ работы подходит им лучше всего. Она предлагает упрощенное agile-управление на основе scrum и kanban, а также способствующие трансформации знания в таких областях, как управление персоналом и финансами, менеджмент, DevOps, управление портфелем и многих других. DA предполагает ситуационное использование различных уровней масштабирования для каждого проекта и акцентирует внимание на том, что для определения стратегического направления необходимо создать условия для принятия решений.
DA приносит наибольшую пользу, когда:
SAFe и Spotify
«Модель» Spotify — это автономный набор практик с акцентом на людей, который можно применять для координации agile-команд. Она не задумывалась как модель или платформа, но некоторые компании внедрили ее именно в таком варианте. Модель Spotify ориентирована на самоорганизующиеся многофункциональные команды, расположенные в одном месте; их называют «отрядами» (эквивалент scrum-команд). Для сравнения, в SAFe нет оговорки по поводу совместного нахождения команд, которое рекомендуется для проведения PI-планирования.
Отряды организованы в более крупные подразделения, называемые «кланами». Проблемы, вызванные немногочисленными зависимостями между отрядами, при необходимости разрешаются на основе принципов Scrum of Scrums. Обмен знаниями происходит через «отделы» и «гильдии»; такие неформальные группы организуются на основе наборов навыков и интересов.
В отличие от других примеров, где доступны онлайн-ресурсы, учебные курсы и сертификации, ресурсы Spotify ограничиваются общедоступным блогом и другими сопутствующими материалами, разработанными основоположниками и поклонниками этой модели. Поскольку популярность Spotify растет, вероятно, в будущем мы увидим больше соответствующих материалов.
Spotify приносит наибольшую пользу, когда:
SAFe 5.0
Основным принципом SAFe является то, что эта платформа продолжает развиваться совместно с сообществом своих пользователей по всему миру. Совсем недавно компания Scaled Agile, Inc. выпустила SAFe версии 5.0. Основными изменениями стали добавление принципа № 10 «Организация происходит вокруг ценности» и изменение шага 12 с «Поддерживайте и улучшайте» на «Ускоряйте». На самом деле изменений гораздо больше. Хотите узнать подробности? Ознакомьтесь со статьей о том, что появилось и что изменилось в SAFe 5.0, в нашем блоге.
Заключение
Платформы типа SAFe и рассмотренных выше предоставляют компаниям экономически приемлемый способ эффективного масштабирования методики agile в организациях и достижения конечных бизнес-результатов. Но не менее важны и инструменты, которые они выбирают для укрепления существующих методов работы и реализации всех преимуществ этих методов. Используйте Jira Align от Atlassian, платформу для корпоративного agile-планирования, созданную для SAFe. С помощью Jira Align вы сможете повысить наглядность, стратегическое соответствие и адаптивность предприятия для ускорения цифрового преобразования.
Джессика Пииккила более десяти лет работает в сфере agile-преобразований, к тому же имеет большой опыт управления продуктами и agile-консультирования в компаниях разного размера из разнообразных отраслей. Привычка мыслить в категориях agile помогла ей пройти через ряд сложных жизненных ситуаций и питает страсть к обучению. Вы увидите, как она находит ключи к внедрению agile на корпоративном уровне вместе с нашими клиентами.