Kitobni o'qish: «Руководство профессионального скрам-мастера: Практические советы по внедрению аджайл-подходов»

В книге упоминаются социальные сети Instagram и/или Facebook – продукты компании Meta Platforms Inc., деятельность которой по реализации соответствующих продуктов на территории Российской Федерации запрещена как экстремистская.

Переводчик Михаил Попов

Научный редактор Петр Гурьянов

Редактор Любовь Макарина

Главный редактор С. Турко

Руководитель проекта А. Василенко

Арт-директор Ю. Буга

Корректоры Е. Аксёнова, Е. Чудинова

Компьютерная верстка М. Поташкин

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

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

© Packt Publishing, 2013

© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2023

* * *

Предисловие

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

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

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

Вас ожидает чудо!

Ли Девин,

консультант AgileEvolution, старший консультант Innovation Practice Cutter Consortium

Об авторе

Стейша Вискарди – аджайл-коуч, сертифицированный тренер скрам-методик, эксперт в области трансформаций в организациях, стремящихся создавать нацеленные на результат и полные энтузиазма команды, которые радуют своих клиентов и служат примером для других. Стейша начала трудовую карьеру в Порт-Артуре (штат Техас), где в начале 1990-х гг. работала менеджером проекта, пока в 1999-м не перешла в сферу высоких технологий. Больше она не оглядывалась назад! В 2003 г. она стала 62-м по счету сертифицированным скрам-мастером (сегодня их уже более 710 000!), а в 2006-м основала компанию AgileEvolution. Стейша помогла многим организациям найти свой путь к аджайл-методу. Среди них Cisco Systems, Martha Stewart Living, Primavera, DoubleClick, Google, Razorfish, My Publisher, Washington Post и многие другие. Стейша, соавтор книги «Мост менеджера проекта ПО к аджайл-методу» (Software Project Manager's Bridge to Agility), преподавала методику аджайл в 17 странах. Она активный член ScrumAlliance и известный эксперт в скрам-сообществе. Помимо работы Стейша занимается бегом, проводит вечера дома, уютно устроившись на диване со своим мужем Крисом и собаками Джексом и Коби.

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

Введение

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

Скрам-мастер, как хороший наездник, должен знать, когда дать лошади свободу, а когда пришпорить и натянуть повод – или вообще повесить на стенку хлыст и отложить седло на денек. На сегодня в мире насчитывается около 250 000 профессиональных скрам-мастеров, и это число постоянно растет. С одной стороны, это хорошо, потому что показывает устойчивый интерес к аджайл-методам, а с другой – у нас проблемы. Многие, не до конца понимая, что такое скрам, неправильно его применяют – а это мешает людям обнаружить его удивительные возможности и даже дискредитирует само понятие. Я сама не раз видела, как скрам приносит не пользу, а вред. Уверенные, смелые и упорные скрам-мастера могли бы добиться замечательных результатов – но не добивались. Владельцы продукта могли бы активнее участвовать в разработке продукта – но опускали руки. Команды скрывали плохое качество своей работы – и напрасно. Кроме того, с появлением нескольких новых методов получили распространение термины «менеджер итераций» и «аджайл-мастер» – жалкие и даже опасные подделки под настоящих скрам-мастеров. Мне это совсем не нравится, я расстраиваюсь, и у меня чешутся руки начать действовать. Я не хочу, чтобы подлинный образ скрам-мастера затерялся на верхней полке вагона с методологиями/сертификациями. Я мечтаю, чтобы люди полностью раскрывали свой потенциал, и уверена, что скрам – один из способов помочь им в этом.

Скрам – простой и надежный процесс: дочитав книгу, вы как следует в нем разберетесь. Однако он же способен и все погубить – людям иногда бывает очень трудно брать на себя ответственность. Иными словами, если лошадь взбрыкнула, то проще всего обвинить лошадь! Но ведь всегда может быть другое объяснение, другая причина: камень под копытом или репей под седлом. Хороший скрам-мастер найдет корень проблемы (тот самый «репей под седлом») и будет упорно работать над ее устранением во имя комфортного существования вашей организации.

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

Скрам – это не способ перехода К (чему-либо), это что-то для движения СКВОЗЬ (что-то)? А через что именно? Что ж, ответ вы найдете в процессе работы. Одни руководители прибегают к практике экстремального программирования, другие находят полезным канбан-метод. Со временем вы захотите, чтобы в вашей организации создавались процессы, которые работают на вас, а не наоборот. По мере того как вы будете узнавать о замечательных идеях из других методов из мира аджайла и бережливого производства¹, вы поймете, что не так важны названия этих методов или фреймворков, как результаты их применения. Старайтесь прежде всего помогать сотрудникам добиваться результатов – быстро, сосредоточенно, но в то же время гибко. В этом случае вы на правильном пути. А скрам поможет вам успешно стартовать.

Я хочу, чтобы вы стали таким скрам-мастером, который – вернемся к лошадиной аналогии – сам едет на великолепном породистом жеребце, а не ведет под уздцы шотландского пони (таких мастеров называют скрам-куклами). Вы должны понимать: у вас больше сил, чем вам кажется. Один-единственный человек (и это вы!) может перевернуть положение дел, а создание всего одной успешной скрам-команды способно в корне изменить вашу организацию. Если вы решитесь взяться за эту миссию, приготовьтесь: это будет самая настоящая скачка века.

О чем эта книга

Глава 1 рассказывает об истории, принципах и практике скрама. Если вы новичок, то вам необходимо прочитать эту главу, а если у вас уже есть какой-то опыт… все равно прочтите. В этой главе приведены основополагающие объяснения, почему скрам работает. Эта и последующие главы также включают раздел «Рекомендованное чтение», в котором находятся мои любимые сайты и книги для самопроверки.

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

Глава 3 содержит рекомендации, как готовить и проводить встречи по планированию спринтов, как настраивать вашу команду на успех того или иного спринта (последнее, пожалуй, важнее всего).

Глава 4 рассказывает о «сердцевине» спринта: о том, что происходит в команде изо дня в день, о совместной работе участников команды, о том, как расчистить дорогу для роста производительности команды. А как же утомительный ежедневный скрам? И о нем расскажем!

Глава 5 ставит вас перед фактом: то, что вы считаете окончанием спринта, на самом деле всего лишь пауза, которая определяет начало следующей итерации. Вы узнаете, как обзор и ретроспектива спринта помогают команде создавать доверительные отношения со стейкхолдерами и как такие совещания укрепляют саму команду.

Глава 6 вооружит вас идеями, как обеспечить прозрачность работы команды, чтобы владелец будущего продукта и другие стейкхолдеры могли принимать правильные решения. Вы узнаете, как помочь людям смотреть на процессы сквозь призму скрама, чтобы принимать разумные и своевременные решения.

Глава 7 знакомит с пятью базовыми ценностями скрама и с пятью главными негативными реакциями команд и организаций, не готовых к принятию этих ценностей.

Глава 8 содержит идеи, как лидеру совершенствовать личные навыки для того, чтобы сделать команду максимально эффективной. Это своего рода прелюдия к следующей главе.

Глава 9 расширяет рамки главы 8 и обращает ваше внимание не только на команду, но и на всю организацию в целом. Мы рассмотрим вопросы мотивации работников интеллектуального труда, «кнуты и пряники» служб по работе с персоналом, организационную структуру аджайл-организаций и т. д.

Глава 10 знакомит с некоторыми соображениями по поводу расширения скрама до рамок крупных многокомандных проектов. Кроме того, мы рассмотрим вопрос об удаленных и рассредоточенных командах.

Глава 11 приоткроет перед вами картину будущего в мире интеллектуального труда, продемонстрирует, как будут выглядеть организации, и расскажет, как при должном профессионализме скрам-мастера могут приблизить будущее.

Приложение А рассказывает об основных обязанностях и функциях скрам-мастера. Вы можете использовать его для быстрого пополнения списка тех знаний и навыков, которых вам пока не хватает.

Приложение Б содержит много вопросов для обдумывания, сценариев развития событий и упражнений (разбитых по главам), чтобы вы могли работать над прочитанным по мере знакомства с книгой.

Кроме того, специально для этой книги я создала поддерживающий сайт www.helloscrum.com, где вы можете ознакомиться с дополнительными идеями, рекомендациями и нюансами, которые помогут вам в жизни.

Что вам нужно, чтобы понять эту книгу

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

Для кого эта книга

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

Условные обозначения

В этой книге вы встретите различные шрифты и иконки, которыми выделяются различные элементы информации. Ниже приведены некоторые примеры.

Перед вами важная информация

Перед вами совет или подсказка

Глава 1
Скрам – краткий обзор основ (и несколько полезных советов)

Цель данной главы – рассмотреть историю, основы и философию скрам-модели, показать ее преимущества и дать несколько полезных советов. Хорошо подготовленный и работоспособный cкрам-мастер прекрасно понимает и теорию, и практику. За много лет я поняла: люди уверены, будто осознают истинную задачу скрам-мастера. Однако, к сожалению, его роль зачастую низводят до простого «менеджера итераций» или «руководителя аджайл-проектов». Эта глава познакомит вас с базовой информацией, необходимой для плавания по бурным водам перемен в вашей организации. А перемены – это и есть истинная задача скрам-мастера.

Проблема

Чтобы оставаться на плаву, типичная компания, работающая на прибыль, должна удовлетворять спрос, предлагая клиентам достаточное количество продуктов или сервисов. Главная роль скрам-мастера – сделать видимым истинный потенциал команды, чтобы организация могла соразмерить его со спросом. В отличие от производства материального продукта на производственных линиях, где руководство измеряет выход товара в единицах в день, аджайл-разработка программного обеспечения измеряется удовлетворенностью клиента, в основе которой лежат созданные командой функции (свойства, фрагменты функциональности) или их наборы. Сегодня, во времена засилья YouTube и соцсетей, компании вынуждены сосредотачиваться на быстром удовлетворении запросов клиентов, гибко реагируя на быстро меняющиеся условия конкуренции и потребления.

Еще несколько десятилетий назад водопадная модель разработки программного обеспечения была вполне адекватной: рынки не создавались каждый день, интернета в его современном виде еще не существовало и распространение идей занимало гораздо больше времени. А сегодня вирусные видеоролики разлетаются по миру с ужасающей скоростью и так же быстро устаревают. Мешкать опасно.

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

Краткий экскурс в историю

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

Джефф Сазерленд впервые использовал скрам в 1993 г. – сначала в Easel Corporation, а затем, в следующие несколько лет, в VMARK, Individual и IDX Systems. Кен Швабер, который работал с Джеффом в Individual, впервые представил cкрам как задокументированную методику на конференции OOPSLA в 1995 г. На рубеже тысячелетий Джефф с блеском применял скрам в Patient Keeper, а Кен помог масштабировать методику в Primavera Systems. Последний пример стал известным благодаря упоминаниям в книге Кена Швабера «Скрам: Гибкое управление продуктом и бизнесом»².

Однако cкрам придумали раньше. В 1986 г. в Harvard Business Review была опубликована статья, которую написали Хиротака Такэути и Икудзиро Нонака. Статья называлась «Новые игры в разработке программного продукта» (The New Product Development Game). Авторы настаивали, что организации, производящие программный продукт, должны любыми средствами увеличить скорость и гибкость его разработки, чтобы победить в условиях конкуренции. Вместо осуществления последовательных операций по принципу передачи эстафетной палочки Такэути и Нонака предлагали «холистический», «регбийный» подход – когда вся команда двигается как единое целое, передавая мяч вперед и назад внутри этого целого: по их мнению, это лучше отвечает сегодняшним потребностям. Эта статья – первое упоминание скрама как новой парадигмы продуктовой разработки, как концептуальной основы для разработки быстрой, гибкой и состязательной. Скрам-мастерам следует помнить, что скрам-процесс – как определенный набор рабочих шагов, достижений и материальных результатов – не имеет смысла, если в его основе не лежат тот образ мыслей и те концепции разработки продуктов, которым Такэути и Нонака впервые дали описание. Это внутренняя подвижность, самоорганизующиеся проектные команды, перекрывающие друг друга фазы разработки, постоянное обучение, тонкие методы контроля и передача опыта.

Концепции, лежащие в основе скрама, своим корнями уходят еще глубже в историю. В 1950-х гг. консультант по менеджменту Уильям Эдвардс Деминг придумал цикл «планируй – пробуй – проверяй – корректируй» (Plan – Do – Check – Act, или PDCA) как модель постоянного улучшения, известную также под названиями «цикл Деминга» или «цикл Шухарта». Эта концепция давно использовалась в так называемом бережливом подходе концерна Toyota к производству. Эти идеи один в один совпадают с концепцией спринта в скраме с его ежедневными скрам-совещаниями (как показано на рисунке ниже и далее в книге). Но Деминг не знал, что он практиковал скрам. Вернее, это современные скрам-команды не всегда осознают, что они применяют цикл Деминга!

Но, строго говоря, основы скрама еще древнее, чем идеи Деминга. Вернемся на 1000 лет назад, когда арабский ученый Ибн аль-Хайсам экспериментировал с рефракцией, линзами и зеркалами: он вывел важнейшие законы оптики, изложенные в его фундаментальном труде «Книга оптики». Ибн аль-Хайсама нередко называют отцом научного метода – когда ученый создает гипотезу или ставит вопрос, проводит эксперименты, получает результаты, анализирует их и, возможно, изменяет концепцию (или продолжает эксперименты). Это эмпирический процесс, построенный на доказательствах: ученый использует знание, полученное в результате одного эксперимента, для того чтобы сделать выводы или спроектировать следующий эксперимент с учетом предыдущего. Так Ибн аль-Хайсам открыл природу человеческого зрения.

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

Базовые концепции скрама

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

Сложные адаптивные системы

Сложные адаптивные системы (САС) состоят из различных взаимозависимых элементов, отношения между которыми меняются в процессе. Сложные системы способны к адаптации: когда меняется одна переменная в системе, это затрагивает и другие. Возьмем простой пример из биологии – бактерии стафилококки. В 1940-х гг. более 99 % стафилококков были чувствительны к пенициллину. Сегодня они к нему устойчивы: в результате постоянного воздействия антибиотиков бактерии эволюционировали, чтобы выжить.

В нашем мире требования к продукту, технологии и люди взаимосвязаны: изменения в одном из этих элементов приводит к изменениям в других. В детстве я любила ходить в кино, а заодно и играть на аркадных автоматах рядом с кинозалом. Мы не могли себе позволить игровую приставку типа Atari (да и аркадные автоматы нравились мне больше домашней приставки). Все поменялось, когда компания Nintendo выпустила свою игровую систему. Соседским ребятам подарили ее на Рождество, и с тех пор мы несколько раз в неделю заявлялись к ним играть в Super Mario Brothers. Потом появились джойстики, Playstation, Sega и другие игровые системы и приставки. А теперь есть и мобильные игры. С появлением 16- и 32-битных консолей значительно улучшилась графика, конкуренция подхлестнула разработку все более и более инновационных продуктов (что серьезно расширило выбор для потребителя), а новые технологии позволили производителям выйти на ранее не охваченные рынки. Технологии, производители, потребности и желания пользователей – в производстве компьютерных игр все это взаимосвязано. Изменения в одном элементе делают необходимыми изменения и в других. Так что в детстве я недооценивала важность Марио и Луиджи для развития технологий – оказалось, они не просто спасали принцессу.

Вот как выглядит эта формула сегодня: у потребителей каждую минуту меняются потребности и желания, разработчики постоянно создают новые технологии и улучшенные версии старых, а потребители и другие стейкхолдеры никогда не упускают возможности высказать свое мнение по поводу свойств существующих продуктов. В процессе реализации проекта происходит эволюция нового знания, потребностей и желаний в отношении требований и технологий, и эта эмерджентность вносит свой вклад в сложность системы: у нее появляются новые свойства, не присущие ее элементам. Сложными проектами невозможно адекватно управлять при традиционных подходах, когда каждая задача ставится заранее и затем передается конкретным работникам. Если неизвестно, к чему нужно прийти в итоге, лучше всего воспользоваться подходами, основанными на эмпирических процессах или процессах с прочной доказательной базой: см. статью Д. Дж. Сноудена и М. Э. Бун «Модель действий лидера при принятии решений» (A Leader's Framework for Decision Making) для журнала Harvard Business Review. Но вопрос не в том, чтобы просто применить к той или иной ситуации правильный инструмент: сложные системы включают в себя и сложные взаимодействия между людьми. Сложному проекту нужен процесс, который учитывал бы эмерджентность. Кроме того, он требует и особого стиля руководства, способствующего развитию нормальных взаимоотношений в коллективе.

На следующем рисунке представлена знаменитая матрица Стейси, созданная Ральфом Стейси, профессором менеджмента из школы бизнеса Хертфордширского университета. Стейси много лет пытался разобраться, как использовать науку о сложных системах для изучения организаций. Вы наверняка столкнетесь с его работами, когда будете проходить курс скрам-мастера. Матрица Стейси рассматривает определенность и согласованность, которые в современном мире связаны с технологиями и требованиями к продукту. Чем дальше та или иная ситуация от определенности и согласованности, тем она сложнее и хаотичнее. В то же время простая ситуация характеризуется согласованностью и пониманием. Вспомните какой-нибудь простой проект – из вашего собственного опыта. Требования к новым характеристикам продукта были простыми и четкими, и вы написали весь необходимый код уже несколько недель назад. Вы с легкостью оценили, сколько времени займет проект: сюрпризы были маловероятны. Но при создании ПО такие «простые ситуации» – редкость. Сложный сценарий предполагает, что код не готов, потребитель постоянно меняет требования, а команда разработчиков то и дело срывает сроки. Тут уже не до планирования, поскольку сюрпризы (в основном неприятные) почти гарантированы.

Обратите внимание: я наложила роли в скраме и контрольные точки на матрицу Стейси. Скрам-мастера знают, что они не контролируют сложные проекты, действуя как специалисты по постановке задач и объясняя каждому работнику, что ему предстоит делать каждый день. Контроль осуществляется скорее за счет того, что каждый член команды имеет право на самоорганизацию в течение ряда спринтов (или тайм-боксов), а владелец продукта внимательно работает с бэклогом. Каждая роль в скраме имеет конкретный набор важных зон ответственности, и каждая из них, как подразумевается, должна контролировать хаос (кстати, первый сайт Кена Швабера так и назывался – controlchaos.com). Меня часто спрашивают, предусматривает ли скрам роль менеджера проекта, и я однозначно отвечаю: «Нет!» Ведь если передать одному человеку функцию контроля – что делать, как делать и почему делать, то все может закончиться хаосом и другими печальными последствиями. Три важные зоны ответственности, поделенные между тремя основными ролями в команде, создают систему сдержек и противовесов в наших сложных проектных системах. Эти три главные роли в скраме в сочетании с простой моделью помогают контролировать хаос. В течение каждого спринта команда, сосредоточенная на небольшом наборе пожеланий по проекту, разрабатывает соответствующие технические решения одно за другим, подводя проект к беспроблемному завершению спринта за спринтом. Если эта система контроля не будет достаточно защищенной, то легко могут возникнуть нежелательные явления. Скрам – концепция довольно простая и вместе с тем очень мощная при правильном применении (что не так-то просто). Вы, мой дорогой скрам-мастер, должны упрощать ход спринтов, исключая лишние вмешательства и помогая владельцу продукта содержать в порядке бэклог.

Даже если матрица профессора Стейси и статья Бун и Сноудена задают удобные рамки для размышлений, как правильно выбрать процесс для той или иной ситуации, не стоит слишком упрощать этот материал! Профессор Стейси перестал публиковать матрицу после второго издания своей книги (на сегодня вышло уже шесть). Что же случилось? Профессор Стейси считает, что аудитория слишком упростила матрицу: люди уверены, будто могут самостоятельно выбирать инструмент в зависимости от характера своего проекта. Все не так просто, согласно Стейси: «Итог – это результат взаимодействия между намерениями и стратегией всех вовлеченных в проект сторон, и ход этого взаимодействия никто предсказать не в силах из-за природной неопределенности и непредсказуемости, присущей нашей с вами жизни». Иначе говоря, проблемы устраняет не скрам, их устраняют люди; скрам только показывает, где искать проблемы. Люди сами должны бороться с этими проблемами и придумывать различные решения для различных сценариев. В этой книге рассказывается, как скрам-мастер может содействовать поиску таких решений – как внутри команды, так и вне ее.

Знание – это результат опыта. В традиционных подходах к управлению проектами все решения принимаются в самом начале. Я всегда недоумевала: ведь мы начинаем всерьез разбираться в проекте только под конец! Скрам подталкивает команды выдавать результаты как можно быстрее, поэтому быстрее расширяются и знания исполнителей относительно требований по проекту и технологий, а в работе команды появляется (и усиливается) динамика. Чем раньше команда начнет работу, тем лучше. Когда команда накапливает достаточно знаний, исполнители могут принимать более правильные и взвешенные решения. Обычно скрам-команды откладывают решения по вопросам меньшей важности на более позднее время – требования в их технологическом окружении все равно постоянно меняются.

Четыре инструмента контроля над эмпирическим процессом

Скрам, как табурет, стоит на четырех «ножках»: приоритезированный бэклог; выделенная кросс-функциональная команда, тайм-боксы и, наконец, инспекция и адаптация. Эти четыре «ножки» и создают структуру, позволяющую нам называть скрам эмпирическим процессом. Когда «табурет» теряет одну из опор, он лишается равновесия (попробуйте-ка усидеть на табурете с тремя ножками). Даже если одна из «ножек» всего лишь короче других, табурет становится неустойчивым и неудобным. То же относится и к скраму: как только какой-то элемент структуры ослабевает, ослабевает и команда, проект идет наперекосяк, эксперимент становится неубедительным, поскольку утрачиваются точки контроля. Скажем, если скрам-мастер по какой-то причине допускает прерывание спринта, команда может и не довести дело до логического завершения. Все вынуждены остановиться и начать все сначала – это мы и называем хаосом. То же самое происходит, если владелец продукта неаккуратно ведет бэклог, где идеи не ранжированы по приоритетности: в этом случае команда может передать потребителю необходимую функциональность, а может и не передать. Даже небольшое нарушение этих основополагающих принципов может вызвать эффект схода лавины. Если же команда твердо придерживается вышеизложенных принципов скрама, то с наибольшей вероятностью достигнет цели.

Кен Швабер и Джефф Сазерленд создали эти четыре «ножки стула», или принципа скрама, для того, чтобы посредством эмпирического процесса контролировать проекты по разработке программного обеспечения. Впрочем, этот метод годится, пожалуй, для проектов любого характера. Скрам представляет собой особый (имеющий доказательную базу) способ продвижения проекта или инициативы. Без определенных временных рамок для получения обратной связи по фрагментам функциональности (как при «водопадном» управлении проектом) команда, менеджмент и потребители не имеют никакого представления, что за продукт вообще создается. Вспомните обычное совещание по ходу работы над проектом при традиционной модели. Нравились они вам? Лично меня пугали. Как правило, я представляла доклад о статусе исполнения проекта с многочисленными красными, зелеными и желтыми точками на нем, зачитывала какие-то цифры, какие-то проценты («завершенность фазы») и иногда приводила список ближайших рисков. Честно говоря, я, выполняя обязанности традиционного менеджера проекта, действовала так: если я не знала точно степень готовности проекта, то изображала на доске желтую точку, рассчитывая уточнить информацию позднее. Или, хуже того, перед совещанием я допоздна проводила несколько вечеров в офисе, стараясь придать диаграммам Ганта правдоподобность.

Скрам-модель, при которой упор делается на потенциально готовый к поставке продукт и которая усиливает каждый спринт, делает игру в прятки ненужной. Анализ спринтов заменяет совещания по статусу проектов, и при этом анализе статус подлинный, то есть команды показывают реальные версии функциональных возможностей, которые работают! Это интересно и конкретно! Это доказательно – и мы можем работать с доказательствами! Можно больше не гадать: благодаря скрам-модели мы можем всегда увидеть и «потрогать» статус исполнения проекта, обратившись к обзору спринта и взаимодействуя с программным продуктом или системой в таком виде, в каком они существуют в данный момент времени.

Недавно я смотрела телевизионную программу про George Cleverly and Company. Это знаменитая лондонская обувная компания, основанная в 1958 г. Она производит дорогие модели (одни из самых дорогих в мире) индивидуальной работы для самых требовательных модниц и модников. Поэтому компания вынуждена ежедневно, ежечасно работать в очень тесном контакте с потребителями, стараясь понять все их желания и требования. Точно измерив стопу заказчика, включая даже всякого роста наросты и мозоли, мастера переходят к предпочтениям клиента (цвет, кожа, подошва, шнурки…) – для того, чтобы сделать именно такую обувь, о которой мечтает клиент и которую он будет любить. Иногда над одной парой мастера трудятся несколько месяцев, и стоит она по меньшей мере $3000, но вот уже больше полувека клиенты с радостью платят такие деньги и с нетерпением ожидают сообщения о готовности заказа. George Cleverly and Company вовлекает своих клиентов в творческий процесс разработки модели – другого способа создать совершенную обувь просто не существует. Когда я слышу, что отличительные черты бренда Cleverly – высокое мастерство, внимание к деталям и клиентоориентированность, то думаю: а ведь процесс производства обуви в этой компании прекрасно вписывается в скрам-модель. Это повторяющийся креативный процесс, в котором клиент становится важной составной частью, обеспечивающей получение желаемого результата. Даже несмотря на то, что бэклог в этом случае остается фиксированным (вернее, фиксированным остается порядок шагов, осуществляемых производителем в процессе изготовления обуви), потребитель вовлечен в каждый этап этого процесса.

Базовые скрам-ценности

В дополнение к основным принципам в теории сложных адаптивных систем скрам сам по себе имеет пять базовых ценностей: приверженность (то есть верность обязательствам), сосредоточенность, открытость, уважение и смелость. Мы подробно рассмотрим этот вопрос в главе 8 «Вопросы повседневного лидерства в отношениях скрам-мастера с командой».

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

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

Поскольку скрам опирается на эмпирический контроль за продвижением проекта, важно, чтобы результаты и опыт эксперимента (то есть спринта) были прозрачными. Так, анализ спринта позволяет увидеть новые свойства продукта, появившиеся в процессе, а ретроспектива спринта вовлекает членов команды в обсуждение личных и общекомандных успехов, достигнутых в ходе работы, а также выявленных проблем. Если все эти аспекты работы по проекту становятся видимыми, то появляется возможность их проанализировать и адаптировать. А получение доказательств (информации) – самая суть эмпирического процесса. Поэтому открытость и является одним из базовых принципов скрам-метода.

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

От скрам-мастера требуется большое мужество, чтобы применять скрам так, как он был задуман. Хотя скрам не слишком сложно устроен, люди зачастую слишком «заорганизовывают» его изначальную простоту. Я не раз сталкивалась с тем, что руководство компании прибегает к скраму в стремлении сделать больше с меньшими затратами (хотя это не всегда так!), но не признает – и даже не слишком отчетливо понимает, что скрам требует от организации перемен. Одна из самых главных задач скрам-мастера – помочь руководителям организации осознать ее слабые места, чтобы устранить их. Это требует смелости. Иногда команда должна идти наперекор владельцу продукта, если в рамках конкретного спринта от нее просят слишком много. Необходимо мужество, чтобы сказать «нет» такому давлению. Владелец продукта, в свою очередь, должен в контакте со стейкхолдерами смело смотреть в лицо правде – реальному состоянию проекта. Это лишь несколько примеров того, когда необходима смелость, чтобы не нарушать границы эмпирического процесса и избегать ненужных усилий или затрат на продукт или процесс.

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

Скрам и бережливость

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

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

Второй принцип: бережливое мышление подразумевает, что у каждого члена команды должен быть шанс учиться. А скрам, в свою очередь, требует, чтобы итогом любого спринта было потенциальное реализуемое улучшение продукта: члены команды должны писать код и тестировать его, чтобы понимать, что именно работает неправильно. При этом владелец продукта узнает его все лучше.

Третий принцип: членам команды необходимо как можно теснее контактировать друг с другом: это подразумевает, что они осваивают и соседние «зоны ответственности».

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

Далее. В бережливом производстве считается, что разработка продукта должна вестись быстро. Принцип скрама – передача готового продукта производится в среднем раз в 30 дней, хотя многие команды успевают быстрее. Для этого и бережливое производство, и скрам наделяют команду соответствующими полномочиями. Кроме того, при бережливом производстве принцип интеграции должен быть встроен в систему; скрам же требует оценивать проделанную работу совместно с клиентом. И, наконец, бережливый метод призывает смотреть на то, как действует поток создания ценности или цепочка событий в целом при создании ценности для конечного потребителя. Любые проблемы должны устраняться как можно скорее, а команды следует формировать так, чтобы они были в состоянии поставить завершенные инкременты продукта. В скраме это означает, что необходимо создавать выделенную кросс-функциональную команду, которая способна анализировать процессы в ходе ретроспективы. Такие ретроспективы помогают вскрывать проблемы (или препятствия, как они называются в скраме) и устранять их.

Роли в скраме

Этот раздел – краткий обзор трех ролей в скраме: скрам-команда, владелец продукта и скрам-мастер. Наша книга посвящена в основном роли скрам-мастера, но мы подробно разберем и остальные роли, исходя из их естественных взаимосвязей. Как вы, наверное, сами понимаете, людей обычно очень беспокоит, какова их роль в коллективе и где границы их зоны ответственности. Мы более предметно поговорим о ролях в скраме (и не только в скраме) в главе 9 «Формирование аджайл-организации».

Скрам-команда

Скрам-команда включает в себя владельца продукта, скрам-мастера и членов команды (оговоримся, что команда разработки состоит только из технического ядра команды). Вся команда принимает участие в работе над поставленной проблемой (элементом бэклога – упорядоченного списка требований, журнала пожеланий) и разрабатывает инновационные решения. Скрам-команда – это 5–9 участников, организованных в группу на период жизненного цикла проекта (и, возможно, на более длительный период). Команда должна обладать соответствующими полномочиями, быть кросс-функциональной⁴, а также способной к самоорганизации. Они сами планируют, оценивают и берут на себя обязательства по своей работе, а не надеются на менеджера. Конечная цель работы команды состоит в создании инкремента продукта, который потенциально можно представить заказчику и который удовлетворяет критериям готовности. Обувных мастеров George Cleverly and Company мы можем рассматривать как ядро скрам-команды (команду разработки), тогда как клиент, дизайнеры обуви и так далее совместно с теми же обувными мастерами будут составлять общую скрам-команду. И все эти люди участвуют в производстве соответствующей модели обуви.

Владелец продукта

Владелец продукта несет ответственность за его конечный успех. Иными словами, если команда отвечает за поставку качественного решения, владелец продукта должен хорошо знать рынок и понимать нужды потребителей, чтобы правильно направлять команду на разработку потенциально продаваемого на рынке релиза – от спринта к спринту. В разных проектах владельцы продуктов, разумеется, разные, но – независимо от технической ситуации и желаемых результатов – у каждого продукта должен быть один (и единственный) владелец, который принимает окончательные решения о направлениях его разработки и порядке создания элементов функциональности. Бэклог, или список того, что должна сделать скрам-команда, составляется владельцем так, чтобы отражать наиболее ценные требования и пожелания к продукту (или их изменения по мере продвижения разработки). Владелец продукта, представляя себе все «что» и «зачем», связанные с разработкой, должен быть доступен для регулярного диалога с командой о требованиях, которые содержатся в бэклоге продукта. Кроме того, владелец продукта должен добиться, чтобы каждый участник команды отчетливо видел будущий продукт и чтобы бэклог заполнялся в соответствии с этим видением. У владельца продукта всегда должен быть готов очередной набор пожеланий по продукту – чтобы команда заблаговременно представляла себе объем работы для следующего спринта. Клиент компании по производству элитной обуви (см. пример выше) – это идеальный пример владельца продукта для скрам-команды: именно он и платит за продукт!

Скрам-мастер

Скрам-мастер «охраняет» процесс разработки. Он понимает причины, лежащие в основе эмпирического процесса, и изо всех сил пытается обеспечить как можно более ровный ход разработки продукта. Этот «слуга-лидер» (термин принадлежит Р. Гринлифу – см. его книгу «Слуга в роли лидера»⁵ (Servant Leadership)) защищает членов команды от нежелательных вмешательств и отвлекающих моментов для того, чтобы дать им возможность сосредоточиться на выполнении своих обязательств по спринту, а также помогает владельцу продукта правильно работать с бэклогом. Кроме того, он фасилитирует все встречи, заложенные в структуру скрама, добиваясь, чтобы каждый член команды осознавал поставленные цели и разделял общую ответственность – словом, чтобы команда была настоящей командой, а не наспех собранной группой индивидуумов. Скрам-мастер устраняет препятствия на пути разработки функциональности, несущей максимальную ценность в продукте. Зачастую природа этих препятствий – организационная.

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

Обзор структуры скрама

Структура скрама проста: это шесть событий, одно из которых опционально, три роли и три «официальных» артефакта.

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

Планирование спринта

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

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

Разумеется, команды всегда ищут способы сделать планирование более быстрым и эффективным. Если команда действует последовательно, то можно заметить, что от спринта к спринту время, затрачиваемое на их планирование, сокращается.

Результат планирования спринта – бэклог спринта, который включает в себя конкретные требования по продукту для конкретного спринта, а также соответствующие задачи, поставленные командой во второй части планирования. Мы детально рассмотрим, как обеспечить эффективность планирования спринтов, в главе 3.

Ежедневные скрам-митинги

В ходе ежедневных скрам-совещаний (третьего события скрама) члены команды стараются сделать свой прогресс в работе видимым, чтобы проинспектировать его и адаптировать к своим целям. Это чем-то похоже на ежедневный мини-цикл Деминга («Планируй – пробуй – проверяй – корректируй»)! Совещание обычно проводится в одно и то же время и в одном и том же месте, о чем команда договаривается заранее. Даже если команда приложила все усилия для правильного планирования спринта, ситуация может измениться в мгновение ока. Том завершает свою работу с небольшим опозданием, Бет, наоборот, раньше, а Ашиш вообще застрял на половине. Во время 15-минутной встречи члены команды обсуждают, что им удалось сделать со времени предыдущего митинга, что они планируют сделать к завтрашнему, а также беседуют про препятствия, которые стоят перед ними. Роль скрам-мастера на таких совещаниях – содействовать обсуждению, не давать участникам «закопаться» в поиск решений для каждой проблемы и фиксировать все препятствия, с которыми, как полагают члены команды, они не могут справиться сами. Скрам-мастер должен попытаться устранить эти препятствия после совещания. Ежедневное скрам-собрание представляет собой текущую оценку и адаптацию сделанного. В совещании участвуют члены команды, владелец продукта и скрам-мастер. Присутствовать могут все желающие – но только в качестве наблюдателей.

Обзор спринта

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

Ретроспектива спринта

В ходе ретроспективы – финальной встречи в рамках спринта – члены команды обсуждают события спринта, отмечают, что помогло им в работе, а что – нет, и решают, что нужно поменять в ходе следующих спринтов. Скрам-мастер фиксирует вопросы, которые команда, по ее мнению, не может решить самостоятельно и которые, возможно, должны решаться в масштабе всей организации. В дальнейшем скрам-мастер должен будет сообщить команде о действиях, предпринятых по поводу возникших вопросов. Ретроспектива должна занимать не более 3 часов. Мы подробнее рассмотрим обзор и ретроспективу спринта в главе 5 «Конец? Как шаг за шагом улучшать продукт и процесс его разработки».

Планирование релиза продукта (опционально)

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

Кен Швабер как-то сказал мне: «Я не понимаю, почему люди превращают планирование релиза в такое долгое и нудное мероприятие. На деле в нем нет ничего сложного». И после этого мы провели планирование релиза за 15 минут.

Артефакты скрама

Набор артефактов скрама невелик: бэклог продукта, бэклог спринта и инкремент продукта после каждого спринта. Ниже мы рассмотрим и детально проанализируем эти артефакты.

Бэклог продукта

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

Владелец продукта формулирует приоритеты, начиная с самых важных или самых полезных позиций. Имеется в виду, что верхняя часть списка представляет собой не просто 10 важнейших позиций, а скорее 10 наиболее приоритетных и срочных позиций. Именно так они и фигурируют в бэклоге продукта – одна за другой. Именно эти позиции – первые в очереди для реализации. Как только команды выбирает задачи, которые должны быть выполнены в рамках очередного спринта (или итерации), эти позиции и их очередности фиксируются. Впрочем, любые приоритеты и детали любого элемента бэклога, если он еще не взят в работу (в спринт), могут быть изменены. При помощи такого механизма команды могут сосредоточиться на задачах конкретного спринта, а владелец продукта сохраняет максимальную свободу действий, устанавливая объем работы на очередной спринт.

У владельцев продукта много способов для оценки и расстановки приоритетов по списку. Требования по продукту, содержащиеся в бэклоге, могут также сопровождаться дополнительными примечаниями: например, нужно увеличить узнаваемость бренда, поднять продажи, заинтересовать клиентов, готовых вложить не менее $10 000, и т. д. Такие дополнительные примечания уникальны для каждой компании и конкретного продукта – они помогают владельцу продукта поддерживать бэклог в порядке.

Бэклог спринта

Бэклогом спринта обычно занимается сама команда: он отражает те задачи, которые команды обязалась выполнить в ходе планирования спринта, а также задачи, отложенные на будущее, и перспективные идеи. Члены команды ежедневно обновляют бэклог спринта, чтобы определить, сколько часов осталось у конкретного работника на выполнение стоящей перед ним задачи. Кроме того, члены команды могут снимать, добавлять и изменять задачи по ходу спринта.

Инкремент продукта

Инкремент (приращение) продукта – ощутимый результат работы каждого спринта. Он представляет собой набор бизнес-функциональности, отдельных пользовательских историй и других результатов, которых команде удалось добиться в ходе спринта. Инкремент продукта должен быть потенциально готовым к поставке, то есть достаточно высококачественным для того, чтобы его можно было передать пользователям. Владелец продукта отвечает за принятие инкремента продукта после каждого спринта – в соответствии с согласованными критериями готовности и критериями приемки по каждому результату работы в спринте (функциональности, пользовательской истории, обособленной задачи). Без инкремента продукта его владелец и другие стейкхолдеры не в состоянии ни проинспектировать, ни адаптировать продукт.

Видимый прогресс

Команда должна добиться, чтобы ее прогресс был всегда видимым. Для этого она может пользоваться различными инструментами. К этим инструментам относятся, например, диаграммы сгорания – то есть графики сделанной и оставшейся по релизу и спринту работы.

Бэклог и диаграмма сгорания релиза

Разновидность бэклога продукта, который составляется под релиз конкретного продукта, так и называется – бэклог релиза. Хотя бэклог релиза можно составить и заранее, в ходе проекта владелец продукта имеет право убирать или менять требования, а также договариваться с командой о глубине охвата конкретных элементов в соответствии со своими взглядами на объем работы, время и затраты. Таким образом, в процессе реализации проекта бэклог релиза должен постоянно обновляться. В главе 2 будет рассказано подробнее о бэклогах продукта, а также о бэклогах релиза и диаграммах сгорания.

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

Диаграмма сгорания спринта

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

Диаграмма сгорания очень важна – ведь дата окончания спринта устанавливается раз и навсегда. Наряду с ежедневными скрам-митингами бэклог спринта и диаграмма сгорания наглядно показывают команде, когда она сбивается с ритма, и позволяют предметно обсудить, что можно предпринять для исправления ситуации. Диаграмма сгорания спринта «сжигает» часы работы по дням спринта, тогда как диаграмма сгорания релиза отражает выполнение единиц работы (часто оцениваемых в неких условных единицах) или количество спринтов, оставшихся до релиза. В главе 3 и 5 подробно рассказывается про бэклоги и диаграммы сгорания.

Сбой или настоящая проблема?

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

Цикл жизни проекта, как правило, краток, а препятствия, которые необходимо выявлять, возникают постоянно, поэтому список проблем, требующих вмешательства скрам-мастера, может быть бесконечным. В ходе работы команда ежедневно, ежечасно сталкивается с самыми разными препятствиями и отвлекающими моментами. Владелец продукта и стейкхолдеры, подводя итоги спринта, внимательно исследуют продукт. Это часто приводит к изменениям в бэклоге продукта и, таким образом, в самом продукте. Ретроспектива спринта дает команде возможность сосредоточиться на совершенствовании процесса, чтобы в дальнейшем он протекал более гладко. Следует отметить, что скрам-модель содержит три встроенных механизма для выявления проблем. Как говорят в Техасе, если вы ищете приключений на свой зад, то обязательно их найдете. А скрам может выявить немало проблем.

Так что же нам, скрам-мастерам, делать со всеми этими трудностями? Нужно спросить себя: «Трудность, с которой мы столкнулись, настоящая проблема нашей организации или просто досадный сбой?» Рассмотрим пример настоящей проблемы – документ, который необходимо представить для утверждения в Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA). Скажем, в ходе ретроспективы команда указала, что эта проблема приводит к непроизводительным потерям, – но ведь ни один продукт не попадет на американский рынок без разрешения от FDA. Так что это и есть настоящая проблема, с которой придется тщательно работать.

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

Готова ли ваша команда к скраму?

Начиная (или даже продолжая) работать со скрамом, вы, скорее всего, едва ли получите в свое распоряжение идеальную команду, функционирующую в идеальных рабочих условиях. Поэтому я подготовила короткий список: что необходимо уяснить в первую очередь для успешного начала работы.

● В вашей команде все члены выделены для проекта на 100 %? Члены команды представляют собой кросс-функциональный набор навыков и способностей, которых в совокупности достаточно для поставки ценности конечному заказчику?

● Есть ли у вас владелец продукта? Если нет, можете ли вы подобрать кого-то на эту роль, чтобы команда как можно скорее начала работать над самыми важными элементами бэклога?

● Есть ли у владельца продукта свое видение, ведет ли он бэклог? (Подробнее см. главу 5.)

● Можете ли вы организовать не более чем 30-дневный (а еще лучше – более короткий) спринт?

● Можете ли вы привлечь к участию в обзоре спринта бизнес-стейкхолдеров? (Это отнюдь не обязательное требование, однако в этом случае повышается оперативность и прозрачность работы вашей команды.)

● Хватит ли вам смелости обсуждать проблемы по мере их появления?

● Можете ли вы помочь команде создать и вести бэклог спринта? (Подробнее см. главу 2.)

● Можете ли вы взять на себя обязательства по защите команды от вмешательств, независимо от того, кто будет их инициатором?

Заключение

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

Глава 2
Планирование релиза – настройка процесса разработки продукта

В традиционных проектах содержание⁶ (объем) определяется и контролируется по ходу проекта. Аджайл-команды подходят к этому вопросу по-другому: сначала определяют достаточный для начала проекта объем, а затем примиряются с необходимостью изменений и начинают работать, следуя по вновь открывающимся путям. Аджайл-команды стремятся прежде всего отвечать на запросы рынка или пользователей по мере возникновения этих потребностей. Однако время от времени нужды бизнеса требуют и от них планирования на перспективу. Члены аджайл-команд понимают, что предсказать итоги работы по проекту невозможно, поэтому действуют прагматически – подстраивают усилия по разработке продукта к последним и самым важным требованиям. Это похоже на прогноз погоды в вечерних новостях: предсказания метеорологов на следующий день, как правило, сбываются, а вот через неделю – никогда! К сожалению, не существует команд (и метеорологов), способных предсказывать будущее. Именно поэтому я всегда держу в машине запасной зонтик.

Традиционные проектные метрики – скажем, запланированный объем, стоимость и сроки – не годятся в случае сложных технических проектов. Вот вам простой пример (на самом деле таких примеров тысячи): если команда проекта меняет его направление потому, что клиент на полпути меняет требования, это провал? Члены аджайл-команд уверенно ответят, что нет, пояснив, что умение реагировать на меняющиеся требования свидетельствует как раз об успехе работы. Но я слышала и противоположные утверждения: если бы члены команды уделяли больше внимания обсуждению требований заказчика, то они смогли бы предугадать все его нужды с самого начала, чтобы не сталкиваться по ходу работы с неожиданными осложнениями (как будто возможно забросить невод и вытащить, как рыбу, все возможные требования к проекту!). Согласно традиционной логике управления проектами, если мы не достигли цели по объему, срокам и стоимости, значит, проект провалился. К сожалению, до сих пор многие руководители следуют этому глубоко укоренившемуся принципу. Это может свести на нет любые попытки аджайл-планирования.

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

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

Впрочем, вы живете в реальном мире и вряд ли решитесь на бунт, поэтому у меня есть для вас совет, который несколько полезнее лозунга «Ура, долой правила!». Во-первых, не бойтесь иметь альтернативную точку зрения по вопросам планирования. Помните, почему в современных условиях вас просят планировать проекты: потому что этого требует бизнес. Ограничения – стоимость проекта, его сроки и ресурсы (человеческие и не только) – это данность, с которой скрам-мастеру придется иметь дело в ходе проекта. Или не совсем данность? Аджайл-методы позволяют сделать паузу и задуматься, что все эти параметры могут изменяться – если организации для итогового успеха необходимы перемены. Знайте, что в настоящее время среди организаций набирает силу тренд на отход от традиционного мышления по вопросам управления проектами. И я целиком и полностью списываю это на аджайл. Аджайл смещает фокус – с «магического кристалла» на «постоянную адаптацию». Мэри Поппендик, автор книги «Бережливая разработка программного обеспечения: Аджайл-инструменты» (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).

Планирование релиза: когда будут продемонстрированы новые функции?

Итак, теперь у вас есть бэклог продукта. Что дальше? Если вы не обязаны спрогнозировать, каким будет набор фрагментов функциональности к какому-то определенному времени, то команда может просто начать выполнять задачи, занесенные в бэклог, начиная с самых верхних. Но если организация требует от команды прогноза, каким будет объем выполненной работы к тому или иному сроку, вам придется осуществить планирование релиза.

Временная привязка релиза и его планирование

Сами по себе релизы продукции должны осуществляться в то время, которое определяет владелец продукта: именно он оценивает такой показатель, как возврат инвестиций, и решает, какой объем функциональности должен быть доступен для клиента или пользователей. Как правило, владелец продукта имеет временные ориентиры по релизу до начала работы по проекту («Он был нужен мне еще вчера!»). Существует определенная частота, с которой потребители хотят видеть новые функции продукта, и в обязанности владельца входить способность определить этот ритм. Например, я рассчитываю, что в приложении «Карты» моего нового iPhone новые функции могут появиться в любое время. В то же время мне бы не очень понравилось, если бы каждый месяц в продаже появлялся новый iPhone с новой операционной системой и интерфейсом (я думаю, что в наше время новые модели смартфонов и так выходят слишком часто, – хотя рынок, судя по всему, думает по-другому… во всяком случае пока).

Необходимо, чтобы владелец продукта был в состоянии доводить планы релиза до других участников бизнеса. Например, маркетологам и продавцам во многих компаниях сведения о сроках релизов нужны как можно раньше – для организации пиар-кампании продукта и подогрева интереса к нему, поэтому с точки зрения бизнес-перспектив очень важно заблаговременно предоставлять этим специалистам информацию о готовящихся событиях. Большинство организаций начинают торговлю новыми фрагментами функциональности еще до завершения их разработки, подписывая контракты, основанные на обещаниях. И хотя я всей душой ненавижу контракты с фиксированными сроками исполнения и содержанием, все же должно существовать хоть какое-то указание на то, когда новые фрагменты функциональности станут реальностью! По моим оценкам, 80 % компаний начинают планирование релиза еще до старта проекта, а впоследствии либо команда вообще не занимается планами релизов, либо эти планы составляются уже после нескольких спринтов, когда команда начинает осознавать, с какой скоростью она продвигается вперед. Независимо от того, когда и как составляется план релиза, владелец продукта и команда должны постоянно сверяться с этим планом по ходу проекта, когда меняются условия. Ваша обязанность как скрам-мастера – обеспечить постоянство таких сверок.

Не создавайте «больших канав» при разработке ПО

Вероятно, вы слышали о Большом бостонском тоннеле, именуемом также Большой траншеей или даже – еще грубее – Большой канавой. Первоначально проект оценивался в $2,5 млрд, и его планировалось завершить в 1998 г. К 2006-му расходы на строительство тоннеля возросли до $14 млрд. К этому времени проект уже считался «завершенным», но по-прежнему необходимо было заменить 25 000 изношенных источников освещения (стоимость работ оценивалась в $54 млн). Вирджиния Грейман из Бостонского университета настаивает: «Причиной взрывного роста стоимости объекта явилось не какое-то катастрофическое событие или недостаточное число контрактов. Критическим для проекта стало отсутствие у подрядчиков необходимого опыта и знаний, как действовать в условиях повышенной сложности и неопределенности, свойственных гигантским проектам…» Разрабатывала проект одна компания, а строительством занималась другая, и обе они с самого начала не обеспечили должное взаимодействие между тысячами своих сотрудников. К сожалению, окончательной ценой строительства «Большой канавы» стала человеческая жизнь – несколько лет назад в тоннеле раздавило машину с водителем, поскольку клеящий состав, использованный для крепления верхнего перекрытия, оказался недолговечным. С самого начала в этом проекте было столько неопределенного, что для любого подрядчика было бы глупо претендовать на определенную сумму контракта, как и для главного заказчика – Massachusetts Turnpike Authority – было бы глупо верить, что обязательства будут выполнены. Однако мы живем в таком мире, в котором, к сожалению, низкие ценовые предложения и туманные обещания иногда приносят компаниям победу в тендерах и контракты.

История с «Большой канавой» – полезный урок и для планирования релизов.

Старайтесь как можно раньше объединить команду, чтобы избежать рисков

Подталкивайте членов команды (или разных команд, если речь идет о большом проекте) к объединению усилий: пусть это начинается как можно раньше и делается как можно чаще, а также учитывается в планах релизов. Многие разработчики не любят совместную деятельность, поскольку не хотят проблем, которые иногда порождает такое объединение усилий. Скрам-мастер всегда должен напоминать членам команды, что часть кода, над которой работает один программист, будет бесполезна, если не окажется совместимой с другими частями и если все части не пройдут тестирование. Возможно, в ходе самых первых спринтов команде будет сложно сработаться по ряду объективных причин (устаревшие приемы, инструменты и т. д.), но вы должны ей помогать, чтобы в итоге усилия всех и каждого были объединены на постоянной основе. Без этого организация не сможет быстро реагировать на самые насущные потребности пользователей. Добейтесь, чтобы ваша команда занималась такими вопросами, как интеграция усилий, тестирование и выработка критериев готовности в планировании релизов, с самого начала, просите ее по ходу проекта постоянно сверяться со своими целями. Подробнее об этом вы можете прочесть в статье Хенрика Книберга, посвященной ситуационному контролю в аджайл-командах⁷.

Делайте «амортизаторы» заметными

Скрам-мастер должен подталкивать членов команды к обмену реальными оценками и так называемыми буферами – для тех проектов, где уровень неопределенности особенно высок. Это значит, что команда должна обеспечивать специальный буфер в расчете на неизвестное. Например, если вашей команде через несколько спринтов предстоит освоить новую технологию третьей стороны, то она должна буферизировать оценки в плане релиза, чтобы учесть все факторы неопределенности в интеграционных усилиях. Конечно, команда может подготовить и заниженные оценки по затратам и срокам, чтобы порадовать владельца продукта (правда, недолго). Беда в том, что вскоре команда придет к нему, поджав хвост, чтобы попросить больше денег и времени, – а это, на мой взгляд, не лучший вариант. Еще хуже, если команда попытается сотворить чудо, «срезав» проблемные углы проекта и понизив качество продукта. В итоге эти проблемы все равно замучают членов команды (или тех несчастных, которые придут им на смену) в будущем. Команда должна буферизировать оценки, чтобы компенсировать факторы неопределенности, и регулярно сообщать скрам-мастеру и владельцу продукта, что ее беспокоит. Чем надежнее буферизирован проект, тем лучше. В этом случае при необходимости можно просто добавить в релиз еще несколько пользовательских историй. Это гораздо лучше, чем убирать истории из релиза!

Буферизация неопределенностей – это просто отказ планировать каждый спринт, исходя из 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).

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

