Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

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

Для примера возьмем то, чем я часто занимаюсь, – запись в блоге. Сейчас мне легко сказать: «Вот, я ее сделал, она готова». Но так ли это на самом деле? Текст нужно отредактировать, вычитать. Необходимо добавить картинку. Потом запись нужно поместить на сайт. Кто-то должен нажать кнопку «Опубликовать». Нет никакой пользы от того, что я написал, пока все это не произойдет. Важно убедиться, что учтена вся работа, а не только малая ее часть.

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

В конце спринта команда и владелец продукта проводят обзор спринта. Во время этого мероприятия они показывают стейкхолдерам и потребителям, что они сделали, что готово. И здесь я имею в виду действительно готовое, а не «почти готовое», «вроде готовое» или «что-то, над чем кто-то очень много трудился, но не закончил, однако усилия надо признать». Готовое. Команда и владелец продукта получат обратную связь от всех, кто в комнате: «Нам нравится это. А то не нравится. Как насчет этого? Теперь, когда у нас есть это, мы хотим получить…» Владелец продукта использует эту обратную связь, чтобы скорректировать приоритизацию в бэклоге продукта, поскольку теперь у него есть конкретные данные от настоящих потребителей, знание о том, чего они хотят на самом деле.

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

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

Удивительно видеть, как маленькие события, которые казались непоследовательными в свое время, стали рычагами, изменившими будущее. Нечто вроде «не было гвоздя – враг вступает в город»[10]. И первый обзор спринта стал одним из таких событий.

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

«Хорошо, – сказал мой отец. – У вас есть выбор: быть одной из многих команд разработки ПО или стать отличной командой разработки ПО. Я не могу вас заставить, вы должны выбрать сами».

Решение этих семерых людей изменило мир. Именно благодаря им вы читаете сейчас эту книгу, и благодаря им люди по всему миру теперь работают лучшими методами. Не так часто в истории удается четко определить время, день, людей, которые стали чему-то причиной, но нам это удалось. В тот день родился Scrum.

«Хорошо, – сказали они. – Еще одна попытка».

Дальнейшее вам известно.