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

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

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

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

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

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

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

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

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

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

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

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