Планирование релиза: что в сухом остатке

Традиционный взгляд – планирование, абсолютно предсказуемое по времени и объемам, – становится невидимым препятствием в нашей повседневной деятельности. Оно возникает на каждом шагу при планировании, поддержке этого процесса и доведении его результатов до потребителей. На совещании со стейкхолдерами из департамента продаж и клиентской поддержки нужно заявлять: «Вот наш прогноз, он основан на том, что мы знаем сегодня». На совещании с руководством по текущему состоянию проекта говорите то же самое. В каждом спринте сохраняйте план релиза абсолютно прозрачным и устанавливайте (меняйте) ожидания. Не поддавайтесь существующим методам корпоративного давления! От них один вред. Если вы сертифицированный скрам-мастер, оставляйте право на решения за собой и берите ответственность на себя.

Нельзя налить литр пива в полулитровую кружку. То есть, конечно, можно, но часть пива прольется. И его будет жалко. Так и команда может довести до релиза только определенное количество фрагментов функциональности, исходя из таких параметров, как имеющиеся ресурсы, количество членов команды, манера поведения владельца продукта (в том числе и уровень его вовлеченности в проект), и других факторов. Возможно, это будет только «пол-литра» конечной функциональности, тогда как клиент хочет сразу «литр». Стоит ли обещать ему этот «литр»? Что тогда произойдет с качеством продукта?

