Ознакомительная версия. Доступно 11 страниц из 54
Мы провели первую половину дня с командой разработки. Просмотрев список запрошенных к реализации во втором релизе функций, мы приблизительно оценили время на разработку каждого элемента и предварительно сгруппировали их в спринты. «Спринт» оказался для Генри, Мэри и Лори новым термином, но они с облегчением вздохнули, узнав, что это всего лишь фиксированный повторяющийся интервал времени максимальной длительностью в один месяц.
После такой оценки и группировки все стали спокойнее и увереннее: Генри, Мэри, Лори и команда разработки чувствовали, что ситуация под контролем, объем работы понятен, задачи каждого спринта потенциально выполнимы за месяц. Вместе они договорились о предварительном плане релиза на общем для заинтересованных лиц и разработчиков языке. Мы освободили вторую половину дня для определения задач следующего спринта, но команде, работающей с Мэри и Лори, удалось выбрать элементы бэклога продукта всего за час. Затем команда приступила к работе над созданием бэклога спринта, а Генри, Мэри и Лори вернулись на рабочие места с чувством удовлетворенности от работы, проделанной для следующего релиза.
Я намеренно скупо рассказал о скраме команде разработки и руководству MegaFund FTS. Термины вроде «элементы бэклога продукта» вызвали бы лишние вопросы. Ни одна из сторон не испытывала потребности в изучении языка и процесса скрама, поэтому я начал знакомить их с конкретными подходами, которые они могли использовать для более эффективного взаимодействия. «Бэклогом продукта» был упорядоченный список требований. А забавное слово «спринт» для обозначения отрезка времени между встречами (обзорами спринта) мы вообще не использовали, это был просто месяц.
Команда FTS использует скрам уже более шести месяцев, поставляя релизы и взаимодействуя со смежными командами. Упрощение языка скрама облегчило его принятие, сократило накладные расходы на изучение и понимание необычного фреймворка и помогло наладить плодотворное сотрудничество.
ВыводыМы рассмотрели четыре сценария, в которых заказчики начали управлять разработкой программного продукта. Благодаря использованию скрама каждый из них взял на себя роль владельца продукта. Кто-то сделал это сознательно, другие – неосознанно. В каждом случае заказчики научились сотрудничать с командой спринт за спринтом, чтобы контролировать развитие продукта и регулировать усилия команды.
В каждом случае скрам-мастер обеспечил сотрудничество владельца продукта и команды. Не важно, явное или завуалированное, во всех примерах оно было успешным. Ключевым элементом в каждом примере стала способность команды разработки и владельца продукта понимать друг друга.
Это может казаться мелочью, но зачастую до начала применения скрама команда и владелец продукта говорят на разных языках. Владелец продукта умеет говорить в терминах требований и целей бизнеса, а команда – в терминах технологий. Поскольку владелец продукта вряд ли освоит технологии, одна из основных задач скрам-мастера – научить команду говорить в терминах потребностей и целей бизнеса. Общий знаменатель для команды и владельца продукта в новом языке – бэклог продукта.
За последний год я провел несколько сертификационных тренингов для людей, которые хотят стать эффективными скрам-мастерами. На них мы подробно обсуждаем, как применять скрам в различных ситуациях, как скрам-мастер может помочь владельцу продукта и команде разработки говорить на одном языке, использовать единый лексикон для обсуждения проблем.
Для обучения новому языку участники тренинга объединяются в мини-группы, обсуждают бизнес-проблему, а затем презентуют результаты обсуждения и рекомендации владельцу продукта. И почти всегда в этих презентациях используется «техносленг», язык технологий, который непонятен владельцу продукта. Я указываю на эту ошибку и учу поступать иначе.
Такими безжалостными упражнениями я помогаю будущим скрам-мастерам понять величину языкового барьера, разделяющего заказчиков и разработчиков. Преодоление этого разрыва критически необходимо: если две стороны не могут говорить на одном языке, сотрудничество невозможно! Владелец продукта часто не заинтересован в преодолении разрыва, у него нет для этого ни образования, ни опыта. Для него это сложнее, чем для команды, поэтому остается один вариант – скрам-мастер должен помочь команде преодолеть этот разрыв.
В каждом примере этой главы владелец продукта и команда разработки сотрудничали, чтобы сделать все возможное для бизнеса компании. Каждое сотрудничество привело к повышению рентабельности инвестиций (ROI). Но в каком размере? Без измеримого индикатора такое достижение остается голословным. В следующей главе мы рассмотрим, как участники тренинга для скрам-мастеров отвечают на предложение оценивать рентабельность принимаемых решений.
Глава 6 Планирование проекта в скрамеК заинтересованным лицам проекта относятся:
■ те, кто финансирует проект;
■ те, кто намерен использовать создаваемую в рамках проекта функциональность;
■ те, на кого так или иначе повлияют ход или результаты проекта.
Процесс планирования в скраме позволяет синхронизировать ожидания заинтересованных лиц с ожиданиями команды. Для заинтересованных лиц, которые будут финансировать проект, в плане уточняется, в каком объеме и когда требуется финансирование, когда будут получены выгоды от проекта. Заинтересованным лицам, которые будут пользователями разрабатываемой системы, план помогает организовать работу так, чтобы они могли начать пользоваться функциональностью по мере ее реализации.
План также является основой отчетности по проекту. В конце спринта заинтересованные лица участвуют в обзоре спринта, где сравнивают фактически достигнутые результаты проекта с запланированными. Заинтересованным лицам разъясняют суть и детали изменений в ходе проекта и корректировок плана. Для тех, кто не может присутствовать на обзоре, в отчетах по проекту приводится сравнение фактических результатов с планом – как с первоначальным, созданным на старте проекта, так и с измененным.
Процесс планирования в скраме включает в себя поиск ответов на три серии вопросов:
■ Каких изменений могут ожидать те, кто финансирует проект? Когда он завершится?
■ Какие результаты будут достигнуты в конце каждого спринта?
■ Почему финансирующие проект должны считать его ценной инвестицией? Почему они должны считать, что команда сможет обеспечить достижение прогнозируемых выгод?
Планирование проектов с помощью диаграмм Ганта обычно требует больше усилий, чем планирование скрам-проектов, поскольку последние стремятся предоставить ожидаемые от них преимущества и осязаемый результат в конце каждого спринта. Эти проекты слишком комплексные, они не могут быть подробно описаны на старте, поэтому мы с самого начала контролируем и направляем их так, чтобы они достигли наилучших результатов.
В скраме план минимален: для запуска проекта необходимы только видение и бэклог продукта. Видение описывает, зачем проект стартует и каков желаемый конечный результат. Для системы, которая будет использоваться внутри организации, видение может описывать, как изменятся бизнес-процесс и работа сотрудников после установки системы. Для программного обеспечения, разрабатываемого для продажи, видение может описывать основные новые функции и характеристики системы, то, как они будут приносить пользу клиентам, каково предполагаемое влияние нового продукта на рынок. Бэклог продукта определяет функциональные и нефункциональные требования, которые система должна выполнять для реализации видения. Требования в бэклоге упорядочены по важности и предварительно оценены. Бэклог продукта делится на потенциальные релизы и спринты, как показано на рис. 6.1.
Ознакомительная версия. Доступно 11 страниц из 54
