Скрам

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

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

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

Я намеренно скупо рассказал о скраме команде разработки и руководству MegaFund FTS. Термины вроде «элементы бэклога продукта» вызвали бы лишние вопросы. Ни одна из сторон не испытывала потребности в изучении языка и процесса скрама, поэтому я начал знакомить их с конкретными подходами, которые они могли использовать для более эффективного взаимодействия. «Бэклогом продукта» был упорядоченный список требований. А забавное слово «спринт» для обозначения отрезка времени между встречами (обзорами спринта) мы вообще не использовали, это был просто месяц.

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

Выводы

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

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

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

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

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

Такими безжалостными упражнениями я помогаю будущим скрам-мастерам понять величину языкового барьера, разделяющего заказчиков и разработчиков. Преодоление этого разрыва критически необходимо: если две стороны не могут говорить на одном языке, сотрудничество невозможно! Владелец продукта часто не заинтересован в преодолении разрыва, у него нет для этого ни образования, ни опыта. Для него это сложнее, чем для команды, поэтому остается один вариант – скрам-мастер должен помочь команде преодолеть этот разрыв.

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

Глава 6 Планирование проекта в скраме

К заинтересованным лицам проекта относятся:

■ те, кто финансирует проект;

■ те, кто намерен использовать создаваемую в рамках проекта функциональность;