Пожалуйста, поймите меня правильно: команда может изо всех сил стараться сделать все от нее зависящее для разработки нужного клиенту продукта, но она должна отдавать себе отчет в том, что план релиза – это в лучшем случае прогноз. Этот прогноз основан на том, что члены команды – как коллектив – знают на данный момент. Поскольку наша осведомленность по поводу требований к продукту, технологий и взаимодействия между людьми со временем растет, зачем ограничивать свои предсказательные возможности, полагаясь лишь на какой-то выдуманный магический кристалл? Например, если появятся новые технологии, которые позволят нашему владельцу продукта затратить на его производство половину от оценочной суммы, зачем продолжать работу с первоначально выбранными технологиями? Разве наш клиент не будет рад выбрать новую опцию и потратить сэкономленные средства на создание нового продукта (или на более ранний релиз)? План релиза – это только материальный результат диалога, который постоянно ведется между владельцем продукта и командой разработчиков. Самая важная часть этого плана – обсуждение владельцем и командой потребностей проекта, его неопределенностей, подходов и компромиссов.

Заключение

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

В главе 3, посвященной планированию спринта и настройке задач по каждому спринту, мы разберем, как команда работает с владельцем продукта над созданием добротного краткосрочного плана на один спринт.

Глава 3
Планирование спринта – тонкая настройка обязательств по спринту

