План управления проектом, часть 2: всестороннее сравнение Waterfall, DAD, SAFe, LeSS и Scrum@Scale

Обзор

В части 1 схемы управления проектами мы рассмотрели методологии разработки программного обеспечения Lean Software Development, Agile, Scrum и Kanban, а также то, как все они восходят к бережливому производству. Эти методологии обычно развертываются на уровне одной команды. Однако сложность растет по мере того, как проекты и проектные группы становятся больше, и необходимы новые подходы, чтобы быть гибкими в масштабе.

Во второй части мы сначала рассмотрим, как менеджеры проектов используют методологию водопада, которая является наиболее распространенной основой для разработки программного обеспечения в традиционных компаниях. Наряду с этим мы рассмотрим самые популярные фреймворки, которые пытаются внедрить гибкие принципы в масштабе: Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), крупномасштабный Scrum (LeSS) и Scrum@Scale.

Водопад

Методология водопада (также известная как модель жизненного цикла разработки программного обеспечения (SDLC)) — это более традиционная методология, в которой разработка программного обеспечения переходит от одной фазы к другой подобно водопаду. Фазы не перекрываются и имеют определенные критерии входа и выхода для перехода от одной фазы к другой.

Шесть этапов жизненного цикла исходной водопадной модели:

1. Требования: на этом этапе определяются ожидания и цели проекта, а требования тщательно анализируются и документируются, как правило, бизнес-аналитиком. Перед выходом из этой фазы требования рассматриваются и утверждаются.
2. Дизайн: после утверждения требований начинается работа по архитектуре и проектированию продукта в соответствии с утвержденными требованиями. Физическая архитектура, архитектура компонентов, дизайн базы данных, подробный компонент, дизайн модуля и другие аспекты проекта документируются архитектором или разработчиком программного обеспечения. Затем он рассматривается и утверждается перед началом реализации.
3. Внедрение: после утверждения дизайна разработчики программного обеспечения выполняют реализацию или кодирование программного обеспечения в соответствии с требованиями и дизайном.
4. Проверка: после завершения внедрения программное обеспечение тестируется группой тестирования или контроля качества, чтобы убедиться, что требования и дизайн соблюдены, а желаемый уровень качества достигнут. Дефекты обнаруживаются, регистрируются, сортируются и во многих случаях исправляются.
5. Выпуск и обслуживание: после завершения тестирования и отладки продукт передается клиенту и устанавливается. Часто проводится цикл тестирования, чтобы убедиться, что установка прошла успешно. После доставки продукта осуществляется текущее обслуживание и поддержка, чтобы гарантировать, что продукт продолжает работать в соответствии с проектом.

Преимущества водопада

У водопада есть некоторые преимущества, и он подходит для определенных типов проектов, но есть и серьезные недостатки. Waterfall лучше всего подходит для более коротких проектов, где требования и технологии хорошо понятны и вряд ли изменятся каким-либо существенным образом.

Применительно к правильному типу проекта некоторые из преимуществ модели водопада:

• Простота. Водопад прост в реализации из-за того, что заранее определяется объем, а также из-за жестких фаз и четкого перехода от одной фазы к другой.
• Наглядность: заинтересованным сторонам легче измерить и увидеть прогресс, поскольку полный объем работ известен заранее и по мере перехода проекта от одного этапа к другому.
• Документация. Объем, требования и планы могут быть тщательно продуманы и хорошо задокументированы, что облегчает работу над проектом менее опытным командам.
• Поэтапная работа: из-за жестких ролей и перехода между фазами ресурсы проекта могут работать над другими проектами, когда их основная фаза не выполняется.

Недостатки водопада

Waterfall не подходит для более длинных проектов, где требования не совсем понятны и/или могут измениться, и/или где существует значительный технический риск. В сегодняшнюю эпоху, когда рыночные условия постоянно меняются и время выхода на рынок имеет решающее значение, это относится к большинству программных проектов.

Недостатки модели водопада, которые в основном связаны с ее неспособностью адаптироваться к изменениям, включают:

• Монолитный масштаб: это вознаграждает заинтересованные стороны думать обо ВСЕХ при определении масштаба проекта, что приводит к монолитному масштабу.
• Запоздалая обратная связь с клиентом. Заинтересованным сторонам и особенно клиентам трудно представить себе все детали проекта. Поскольку водопад предоставляет клиентам результаты проекта в основном на последних этапах проекта, неизбежно становится трудно включить отзывы клиентов в проект.
• Изменение требований: в более длительных проектах рыночные условия и, следовательно, цели и требования проекта подвержены очень высокому риску изменения в ходе проекта.
• Ценность, созданная в конце: Waterfall требует большой работы заранее, а это означает, что ценность создается только в конце проекта.
• Взаимозависимость фаз: внесение изменений часто приводит к изменениям требований и/или дизайну, которые могут повлиять на другие области проекта. Зависимость более поздних стадий от более ранних может сделать небольшие изменения в проекте несоразмерно сложными.

Дисциплинированная гибкая поставка (DAD)

Дисциплинированная гибкая поставка (DAD) была формализована Скоттом Амблер из IBM и Марком Лайнсом и расширяет рамки agile и scrum, признавая, что негибкие части организации обычно участвуют в реализации программного проекта в той или иной степени. Эта структура явно включает действия из ИТ-операций, архитектуры предприятия, управления портфелем, финансами и закупками в полный жизненный цикл доставки. DAD стремится повысить общую гибкость бизнеса прагматичным образом.

Основные принципы и компоненты

Роли

В DAD значительно больше ролей, чем в схватке, и она делится на две категории командных ролей. Первичные роли занимают люди, которые работают с проектом на постоянной основе. Второстепенные роли обычно вводятся временно, чтобы помочь команде с масштабированием или другими проблемами. DAD имеет эти дополнительные роли, потому что он охватывает весь жизненный цикл решения и распознает различные типы необходимых временных и вспомогательных ролей, встречающихся в реальном мире.

Основные роли:

1. Заинтересованное лицо: кто-то, кто зависит от вашей команды, заканчивающей проект: клиент, конечный пользователь или внутренний коллега.
2. Член команды: люди в команде, которые фактически выполняют запланированную работу: разработчики, дизайнеры, тестировщики и т. д.
3. Лидер команды: по аналогии со скрам-мастером, лидер команды работает как лидер-слуга для команды, устраняя препятствия, способствуя сплочению команды и распространяя ценности Agile.
4. Владелец продукта: иногда его называют «голосом клиента». Владелец продукта представляет заинтересованные стороны и поддерживает приоритетный список работ, которые необходимо выполнить.
5. Владелец архитектуры: отвечает за снижение риска архитектуры в масштабе. Эта роль обычно выполняется старшим разработчиком в команде, поскольку она требует глубоких технических знаний и глубоких знаний в области бизнеса.

Второстепенные роли:

1. Специалист: люди, которые временно присоединяются к команде, чтобы помочь в специальной роли. Например, аналитик данных может присоединиться, чтобы предоставить исследовательские возможности на ранних стадиях проекта.
2. Эксперт в предметной области: налоговые консультанты, юрисконсульты и другие люди, обладающие знаниями в предметной области и помогающие команде в решении соответствующих задач.
3. Технический эксперт: администратор базы данных, мастер сборки эксперта по безопасности и т. д. Эти люди помогают членам команды более общего профиля в ключевые моменты жизненного цикла.
4. Независимый тестировщик. Хотя тестировщики обычно являются частью основной команды, в некоторых случаях в соответствии с жизненными нормативными требованиями или очень сложными системами независимые тестировщики работают параллельно для проверки выполненной работы.
5. Интегратор: в масштабе разные команды работают над разными частями всей системы. Интегратор помогает команде интегрировать свою часть со всей системой и управляет зависимостями.

Поддержка жизненного цикла

DAD продвигает полный жизненный цикл доставки, а не только часть программирования и выпуска, охватываемую agile/scrum, но также начальный этап, на котором определяется и утверждается видение проекта, а также этапы поддержки и вывода из эксплуатации после выпуска. В настоящее время DAD поддерживает 6 различных жизненных циклов:

• Жизненный цикл Agile: жизненный цикл проекта на основе Scrum
• Жизненный цикл бережливого производства: жизненный цикл проекта на основе Канбана
• Непрерывная доставка: гибкий жизненный цикл
• Непрерывная доставка: экономичный жизненный цикл
• Жизненный цикл исследовательского (бережливого стартапа)
• Жизненный цикл программы для команды команд

Эти жизненные циклы учитывают различные стили работы, уровни гибкости компании и другие ситуации, в которых могут оказаться команды. Суть в том, что эти жизненные циклы действуют как предложения. DAD продвигает прагматизм, а не пуризм, поскольку каждая ситуация уникальна, и дисциплинированные agile-практики должны адаптировать agile-процесс к своим потребностям.

Цели процесса

DAD использует целеустремленный подход к созданию и адаптации гибких процессов. Авторы этой методологии выделяют 21 наиболее важный и распространенный процесс, с которым сталкивается большинство команд в течение своего жизненного цикла.

Все эти процессы имеют задокументированные точки принятия решений, которые потребуют от команды принятия решения о том, как они будут структурировать этот процесс. Каждая точка принятия решения предоставляет предлагаемые методы или практики, которые можно использовать для реализации решения. Вы можете увидеть пример этого на изображении ниже. Процесс «Разработка общего видения» включает 6 решений, которые необходимо принять. Каждое из этих решений имеет от 2 до 5 рекомендуемых практик. Стрелки указывают на то, что авторы DAD упорядочили список так, чтобы верхний элемент соответствовал наилучшей практике, а нижний элемент — наихудшей практике в этом списке. Текст , выделенный полужирным курсивом, означает хорошую отправную точку для новых команд, которые только начинают работать с DAD.

Масштабирование DAD

Disciplined Agile Delivery подходит к масштабированию с двух разных точек зрения:

• Тактическая маневренность в масштабе

• Стратегическая гибкость в масштабе

Тактическая маневренность пытается учитывать факторы масштабирования отдельных команд, такие как размер, географическое распределение, сложность проекта и т. д., посредством ситуационного применения целей процесса и предлагаемых практик.

Стратегическая гибкость пытается решить проблему масштабирования за счет применения гибких и бережливых стратегий в широком масштабе во всей организации, расширяя структуру для охвата различных областей организации:

• Disciplined DevOps: охватывает использование DevOps для обеспечения более эффективных результатов для организации.

• Disciplined Agile IT (DAIT): рассказывает, как применять гибкие и бережливые стратегии ко всем аспектам ИТ.

• Дисциплинированное Agile Enterprise:. охватывает, как применять бережливое и гибкое управление на предприятии.

Безопасно

Scaled Agile Framework (SAFe) — самая популярная, а также самая сложная и всесторонняя масштабируемая Agile-инфраструктура на данный момент. 29% респондентов ежегодного отчета State of Agile утверждают, что используют эту структуру в своих организациях. В свою очередь, на рынке есть много менеджеров проектов SAFe.

Началом SAFe послужила книга Дина Леффингвелла «Масштабирование гибкости программного обеспечения: лучшие практики для крупных предприятий», опубликованная в 2007 году. Сейчас Леффингвелл является главным методологом SAFe, но многие другие люди также вносят свой вклад в эту структуру. В настоящее время в версии 4.6 этот фреймворк напоминает программный продукт с управлением версиями, обратной совместимостью и различными компонентами.

Основные принципы и компоненты

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

SAFe for Lean Enterprises пытается создать бережливое предприятие, предоставляя базу знаний проверенных принципов, компетенций и лучших практик.

SAFe 4.6 определяет пять основных компетенций бережливого предприятия. Каждая компетенция представляет собой набор связанных знаний, навыков и поведенческих моделей, которые вместе позволяют организациям преуспеть:

1. Лидерство Lean-Agile : описывает, как лидеры управляют организационными изменениями и поддерживают их посредством обучения, обучения и внедрения мышления SAFe Lean-Agile.

2. Командная и техническая гибкость : описывает навыки, принципы и практики, необходимые для создания высокоэффективных Agile-команд.

3. DevOps и выпуск по запросу : описывает, как внедрение DevOps и конвейера непрерывной доставки предоставляет организациям возможность выпускать обновления продукта в любое время, необходимое для удовлетворения спроса.

4. Бизнес-решения и проектирование бережливых систем : описывает, как применять принципы и методы бережливой гибкости к спецификации, разработке, развертыванию и эволюции больших и сложных программных приложений.

5. Бережливое управление портфелем : согласовывает стратегию и исполнение, применяя подходы бережливого и системного мышления к стратегии и финансированию инвестиций, гибким портфельным операциям и управлению.

Каждая из основных компетенций напрямую соотносится с соответствующим уровнем на диаграмме процесса SAFe, за исключением Lean-Agile Leadership, которая охватывает весь процесс.

Lean-Agile Лидерская компетенция

Основная цель компетенции Lean-Agile Leadership — помочь преобразовать организацию в предприятие с бережливой и гибкой практикой. Это делается путем изучения, практики и обучения мышлению, ценностям, принципам и практикам SAFe Lean-Agile.

Основные ценности SAFe определяют переход к бережливому предприятию. При каждой возможности поведение лидера играет решающую роль в их продвижении. Основные ценности:

1. Согласование : Сообщите миссию, стратегию портфеля и видение решения. Проводите соответствующие брифинги и участвуйте в планировании приращений программы (PI) и обслуживании невыполненных работ.

2. Прозрачность : Визуализируйте всю соответствующую работу.

3. Встроенное качество : Практика обеспечения качества на протяжении всего жизненного цикла. Отказаться от некачественной работы. Поддержка инвестиций в техническое обслуживание и сокращение технического долга.

4. Выполнение программы : Участвуйте в качестве владельцев бизнеса в выполнении PI и устанавливайте ценность для бизнеса. Убедитесь, что объем соответствует спросу и возможностям. Агрессивно устраняйте препятствия и демотиваторы.

Основные ценности SAFe поддерживаются принятием подхода Lean-Agile и применением принципов SAFe:

1. С экономической точки зрения

2. Применять системное мышление

3. Предположим изменчивость; сохранить параметры

4. Создавайте поэтапно с помощью быстрых интегрированных циклов обучения

5. Базовые вехи на основе объективной оценки работающих систем

6. Визуализируйте и ограничивайте незавершенное производство, уменьшайте размеры пакетов и управляйте длиной очередей

7. Применение каденции, синхронизация с междоменным планированием

8. Раскройте внутреннюю мотивацию работников умственного труда

   

9. Децентрализовать принятие решений

Эти принципы аналогичны принципам Lean и Agile. Наконец, трансформация организации осуществляется путем следования дорожной карте внедрения SAFe.

Командная и техническая компетенция / уровень команды

Компетенция Team and Technical Agility описывает навыки, принципы и практики, необходимые для создания высокоэффективных agile-команд, создающих высококачественные решения. Две ключевые характеристики имеют решающее значение:

• Командная гибкость : команды принимают методы и принципы Agile, которые позволяют им работать, учиться и адаптироваться в надежном темпе.

• Техническая гибкость : команды применяют технические методы Agile, которые обеспечивают качество кода и компонентов, а также удобство сопровождения кода, который они производят. Качество является большим приоритетом в компетенции команды и технической гибкости. Для достижения этого применяются гибкие инженерные методы, такие как разработка, управляемая поведением (BDD) и разработка, управляемая тестированием (TDD), для повышения качества и потока. Быстрый поток зависит от качества построения всей системы, поскольку ошибки могут серьезно повлиять на поток и задержать выпуск.

Уровень команды на диаграмме SAFe описывает, как работают отдельные Agile-команды. Все команды являются частью Agile Release Train, которая работает над созданием Инкремента Продукта. Применяется большая часть традиционного потока agile/scrum, когда команды работают в итерациях, чтобы создать рабочие системы. Роли мастера схватки, владельца продукта и члена команды используются в SAFe, как и большинство действий и артефактов схватки. Команды также поддерживаются ролями уровня программы, такими как управление продуктом, системный архитектор и другие общие службы. Канбан помогает визуализировать поток функций на протяжении жизненного цикла поставки, а также взаимодействия и передачи между командами.

DevOps и выпуск по запросу Компетенция/уровень программы

Компетенции DevOps и Release on Demand описывают, как «внедрение DevOps и конвейера непрерывной доставки дает предприятию возможность полностью или частично высвобождать ценность в любое время, необходимое для удовлетворения потребностей рынка и клиентов».

