Кен Швабер - Скрам

• Название: Скрам
• Автор: Кен Швабер
• Жанр: Отраслевые издания
• Год: 2019
• ISBN: 978-5-9614-2860-5

Эта книга несет в себе дух скрама, раскрывая его ценности и основные принципы. Кен Швабер, один из создателей скрама, соавтор «Руководства по скраму» и основатель Scrum.org, собрал лучшие кейсы из своей практики, демонстрирующие примеры успехов и неудач применения скрама в реальных проектах. Они помогут вам понять, как использовать скрам для решения комплексных проблем и достижения результатов. Автор рассказывает, как эффективно управлять сложными, громоздкими проектами и изменяющимися требованиями к продукту; упрощать организационную структуру с помощью самоуправляемых команд разработки; получать более четкие описания требований и внятную обратную связь от клиентов и заказчиков. Вы узнаете, как эффективнее планировать работу над проектом, научитесь избегать ошибочных действий, используя регулярную инспекцию, а также увеличивать отдачу от инвестиций.

---

Команда разработки в Service1st

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

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

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

Ситуация в Service1st

Service1st – поставщик программного обеспечения для клиентских служб. Это компания среднего размера с большим количеством внутренних и международных клиентов. Продукты Service1st хорошо известны в отрасли, а обновления выходят не реже раза в год. Руководство компании решило, что часть разработчиков должны начать работу над следующим релизом продукта, а остальные – завершить текущий.

Команда нового релиза была сформирована из людей с подходящими навыками, включая инженеров и тестировщиков. В ее состав вошли 17 человек, участие которых в текущем релизе не было обязательным. Изначально для управления нагрузкой команды менеджеры использовали диаграммы Ганта. Но Service1st решила перевести на скрам все команды разработки, в том числе и эту.

Команда разработки в действии

Я провел с командой упражнение «Быстрый старт». Это интенсивная двухдневная сессия, в которой участники изучают практики скрама и готовятся к запуску своего первого спринта. Учебная часть сессии прошла хорошо, но, когда я добрался до первой части планирования спринта, все начало рассыпаться. Комната была переполнена: 17 участников команды разработки плотно расположились вокруг небольшого стола, а заинтересованные лица сформировали кольцо за ними. Более активные участники команды расспрашивали и общались с владельцем продукта, а более пассивные – выпали из процесса. К началу второй части планирования спринта, когда команда разработки определяет свой бэклог спринта, по-прежнему участвовали только самые бойкие. Прерывая их, я несколько раз старался вовлечь молчунов и спрашивал, над чем они будут работать. Я уточнил, понимают ли они, что нет ничего хуже, чем во время ежедневного скрама сознаваться, что они ничего не делали и вообще не сильно вовлечены в проект. Имея благие намерения, этим своим замечанием я добился лишь того, что пассивным участникам стало только хуже.

Команда разработки была слишком большой, поэтому вовлечь всех не удалось. Оптимальный размер команды – от трех до девяти человек, чтобы во время планирования спринта они могли общаться, глядя друг другу в глаза, взаимодействовать и формировать общий план действий. Команда из 17 человек сделала фактически то же самое: 7 активных участников планировали спринт, а 10 пассивных сотрудников не участвовали в процессе. Что мог сделать я? Понимая, что пересобирать команду уже поздно, я решил оставить все как есть и посмотреть, что произойдет. Несколько дней спустя я присутствовал на ежедневном скраме этой команды разработки. К моему большому удивлению, о выполненной и планируемой работе рассказывали все. Конечно, с таким количеством людей ежедневный скрам длился 20 минут вместо 15, но это была активная, оживленная сессия, и все участники команды, казалось, были увлечены работой. После встречи они поделились со мной своими соображениями. Они решили, что менеджмент сформировал такую большую команду разработки по ошибке, однако не хотели перечить ему, полагая, что мудрое руководство знает о причинах, по которым команда должна быть настолько многочисленной. Но большая команда разработки не функционировала – прогресса в работе над задачами спринта почти не было. Команда решила разделиться на четыре подгруппы численностью от трех до пяти участников каждая. Руководители программистов и тестировщиков помогли сформировать эти подгруппы и разделить работу так, чтобы сложносоставные задачи выполнялись внутри подгрупп, а коммуникации между ними свелись к минимуму. Также они взяли на себя ответственность за устранение зависимостей, возникающих между участниками команды в ходе работы. Эти руководители были частью команды разработки, они были преданы работе и общей цели, поэтому их действия являлись проявлением самоорганизации.

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

Ценность команды разработки

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

Выводы

В MetaEco в роли скрам-мастера Том защищал производительность команды разработки и помогал ей выполнять прогнозы. В MetaEnergy Джейн оптимизировала приносимую проектом ценность, выполняя обязанности владельца продукта. В Service1st команда разработки путем формирования подгрупп проявила свою способность к самоорганизации, которая помогла им достичь цели спринта. Действия каждой роли требовали смекалки и инициативы, они были критичны для успеха проекта.

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

Глава 3 Скрам-мастер

Почему я выбрал такое странное название для роли человека, помогающего скрам-проектам? Почему оставил в стороне привычный титул «менеджер проекта»? Потому что хотел подчеркнуть, насколько обязанности скрам-мастера отличаются от обязанностей традиционного менеджера проектов. Это различие в терминологии – символ тех радикальных изменений в подходе к управлению, на которые должны пойти менеджеры, чтобы эффективно управлять проектами по скраму.

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

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