Если планирование релиза – камертон, то планирование спринта – это настройка музыкального инструмента, которую музыкант выполняет перед началом и во время игры. Настройка инструмента зависит от его состояния и влияния внешних факторов (например, погоды), а также манеры исполнения музыканта. Она возвращает инструменту его эталонный звук, то есть соответствующий внешнему эталону – камертону или цифровому тюнеру. В нашем аджайл-концерте планирование спринта – это тонкая настройка на элементы, занесенные в бэклог, но с ориентиром на более широкую картину (цели, которые записаны в план релиза). Инструмент может расстроиться, планы тоже. Но аджайл-план никогда не оторвется от общей линии, поскольку владелец продукта ведет его бэклог в соответствии с последними приоритетами и участвует вместе с командой в планировании спринта. Спринт позволяет команде и клиенту «настроить» кратковременные задачи, чтобы обеспечить достижение долговременных целей – от одного спринта к другому.

Основы планирования спринта

Если совсем грубо, то термин «планирование спринта» просто-напросто означает отрезок времени, когда команда… планирует спринт. Обычно это происходит в первый день спринта. Традиционно скрам оставляет восемь часов на планирование 30-дневного спринта. В последнее время многие команды перешли на двухнедельные спринты. Довольно распространены и спринты длительностью одну или три недели. В любом случае вполне логично, что при сокращении длительности спринта (менее одного месяца) команда должна сократить и количество времени, затрачиваемое на его планирование. Например, двухнедельный спринт не должен требовать более четырех часов планирования (его легко можно спланировать и за два часа). Как-то я работала с командой, которая затрачивала на планирование трехнедельного спринта всего 15 минут. При этом она постоянно добивалась выполнения от 85 до 95 % обязательств по спринту. При планировании «дольше» не означает «лучше»!