DevOps работает, чтобы согласовать разработку, эксплуатацию, бизнес и другие области для совместной работы для достижения бизнес-результатов. Хотя не каждой организации нужно выпускать релизы так часто, как некоторым отраслевым лидерам движения DevOps (Amazon выпускает релизы каждые несколько секунд), все организации должны иметь возможность выпускать релизы по запросу.

• DevOps обеспечивает культуру, автоматизацию, экономичный поток, измерение и восстановление (CALMR), что обеспечивает непрерывную доставку и выпуск по запросу.

• Поезда гибких релизов (ART) — это группы гибких команд, которые организованы для предоставления ценности по запросу через конвейер непрерывной доставки.

Уровень программы на диаграмме описывает роли и действия, необходимые для непрерывной доставки с помощью Agile Release Train (ART) . Этот уровень работает аналогично уровню команды, но объединяет несколько agile-команд и включает больше циклов. ART — это agile-группа команд, состоящая из 5–12 команд (от 50 до 125 человек), включая традиционные agile-роли, а также критические программные роли, такие как Release Train Engineer (RTE) и Product Management. ART реализует 8-12-недельные Инкременты Программы (PI) , которые планируются с помощью PI Planning и возглавляются менеджером по продукту .

Ход выполнения функций PI, эпиков и т. д. отслеживается и управляется с помощью доски Program Kanban. RTE действует как Scrum Master на ART. Ежедневные собрания по синхронизации включают в себя ежедневные командные стендапы, скрам-оф-скрамы (RTE и скрам-мастера), синхронизацию заказов на поставку (управление продуктом и владельцы продуктов) и синхронизацию АРТ (синхронизация скрамов и закупок вместе). У каждого PI есть демонстрация системы и ретроспектива.

Компетенция в области бизнес-решений и проектирования бережливых систем/уровень больших решений

Компетенция Business Solutions and Lean Systems Engineering описывает, «как применять принципы и методы Lean-Agile к спецификации, разработке, развертыванию и эволюции больших, сложных программных приложений и киберфизических систем».

В дополнение к принципам SAFe ключом к этой компетенции является применение следующих 8 принципов при работе над крупными решениями:

Уровень большого решения содержит роли, артефакты и процессы, необходимые для создания больших и сложных решений. Несколько ART совместно работают над решениями для доставки решений . Основные цели заключаются в следующем:

• Управление частой интеграцией

• Постоянно устраняйте проблемы с соблюдением требований

• Архитектор для масштабирования, модульности, возможности выпуска и обслуживания

Управление решениями контролирует содержимое решения, а инженер по обучению решений (STE) направляет работу. Архитектор решения отвечает за поддержание хорошей архитектуры для всех ART в решении. Предварительное и последующее планирование PI используется для планирования Решений, предоставляемых посредством нескольких Инкрементов программы. Бэклог решения содержит возможности и этапы решения и отслеживается с помощью доски Solution Kanban .

Уровень портфеля/компетентность в области управления бережливым портфелем

Компетенция Lean Portfolio Management «сочетает стратегию и исполнение, применяя подходы Lean и системного мышления к стратегии и финансированию инвестиций, гибким портфельным операциям и управлению».

Бережливое управление портфелем фокусируется на следующих областях:

1. Стратегическое и инвестиционное финансирование: связывает портфель со стратегией предприятия, финансирует потоки создания ценности и устанавливает поток портфеля.

2. Гибкие портфельные операции: координирует потоки создания ценности, поддерживает выполнение программ и операционное превосходство.

3. Бережливое управление: прогнозирует бюджеты, измеряет эффективность портфеля и обеспечивает соблюдение

Уровень портфеля содержит принципы, методы и роли, необходимые для инициирования и управления набором потоков создания ценности разработки. Бэклог портфеля содержит бизнес-эпики и активирующие эпики и отслеживается с помощью доски портфолио Канбан*. **Бережливое управление портфелем (LPM) определяет, какие потоки создания ценности входят в портфель, и включает в себя высших лиц, принимающих решения на предприятии. Архитектор предприятия направляет работу и координирует потоки создания ценности.

Меньше

