Стейша Вискарди
Руководство профессионального скрам-мастера: Практические советы по внедрению аджайл-подходов
Заключение
Профессиональный скрам-мастер должен знать принципы и практику скрама – его историю, основополагающие концепции, методику проведения совещаний, артефакты и роли. Эти знания помогут вам в тех случаях, когда вы столкнетесь с ошибочными ожиданиями от скрама, с непониманием его идей, базы знаний и целей. Работа со скрамом порождает массу сложностей – как для руководства организаций, где он применяется, так и для команд. По мере чтения этой книги вы начнете понимать, почему это такое непростое дело и почему оно требует мужества.
Глава 2
Планирование релиза – настройка процесса разработки продукта
В традиционных проектах содержание[6] (объем) определяется и контролируется по ходу проекта. Аджайл-команды подходят к этому вопросу по-другому: сначала определяют достаточный для начала проекта объем, а затем примиряются с необходимостью изменений и начинают работать, следуя по вновь открывающимся путям. Аджайл-команды стремятся прежде всего отвечать на запросы рынка или пользователей по мере возникновения этих потребностей. Однако время от времени нужды бизнеса требуют и от них планирования на перспективу. Члены аджайл-команд понимают, что предсказать итоги работы по проекту невозможно, поэтому действуют прагматически – подстраивают усилия по разработке продукта к последним и самым важным требованиям. Это похоже на прогноз погоды в вечерних новостях: предсказания метеорологов на следующий день, как правило, сбываются, а вот через неделю – никогда! К сожалению, не существует команд (и метеорологов), способных предсказывать будущее. Именно поэтому я всегда держу в машине запасной зонтик.
Традиционные проектные метрики – скажем, запланированный объем, стоимость и сроки – не годятся в случае сложных технических проектов. Вот вам простой пример (на самом деле таких примеров тысячи): если команда проекта меняет его направление потому, что клиент на полпути меняет требования, это провал? Члены аджайл-команд уверенно ответят, что нет, пояснив, что умение реагировать на меняющиеся требования свидетельствует как раз об успехе работы. Но я слышала и противоположные утверждения: если бы члены команды уделяли больше внимания обсуждению требований заказчика, то они смогли бы предугадать все его нужды с самого начала, чтобы не сталкиваться по ходу работы с неожиданными осложнениями (как будто возможно забросить невод и вытащить, как рыбу, все возможные требования к проекту!). Согласно традиционной логике управления проектами, если мы не достигли цели по объему, срокам и стоимости, значит, проект провалился. К сожалению, до сих пор многие руководители следуют этому глубоко укоренившемуся принципу. Это может свести на нет любые попытки аджайл-планирования.
Лично я отдала бы все на свете за способность предвидеть будущее проектов. Как и многие из вас, читателей. Как вы думаете, почему? Потому что людям нравятся идеальные планы, людям нравится ощущение безопасности, когда они знают, что ждет их впереди. Мы чувствуем себя спокойно и уверенно, когда перед нами лежат аккуратные диаграммы Ганта, таблицы рисков и планы по распределению ресурсов. В конце концов, мы только и делаем, что решаем проблемы. Возможно, наше стремление к спокойствию – это нормально? Ведь планы придают нам уверенности. Да, придают – пока не начинают меняться.
Если бы мы с вами жили не в реальном мире, то, разумеется, я рекомендовала планировать проекты без особого запаса, под быстрый результат, и впоследствии выделять побольше времени на «подгонку» этого результата к реальности. Еще один совет: добейтесь, чтобы ваши команды не переоценивали свои силы и не поддавались искушению взять на себя обязательства по выполнению более чем недельного объема работы. И, пожалуйста, сделайте так, чтобы ваших коллег даже не пытались привлечь к решению более одной задачи по проекту за раз. Это повод для бунта!
Впрочем, вы живете в реальном мире и вряд ли решитесь на бунт, поэтому у меня есть для вас совет, который несколько полезнее лозунга «Ура, долой правила!». Во-первых, не бойтесь иметь альтернативную точку зрения по вопросам планирования. Помните, почему в современных условиях вас просят планировать проекты: потому что этого требует бизнес. Ограничения – стоимость проекта, его сроки и ресурсы (человеческие и не только) – это данность, с которой скрам-мастеру придется иметь дело в ходе проекта. Или не совсем данность? Аджайл-методы позволяют сделать паузу и задуматься, что все эти параметры могут изменяться – если организации для итогового успеха необходимы перемены. Знайте, что в настоящее время среди организаций набирает силу тренд на отход от традиционного мышления по вопросам управления проектами. И я целиком и полностью списываю это на аджайл. Аджайл смещает фокус – с «магического кристалла» на «постоянную адаптацию». Мэри Поппендик, автор книги «Бережливая разработка программного обеспечения: Аджайл-инструменты» (Lean Software Development: An Agile Toolkit), утверждает, что успешные компании не составляют планы и не следуют им, а создают возможности и реагируют на перемены в реальном мире. Скрам-фреймворк предоставляет два инструмента для осознания потенциала и планирования: долгосрочное планирование релиза продукта и краткосрочное планирование спринтов. Основа обоих инструментов – бэклог. Эта глава научит вас, как планировать релизы и вместе с тем видеть в скраме возможность тихого бунта, как применять философию и инструменты скрама, чтобы изменить взгляд организации на проекты и ценности.
Как уже говорилось в первой главе, скрам – новое воплощение цикла Деминга: планируй – пробуй – проверяй – корректируй. (Постирай. Прополощи. Повтори.) Причины этого ясны как день: в ходе жизненного цикла проекта у вас появляются новые знания относительно требований и технологий. Поэтому степень детализации планирования лучше ограничивать проработкой сроков проекта и его результатов. Иными словами, долгосрочное планирование сводится к слишком грубым прикидкам (если говорить о качестве оценки), а планы на ближайшую перспективу обычно гораздо более детализированные. Нижеприведенная схема иллюстрирует идею сужения фокуса с точки зрения временного горизонта. Дорожные карты, которые мы рассмотрим в главе 6, дают широчайшие возможности: у них долгосрочный диапазон (иногда это годы). Планы релизов продукта позволяют заглянуть в будущее, на срок от одного до трех месяцев (иногда чуть дальше), а их возможности не такие широкие: грубо говоря, планы релизов скорее указывают на то, чего команде не стоит делать, чем на то, что нужно попытаться сделать. И, наконец, план спринта – это узкий спектр задач: команда берет на себя обязательство по выполнению определенного объема работы в относительно короткой срок (цикл из 1–4 недель; подробнее см. главу 3).
Когда-то я играла на скрипке. Перед каждым занятием инструмент нужно было настраивать. Настройка скрипки – это подтягивание или ослабление деревянных колков так, чтобы вторая струна звучала как нота ля первой октавы (вам поможет пианино или камертон). Именно с нее начинается настройка, поэтому очень важно не ошибиться. Остальные струны, в свою очередь, настраиваются по второй струне. Если вы когда-нибудь слушали выступление оркестра, то наверняка заметили, что музыканты во время концерта не раз подстраивают инструменты. Это все из-за того, что физические условия меняются по ходу выступления: деревянные части скрипок немного расширяются под воздействием тепла тел и пальцев оркестрантов, натяжение струн уменьшается, а волос смычка становится более мягким после многочисленных крещендо и диминуэндо. Бывает и так, что, играя предыдущую вещь, музыкант замечает, что инструмент немного расстроен. Музыканты рассматривают подстройку инструментов как неотъемлемую часть концерта или выступления. Подстраивая инструмент, оркестрант подстраивает и свое мышление.
План релиза чем-то похож на камертон. Он определяет направление движения, цель или результаты, на которые должна «настроиться» команда. Планирование спринта подобно тонкой настройке – повороту колков для достижения чистейшего звука струны. Такое планирование позволяет определить обязательства по проекту на одну, две или три недели. Нельзя настроить скрипку раз и навсегда, а потом, через несколько месяцев, выступать на концерте, не подстроив ее дополнительно. Всегда нужно учитывать изменения, происходящие с инструментом и средой. Несмотря на то, что я не люблю слово «план», поскольку в нем есть некий оттенок окончательности и закрепленности, мне очень нравится концепция «подстройки» продукта под потребности пользователей и клиентов с использованием инструментов адаптивного планирования (скажем, планов релизов и спринтов как неотъемлемой части самого проекта).
Чтобы еще сильнее заинтересовать вас музыкой, расскажу про нестандартный метод настройки скрипки, он называется скордатура. Так, при исполнении «Пляски смерти» французского композитора К. Сен-Санса первая струна у солирующей скрипки понижается на полтона (не ми, а ми-бемоль). С планированием релизов и спринтов то же самое: мы используем самые разные методы и приемы. Совет прост – делайте планирование простым и эффективным, относитесь к планированию как к возможностям настроить процесс разработки продукта в соответствии с потребностями стейкхолдеров. Эти потребности непременно будут меняться, и настройка станет постоянным процессом – как у струнной группы оркестра. В этой главе рассматриваются вопросы долгосрочного планирования релизов, тогда как следующая будет посвящена краткосрочному планированию спринта. Одна из ваших обязанностей как скрам-мастера – искать и находить лучшие инструменты настройки для вашей команды и организации. Вперед, скрам-мастер… или скрам-маэстро?
Начнем сначала – бэклог продукта
Бэклог продукта – упорядоченный список требований к продукту и необходимых работ. Этот список бывает бесконечным – новые требования могут появляться постоянно. Вести бэклог, управлять им, расставлять в нем приоритеты является обязанностью владельца продукта, который может быть реальным клиентом или представителем какой-то общности людей (так, в случае с iPad «владелец продукта» – это миллионы и миллионы его пользователей). Бэклог продукта, основанный на маркетинговых исследованиях, видении продукта, анализе отрасли, технических инновациях или просто наблюдениях для тестирования, представляет собой набор самых ценных идей и фрагментов функциональности, имеющихся у его владельца.
После того, как команда отобрала, запланировала и включила в свои обязательства те задачи из журнала пожеланий, которые относятся к конкретному спринту, владелец продукта уже не может вносить в них изменения. Однако он имеет право менять и даже убирать требования бэклога продукта (если они не были внесены в план спринта и не являются обязательствами команды), а также менять их приоритетность. Эти простые правила игры требуют от владельца продукта дисциплины: он должен заблаговременно определять приоритетность и подготавливать детали по важнейшим задачам бэклога к моменту планирования очередного спринта. Кроме того, ему необходимо определить приоритетность и подготовить набор желаемых свойств продукта для его релиза до момента начала совещания по релизу.
Бэклог продукта очень полезен для решения вопросов с внесением изменений. Ведь работу, которая еще не начата, можно легко перенастроить в соответствии с потребностями рынка в любой конкретный момент. Если команде необходимо отреагировать на текущую ситуацию с точки зрения конкуренции, владелец продукта может «положить на полку» еще не начатые позиции, чтобы дать приоритет тем, которые отвечают требованиям конкуренции и могут быть выполнены уже в ходе ближайшего спринта. Поскольку известно, что потребности рынка меняются, в интересах владельца продукта как можно более тщательно и детально спланировать работу по тем важнейшим позициям, к которым команда должна будет приступить здесь и сейчас. На иллюстрации ниже бэклог продукта изображен как основа и для долгосрочного, и краткосрочного планирования. Он облегчает и то и другое. Таким образом, бэклог можно легко переписать для долгосрочного прогнозирования, тогда как в планах спринтов важнейшие позиции могут быть спланированы с максимальной детализацией (задачи, часы, владельцы и пр.), поскольку они уже готовы к выполнению. Как проще всего использовать бэклог? Взять первую по приоритетности позицию, завершить работу по ней, выпустить продукт, а затем перейти к следующей позиции… и т. д. Такой вариант действительно работает в некоторых компаниях, о чем будет подробнее рассказано в главе 11. Однако большинство команд одновременно занимаются и долгосрочным, и краткосрочным планированием, полагаясь при этом на бэклог продукта как на важнейший базовый материал.
Сосредоточенность бэклога на интересах пользователей и ценностях
Именно продукт и его функции, а не компоненты системы лежат в основе бэклога и планирования релиза. «Пользователь может увидеть список продуктов на главной странице» – эта позиция бэклога обращена к пользователю. А, скажем, позиция «обновить CSS, чтобы сохранить шрифт заголовков продукта» не обращена. Взгляд на план с точки зрения продукта, сделанный на языке пользователя, помогает владельцу продукта увязать планы релиза с настроениями рынка. Во многих случаях более масштабное планирование, которое называют дорожной картой, предшествует плану релиза (см. главу 6). Бэклоги продукта, дорожные карты и планы релизов помогают владельцу продукта и командам увидеть картину целиком. Это принцип бережливого производства, позволяющий нам время от времени сделать шаг назад и рассмотреть всю картину, а не только детали, с которыми мы имеем дело в повседневной работе. Изучите иллюстрацию: по вашему мнению, какой из двух бэклогов владельцу продукта будет легче представить стейкхолдерам? На основании какого бэклога ему будет проще разобраться в данном этапе развития проекта? Какой бэклог позволяет ему увидеть картину целиком?
Бэклог А сформулирован очень хорошо. Визуализация планов с точки зрения ценности для пользователя позволяет владельцу продукта эффективно продвигать проект, менять приоритеты по содержанию и находить компромиссы по объемам функциональности, передающейся пользователю. Кроме того, возможность контролировать продвижение проекта с точки зрения интересов пользователя помогает владельцу мгновенно определить, когда он может передать заказчику инкремент продукта после завершения очередного спринта (видимо, после того, как будет выполнена позиция 4). Он может сделать то же самое и на основании бэклога Б, но его позиции выглядят как технические задания, поэтому владельцу продукта придется собрать одно или несколько совещаний, чтобы все разобрались, как эти позиции соотносятся с ценностями, которые должны быть созданы в результате выполнения плана. Строго говоря, позиции бэклога Б больше подходят для бэклогов спринтов, которые ежедневно контролируются командой: их завершение может обеспечить разработку фрагментов функциональности. Мы подробно разберем этот вопрос в главах 3 и 6. Вы как скрам-мастер должны добиться, чтобы владелец продукта и команда осознали, как важно формулировать и отслеживать позиции бэклога с точки зрения ценности для пользователя.
Элементы бэклога называют по-разному. В традиционной скрам-концепции есть «официальное название» – элементы бэклога продукта (Product Backlog Item, PBI), а в повседневной практике члены команд могут употреблять термины «фрагменты функциональности», «пользовательские истории» и/или «требования». Запомните: на самом деле совершенно не важно, как называются элементы бэклога, если они записаны так, что всем все понятно. С учетом того, что бэклог продукта обеспечивает обсуждение как долгосрочного, так и краткосрочного планирования, то по возможности следует писать на языке, доступном пользователям, или на языке бизнеса.
Бэклог продукта должен иметь по меньшей мере три колонки с информацией: приоритетность, описание и оценка (или стоимость). Однако мне приходилось работать с самыми разными видами бэклогов – в одном насчитывалось целых 17 колонок (это был огромный проект с участием семи команд, множества региональных представителей владельца объекта, самого владельца и нескольких скрам-мастеров). Многие владельцы продуктов оформляют бэклоги сами и так, как им заблагорассудится, даже в виде стикеров, наклеенных на стену (рядом с такой важной информацией, как, например, заявление о видении продукта).
Помните, что бэклог продукта – это одновременно и инструмент планирования, и инструмент коммуникации, которым будет пользоваться множество самых разных людей с разным уровнем подготовки и разными обязанностями.
Привлекайте команду как можно раньше
Постарайтесь добиться, чтобы владелец продукта привлек команду разработчиков к планированию бэклога как можно раньше. У членов команды – уникальные навыки, уникальный опыт, и, следовательно, у каждого из них могут быть оригинальные мысли относительно продукта. Если есть возможность устроить совместный (с владельцем продукта и остальной командой) мозговой штурм для обсуждения продукта, от членов команды можно услышать свежие идеи – те, до которых владелец, вероятно, не додумался бы сам. Иногда техническим группам удается серьезно изменить направление проекта, если они могут поучаствовать в разработке бэклога на самом раннем этапе.
Создание бумажных прототипов – один из популярных вариантов мозгового штурма при создании бэклога продукта. В ходе такой встречи владелец продукта и команда работают вместе, чтобы смоделировать пользовательский интерфейс, базовые компоненты и системы взаимодействия – исключительно при помощи бумаги! Прекрасная возможность представить себе, как пользователь будет обращаться с системой. А еще – механизм сбора отзывов пользователей и определения критериев приемки продукта (причем еще на ранней стадии). Конечно, команда может прибегать к бумажным моделям при работе с любой системой. Моделирование взаимодействий помогает получить общее представление об архитектуре системы. Лично я использую бумажные прототипы дизайнерской платформы UXpin (http://uxpin.com/web-kit.html) во время лекций и при работе с клиентами. Всем очень нравится! Занятия с использованием бумажных моделей полезны для команды – они упрощают создание образа продукта, развивают в команде дух сотрудничества и командной работы, а также помогают в разработке требований для бэклога продукта.
Я нередко замечаю, что аджайл понимают неправильно. Одно из распространенных заблуждений – якобы только владелец продукта может добавлять новые позиции в бэклог продукта. Гораздо удобнее, чтобы каждый, кого это касается, имел такую возможность. Продукт определенно выиграет, если его владелец разрешит другим стейкхолдерам предлагать свои идеи. Однако помните: чтобы избежать хаоса и стресса, только владелец продукта должен нести ответственность за расстановку позиций по важности – или, точнее говоря, по порядку. Представляете, какое безумие творилось бы вокруг, если бы, скажем, 10 человек ежедневно вносили свои идеи в бэклог и сражались за их приоритетность?
Польза от расстановки приоритетов
Нижеприведенный скриншот – пример бэклога портфеля проектов, который был создан в формате Excel в декабре 2012 г. Его цель состояла в том, чтобы собрать в одном месте все идеи по проектам от различных владельцев и расставить их по приоритетности с точки зрения задач организации. Охват списка весьма широк – запуск продуктов, оптимизация текущей работы и технические инфраструктурные проекты. Легко заметить, что у каждой позиции бэклога различные заказчики (Dev – разработчики, PO – владелец продукта, QA – специалисты по обеспечению качества). Мне нравится этот пример – он показывает, что бэклог полезен не только для расстановки приоритетов по функциям в одном продукте или релизе, но помогает и при планировании портфеля проектов на основе стратегии организации. Чтобы составить и проработать этот список, потребовалось несколько встреч с разными владельцами продукта и руководителями департаментов: они упорядочили все данные, собрав их в одном месте, и расставили приоритеты, сделав работу прозрачной. В ходе встреч были очень напряженные моменты: многие владельцы продуктов поняли, что их идеи могут не получить соответствующего финансирования на начало 2013 г.
Генеральный директор выступал в качестве владельца суперпродукта и в конечном счете решал, на что именно будут выделены деньги. Мне нравятся организационная строгость и простота этого списка: обратите внимание, как команда менеджеров по продукту разделила бэклог в таблице по месяцам работы (декабрь, январь и т. д.). Позиции легко группируются под названием месяца (или любым другим параметром, по вашему усмотрению) для того, чтобы свернуть или развернуть часть бэклога. Скрам-мастер на этой встрече мог легко, одним щелчком мышки развернуть данные по тому или иному месяцу, чтобы привлечь всеобщее внимание к необходимым позициям. Этот скриншот в конечном счете стал целевой страницей продукта, благодаря которой владельцы продуктов могли дальше работать со своими конкретными бэклогами. Обратите внимание на строчку-ссылку – «Блог нового продукта». Владелец продукта может кликнуть на эту ссылку, чтобы попасть на отдельный лист, на котором находится бэклог с конкретными требованиями. Это позволяет команде быстро добраться до необходимых деталей и так же быстро вернуться на целевую страницу для поддержания обсуждения в ходе встреч по расстановке приоритетов. Для организации бэклога продукта хорошо подходят таблицы Google, которые обеспечивают сотрудничество множества пользователей в режиме реального времени. В наши дни на рынке есть множество аджайл-инструментов, которые помогают владельцам продукта поддерживать всевозможные бэклоги (см. www.userstories.com).