Программа Weight Watchers (контроль собственного веса) очень похожа на скрам. Когда человек начинает работать по этой программе, то он сначала взвешивается, чтобы определить, от чего отсчитывать прогресс. Он устанавливает цель и работает над еженедельными улучшениями показателей своего веса и состояния здоровья. Weight Watchers основана на системе еженедельных взвешиваний (они похожи на подведение итогов очередного спринта в скраме), а также еженедельных встреч партнеров-пользователей программы, в ходе которых они обсуждают результаты предыдущей недели и намечают планы на будущую. Взвешивания обеспечивают видимость и контролируемость результатов: да, пользователь может и не делиться результатами, но это, скорее всего, будет не очень продуктивно. Если результаты пользователя программы Weight Watchers невидимы, то невозможно узнать, в правильном ли направлении он двигается и правильно ли действует. Следовательно, невозможно и адаптироваться к ситуации. Без видимости процесса нельзя почувствовать, в чем именно возникла острая необходимость. Так, Weight Watchers побуждает пользователей в обязательном порядке посещать еженедельные собрания – чтобы перенимать у других опыт, учиться планировать работу на неделю вперед, разрабатывать стратегию, подогревать в себе интерес к продолжению занятий и заставлять себя выполнять взятые обязательства. Такова и суть планирования спринта в рамках скрама: представить себе процесс спринта, «зарядиться» на него и добиться выполнения своих обязательств. К сожалению, в реальном мире такому настрою отнюдь не помогает «внутренняя кухня» скрама – повестки дня, правила, точные результаты, бэклоги и цифры: то, что должно быть, напротив, средствами достижения цели. Вы как скрам-мастер не должны бояться вносить изменения в процесс в случае необходимости – а иногда и вообще отказываться от привычного подхода! Вы удивитесь, как изменятся ваши совещания, если вы сосредоточитесь на чувстве, которое стараетесь создать, а не на всех этих технических штучках. Изменяйте процессы, не бойтесь экспериментировать!

Я не раз слышала, что во многих командах не любят планирование спринта. Я считаю, что это неудача скрам-мастеров. Обязанность скрам-мастера состоит в том, чтобы сделать планирование спринта значимой и интересной частью работы команды. Если такое совещание вы хотите превратить в скучное мероприятие с таблицами на экране и пускающими во сне слюни разработчиками, то лучше не надо! Скрам-мастер должен создавать на совещании увлекательную атмосферу, чтобы каждому члену команды хотелось внести свой вклад в обсуждение. В ходе планирования спринта они должны обсудить дизайн и код очередного продукта, продумать вопросы его тестирования и создать свой собственный план. Не тратьте время профессионалов, заставляя их смотреть, как вы впечатываете те или иные задачи в план, развернутый перед ними на экране. Не следует и диктовать им их задачи или вручать оценки, составленные вами или руководителем группы. Эти люди вполне способны сделать это самостоятельно.

И, наконец, ни в коем случае нельзя принуждать команду брать на себя семь обязательств, если она знает, что сможет выполнить как следует только три. Планирование спринта должно представлять собой активное и вдумчивое обсуждение командой своего видения и планов на спринт, чтобы в итоге она взяла на себя такие обязательства, которые действительно сможет выполнить с подобающим качеством.

Допустим, врач назначил мне прием, потому что у меня проблемы с сердцем. После ряда обследований врач приглашает меня в кабинет, закрывает дверь и смотрит на меня с очень серьезным выражением лица. «Стейша, – говорит он, – вам нужна операция на открытом сердце. Это не самая простая операция, к тому же у вас есть некоторые проблемы со здоровьем. Вас подключат к аппарату "искусственное сердце" на 4–5 часов. Вы очнетесь с очень длинным послеоперационным рубцом на груди, а реабилитация займет от полутора до двух месяцев. И, между прочим, такая операция не из дешевых. Она будет стоить около $100 000». На моем лице застывает изумление. Мне трудно даже представить себе такую сложную и обширную операцию. Я смотрю на врача и говорю ему: «Доктор, я очень уважаю вас как профессионала. Но мне нужно быть на ногах уже через два дня после операции. Я не хочу, чтобы меня уродовал длинный шрам. И кстати, я могу потратить только $1000. Вы можете помочь мне на таких условиях?» Разумеется, врач посылает меня куда подальше и захлопывает за мной дверь. Он профессионал и хочет выполнить свою работу профессионально, поэтому никогда не согласится на мои условия. Почему же тогда наш разработчик-программист сдается и отступает от своих оценок? «Две недели? – восклицает его менеджер. – Какие еще две недели, вы должны выполнить это за два дня!» Программист смотрит на своего менеджера, кивает и говорит: «За два дня так за два дня». Как вы думаете, что получится в результате такого компромисса?

Формально часы начинают отсчитывать время проекта от планирования спринта, когда владелец продукта и команда собираются вместе и обсуждают, какие задачи следует решить в ходе предстоящего спринта. Во время этого совещания владелец продукта объясняет приоритетные требования из бэклога, а команда рассказывает владельцу, что она рассчитывает реально выполнить за спринт. Взгляните на выдержку из инструкции по проектному менеджменту от Microsoft Press:

Планирование спринта не может длиться дольше 8 часов. Таким образом, оно ограничено по времени, чтобы не болтать лишнего по поводу того, что можно и нельзя выполнить. Цель состоит в том, чтобы взяться за работу, а не порассуждать о работе.

Я обнаружила, что многие скрам-мастера неправильно понимают это указание: они считают, что нужно как-то заполнить все 8 часов различными мероприятиями. Нет! Ни в коем случае! Чем дольше команда планирует спринт, тем больше беспокойства возникает у нее по поводу самой работы. Поэтому подходите к планированию по принципу «необходимо и достаточно» – и беритесь за выполнение плана!

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

Подготовка планирования спринта

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

«Высокооктановые» задачи

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

Я обнаружила, что придуманное Биллом Уэйком сокращение INVEST, о котором говорилось выше, лучше всего отражает готовность команды к качественному планированию спринта. Напомню, что буквы этого слова обозначают свойства планирования: все, что планируется, должно быть независимым (Independent), обсуждаемым (Negotiable), важным (Valuable), поддающимся оценке (Estimable), небольшим по объему (Small) и тестируемым (Testable).

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

● Возможность обсуждения: позиция бэклога или задача (PBI) – это не подписанный контракт. Это просто идея: чего хочет владелец продукта и почему он этого хочет. Однако детали будут уточняться во время обсуждений между владельцем продукта и командой. Допустим, когда в ходе планирования спринта владелец и члены команды обсуждают параметры аккаунта, владелец может сказать, что команде необязательно в процессе спринта выполнять задачу «забытый пароль». Для этой функциональности он создаст отдельное требование в бэклоге и поместит его туда позднее.

● Важность: описание задачи бэклога должно помогать команде понять, почему она важна для пользователя.

● Возможность оценки: команда разработчиков должна иметь возможность оценить задачу. Это помогает владельцу продукта расставлять задачи по приоритетам и дает представление об ее объемах. Почему это важно? Обратимся к следующему пункту.

● Небольшие размеры: при планировании спринта объемы задач должны быть небольшими. Это позволит команде как следует понять задачу и увидеть ее границы. Если пользовательская история бэклога небольшая, то она может быть реализована и протестирована в процессе спринта. Включение функции «социальные сети» – это большая задача (возможно, даже эпик), тогда как функция «лайки Facebook на домашней странице» – задача небольшая.

● Поддающаяся тестированию: команда должна ясно представлять себе, как можно протестировать выполненную задачу. «На нашей странице должна отображаться кнопка Like размером 90 × 20 пикселей. Выбирайте – XFBML или Iframe. В первом случае пользователи смогут добавлять комментарии, а во втором – только ставить "лайки"».

Кроме того, есть и другая причина, почему INVEST такое удачное сокращение: оно напоминает нам, что владелец продукта может вносить свой вклад (читай: инвестировать) в виде идей в каждый спринт и ждет, что его вложения окупятся ко времени подведения итогов спринта. Поэтому для команды важно обсудить, как те или иные требования бэклога будут оценены при подведении итогов, чтобы стало ясно, насколько рентабельны «инвестиции».

Путаные задачи бэклога – это все равно что плохое топливо: у машины заглохнет двигатель, а в работе команды возникнут перебои и задержки. Хорошо проработанный бэклог – это высокооктановое топливо для вашей команды, поэтому необходимо постоянно работать с владельцем продукта, помогая ему совершенствовать бэклог и направлять команду. Кроме того, постоянно напоминайте вашей команде, что далеко не каждый владелец продукта способен идеально сформулировать требования бэклога или пользовательской истории (да, в общем-то, дело и не в этом). Гораздо важнее формулировать пользовательские истории так, чтобы команда могла их предметно обсудить и полностью понять, чего от нее хотят. Когда владелец продукта привлекает команду к составлению бэклога уже на ранней стадии (о чем говорилось в главе 2), то с самого начала все понимают проблему одинаково, что впоследствии помогает им в формулировании пользовательских историй и их реализации.

Помогайте владельцу продукта в планировании спринта

Свяжитесь с вашим владельцем продукта за несколько дней до планирования спринта, чтобы убедиться в том, что:

● он сможет присутствовать на планировании спринта;

● очень большие функциональности, которые иногда называют эпиками (epic), разделены на небольшие фрагменты, именуемые пользовательскими историями (user stories);

● бэклог продукта отражает последние приоритеты (не только между требованиями, но и по глубине разработки каждой отдельной функциональности);

● вы хорошо понимаете, как сможете наиболее эффективно помочь владельцу продукта до, во время и после совещания (есть ли у него материалы, которые стоит заранее распечатать и развесить в конференц-зале, хочет ли он, чтобы вы делали заметки по ходу совещания, и т. д.) и не стесняетесь спросить у него, какая помощь может ему потребоваться;

● владелец продукта попытался определить критерии приемки или условия удовлетворительного выполнения задач, планируемых на спринт.

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

Физическое пространство

Как и при планировании релиза, для планирования спринта обеспечьте достаточно свободное помещение и достаточное количество стикеров, досок, маркеров и… да-да, стен – по крайней мере на несколько первых совещаний (а потом можно и в парк). Нужно ли покупать материалы перед совещанием? Есть ли у вас цифровой фотоаппарат или смартфон с хорошей камерой, чтобы можно было просто «щелкнуть» подготовленный план, не переписывая его? Найдется ли у вас пять минут до совещания, чтобы вывесить календарь спринта или «напоминалку» по его важнейшим моментам? Даже такая простая вещь, как круглый стол (за которым члены команды будут видеть лица друг друга), может значительно увеличить объем и качество взаимодействия во время планирования спринта.

В отличие от обычных менеджеров, которые могут попытаться контролировать планирование спринта или даже явиться на совещание с заранее составленным планом спринта, скрам-мастер создает как можно более благоприятные условия и атмосферу, чтобы сама команда разрабатывала план и определяла свои обязательства по нему.

Я люблю перед совещанием вешать на стену календарь спринта, критерии готовности и стандартные принадлежности совещания (повестку, формулировку целей, описание проблем и идей на будущее). Все это должно быть готово до того, как на совещание прибудут члены команды. Если я не могу попасть в помещение заранее, то приношу плакаты (графики, таблицы), которые можно будет быстренько пришпилить к стенам за несколько минут до совещания.

Визуализируйте совещание

Начиная подготовку к совещанию за несколько дней, я просто сажусь, беру в руку ручку и стараюсь представить себе, как все будет выглядеть. Я воображаю, как собираются члены команды, переговариваясь и посмеиваясь, как я буду общаться с ними и как будут развиваться события.

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

● Что я должна сделать в первую очередь, придя на совещание? Организовать пространство, подготовить все необходимые материалы, запустить оборудование для встречи онлайн, расставить стулья, разложить стикеры, очистить доски для записей…

Мои действия:

■ Записать цель совещания, его повестку и идеи на будущее на больших отрывных листах и закрепить их на стенах до начала совещания.

■ Убедиться, что приглашение на онлайн-совещание содержит всю необходимую информацию. Протестировать связь.

■ Купить до завтра новые стикеры.

● Каким будет начало совещания? Члены команды входят в комнату совещаний, рассаживаются, переговариваются друг с другом и проверяют свои телефоны. Я в передней части зала, обмениваюсь репликами с участниками.

Мои действия:

■ Завтра принести с собой кофе и пончики.

● Что дальше? В начале совещания я прошу внимания собравшихся и обращаюсь с просьбой отложить смартфоны и закрыть ноутбуки. Я повторяю цель совещания и еще раз напоминаю его повестку. Я разъясняю участникам регламент и рассказываю про перерывы (туалет, обед и т. д.).

Мои действия:

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

● Что дальше? Владелец продукта зачитывает пользовательские истории из бэклога продукта, чтобы помочь команде понять, что нужно сделать в ходе данного спринта (и почему это ему нужно). Члены команды задают вопросы и обсуждают услышанное.

Мои действия:

■ Я предложу записать критерии приемки для каждой пользовательской истории, чтобы команда могла сосредоточиться на обсуждении.

■ Я еще раз взгляну на бэклог продукта, чтобы убедиться, что он готов для совещания.

■ Проведу экспресс-встречу с владельцем продукта, чтобы обсудить его роль в совещании и помочь ему подготовиться.

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

Мои действия:

■ Составить до совещания таблицу возможностей команды. Разослать ее участникам совещания заранее.

■ Предложить, чтобы команда разбилась на маленькие подгруппы по принципу «разделяй и властвуй» (работа с детальным планом).

■ Дать участникам таблицы и попросить их составить свою собственную доску задач (показать пример).

■ Использовать упражнение «на пальцах»⁸, чтобы проверить, есть ли в команде согласие, и определить уровень уверенности.

Отличный инструмент для продумывания хода совещаний и поиска новых способов его подготовки – ваше собственное воображение. Запишите у себя в блокноте то, что поможет вам подготовить сценарий совещания и его повестку.

Тетрадь для записей, сценарий и повестка дня

В тетради для записей вы собираете идеи и делаете первые грубые наброски (как вы видите будущее совещание). Идеи, которые накапливаются в тетради, в итоге рано или поздно «переедут» в повестку дня. Лично я люблю составлять так называемый сценарий – это, грубо говоря, расширенная повестка дня со всякими «напоминалками», заметками, рисунками, идеями… словом, со всем, что может пригодиться в ходе совещания. Сценарий – для вас, повестка дня – для всей команды. Благодаря сценарию скрам-мастер не забудет имена участников совещания, данные для онлайн-связи и т. п. (слава богу, со мной такого никогда не случалось). Ничто так не портит настрой участников и не мешает сосредоточиться на работе, чем ситуация, когда совещание прерывается из-за судорожных поисков какой-то информации, зарядных устройств, пульта управления проектором или из-за суеты: скажем, скрам-мастер забыл заранее позвонить удаленному участнику совещания и пригласить его на онлайн-встречу.

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

Ниже приведен пример, как я обычно готовлюсь к совещанию команды: это записи в моей тетради, которые помогают мне спланировать встречу в голове, а потом написать ее сценарий. Этот конкретный пример касается двухдневного совещания с несколькими командами: первый день был посвящен обзору спринта, анализу событий и подготовке бэклога на очередной спринт (в чем я не участвовала), а во второй день осуществлялось планирование релиза и спринта (в этих мероприятиях я принимала участие).

Главное, что нужно учитывать, – довольно беспорядочный характер записей в моем блокноте. Но ведь они предназначены лично для меня, так что все в порядке. Вы заметите, что я мысленно представляю себе и «сегодня», и «завтра». Под заголовком «Завтра» я представила всю подготовительную работу: вывесить главные пользовательские истории, обеспечить наличие стикеров… Обратите внимание, что в разделе «Сценарий» я подготовила для себя «напоминалки» (что было вынесено из предыдущих спринтов), а также информацию для обсуждения всей командой. Под пометкой «Обратная связь от команды» я поместила рукописные замечания, основанные на высказываниях членов команды в ходе предыдущего подведения итогов. В ходе обсуждения плана релиза я хотела использовать все возможности, чтобы напомнить членам команды об их задачах и обязательствах.

Вы также можете понять из моих рукописных замечаний, что поначалу я не хотела, чтобы команда присваивала очки своей будущей работе, но впоследствии передумала: команде необходимо чувствовать свою скорость. Тетрадь для записей именно для этого и предназначена: в нее вы записываете свои идеи, замечания или «напоминалки», чтобы в дальнейшем составлять план или повестку совещания.

После того как я мысленно представила себе совещание и сделала наброски по нему в тетради, я полностью переделала повестку дня и выписала ее на большой лист, чтобы вывесить в зале совещания. Однако свой рабочий сценарий я сохранила для себя, чтобы руководствоваться им во время встречи (см. рисунок выше).

Понимаю, со стороны кажется, что за всем этим стоит уйма работы. Не спорю. Но чем чаще вы проводите совещания и практикуетесь (испытываете в деле то, чему научились, и приспосабливаетесь к реалиям), тем легче вам становится. На то, что раньше занимало четыре часа, вы тратите всего 15 минут. Если готовить совещания тщательно, продумывая детали, члены команды обязательно заметят, что вы цените их время, энергию и приверженность делу. Вы облегчаете участникам задачу (обсуждение успешного спринта), а они ценят вашу подготовленность. Совещания, во время которых участники не топчутся на одном месте, а динамично переходят от одной темы к другой (с новыми повестками и ощущением продуктивности), – возможность для подлинного и энергичного сотрудничества. Старайтесь подготавливать такие совещания, которыми ваша команда не будет пренебрегать.