Стейша Вискарди
Руководство профессионального скрам-мастера: Практические советы по внедрению аджайл-подходов
Планирование релиза: когда будут продемонстрированы новые функции?
Итак, теперь у вас есть бэклог продукта. Что дальше? Если вы не обязаны спрогнозировать, каким будет набор фрагментов функциональности к какому-то определенному времени, то команда может просто начать выполнять задачи, занесенные в бэклог, начиная с самых верхних. Но если организация требует от команды прогноза, каким будет объем выполненной работы к тому или иному сроку, вам придется осуществить планирование релиза.
Временная привязка релиза и его планирование
Сами по себе релизы продукции должны осуществляться в то время, которое определяет владелец продукта: именно он оценивает такой показатель, как возврат инвестиций, и решает, какой объем функциональности должен быть доступен для клиента или пользователей. Как правило, владелец продукта имеет временные ориентиры по релизу до начала работы по проекту («Он был нужен мне еще вчера!»). Существует определенная частота, с которой потребители хотят видеть новые функции продукта, и в обязанности владельца входить способность определить этот ритм. Например, я рассчитываю, что в приложении «Карты» моего нового iPhone новые функции могут появиться в любое время. В то же время мне бы не очень понравилось, если бы каждый месяц в продаже появлялся новый iPhone с новой операционной системой и интерфейсом (я думаю, что в наше время новые модели смартфонов и так выходят слишком часто, – хотя рынок, судя по всему, думает по-другому… во всяком случае пока).
Необходимо, чтобы владелец продукта был в состоянии доводить планы релиза до других участников бизнеса. Например, маркетологам и продавцам во многих компаниях сведения о сроках релизов нужны как можно раньше – для организации пиар-кампании продукта и подогрева интереса к нему, поэтому с точки зрения бизнес-перспектив очень важно заблаговременно предоставлять этим специалистам информацию о готовящихся событиях. Большинство организаций начинают торговлю новыми фрагментами функциональности еще до завершения их разработки, подписывая контракты, основанные на обещаниях. И хотя я всей душой ненавижу контракты с фиксированными сроками исполнения и содержанием, все же должно существовать хоть какое-то указание на то, когда новые фрагменты функциональности станут реальностью! По моим оценкам, 80 % компаний начинают планирование релиза еще до старта проекта, а впоследствии либо команда вообще не занимается планами релизов, либо эти планы составляются уже после нескольких спринтов, когда команда начинает осознавать, с какой скоростью она продвигается вперед. Независимо от того, когда и как составляется план релиза, владелец продукта и команда должны постоянно сверяться с этим планом по ходу проекта, когда меняются условия. Ваша обязанность как скрам-мастера – обеспечить постоянство таких сверок.
Не создавайте «больших канав» при разработке ПО
Вероятно, вы слышали о Большом бостонском тоннеле, именуемом также Большой траншеей или даже – еще грубее – Большой канавой. Первоначально проект оценивался в $2,5 млрд, и его планировалось завершить в 1998 г. К 2006-му расходы на строительство тоннеля возросли до $14 млрд. К этому времени проект уже считался «завершенным», но по-прежнему необходимо было заменить 25 000 изношенных источников освещения (стоимость работ оценивалась в $54 млн). Вирджиния Грейман из Бостонского университета настаивает: «Причиной взрывного роста стоимости объекта явилось не какое-то катастрофическое событие или недостаточное число контрактов. Критическим для проекта стало отсутствие у подрядчиков необходимого опыта и знаний, как действовать в условиях повышенной сложности и неопределенности, свойственных гигантским проектам…» Разрабатывала проект одна компания, а строительством занималась другая, и обе они с самого начала не обеспечили должное взаимодействие между тысячами своих сотрудников. К сожалению, окончательной ценой строительства «Большой канавы» стала человеческая жизнь – несколько лет назад в тоннеле раздавило машину с водителем, поскольку клеящий состав, использованный для крепления верхнего перекрытия, оказался недолговечным. С самого начала в этом проекте было столько неопределенного, что для любого подрядчика было бы глупо претендовать на определенную сумму контракта, как и для главного заказчика – Massachusetts Turnpike Authority – было бы глупо верить, что обязательства будут выполнены. Однако мы живем в таком мире, в котором, к сожалению, низкие ценовые предложения и туманные обещания иногда приносят компаниям победу в тендерах и контракты.
История с «Большой канавой» – полезный урок и для планирования релизов.
Старайтесь как можно раньше объединить команду, чтобы избежать рисков
Подталкивайте членов команды (или разных команд, если речь идет о большом проекте) к объединению усилий: пусть это начинается как можно раньше и делается как можно чаще, а также учитывается в планах релизов. Многие разработчики не любят совместную деятельность, поскольку не хотят проблем, которые иногда порождает такое объединение усилий. Скрам-мастер всегда должен напоминать членам команды, что часть кода, над которой работает один программист, будет бесполезна, если не окажется совместимой с другими частями и если все части не пройдут тестирование. Возможно, в ходе самых первых спринтов команде будет сложно сработаться по ряду объективных причин (устаревшие приемы, инструменты и т. д.), но вы должны ей помогать, чтобы в итоге усилия всех и каждого были объединены на постоянной основе. Без этого организация не сможет быстро реагировать на самые насущные потребности пользователей. Добейтесь, чтобы ваша команда занималась такими вопросами, как интеграция усилий, тестирование и выработка критериев готовности в планировании релизов, с самого начала, просите ее по ходу проекта постоянно сверяться со своими целями. Подробнее об этом вы можете прочесть в статье Хенрика Книберга, посвященной ситуационному контролю в аджайл-командах[7].
Делайте «амортизаторы» заметными
Скрам-мастер должен подталкивать членов команды к обмену реальными оценками и так называемыми буферами – для тех проектов, где уровень неопределенности особенно высок. Это значит, что команда должна обеспечивать специальный буфер в расчете на неизвестное. Например, если вашей команде через несколько спринтов предстоит освоить новую технологию третьей стороны, то она должна буферизировать оценки в плане релиза, чтобы учесть все факторы неопределенности в интеграционных усилиях. Конечно, команда может подготовить и заниженные оценки по затратам и срокам, чтобы порадовать владельца продукта (правда, недолго). Беда в том, что вскоре команда придет к нему, поджав хвост, чтобы попросить больше денег и времени, – а это, на мой взгляд, не лучший вариант. Еще хуже, если команда попытается сотворить чудо, «срезав» проблемные углы проекта и понизив качество продукта. В итоге эти проблемы все равно замучают членов команды (или тех несчастных, которые придут им на смену) в будущем. Команда должна буферизировать оценки, чтобы компенсировать факторы неопределенности, и регулярно сообщать скрам-мастеру и владельцу продукта, что ее беспокоит. Чем надежнее буферизирован проект, тем лучше. В этом случае при необходимости можно просто добавить в релиз еще несколько пользовательских историй. Это гораздо лучше, чем убирать истории из релиза!
Буферизация неопределенностей – это просто отказ планировать каждый спринт, исходя из 100 % возможностей команды. Скажем, наша команда изначально чувствует, что может выполнить 20 условных единиц работы за один спринт, однако после дополнительного обсуждения члены команды понимают, что надо зарезервировать 25 % возможностей для освоения новой технологии (все они в проекте новички) и поддержания существующей версии продукта. «Резерв» 25 % означает, что обязательства по релизу будут составлять 15 (а не 20) единиц за спринт. Разумно, согласитесь. Но я часто вижу, что люди очень негативно воспринимают такой подход. И часто слышу: «Мы не можем обманывать клиента», «Руководство хочет 100 %-ной отдачи, нельзя планировать только 75 %!». Но на деле это не так: «обманывать клиента» – как раз не учитывать время на освоение новых технологий и поддержку существующего продукта (что тоже входит в обязательства команды), а при планировании релиза заполнять каждый спринт работой на 100 %. После двух-трех спринтов, поняв, что задачи слишком объемные, команда будет вынуждена объясняться с владельцем продукта. Дело в том, что планирование релиза должно быть осмысленным обсуждением между командой и владельцем продукта: какие задачи на самом деле выполнимы? Иногда такое обсуждение подразумевает и жесткие решения, и компромиссы. Все мои знакомые владельцы продуктов в один голос говорили, что лучше узнать все проблемы и риски по проекту как можно раньше, чтобы вовремя принимать адекватные решения. Буферизация помогает команде составлять реальные планы и позволяет лучше выполнять обязательства перед владельцем продукта.
Помните, что ваша работа в качестве скрам-мастера – делать эти буферы видимыми. Если клиент или владелец продукта принимает участие в планировании релиза, то после содержательного разговора с командой ему будет понятнее, что стоит за необходимостью создания буферов. Большинство специалистов считают буферизацию хорошим способом снизить риски по проектам.
Если наша команда выполнила 15 условных единиц работы по пользовательским историям к концу первой половины спринта, ей следует обратить внимание на дополнительные требования из верхней части бэклога, чтобы завершить спринт. (Стоит устроить мини-совещание для членов команды, чтобы определить, сколько брать новых таких задач, – см. главу 3, посвященную планированию спринта.) Давайте представим себе, что команда взяла восемь дополнительных единиц и смогла завершить работу по ним в дополнение к тем 15, которые изначально входили в ее обязательства. В результате у команды имеется реальная скорость работы 23 единицы: именно из этого показателя она может исходить в корректировании сроков релиза.
Чем сильнее неопределенность по проекту в глазах команды и владельца продукта, тем полезнее буфера. Нижеприведенный скриншот – пример буферизации в работе, которая не связана с имплементацией фрагмента функциональности:
Некоторые команды создают буфер, оставляя свободным от обязательств целый спринт в конце проекта, как показано на скриншоте:
Планирование релиза похоже на настройку музыкального инструмента по камертону. План релиза можно настроить, но настройка может устроить владельца продукта, а может и не устроить. Мы узнаем это только тогда, когда начнем играть на инструменте (выполнять спринт). Мы хотим взаимодействия с клиентами при создании функциональностей продукта с приемлемым уровнем качества в приемлемые сроки, делая видимыми неопределенности и возможные затраты, чтобы клиент впоследствии не удивлялся. Однако не стоит рассчитывать, что клиент уже сейчас знает все, чего хочет от продукта, – он просто не может этого знать. Помните, что скрам-команда должна видеть во владельце продукта партнера (принцип из аджайл-манифеста: сотрудничество с заказчиком важнее согласования условий контракта). В любых отношениях с партнером действия обеих сторон должны быть полностью прозрачными.
Планирование релиза отнюдь не обязательное мероприятие. Изначально в скрам-материалах оно даже не упоминалось. Лишь недавно рамки скрам-концепции были расширены и включили в себя планирование релизов как полезную (но по-прежнему опциональную) практику. Иногда еще в самом начале нужно спросить команду, требуется ли ей планирование релиза. Если вы чувствуете, что команда способна постоянно двигаться вперед в разработке продукта, а владелец продукта проявляет достаточную гибкость в вопросах сроков и содержания проекта, то в таких случаях ваша команда, пожалуй, может и обойтись без планирования релизов.
Планирование релиза открывает диалог с опорой на то, что план – это не предсказание, а скорее прогноз: некоторые функциональности нового продукта могут менять характеристики или объем. Часто бывает так: планирование релизов – это не только попытка команды определить, что должно остаться в релизе, но и решительный отказ от того, что до него дойти не должно.
На нижеприведенном рисунке – три колонки: возможные решения (фрагменты функциональности / пользовательские истории / требования бэклога продукта), временные рамки и нуждающиеся в решении бизнес-проблемы. Роль владельца продукта (в центре) состоит в том, чтобы определить правильный набор требований для разрешения текущих и предполагаемых бизнес-проблем в определенный отрезок времени: в течение спринта, до релиза, запланированного на следующий год, и т. д. Сложность заключается в том, что проблемы – и их решения – не стоят на месте. На повестке дня всегда есть какие-то текущие проблемы, которые требуют решения, и о некоторых из них мы узнаем из регулярных событий (например, конференций пользователей), но время от времени перед нами встают и по-настоящему срочные проблемы (реакция на действия конкурента Х, производственные вопросы и т. д.). Но тут есть и плюс: в бэклоге продукта обычно накапливается много идей, из которых владелец продукта может выбирать самые подходящие для решения проблемы. Цель состоит в том, чтобы расположить позиции бэклога в правильном временном порядке в соответствии с потребностями бизнеса. Это немного похоже на борьбу с «одноруким бандитом»: соберите три вишенки в ряд – и вы победили. Но в IT-сфере, сколько бы вы ни старались, не все выстраивается в ряды. В ней всюду сплошные взаимозависимости: изменишь что-то одно – это сразу же вызовет перемены в чем-то еще. Поскольку в колонках, касающихся проблем и решений, изменения происходят постоянно (это, между прочим, может касаться и колонки «Временные рамки»), планирование следует рассматривать как постоянный диалог между командой и владельцем продукта: в рамках этого диалога нужно учитывать все текущие изменения во всех колонках, чтобы всякий раз наилучшим образом реагировать, выстраивая «вишенки» на табло в ряд.
Как проводить планирование релиза?
Итак, вы со своей командой и владельцем продукта осуществили мозговой штурм по составлению бэклога продукта с необходимыми фрагментами функциональности, и все готовы начать работу. Владелец продукта уже подошел к «однорукому бандиту». Как вовлечь всех в эффективное обсуждение плана релиза?
Делайте домашнее задание!
Перед планированиием релиза выполните небольшое домашнее задание: попытайтесь ответить на нижеприведенные вопросы, чтобы встреча с командой прошла более гладко и эффективно. Возможно, некоторые вопросы не имеют прямого отношения лично к вам, но в целом это достаточно репрезентативный, подходящий для большинства ситуаций опросник.
● Когда члены вашей команды могут встретиться? В идеале это должна быть личная встреча. Если ваша команда физически находится в одном месте, то вы уже готовы к встрече! Если нет, то планирование релиза – как и планирование спринта – то самое мероприятие, когда вы как скрам-мастер должны собрать команду вместе. Сделайте все возможное. Постарайтесь выбить у руководства деньги на организацию встречи. Если собрать людей все же не получится, продумайте комбинацию технических средств, при помощи которых можно частично сгладить остроту этой не очень желательной ситуации (см. главу 10, где подробно разбираются вопросы работы с удаленными командами).
● Есть ли в помещении для совещания доска для записей, достаточно ли стирающихся и перманентных маркеров, бумаги для записей, стикеров?
● Какова желаемая дата релиза? Возможно, стоит спросить у владельца продукта. Как правило, это «вчера».
● Есть ли у владельца продукта концепция продукта и информация о целевой аудитории, рынку, потребителях, образе типового пользователя? Для команды очень полезно видеть всю картину целиком: и все проблемы, которые ей предстоит решать, и то, чем она собирается удивить будущих потребителей. В этом случае члены команды куда чаще выдвигают инновационные идеи.
● Сколько спринтов потребует релиз продукта? Какова будет их продолжительность: одна, две, три или четыре недели? Длительность спринта определяет руководство? Приемлема ли она для владельца продукта? Следует ли вам вмешаться в решение этого вопроса?
● Кто будет определять, готов ли продукт к релизу? Когда считать каждый спринт внутри процесса релиза завершенным? (Подробнее см. следующий раздел.)
● Достаточно ли компетентна ваша команда для того, чтобы соблюсти критерии готовности? Если нет, то какие обходные пути может она использовать?
● Есть ли у вашей команды действующий производственный регламент, которому она должна следовать? (В него входит настройка оборудования, создание необходимых условий для программирования, протоколов тестирования и т. д.)
● Понятен ли команде процесс релиза еще до начала производства? Если да, то как это влияет на план релиза?
● Знает ли команда свою скорость? Если нет, нужно организовать тестирование возможностей команды в ходе планирования релиза.
● Как намерена команда бороться с возможными помехами на пути к релизу? Какие есть способы борьбы?
● Где будет храниться бэклог продукта? Может ли владелец продукта пообещать хотя бы сделать его видимым для команды?
● Понимает ли команда, что такое скрам?
● Известно ли, где будут храниться бэклоги спринта и диаграммы сгорания? А другая информацию по проекту?
● Следует ли пригласить других стейкхолдеров?
● Какие риски по релизу существуют на данный момент? Известно ли о каких-либо помехах, существующих уже сегодня? Могут ли какие-то члены команды долгое время отсутствовать?
Однажды я работала с командой, в которой встреча коллектива была запланирована на середину ноября на острове Аруба (к сожалению, я не была на нее приглашена). План релиза на четвертый квартал (октябрь–декабрь) мы составили в сентябре. Совещание на Арубе в ноябре означало, что команда не могла брать на этот период слишком большие обязательства по фрагментам функциональности. Вроде бы это очевидно – но вы даже не представляете себе, как часто команды берут на себя слишком большие обязательства с первого дня проекта.
Чтобы найти ответы на многие типовые вопросы, достаточно выполнить это домашнее задание, однако необходимо также обсудить полученную информацию с командой: так вы сможете выявить все дополнительные проблемы, решить возникшие вопросы и, возможно, уладить разногласия. Например, вы и ваш владелец продукта перед планированием релиза выявили три группы рисков. Но вам следует спросить и членов команды, не видят ли они какие-либо другие риски. Как правило, видят.
Как организовать совещание
Ваша задача в качестве скрам-мастера в ходе планирования релиза – выполнять обязанности ведущего, организатора и модератора, а также следить за временем. В отличие от менеджера проекта, вы не принимаете решений по его содержанию, срокам и стоимости. Скрам подразумевает, что это обязанности владельца продукта. Планирование релиза дает владельцу продукта возможность обсудить проблемы, которые он стремится решить, объявить оптимальные для проекта сроки и совместно с командой определить необходимый объем работ.
Участники
Основные участники планирования релиза – скрам-мастер, владелец продукта и члены команды, непосредственно занимающиеся его разработкой. Другие стейкхолдеры также могут захотеть принять участие. Например, представитель службы поддержки клиентов может попросить что-то поправить в продукте по запросам клиентов. На совещании он предоставит команде соответствующую дополнительную информацию.
Этот представитель находится ближе всего к потребителю, поэтому он важный стейкхолдер и должен присутствовать на встрече. Однако важно помнить: даже если в совещании участвуют другие стейкхолдеры, все же именно владелец продукта определяет порядок и глубину выполнения требований бэклога продукта. Скрам-мастер и владелец продукта должны работать сообща, чтобы заблаговременно определить и оповестить всех нужных стейкхолдеров.
Повестка
Обсуждение плана релиза и должно быть именно обсуждением, а не односторонним предложением плана владельцем продукта команде. Нужно создать соответствующую атмосферу, чтобы члены команды и владелец продукта сумели договориться об общем видении продукта и совместно составили план. Чтобы добиться качественного и целенаправленного обсуждения и обеспечить достижение необходимых результатов, нужна хорошо подготовленная повестка дня.
Ниже приведен пример такой повестки. Вы можете адаптировать ее к своим потребностям, однако помните, что она должна быть максимально легкой.
Недавно я работала с командой, которая разрабатывала свой продукт в течение трех лет (так и не доведя его до релиза!). Владельцем продукта был генеральный директор, но он мог посещать лишь одну из трех-четырех демонстраций. А если он все-таки присутствовал на совещании, то пытался все переделать. В результате продукт завис на стадии разработки, и команда была в печали. Самое ужасное, что все это время продукт находился в инкубаторе. Со стороны генерального директора было бы куда разумнее выделить для этого продукта настоящего владельца, который вывел бы его на рынок в течение года. Компания вернула бы потраченные инвестиции значительно раньше!
Физическое пространство
Чтобы планирование релиза оказалось результативным, важно правильно организовать физическое пространство, где оно будет проходить. Следует выбрать помещение, в котором члены команды, находясь лицом к лицу, смогут беспрепятственно обмениваться идеями по ходу встречи. Все нужное должно быть у участников совещания под рукой: если кто-то из присутствующих выбегает из помещения за маркером или губкой, это может разрушить весь деловой настрой! Постарайтесь уберечь от этого свою команду.
При организации пространства для совещания подумайте о цели и возможных итогах встречи. Какие темы в ходе обсуждения команда поднимет с наибольшей вероятностью? Как организовать помещение, чтобы все сразу уловили эти идеи? На рисунке, приведенном ниже, показаны наиболее распространенные вопросы и заявления, звучащие на планировании релизов.
При планировании релиза обсуждаются содержание, оценки и сроки проектов при планировании релиза, и, как правило, члены команды достаточно открыто высказываются по поводу стоящих перед ней проблем и рисков. Это значит, что вам нужны инструменты, которые позволяли бы фиксировать содержание обсуждения, не мешая ему, и сохранять информацию, доступной для общекомандной работы в процессе совещания. Если ваша команда едина (или хотя бы 80 % ее членов физически присутствуют на совещании), приготовьте перекидные блокноты и стикеры. Я обычно прихожу в помещение за 30 минут до начала совещания, чтобы свериться с контрольным списком, который всегда держу в голове:
● Убедиться, что стульев или кресел достаточно и что все участники будут видеть лица друг друга (стол для совещания в форме буквы U далеко не лучший вариант).
● Положить на стол в достаточном количестве гелевые/шариковые ручки и стикеры.
● Развесить на стенах таблицы и графики с необходимой информацией – скажем, по критериям готовности, повестке дня и основным пунктам регламента (см. для примера нижеприведенный рисунок).
● С собой должен быть блокнот для записей во время совещания.
● Если бэклог продукта представлен в электронном виде, я обычно трачу полдня, чтобы выписать позиции на стикеры: они должны быть у участников перед глазами.
● Еще раз просмотреть повестку и выделить вопросы, которые следует обсудить коллективно.
● По возможности сделать так, чтобы в помещение проникал естественный свет. Обеспечить комфортную температуру.
● Если в совещании участвуют удаленные участники, подготовить к использованию Skype или другие способы связи. Найти волонтера (не члена команды), который придет на совещание с хорошим смартфоном для отправки фотографий материалов совещания и результатов его работы удаленным участникам.
Критерии готовности
Очень важно, чтобы в ходе планирования релиза команда пришла к единому мнению, что означает «готово» – и для спринтов, и для релиза. Другими словами, готов ли клиент принять более низкий уровень качества продукта просто потому, что он первым появится на рынке? Или устойчивость системы критически важна и поэтому никакие компромиссы относительно качества невозможны? Достижение согласия по критериям готовности для каждого спринта и релиза – абсолютное требование с точки зрения формирования ожиданий по продукту: оно отвечает концепции «качество продукта должно быть встроено в него». Кроме того, такое согласие предотвращает путаницу и ошибки в процессе спринта.
Рассмотрим пример критерия готовности для релиза:
Качественная работа той или иной функциональности, то есть отсутствие сбоев (на 1, 2 или 3 уровне сложности). Загрузка страницы осуществляется меньше чем за 1 секунду. Все интеграционные тесты автоматизированы, чтобы в будущем проблемы обнаруживались быстрее и легче.
Мы разберем критерии готовности применительно к спринту в следующем разделе, а в главе 10 рассмотрим их в целом.
Итоги планирования релиза
Завершив планирование релиза, скрам-мастер и владелец продукта должны решить, кто возьмет на себя распространение материалов по итогам совещания: датам начала/окончания спринтов, промежуточным срокам создания функциональности, возможным приостановкам процесса, изменениям в промежуточных сроках, возможному воздействию входящих факторов, рискам, проблемам, необходимым действиям и т. д. Эта информация при необходимости может быть доведена до стейкхолдеров при помощи инструментов коммуникации или – для простоты – представлена в виде таблицы Excel. Некоторые скрам-мастера просто фотографируют лист флип-чарта и распространяют информацию в таком виде.
Вот очень простой план релиза:
Написать книгу (дата релиза – 15 декабря 2012 г.) *Кстати, я уже опаздываю.
Спринт 1 = глава 1.
Спринт 2 = написать главу 2, отредактировать главу 1.
Спринт 3 = написать главу 3, отредактировать главу 2.
…
Финальный предрелизный спринт = окончательная редакция, графики и таблицы.
Релиз = издание и посвященная выходу книги вечеринка!
Шутки в сторону, ниже приведен визуальный вариант плана релиза.
Другой способ изображения плана релиза подразумевает использование линии отсечки в бэклоге продукта: команда прогнозирует для релиза все требования, находящиеся выше линии отсечки, а все, что находится ниже, в релиз не входит.
Ниже приведена фотография реального плана релиза одной из команд, составленного с использованием перекидных листов и стикеров:
А еще ниже – пример бэклога продукта: скрам-мастер расширил его, чтобы были наглядно видны стадии выполнения той или иной пользовательской истории. Обратите внимание: указаны приоритетность каждой истории, ее название и оценка в условных единицах. Это минимум для бэклога продукта. Есть еще две добавочные колонки: «План спринта» и «Реальные результаты спринта» – так будет понятно, когда была реально завершена разработка той или иной функциональности в сопоставлении с запланированным темпом разработки. Выделенные позиции – Создать страницу «Инструменты», Социальные сети и Аналитика Google – указывают на то, что при исполнении плана имел место «эффект домино»: запланированные к выполнению истории перешли в следующий спринт. Я специально сместила колонки планируемой и действительной скорости работы вправо, чтобы можно было составить диаграмму сгорания (см. главу 6).
И наконец, ниже я привожу временной график плана релиза, который показывает в самом общем виде эпики (или большие куски функциональности) с приблизительным временем их разработки. Такой график может быть полезным для доклада руководству о ситуации: в этом случае излишняя детализация только помешает донести необходимую информации до адресата.
Планирование релиза: что в сухом остатке
Традиционный взгляд – планирование, абсолютно предсказуемое по времени и объемам, – становится невидимым препятствием в нашей повседневной деятельности. Оно возникает на каждом шагу при планировании, поддержке этого процесса и доведении его результатов до потребителей. На совещании со стейкхолдерами из департамента продаж и клиентской поддержки нужно заявлять: «Вот наш прогноз, он основан на том, что мы знаем сегодня». На совещании с руководством по текущему состоянию проекта говорите то же самое. В каждом спринте сохраняйте план релиза абсолютно прозрачным и устанавливайте (меняйте) ожидания. Не поддавайтесь существующим методам корпоративного давления! От них один вред. Если вы сертифицированный скрам-мастер, оставляйте право на решения за собой и берите ответственность на себя.
Нельзя налить литр пива в полулитровую кружку. То есть, конечно, можно, но часть пива прольется. И его будет жалко. Так и команда может довести до релиза только определенное количество фрагментов функциональности, исходя из таких параметров, как имеющиеся ресурсы, количество членов команды, манера поведения владельца продукта (в том числе и уровень его вовлеченности в проект), и других факторов. Возможно, это будет только «пол-литра» конечной функциональности, тогда как клиент хочет сразу «литр». Стоит ли обещать ему этот «литр»? Что тогда произойдет с качеством продукта?
Пожалуйста, поймите меня правильно: команда может изо всех сил стараться сделать все от нее зависящее для разработки нужного клиенту продукта, но она должна отдавать себе отчет в том, что план релиза – это в лучшем случае прогноз. Этот прогноз основан на том, что члены команды – как коллектив – знают на данный момент. Поскольку наша осведомленность по поводу требований к продукту, технологий и взаимодействия между людьми со временем растет, зачем ограничивать свои предсказательные возможности, полагаясь лишь на какой-то выдуманный магический кристалл? Например, если появятся новые технологии, которые позволят нашему владельцу продукта затратить на его производство половину от оценочной суммы, зачем продолжать работу с первоначально выбранными технологиями? Разве наш клиент не будет рад выбрать новую опцию и потратить сэкономленные средства на создание нового продукта (или на более ранний релиз)? План релиза – это только материальный результат диалога, который постоянно ведется между владельцем продукта и командой разработчиков. Самая важная часть этого плана – обсуждение владельцем и командой потребностей проекта, его неопределенностей, подходов и компромиссов.