Что такое 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, адаптированный именно для госуправления (западного).
Как мы масштабировали agile в тестировании: обзор Scaled Agile Framework
Предлагаем поговорить про гибкие методологии. Но речь пойдет не про Scrum, с которым многие знакомы не понаслышке, а про SAFe – методологию, которая позволяет делать гибким процесс разработки ПО в очень больших командах.
Начнем с предыстории. У нас есть заказчик, качество продуктов которого мы обеспечиваем уже более четырех лет. Работа над его решениями строилась по Scrum’у до тех пор, пока однажды он не поставил нас перед фактом: с завтрашнего дня переходим на SAFe. Данный фреймворк можно отнести к редко используемым, и мы решили не упускать возможности детально его изучить.
Внедрение SAFe происходило методом проб и ошибок, но в итоге процесс был настроен, оптимизирован и уже более полутора лет успешно работает.
Мы решили поделиться интересным опытом и надеемся, что наши советы будут полезны и предупредят сложности, которые могут возникнуть у вашей команды.
В этой и еще четырех статьях мы дадим базовое представление о SAFe, расскажем о том, какие уровни он включает. Кроме этого, поделимся своим опытом внедрения фреймворка и перечислим главные отличия от обычного Scrum’а. Итак, начнем.
Что такое SAFe?
На запрос «Что такое SAFe?» в Google мы получили вот такую диаграмму:
Scaled Agile Framework – это набор правил и предписаний для внедрения agile-принципов в больших организациях. Одной из причин популярности данного фреймворка сегодня – это неудачный опыт использования agile-принципов на крупных предприятиях, которые, с одной стороны, стремятся соответствовать принципам agile, а, с другой стороны, хотят добиться предсказуемости сроков выпуска продукта. Всем им необходим проверенный подход, который можно было бы «развернуть» среди многочисленных команд разработки.
Когда стоит внедрять SAFe?
Наличие следующих предпосылок говорит о том, что на предприятии можно подумать о внедрении SAFe:
Допустим, нам нужно увязать между собой разработку и релиз более чем 15 программных решений, каждое из которых имеет более десятка stakeholder’ов. Решения разрабатываются 10 командами из 5 стран. Такого уровня задачу решить с помощью традиционного Scrum’а невозможно.
Какое решение предлагает SAFe?
SAFe разбивает любое предприятие на три уровня:
Давайте разберемся на примере простого вымышленного проекта, что собой представляет каждый из уровней.
Допустим, нам нужно доработать веб-приложение для книжного магазина. Основные функции текущей версии просты: на сайте через поиск можно найти книгу и оставить предзаказ. Когда заказ готов, менеджер связывается с покупателем, и тот самостоятельно забирает его со склада. Очевидно, что функциональность описанной версии веб-сайта весьма ограничена. Чтобы добавить конкурентных преимуществ, нужно придумать дополнительную функциональность на сайт.
Работа начинается на уровне портфолио. Здесь центральным является понятие «бизнес-эпика», которое отражает наиболее приоритетные направления развития продукта в ближайшее время. Эпики бывают функциональные и архитектурные.
Для нашего веб-сайта примерами функциональных эпиков будут следующие: «Организовать доставку по стране с возможностью отслеживания обработки заказа в личном кабинете» и «Создать онлайн-площадку для общения любителей книг». Примерами архитектурных эпиков могут быть «Интеграция с геоинформационными системами» и «Перенос системы в облако».
SAFe: пока все просто, спускаемся ниже
На уровне программ эпики разбиваются на фичи, т.е. куски функциональности, реализующие данный эпик. Фича – это ограниченный, чаще всего крупный кусок функциональности, который приносит определенную пользу бизнесу или позволяет конечному пользователю решать какую-либо задачу.
Давайте возьмем один из эпиков и детализируем его до уровня команд. Например, функциональный эпик про создание площадки для общения онлайн. На уровне программ он будет представлен фичами «Управление профилем пользователя», «Форум» и «Личные сообщения».
На уровне команд требуется еще большая декомпозиция задач. Каждая фича должна быть разбита на несколько понятных и четко сформулированных пользовательских историй (user stories), которые можно оценить и реализовать в течение спринта.
Например, фичу «Личные сообщения» можно декомпозировать в следующие пользовательские истории: «Возможность отправлять сообщения», «Возможность получать сообщения», «Сохранение истории переписки». Такая же декомпозиция потребуется и для архитектурных эпиков.
Таким образом, по мере спуска с уровня портфолио к уровню команд, задачи уменьшаются, а их границы уточняются. Соответственно, оценки также становятся точнее.
В следующей статье мы расскажем подробнее про то, как организуется работа на каждом из уровней SAFe.
Связаться с нами можно через форму обратной связи.
Фреймворки масштабирования 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, кому он нужен и где его применять
Scaled Agile Framework® (SAFe) — это онлайн-база знаний, состоящая из доказанных, интегрированных принципов, практик и компетенций внедрения Lean, Agile и DevOps при масштабировании.
Так что это, Scaled Agile Framework или SAFe?
Методология Scaled Agile Framework — это гибкий фреймворк для масштабирования процессов и проектов в организациях, плавающий в айти-вселенной на трех китах: Команда, Программа и Портфель.
Думаете, это выглядит так?
Нет. По сути, SAFe внедряет принципы равенства лишь внутри каждого из китов:
Вся же структура организации выглядит как-то так:
На первом этаже SAFe — Scrum
Это почти что классический скрам: команды по 3-9 человек, спринты по 2-3 недели, скрам-роли, скрам-артефакты и скрам-события. Но только команда теперь не полностью независима. И спринт не полностью самостоятелен.
Для того, чтобы связать между собой работу разных команд над одним продуктом, спринты теперь объединяются в программные инкременты (обычно 5 спринтов = 1 PI). И если в Scrum коррекция производилась по окончанию каждого отдельного спринта, то в SAFe — по окончанию PI. В чем-то это экономит время и упрощает работу в масштабе. С другой стороны, если мы ошиблись вначале, то часто тащим и развиваем этот груз до следующего PI Planning.
На втором этаже SAFe
Ходят Agile Release Trains (по-простому поезда). Здесь же “живут” носители новых ролей: системный архитектор (управляющий архитектурой), продакт-менеджер (старше владельца продукта по званию и полномочиям) и Release Train Engineer (тот же профессионал проектного менеджмента, по-простому PMP в SAFe).
На втором этаже SAFe добавляются некоторые наработки канбана — velocity metrics, scope, способ назначения приоритетов и, конечно же, доска.
Последний из 5 спринтов объявляется организационным. На собрания этого спринта приходят все команды, то есть, 100 и более человек. Здесь анализируется технический долг, производится планирование архитектуры и в целом синхронизируется работа команд.
На третьем этаже SAFe
Происходит координация больших систем и взаимодействия между директорами, отделами и клиентом. На этом этаже анализируются и проверяются гипотезы, а также создаются долгосрочные планы (ура waterfall).
Этот этаж может быть последним, если у компании нет портфеля. А вот если есть…
На четвертом этаже SAFe
Происходит бережливое управление портфелем — Lean Portfolio Management. Здесь выбираются перспективные направления и распределяются средства, принимаются решения о покупке или слиянии организаций, создаются новые направления и закрываются старые. На этом этаже рождается, корректируется и переназначается бюджет. Для оценивания существует ряд метрик, для синхронизации — свои ритуалы.
“Вишенка на торте” — стратегия. Но так глубоко фреймворк SAFe уже не заходит.
Ценности SAFe
Четыре основные ценности SAFe — это ключ и основа для эффективного применения этой методологии.
1. Согласованность
Согласованность необходима, чтобы идти в ногу с быстрыми изменениями, разрушительными силами конкуренции и географически распределенными командами.
Согласованность не подразумевает и не поощряет каскадный менеджмент. Согласование происходит, когда все работают в одном направлении. Оно обеспечивает расширение прав и возможностей, автономию и децентрализованное принятие решений, позволяя тем, кто реализует ценности, принимать более правильные решения на местном уровне.
2. Встроенное качество
Встроенное качество гарантирует, что каждый элемент и инкремент решения отражает стандарты качества на протяжении всего жизненного цикла разработки. Качество — это не то, что «добавляется позже».
Повышение качества является требованием бережливого производства и потока — без него организация, скорее всего, будет работать с большими партиями непроверенной работы. Вероятные результаты — чрезмерная потребность в переделках и снижение скорости.
3. Прозрачность
Без доверия никто не может создать высокопроизводительные команды и программы, а также укрепить (или восстановить) уверенность, необходимую для принятия и выполнения разумных обязательств. Без доверия рабочая среда намного менее увлекательна и меньше мотивирует.
Прозрачность, которую вы обеспечиваете с помощью некоторых практик SAFe, — первый шаг к доверию.
4. Программная реализация
Первые три ценности SAFe не имеют значения, если команды не могут работать и постоянно доставлять ценность. Поэтому SAFe уделяет большое внимание рабочим системам и бизнес-результатам.
Первые три ценности позволяют командам SAFe сосредоточиться на четвертой. И если они будут бороться (а они будут, потому что разработка сложных решений — непростая задача), у них есть краеугольный камень воркшопов по инспекции и адаптации. Таким образом, они замыкают цикл и работают все лучше и лучше во время каждого программного инкремента.
Все эти ценности невозможны без настоящего Lean-Agile лидерства и культуры непрерывного обучения. Только так, создавая постоянную и осмысленную культуру для команд и стейкхолдеров, можно организовать постоянную поставку ценности в потоке.
Принципы SAFe
1. Обосновывайте экономически. Традиционно бюджеты были известны только лицам, принимающим решения. Повседневные решения участников процесса на всех уровнях принимались без понимания экономической составляющей. Это приводило к задержкам, ограниченным возможностям и сниженной эффективности команд на всех уровнях.Экономика должна обосновывать и определять решения на всех уровнях, от портфолио до гибких команд.
2. Мыслите системно. Системное мышление предполагает целостный подход к разработке решений, включающий все аспекты системы и ее среды в ее проектирование, разработку, развертывание и обслуживание.Три аспекта системного мышления:
Понимание этих концепций помогает лидерам и командам ориентироваться в сложности разработки решения, организации и общей картине времени вывода на рынок в целом.
3. Предполагайте изменчивость. Сохраняйте варианты. Человеческая природа стремится к стабильности и устойчивости. Чем меньше изменений, тем нам спокойнее.Изменчивость сама по себе — это ни плохо, ни хорошо. Однако, именно экономика, связанная со сроками и типом изменчивости, определяет результаты. Наша цель в том, чтобы управлять изменчивостью и сохранять варианты. Так у нас будет и контроль, и гибкость, необходимые командам для разработки отличных решений.
4. Разрабатывайте поэтапно (инкрементально) с помощью быстрых интегрированных циклов обучения. Вместо того, чтобы на раннем этапе выбрать один вариант требований и дизайна, мы строим решение постепенно, каждый раз учитывая серию требований и вариантов дизайна.Каждый результат дает инкремент рабочей системы, который можно оценить отдельно. Дальнейшие временные рамки основываются на предыдущих шагах. Так решение развивается поэтапно вплоть до релиза.
5. Основывайте майлстоуны на объективной оценке рабочих систем. Обычно в отрасли применяется последовательный каскадный процесс разработки, где измерение и контроль прогресса происходит через ряд конкретных этапов: открытие идеи, подготовка требований, дизайн, разработку, тестирование и доставку.SAFe советует не привязываться к этим этапам, а определять контрольные точки для инспекции и адаптации исходя из конкретной рабочей системы, над которой работает команда команд. Благодаря этому систему можно будет проверять и улучшать чаще, и делать это будут стейкхолдеры, релевантные конкретному этапу разработки. Коммерческая ценность системы также повысится.
6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей. Ограничьте количество параллельно реализуемых решений. Поработайте над тем, чтобы уменьшить сложность каждого элемента и всей работы целиком.Небольшие задачи позволяют чаще проверять правильность направления и лучше контролировать очередь задач.
7. Применяйте каденции и выполняйте синхронизацию с помощью кросс-доменного планирования. Гибкая разработка лучше всего работает в «зоне безопасности», где достаточная неопределенность обеспечивает свободу для внедрения инноваций и реагирования на события, а также уверенность в работе бизнеса. Основное средство достижения этого баланса — объективное знание текущего состояния. Эти знания приобретаются путем применения каденции, синхронизации и периодического междоменного планирования.Каденция — это ритмичный паттерн событий, обеспечивающий устойчивое сердцебиение процесса развития. Он делает рутинным все, что может быть рутинным, поэтому разработчики могут сосредоточиться на управлении переменной частью разработки решения.Синхронизация позволяет одновременно понять, решить и интегрировать несколько точек зрения.В дополнение к общей каденции, периодическое междоменное планирование (пример: PI Planning в SAFe) дает возможность одновременно интегрировать и оценивать различные аспекты решения — деловые и технические.Вcе это позволяет управлять изменчивостью за счет частого пересмотра и обновления плана.
8. Раскройте внутреннюю мотивацию работников умственного труда. С SAFe, работники умственного труда могут больше:
9. Децентрализируйте процесс принятия решений. Централизировать нужно только решения стратегического характера. Они:
Все прочее нужно решать на местах.
10. Организовывайте вокруг ценности. Этот принцип описывает, как освободить предприятие от самоорганизации, оптимизируя доставку ценности. Это получается сделать за счет трех вложенных частей: