Критерии готовности и завершенности одни для всех команд – так обеспечивается единый уровень качества. Роль критериев не меняется с увеличением количества команд.
Критерии разрабатываются коллективно во время прелюдии. Особое внимание следует уделить критериям завершенности для функциональности.
21.5 События спринта в больших масштабах
Этот раздел требует знания глав 9 о планировании спринта, 10 о ежедневных схватках, 11 об обзоре спринта и 12 о ретроспективе.
Каждая команда – одновременно с другими – проводит свое обычное планирование спринта. В случае, если команды находятся в одном рабочем пространстве, все они располагаются перед бэклогом. Владелец продукта перемещается от группы к группе.
Хотя все объединены в продуктовые команды, бывает, что функциональность требует участия нескольких команд. Этот момент обговаривается во время доработки и подтверждается в ходе этого собрания.
Кроме того, проводится небольшое общее собрание, чтобы вспомнить и, возможно, скорректировать распределение функциональностей, напомнить цель сезона и, прежде всего, синхронизироваться командами.
Крупномасштабная схватка – тот самый легендарный Scrum of Scrums. Это напоминает мне большую схватку в регби, о которой писал Даниэль Эрреро [Эрреро, «Rugby»]. Только в нашем случае в ней участвуют не все сразу.
Принцип следующий: каждая команда проводит свою схватку. Сразу после этого происходит схватка схваток, в которой участвует по одному участнику от каждой команды.
Этот паттерн упрощает коммуникацию между несколькими командами.
Схватки могут проходить не одновременно, так что один участник может принять участие в нескольких схватках. За ними следует схватка схваток, которая, возможно, проводится не так часто – например, раз в два дня. На этой встрече присутствуют представители от каждой команды, Scrum-мастера или другие лица, которые лучше всего подходят для обсуждения между командами.
Во время этой схватки схваток может быть выявлено препятствие, в котором задействованы сразу несколько команд. В таком случае в течение дня нужно провести встречу с представителями всех затронутых команд для устранения препятствия (продолжая сравнение с регби: именно со схватки начинается общее сражение).
Обзор проводится коллективно с участием всех, кто работает над продуктом. На демонстрации показывается совместно разработанный инкремент продукта. Это предполагает, что непрерывная интеграция осуществляется на уровне продукта и всеми командами.
Владелец продукта (или группа РО) проводит эту встречу, которая, по сравнению с обзором от одной команды, очевидно, займет больше времени. На нее приглашены команды и все заинтересованные стороны.
Каждая команда проводит свою ретроспективу. По запросу команды возможна организация общей ретроспективы. Вероятно, она будет проведена с началом следующего спринта. Команда делает запрос о проведении ретро, когда сталкивается с организационным препятствием, или чтобы внести изменения в общие критерии завершенности.
В конце сезона проводится общая ретроспектива для всех команд. Она охватывает большее количество вопросов и занимает больше времени. Ретроспектива может занять весь день, и команды могут провести ее иначе. Например, это может быть встреча в виде открытого форума, на который приглашены все участники и заинтересованные стороны.
Рисунок 21.8 – События спринта для нескольких команд
21.6 Антипаттерны
Ситуация. Организации переходят на Scrum в больших масштабах. Некоторые менеджеры считают, что необходимо индустриализировать процесс.
Последствия. Это создает большую путаницу, так как участники вынуждены работать по методологии, которую им навязывают.
Как сделать лучше? Даже если Scrum в больших масштабах кажется хорошей идеей, лучше переходить к нему только в случае реальной нужды.
Несколько лет назад один эксперт сказал, что это последняя вещь, которую стоит попробовать [Фаулер, «LargeAgileProjects»]: большой проект всегда разбивается на подпроекты, и Agile-методы можно применять только в этих подпроектах и на уровне стандартной Agile-команды.
Рисунок 21.9 – Новые методы следует искать только в случае масштабной проблемы
Ситуация. Есть несколько команд, и организация навязывает им одни и те же методы. Методы сформированы коучами, которые установили в организации определенные рамки. Менеджеров успокаивает эта структура: она дает им ощущение, что контроль по-прежнему в их руках.
Последствия. В итоге получается все то же самое, только вид сбоку (откуда и название антипаттерна). Созданы новые роли. Способы работы навязаны командам, которые, в свою очередь, лишены автономии.
Как сделать лучше? Использовать принцип миссии. Каждая команда свободна выбирать свой способ работы и самоорганизовываться, чтобы достигать поставленных целей. Одни команды могут выбрать Scrum, другие – Kanban.
Ситуация. Менеджеры крупных проектов, привыкшие составлять подробные планы, делают то же самое с историями и даже задачами.
Последствия. Скорость команды под пристальным наблюдением, что, конечно, оказывает давление на участников.
Как сделать лучше? Учитывая, насколько разработка сложных систем может быть неопределенной, не нужно строить слишком далеких планов. И не стоит эти планы слишком сильно детализировать. В их основе должны быть элементы побольше, чем истории.
Классификация и группировка элементов по воздействию, функциональностям и историям позволяет ограничить размер бэклога, в частности, лотка доработки. Agilitу помогает осуществить переход к системе в виде многоуровневого потока.
Иерархическая организация воздействие – функциональность – история – задача ограничивает размер потока и очереди ожидания, согласно примерной продолжительности их реализации.
Ситуация. В 2012 году большой интерес вызвала публикация крупного эксперимента с участием нескольких команд [Книберг, «Spotify»]. После нее некоторые предложили сделать этот опыт образцом крупномасштабной Agility.
Последствия. Все говорят о гильдиях (guilds) и отрядах (squads). Люди копируют, игнорируя контекст.
Как сделать лучше? Книберг напоминает, что проведенный эксперимент – это не образец для подражания, но очень интересный опыт в строго определенном контексте. На что стоит обратить внимание, так это на создание продуктовых команд, применение инженерных практик и коммуникацию между командами.
Чтобы идти дальше
Онлайн-ресурсы
‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/
‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum
‣ Крэйг Ларман и Бас Водда, Fonctionnalité Team Primer, VF, 2010
‣ Martin Fowler, LargeAgileProjects, 2003
‣ Хенрик Книберг и Андерс Иварссон, Agilité à grande échelle chez Spotify, VF, 2012.
22Закрепление Agile-практик
Команда сформирована, создала свою экосистему во время прелюдии и установила ритм спринтов и сезонов. Каждый раз в конце спринта она проводит ретроспективу, чтобы обсудить, каким образом улучшить рабочий процесс в следующем спринте.
Это все замечательно. Но насколько этот процесс жизнеспособен? Идеи пермакультуры в Scrum внедряются с целью создания устойчивой экосистемы.
В VUCA-мире (нестабильном, неопределенном, сложном и неоднозначном) множество ловушек. И часто они возникают вне созданной экосистемы. Системология побуждает нас обратить внимание и сосредоточиться на более крупной системе – той, что окружает экосистему Scrum, то есть на всей организации или даже на совокупности нескольких. Чтобы процесс был устойчивым и жизнеспособным, вероятно, этим организациям придется пройти через трансформацию.
Цель этой последней главы – предложить пути для трансформации, чтобы закрепить Agile-практики на уровне команды, экосистемы и, если необходимо, организаций.
22.1 Agility на уровне команды
Scrum-команда поддерживает Agility преимущественно благодаря ретроспективе спринта (глава 12). Это быстрый и регулярный способ совершенствования и адаптации.
Ретроспектива – дело команды. В этот момент участники фокусируются на том, что они могут улучшить самостоятельно. Это замечательно. Но есть то, что можно улучшить только на уровне экосистемы и с привлечением заинтересованных сторон.
Постоянная адаптация в условиях Scrum будет эффективной только в случае стабильной команды. Как мы поняли из главы 3, стабильность – один из важнейших аспектов Scrum-команды.
Стабильность не означает бездействие: возможно привлечение новых участников или выход кого-либо из команды. Но никакие изменения не должны нарушать свойства Scrum-команды.
Выявленные командой препятствия могут мешать или полностью останавливать разработку продукта. Препятствия могут возникать из-за:
✓ Scrum-практик;
✓ практик, дополняющих Scrum, в частности инженерных;