Фреймворк крупномасштабной схватки (LeSS) был создан Крейгом Ларманом и Басом Водде на основе их опыта работы в финансовой и телекоммуникационной отраслях. Как следует из названия, LeSS способствует тому, чтобы процессов и процедур было как можно меньше, чтобы многие Scrum-команды работали вместе. Масштабирование сложно, потому что люди делают его сложным, поэтому цель здесь — сделать его как можно проще.

Основные принципы и компоненты

«LeSS — это Scrum, применяемый ко многим командам, работающим вместе над одним продуктом». LeSS основан на десяти принципах, которые покажутся знакомыми любому, кто знаком с принципами Lean-Agile:

1. Крупномасштабный Scrum — это Scrum

2. Эмпирический контроль процесса

3. Прозрачность

4. Больше с меньшими затратами

5. Ориентация на весь продукт

6. Ориентированный на клиента

7. Постоянное совершенствование на пути к совершенству

8. Системное мышление

9. Склонность к мышлению

10. Теория массового обслуживания

В LeSS всего две основные роли, обе позаимствованы из Scrum:

1. Владелец продукта: Работает с 2-8 командами.
2. Скрам-мастер: Работает с 1-3 командами.

Все команды работают с одним и тем же бэклогом продукта в спринтах по 1-4 недели. Команды работают параллельно, то есть начинают и заканчивают спринты одновременно. В конце спринта команды совместно создают инкремент продукта . Может показаться почти невозможным, чтобы один владелец продукта работал с 8 командами. LeSS способствует передаче ответственности за уточнение элементов невыполненной работы по продукту командам. В свою очередь, команды должны быть кросс-функциональными и обладать не только компетенциями в области кодирования, проектирования и тестирования, но и знаниями в предметной области. Что еще более важно, команды должны иметь возможность обращаться к клиентам.

Планирование спринта

Планирование делится на две части:

1. Планирование спринта 1: когда представители команд встречаются с владельцем продукта и решают, какие элементы невыполненной работы они возьмут на себя, и обсуждают любое потенциальное сотрудничество, которое может потребоваться между командами во время спринта.
2. Планирование спринта 2: так же, как и в традиционном скраме, каждая команда собирается отдельно, чтобы создать план того, как будут выполняться элементы невыполненной работы.

Уточнение бэклога продукта

Уточнение невыполненной работы по продукту (PBR) выполняется во время спринта, чтобы подготовить элементы невыполненной работы по продукту для планирования спринта. LeSS не предлагает правил, как выполнять PBR, и предоставляет компаниям возможность самостоятельно определить наиболее эффективный процесс. PBR включает в себя три ключевых действия:

1. Разделение больших предметов.
2. Детализация элементов до готовности.
3. Оценка.

Конец спринта

В конце каждого спринта происходят три вещи:

1. Обзор спринта: общая демонстрация спринта, в которой команды и клиенты изучают, что было сделано во время спринта и что нужно делать дальше.
2. Ретроспектива: каждая команда проводит свою ретроспективу, чтобы улучшить свой процесс.
3. Общая ретроспектива: команды, владельцы продукта и скрам-мастера собираются вместе, чтобы проверить и адаптировать организационные методы для повышения эффективности.

Scrum@Scale

Scrum at Scale и Scrum@Scale взаимозаменяемы. Эта методология была представлена ​​Джеффом Сазерлендом в 2014 году, который создал методологию Scrum и был одним из подписавших Манифест Agile.

Scrum@Scale использует Scrum в качестве отправной точки и предлагает простую и легкую структуру для масштабирования Scrum с «минимально жизнеспособной бюрократией». Он менее предписывающий, чем другие масштабируемые гибкие методологии, и его можно рассматривать как метаструктуру. Он выделяет проблемы и области масштабирования и предлагает ментальную основу того, как их можно решить.

Основные принципы и компоненты

Scrum@Scale — это фреймворк, радикально упрощающий масштабирование за счет использования Scrum для масштабирования Scrum. В Scrum «что» (владелец продукта) четко отделено от «как» (мастер скрама). Та же стратегия используется в Scrum@Scale, чтобы хорошо понимать юрисдикцию и подотчетность, устраняя потери и конфликты.

Scrum@Scale содержит два цикла для четкого разделения юрисдикций: цикл Scrum Master и цикл владельца продукта с двумя точками взаимодействия: процесс на уровне команды и обратная связь о выпуске продукта.

