Одна из целей плана – убедить кого-то финансировать проект. В плане должны быть представлены сведения, достаточно подробные для объяснения источнику финансирования, что:

■ проект целесообразен;

■ в определенные моменты времени будут поставляться результаты;

■ выгоды перевешивают риски и издержки;

■ команда проекта достаточно компетентна для исполнения этого плана.

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

MegaBank является одним из крупнейших финансовых институтов в мире. Мы уже познакомились с ним в пятой главе и еще встретим в следующих главах. Спустя два года после первого рассказа о скраме представителям компании 20 % всех программных продуктов MegaBank используют его. Одна команда узнала об успехе скрама в других подразделениях MegaBank и захотела попробовать его в пилотном проекте по миграции с мейнфреймов в интернет приложения учета денежных переводов. Финансирование было одобрено, команда сформирована, план разработан. Команда проекта получила указание, предписывающее полную готовность к внедрению веб-версии приложения через пять месяцев. Других деталей не требовалось, поскольку новое приложение полностью должно было повторить функциональность своего мейнфрейм-предшественника без добавления каких бы то ни было новых функций.

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

Событие «Планирование спринта»

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

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

Оценка бэклога продукта

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

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

Учитывая эти рекомендации, команда разработки смогла оценить весь бэклог продукта всего за час. При оценке команда основывалась на знаниях о существующей мейнфрейм-версии приложения, над которой работали все участники, и на понимании ранее использованных технологий J2EE и Java и планируемых к применению в веб-версии. Команда разработки, владелец продукта Джули, скрам-мастер Том и менеджер по разработке систем Эд были готовы сравнить данные оценки с ожиданиями руководства: подтверждают ли они, что проект будет выполнен через пять месяцев? Особенно заинтересованным был Эд, поскольку именно он предложил такой срок.