ScrumXP — Agile-команды на масштабе. Часть 1: Теория

Насколько вообще можно говорить о Scrum в больших организациях? С какими сложностями можно столкнуться? Как работает на практике ролевая модель ScrumXP в энерпрайзах? Но перед тем как перейти к реальным имплементациям, нужно посмотреть, как работу в ScrumXP видели авторы SAFe.

Так и поступим. В первой части статьи будет перевод официального материала, а во второй — более детальный разбор ScrumXP от экспертов и практиков.

Ниже представлен вольный пересказ статьи: ScrumXP — Scaled Agile Framework®.

ScrumXP

“…целостный подход или, как он еще называется, подход “регби” , когда команда вместе старается пройти всю дистанцию, передавая мяч друг другу, более конкурентноспособен сегодня.”.

Нонака и Такеучи, “Разработка нового продукта. Новые правила игры”

ScrumXP – это легковесный процесс поставки ценности для кросс-функциональных самоорганизующихся команд в SAFe. Он сочетает в себе мощь фреймворка Scrum и методов экстремального программирования (Extreme Programming, XP).

Под термином ScrumXP имеются в виду две базовые характеристики Командной и Технической Гибкости, при этом Scrum отвечает за командную гибкость, а XP — за технические практики. Большинство Agile-команд используют Scrum в качестве основного командного фреймворка. Легковесный, но в то же время дисциплинированный и ориентированный на результат, Scrum позволяет кросс-функциональным самоорганизованным командам работать в контексте SAFe. В нем прописаны две специальные роли: Scrum-мастер и Владелец Продукта. Scrum-мастер — это лидер-слуга, который помогает команде придерживаться правил Scrum. Он работает как внутри, так и за пределами команды. Его цель — устранить препятствия в работе команды. Владелец Продукта определяет, какой продукт будет создан. Расширенная Lean-практиками обеспечения качества и инженерными техниками экстремального программирования (XP), Agile-команда, использующая ScrumXP (далее — Команда), представляет собой базовый кирпичик Agile в SAFe.

Разумеется, Команды не работают разобщенно. Каждая из них является частью более крупной команды —  Agile Release Train (ART), в рамках которой Команды сотрудничают друг с другом при создании одного или нескольких решений.

Agile-команда

Команда, представляет собой самоорганизующуюся, самоуправляемую, кросс-функциональную группу из 5-11 человек, по возможности работающую в одном помещении. Размер и структура команды оптимизированы для общения, взаимодействия и способности поставлять ценность.

Самоорганизация подразумевает, что в команде нет руководителя или менеджера, который наблюдает за членами команды, оценивает их работу, направляет их на достижение конкретных целей или определяет, как именно они будут совершенствовать то или иное решение. Команда знакома с целью Итерации и несет полную ответственность за определение того, какую часть задач проекта они могут выполнить. Кросс-функциональная команда включает все роли и навыки, необходимые для разработки и поставки инкрементов ценности. Самоорганизация и кросс-функциональный характер команды — наряду с постоянным общением, конструктивными спорами и динамичным взаимодействием — могут создать продуктивную и более приятную рабочую среду для ее участников.

ScrumXP определяет две конкретные роли в Agile-команде: Владелец Продукта и Scrum-мастер — которые имеют специальные обязанности. Каждая из этих ролей более подробно описана в статьях на сайте SAFe. Ниже приводится краткое описание их обязанностей.

Владелец Продукта

У каждой Agile-команды есть Владелец Продукта (Product Owner, PO), который отвечает за бэклог команды.

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

Scrum-мастер

Это лидер и коуч Agile-команды. Его основные обязанности:

• Продвигать и поддерживать Agile-команды в следовании процессу ScrumXP.
• Обучать команды Scrum, XP и практикам SAFe.
• Коучить команды в самоуправлении.
• Помогать команде сосредоточиться на создании инкремента ценности в каждой итерации.
• Содействовать устранению препятствий, мешающих успехам команды.
• Заботиться о проведении всех командных мероприятий, а также их продуктивности и соблюдении тайминга.
• Создавать условия непрерывного совершенствования.
• Поддерживать внедрение SAFe.

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

Процесс Scrum

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

Scrum использует термин «спринт». SAFe использует более общий термин «итерация».

Планирование Итерации

Итерация начинается с Планирования Итерации, события с фиксированным временным интервалом в четыре часа или менее, в котором Владелец Продукта представляет истории для планирования. После этого команда:

• Уточняет истории.
• Определяет критерии приёмки.
• При необходимости разбивает большие истории на более мелкие.
• Оценивает их в Story Points.
• Формулируют Цели Итерации на основе того, что они могут поставить за предстоящую итерацию с учетом известной скорости (velocity, или количества Story Points за итерацию).
• Берут обязательства по Целям Итерации.

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

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

Визуализация Работы

Во время выполнения работы, команда создает и тестирует истории, чтобы каждые несколько дней поставлять одну или две истории. Это ограничивает незавершенную работу (Work In Progress, WIP) и помогает избежать «водопада» в итерации. Команды используют «Большие Визуальные Информационные Радиаторы» (Big Visible Information Radiator, BVIR) для понимания и отслеживания прогресса во время выполнения итерации. Один из примеров BVIR — это доска задач: она наглядно показывает истории и их прогресс на протяжении всей итерации. При этом они часто используют этапы разработки в качестве столбцов, перемещая истории слева направо с течением времени.

Некоторые команды также применяют ограничение WIP ко всем или некоторым шагам, чтобы реализовать процесс «вытягивания» работы в рамках итерации и постоянно балансировать работу с имеющимися ресурсами, чтобы увеличить пропускную способность. Чтобы улучшить поток работы через итерации, многие команды на самом деле внедряют лучшие практики Scrum и Kanban.

Координация на Ежедневных Стендапах

Каждый день команда проводит ежедневный стендап (Daily Stand-Up, DSU), чтобы понять, где они находятся, поднять острые проблемы и получить помощь от других членов команды. Во время этого мероприятия каждый участник команды описывает, что он сделал вчера для достижения целей итерации, над чем он будет работать сегодня для достижения целей итерации, а также рассказывает о всех препятствиях для достижения целей итерации, которые он видит. Поскольку это ежедневное собрание Scrum-мастер должен следить, чтобы обсуждение было кратким и по существу. Собрание должно длиться не более 15 минут и проходит перед доской команды.

Но взаимодействие команды на этом не заканчивается, поскольку участники команды непрерывно обращаются друг к другу за помощью в течение всей итерации. Именно поэтому рекомендуется максимально простое взаимодействие внутри ScrumXP-команды, когда все ее члены работают в одном рабочем пространстве.

Демонстрация Ценности и Совершенствование Процесса

В конце каждой итерации Agile-команда проводит Обзор Итерации и Ретроспективу Итерации. Во время Обзора Итерации команда демонстрирует каждую завершенную историю, результатом которой является Инкремент Ценности команды в этой итерации. Это скорее обзор значимых результатов итерации, нежели официальный отчет о ходе работ. После этого команда проводит краткую ретроспективу — анализирует предыдущие итерации и сам процесс, положительные моменты и текущие препятствия. Затем команда предлагает истории совершенствования для следующей итерации.

Встроенное Качество

Один из постулатов SAFe звучит так: «Вы не можете масштабировать «плохой» код».  Поэтому одним из основных элементов SAFe является Встроенное Качество. Качество на уровне кода и компонентов обеспечивают люди, создающие решение. В противном случае, в дальнейшем становится трудно (или невозможно) удостовериться в качестве, поскольку работа интегрирована и масштабируется от компонента до системы и решения.

Чтобы убедиться, что команды встраивают качество, SAFe описывает пять методов проектирования и техник, заимствованных из экстремального программирования (XP) и дополняющих практики Scrum. В эти пять методов входят: Непрерывная Интеграция (Continuous Integration), Сначала Тест (Test-First), включая разработку через тестирование (Test-Driven Development) и разработку на основе поведения (Behaviour-Driven Development), Рефакторинг, парная работа и коллективное владение. Некоторые команды используют другие методы XP, такие как парное программирование и метафоры систем.

Agile Release Train

Команды являются кросс-функциональными, но сложно представить, что команда из 5-11 человек может обеспечить ценность для конечного пользователя, когда решение включает в себя различные технологические платформы и требует привлечения специалистов из широкого спектра дисциплин, таких как аппаратное обеспечение, программное обеспечение и системная инженерия. Как правило, требуется гораздо больше команд. Для решения этой проблемы Agile-команды в SAFe работают в рамках большой команды — ART (Agile Release Train), который обеспечивает согласование целей и среду совместной работы, где команды могут сотрудничать с другими командами. Так появляется больше возможностей для создания решения. В рамках этой технологии все команды планируют, демонстрируют и учатся вместе, что позволяет им вместе фокусироваться на более глобальных проблемах. Такое согласование позволяет командам исследовать, интегрировать, развертывать и выпускать ценность более независимо.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.