Скрам-мастер-цикл

Мастер-цикл схватки отвечает за то, как будут построены вещи, определенные циклом владельца продукта. В Scrum@Scale отдельные команды Scrum имеют те же роли, артефакты, действия и церемонии, что и традиционный Scrum.

Scrum-команды сгруппированы в Scrum of Scrums (SoS) , которые совместно несут ответственность за создание совместного приращения продукта. Они участвуют в совместном уходе за невыполненными работами и расстановке приоритетов, проводят ретроспективы, обслуживают невыполненные работы по препятствиям и проводят Масштабируемый ежедневный скрам (SDS) (аналогичный по формату ежедневному скраму) для координации команд и устранения препятствий. В SDS присутствует по крайней мере один представитель (обычно скрам-мастер команды) каждой из участвующих команд, и его возглавляет скрам-мастер скрамов (SoSM) , который отвечает за координацию со скрам-командами и владельцами продукта.

Если требуется дальнейшее масштабирование, существует схватка схватки схваток (SoSoS) , созданная из нескольких SoS, которые также будут собираться ежедневно, и так далее. Главным лидером является Исполнительная группа действий (EAT) , которая отвечает за продвижение Agile в организации, координацию Scrum-команд по мере необходимости и за то, чтобы быть последней остановкой для устранения препятствий.

Цикл владельца продукта

Цикл владельца продукта отвечает за то, какой продукт или услуга будут созданы, и за все действия, необходимые для их поддержки. Владельцы продукта назначаются командам Scrum и выполняют все действия своей роли, как определено в Scrum. Владельцы продукта сгруппированы в команды владельцев продукта , которые соответствуют командам SoS. Команды владельцев продукта ежедневно встречаются на Meta Scrum , чтобы обсудить стратегию высокого уровня для команд и при необходимости координировать свои действия с соответствующими SoSM и другими владельцами продукта и заинтересованными сторонами. Meta Scrums возглавляет главный владелец продукта (CPO) .

Владельцы продукта масштабируются аналогично мастер-циклу схватки, в зависимости от размера организации и завершаются исполнительным мета-скрамом (EMT) , который отвечает за установление приоритетов в масштабах всей компании.

Внедрение Scrum@Scale

Внедрение Scrum@Scale начинается с создания масштабируемой эталонной модели, то есть небольшого набора команд, использующих Scrum в небольшом масштабе. Это делается для устранения любых организационных политик и практик разработки, которые мешают Agile. Scrum@Scale предлагает решить их как можно раньше, потому что все команды, вероятно, столкнутся с этими общими организационными проблемами, и последующие разочарования могут помешать внедрению Agile. Затем эталонная модель используется в качестве шаблона для масштабирования scrum на другие команды и отделы.

Для внедрения эталонной модели изначально необходимо создать группу исполнительных действий (EAT). EAT состоит из лиц, наделенных политическими и финансовыми полномочиями в рамках организации, поскольку они смогут осуществлять изменения организационной политики.

Заключение

Во второй части схемы управления проектами мы рассмотрели некоторые из наиболее популярных фреймворков, используемых в крупных проектах или программах. Водопад по-прежнему широко используется во многих организациях, и хотя он имеет много недостатков из-за негибких процессов, иногда имеет смысл использовать эту структуру, когда проекты небольшие, а объем четко определен и вряд ли изменится.

По мере того, как компании сталкиваются с более крупными и сложными проектами с постоянно меняющимися требованиями или целями, они обращаются к более гибким подходам. Поскольку Agile изначально предназначался для небольших команд из 5-9 человек, различные практики Agile придумали несколько способов масштабирования Agile от отдельных команд до нескольких команд и до всего предприятия. В этой статье мы рассмотрели Discipline Agile Delivery (DAD), Scaled Agile Framework (SAFe), крупномасштабный Scrum (LeSS) и Scrum@Scale.

В заключительной части схемы управления проектами мы рассмотрим несколько конкретных фреймворков управления проектами, таких как PMP (PMBOK) и PRINCE2. Мы также рассмотрим некоторые инновационные процессы и концепции, такие как «задачи, которые необходимо выполнить» (JTBD) и «дизайнерское мышление».