Все о SCRUM. Изучение, разработка, интеграция

Последствия. В итоге получается все то же самое, только вид сбоку (откуда и название антипаттерна). Созданы новые роли. Способы работы навязаны командам, которые, в свою очередь, лишены автономии.

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

21.6.3 Зависимость от планов

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

Последствия. Скорость команды под пристальным наблюдением, что, конечно, оказывает давление на участников.

Как сделать лучше? Учитывая, насколько разработка сложных систем может быть неопределенной, не нужно строить слишком далеких планов. И не стоит эти планы слишком сильно детализировать. В их основе должны быть элементы побольше, чем истории.

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

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

21.6.4 Карго-культ Spotify

Ситуация. В 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 на уровне команды

22.1.1 Достижение Agility при помощи ретроспективы

Scrum-команда поддерживает Agility преимущественно благодаря ретроспективе спринта (глава 12). Это быстрый и регулярный способ совершенствования и адаптации.

Ретроспектива – дело команды. В этот момент участники фокусируются на том, что они могут улучшить самостоятельно. Это замечательно. Но есть то, что можно улучшить только на уровне экосистемы и с привлечением заинтересованных сторон.

22.1.2 Стабильная команда

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

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

22.1.3 Препятствия, связанные с экосистемой

Выявленные командой препятствия могут мешать или полностью останавливать разработку продукта. Препятствия могут возникать из-за:

✓ Scrum-практик;

✓ практик, дополняющих Scrum, в частности инженерных;