Читать книгу "Скрам - Кен Швабер"

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

Что стало результатом ретроспективы спринта? Многие в Service1st были рады помочь друг другу. Когда кто-то отставал, другие участники команды были рядом. Некоторые программисты были рады сидеть рядом с тестировщиками, потому что еще в процессе кодирования могли понять полный набор тестов, которые впоследствии будут применены к системе. Все были довольны, а очевидный прогресс достигнут уже через два спринта после начала цикла создания релиза. Один программист был в восторге оттого, что ему пришлось общаться и работать с проектировщиком, с которым он не обменялся и фразой за три года работы в Service1st.

Что можно улучшить? Участники команды, которые были назначены сразу в несколько команд, не были довольны этим. Они не могли сосредоточиться на одной группе задач, и им не удалось понять, как распределить свое время, чтобы быть доступными для каждой команды при наличии такой потребности. Большинство команд были недовольны перегородками между рабочими местами. Первоначально они полагали, что им нужна приватность, но в итоге начали чувствовать, что стены мешают сотрудничеству. Все команды считали, что им не хватает навыков для выполнения работы: одним не хватало тестировщиков, а другим – технических писателей.

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

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

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

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

Извлеченные уроки

Время от времени я размышляю о своем внутреннем конфликте. Я убежден в преимуществах управления с помощью эмпирического процесса: полагаться на частую инспекцию и адаптацию, чтобы и следовать цели, и поставлять наилучший возможный продукт. Но мой опыт управления с помощью предопределенных процессов продолжает периодически поднимать свою уродливую голову. Где-то в глубине души я по-прежнему верю, что моя обязанность заключается в том, чтобы вначале все аккуратно спланировать и только потом настаивать на соблюдении этого плана. Если первоначальный план не работает и необходима корректировка, я считаю это своей виной. Но правила скрама спасают меня и от самого себя. Управление командой – не задача скрам-мастера. Команда должна научиться управлять собой, постоянно оптимизируя свои подходы ради повышения шансов на успех. Ретроспектива спринта предназначена именно для такой инспекции и адаптации. Как и почти все практики скрама, ретроспектива спринта ограничена во времени. Нет смысла слишком долго искать совершенство, поскольку в комплексном, несовершенном мире его не существует.

За годы реализации скрама я усвоил следующее жизненное правило: пусть команда разберется сама. Роль скрам-мастера не имеет полномочий над командой и тем самым гарантирует, что самоорганизация произойдет. Скрам-мастер отвечает за процесс и устранение препятствий, но не за управление командой разработки. Скрам-мастер помогает, задавая вопросы и делясь советами, но команда сама отвечает за определение того, как она будет выполнять свою работу. Задача скрам-мастера – обеспечить соблюдение практик скрама. Все действия команды, конечно же, должны оставаться в рамках норм и стандартов компании. Действуя совместно, скрам-мастер и команда разработки выстраивают такой процесс создания программного обеспечения, который позволяет поддерживать движение в направлении цели и добиваться наилучших результатов.

Оцениваем планируемую работу

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