В 1996 году я был консультантом по разработке программного обеспечения. Twitter еще не существовал. Чтобы не отставать от технического прогресса, я читал, пусть иногда месяцы спустя, материалы конференций того времени. Agility, гибкость, тогда не была в тренде, зато было ООП (объектно-ориентированное программирование). Одной из многочисленных конференций по теме была «OOPSLA» («Object-Oriented Programming, Systems, Languages & Applications»). Именно во время просмотра материалов 1995 года я впервые наткнулся на Scrum. Подписанная Кеном Швабером, статья представляла Scrum как эмпирический процесс разработки сложных продуктов.

Пока я читал, в голову пришла мысль: этот пришелец явно не с привычной мне планеты. Хотя в статье было много ссылок на объектно-ориентированное программирование (вероятно, просто чтобы ее включили в конференцию OOPSLA), она противоречила настроениям того времени.

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

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

Давайте коротко рассмотрим, что это вообще такое – Scrum.

В статье 1995 года Швабер взбудоражил читателей, рассказав о процессе и методологии. После этого Scrum чаще всего определялся как Agile-методология.

Затем Кен Швабер и Джефф Сазерленд, его со-основатель, установили, что Scrum – это процессный фреймворк (process framework).

Процесс определяет способ работы, а фреймворк только определяет границы, фреймы. Это рамка, при помощи которой Scrum вводит несколько правил и принципов.

Классифицировать Scrum нелегко – проще объяснить механизм его реализации.

Прежде чем перейти к ответу на вопрос как? – факт, на который стоит обратить внимание:

Слово команда имеет фундаментальное значение!

Можно объяснить Scrum несколькими словами. Помнится, были челленджи, в которых надо было представить Scrum меньше, чем за пять минут. Удалось это далеко не всем. Большинство пытались прояснить, как, собственно, применять Scrum.

На данный момент моя версия ответа на этот вопрос звучит так:

✓ Люди работают в команде, следуя принципам Scrum.

✓ Ритм устанавливается при помощи серии итераций.

✓ Все, что необходимо сделать, включено в список задач.

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

✓ Первое событие в начале спринта – согласование цели и подготовка к работе.

✓ Второе событие – это ежедневная синхронизация команды для достижения общей цели.

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

Scrum не аббревиатура. Это слово взято из игры в регби: в английском языке scrum означает схватка. Чтобы отличать одно от другого, к нашему Scrum добавили заглавную букву.

Рисунок 1.1 – Схватка

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

✓ был пас вперед;

✓ мяч был выбит в аут.

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

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

• Почему именно регби?

Оба основателя Scrum – американцы. В США особо не играют в регби со схватками. Почему же именно этот вид спорта?

Отсылка к регби появилась в статье 1986 года, написанной японцами. Они любят эту игру вместе с ее схватками. Там было описано, как компании Honda, Canon, NEC и Fuji-Xerox демонстрируют совместный подход к разработке своих продуктов, и подчеркивалась важность автономных и самоуправляемых команд. Авторы сравнили такой формат работы с игрой в регби:

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

Джефф Сазерленд опирался на эту статью, когда придумывал Scrum.

В мире организаций, где центральное место все еще занимает процессный подход и индивидуализация целей, Scrum сильно выделяется.

Рисунок 1.2–6 свойств Scrum

1. Появление нового

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

2. Приоритизация

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

3. Предприимчивость

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

4. Прозрачность

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

Рисунок 1.3 – Визуальный менеджмент

5. Практика

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

6. Постоянный ритм

Scrum использует фиксированные отрезки времени для создания ритма. Основа ритма Scrum – это спринт. Спринт завершается по расписанию, а не с окончанием работы. Отодвинуть завершение спринта по времени невозможно.

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

В 2010 Джефф Сазерленд и Кен Швабер опубликовали небольшой документ – «Руководство по Scrum» («The Scrum Guide»).

Очевидно, что на 19 страницах текста авторы дают читателю лишь правила игры, рассказывая о Scrum в общих чертах. Но этого достаточно, чтобы получить представление о том, что это такое.

Это руководство – надежный источник информации о Scrum.

В начале 2017 года компания 3Back опубликовала статью объемом около двадцати страниц, в которой предлагалось развить концепцию Scrum. Авторы – Дэн Роастхорн и Дуг Шимп – ранее уже написали весьма содержательную книгу «Исследуя Scrum»[5]. Их новая статья называлась «Обзор Scrum 3.0» (Scrum 3.0 overview [6])

В предыдущем издании этой книги я рассматривал некоторые паттерны, предложенные Роастхорном и Шимпом.

Термин Аgile, тесно связанный со Scrum, появился в сфере разработки ПО в документе под названием «Agile-манифест».

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

Эта позиция отражается в формулировке не отрицая важности того, что справа, мы больше ценим то, что слева. Основополагающие ценности манифеста следующие:

✓ Люди и взаимодействие важнее процессов и инструментов.

✓ Работающий продукт важнее исчерпывающей документации.

✓ Сотрудничество с заказчиком важнее согласования условий контракта.

✓ Готовность к изменениям важнее следования первоначальному плану.

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

Помимо четырех основных ценностей, Манифест содержит двенадцать принципов. Ниже я цитирую первый, ключевой:

Scrum стоит под знаменем Agile-манифеста. Два его основателя также входят в число 17 подписавших документ.

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

Scrum предлагает несколько четко определенных практик, с которыми мы познакомимся дальше. Но в семье Agile существует и много других практик, которые можно использовать со Scrum.

Практики, описываемые как гибкие, или Agile-практики, существовали и до Манифеста, а некоторые – задолго до него.

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

Некоторые практики появились вместе с Agile-движением и со временем стали незаменимыми, многократно подтверждая свою эффективность. Среди них можно отметить ежедневные совещания (схватки, или собственно Scrum).

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

Scrum и Экстремальное Программирование (XP) существовали и до Манифеста. После его подписания и публикации они стали считаться Agile-методами, в то время как другие попали в список отсталых и утратили популярность. С недавнего времени к семье Agile присоединился Kanban [7].

Рисунок 1.4 – Быть гибким с Agile-методикой

По статистике проводимых год за годом опросов, Scrum – самый популярный из трех. Scrum и Agile – слова, которые мы часто произносим в речи и складываем друг с другом, будь то предложение о работе или статья об Agile Scrum. Но мы убедились, что Scrum на самом деле не метод [8].

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

Однако Scrum потерял смысл в этом Agile-режиме разработки программного обеспечения [9].

• За пределами информационных технологий

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

Scrum берет начало в разработке ПО, но сейчас широко используется и за пределами ИТ:

✓ в маркетинге и торговле;

✓ в сфере цифровых технологий;

✓ при разработке оборудования (hardware) и систем, включающих программное обеспечение.

Марк Андриссен, основатель Netscape, произнес известную фразу: софт пожирает мир.

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

Scrum не относится ни к какой конкретной области и может быть использован для разработки продуктов или услуг совершенно любого характера.

• Аgile-менеджмент

Управление меняется. Новые подходы[10] идут в ногу с Agile-принципами.

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

• Определение Agility

Джим Хайсмит, один из подписантов Манифеста, так определяет Agility по отношению к изменениям:

Agility – это способность отвечать на изменения для того, чтобы процветать в непрерывно меняющейся экономической обстановке.

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

Agility – это способность организации приносить максимум ценности, часто и своевременно, и адаптироваться к изменениям в своей среде.

Из этого определения ясно, что гибкость относится не только к команде, но и к организации.

• Agile организация

Принципы освобожденных компаний (liberated companies) также имеют много общего с Agile-движением с точки зрения ценностей и важности человеческого фактора.

Работа Фредерика Лалу[11], посвященная успешным новым организациям, выдвигает на первый план принципы бирюзовых организаций (teal organisations), идущих в ногу с Agile.

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

Рисунок 1.5 – Agility – трамплин, чтобы выбраться с галеры на свободу

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

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

Если организации, практикующие Scrum, не согласны с духом Agility, который несут Scrum-команды, несоответствие довольно скоро вызовет перебои. Необходим комплексный подход.

Agility рассматривается в масштабе всей организации, в то время как Scrum зачастую пытаются поместить в рамки одной команды.

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

Это становится ясно на практике. Многие задачи невозможно решить внутри команды. Нужно обращаться к экосистеме, внутри которой развивается команда, в частности, к отношениям с заинтересованными сторонами.

В этом издании мы разработаем системный подход к Scrum.

Существует множество направлений системологии: холизм, кибернетика, теория систем и т. д.

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

Соотнесение Scrum и понятий пермакультуры поможет нам построить экосистему, которая будет долгое время приносить пользу многим людям.

Какова ситуация в отношении Scrum сегодня?

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

В опросах три четверти респондентов утверждают, что используют Scrum или его варианты.

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

Основная трудность для участников Scrum-сообщества состоит в том, чтобы убедить его пользователей не быть чрезмерно консервативными.

Вполне логично, что при нынешней популярности Scrum написано много статей, критикующих его и предлагающих другие подходы.

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

Другие понимают Scrum лишь частично:

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

✓ Менеджеры, которые уверены, что Agilе-команда – на то и Agile, что может выполнять больше работы за меньшее время.

Реальность может их разочаровать. Мы постараемся дать ответ на эту критику и разочарования.

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

✓ Если вы разрабатываете приложения из категории несложных по модели Cynefin вероятно, Scrum для вас – не лучший выбор.

✓ Если ваша организация придерживается культуры контроля и вы не можете продвигать необходимымые радикальные изменения, то Scrum не для вас.

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

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

Мы за изменения, но против постоянных прерываний процесса!

Концепция Shu Ha Ri была создана Алистером Кокберном (подписал Манифест и предложил использовать слово agile). Это модель развития, взятая из айкидо. Shu соответствует фазе обучения, когда ученик повторяет за учителем, не пытаясь что-либо изменить.

✓ Ha – вторая фаза обучения. Ученик берет на себя инициативу и ответственность за то, что делает.

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

Тех, у кого проблемы со Scrum, можно, спросить: начали они с фазы Shu прежде, чем перейти к Ha? Сохранился при этом формат Scrum? Соблюдали они все принципы?

В противном случае существует риск исказить концепцию Scrum.

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

Например, во время разработки ПО дополнительно пригодятся инженерные практики из Экстремального Программирования.

Мы поговорим об этом в главе «Контекстуализация Scrum».

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

Некоторые практики, когда-то связанные со Scrum, уже устарели: Scrum постоянно развивается.

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

Добившись успеха на уровне работы в командах, Scrum все больше начинает выходить на уровень организаций и крупных проектов.

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

Мы рассмотрим их в основном во второй части этой книги с точки зрения системологии.

Знакомство с новой культурой начинается с новых слов. И Scrum имеет свой язык.

Чтобы помочь разобраться в значении тех или иных терминов, я добавил глоссарий в конце книги. Много неологизмов пришли из английского языка. При распространении Scrum во Франции некоторые утвердились в английском варианте, другие же были переведены.

Словарь значительно расширился за десять лет и продолжает развиваться.

• Не переведенные термины

Такие слова, как, например, спринт, уже давно нашли место во французском словаре. И в английском, и во французском они означают одно и то же.

В этой книге я не переводил ряд английских терминов, связанных со Scrum/Agile. Это не значит, что не было попыток их перевода. По большей части перевод терминов был предложен, но не принят пользователями.

В этом списке следующие слова: бэклог, Scrum-мастер, эпик. Я объясняю, почему эти термины не переведены, в соответствующих главах [12].

• Переведенные термины

Другие термины Scrum используются в переводе. Некоторым такое использование важно, но, к сожалению, как мне кажется, это никак не закреплено правилами. В повседневной речи, а иногда даже в письменном виде можно встретить: definition of done, sprint planning meeting, sprint review, impediment. Я трепетно защищаю использование французского языка, поэтому, соответственно: критерии завершенности, встреча по планированию спринта, обзор спринта, препятствие.

Иногда появляются смешанные термины, например, приемочный тестинг, а не приемочное тестирование.

Словарь развивается с помощью терминов, которые приобретают все большее значение. Я имею в виду, в частности, такие слова как stakeholder или backlog refinement, для которых рекомендую использовать заинтересованные стороны и доработка бэклога. В этой редакции книги больше не говорю feature – теперь это функциональность.

Поскольку французский является живым языком, можно полагать, что некоторые слова из сферы Scrum, как, например, бэклог, войдут в состав языка. Люди задумаются, какого это слово рода, почему не женского? Среди таких неологизмов есть слово аджайлист для адепта Agile-методов.

Мы не используем ни скраммер, ни скрамист, когда говорим о приверженцах Scrum. Однако таких много.

Чтобы идти дальше

Книги [13]

‣ Steven Denning, Radical Management, Jossey & Bass, 2010

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

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

Рисунок 2.1 – В традиционном цикле стадии различаются

Течение цикла зависит от используемой модели (или процесса). Во Франции по-прежнему распространена V-модель, но компании, особенно крупные, обычно берут ее за основу для дальнейшей адаптации к их контексту и создания уже своей собственной модели.

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

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

Этому есть причины:

✓ Модель разработана методологами-теоретиками и оказывается слишком удалена от реальности и неприменима на практике.

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

✓ Команда пропускает контрольные точки – и накапливает работу, не выполненную на предыдущих этапах. Это создает неудобства в дальнейшем.

Все это давно известно.

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

В то же время возникла противоположная идея индустриализации процессов, и пришлось подождать, пока она провалится на практике.

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

Рисунок 2.2 – Повторение спринта

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

Еще одно фундаментальное отличие заключается в том, что Scrum – это не более чем фреймворк. Он не определяет наполнение каждого спринта: за это отвечает команда.

Scrum основывается на итеративном и инкрементальном подходе к разработке продукта. Давайте разберемся, что это значит.

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

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

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

Рисунок 2.3 – Густав Эйфель, инженер, практиковавший инкрементальный подход

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

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

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

Scrum объединяет оба подхода с концепцией спринта:

✓ в конце спринта появляется инкремент продукта;

✓ обратная связь на этот инкремент позволяет скорректировать цель следующего спринта.

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

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

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

Lean Startup популяризировал эту концепцию тестирования гипотез и коротких спринтов для получения информации о новом продукте. Мы все постоянно слышим термин MVP (Минимальный жизнеспособный продукт, Minimum Viable Product), который, на мой взгляд, плохо отражает его суть. Ведь речь идет не о продукте, пусть даже с минимальным количеством функций, но о результате, который позволяет проверить предположения, и, следовательно, узнать новую информацию.

Если гипотеза не подтверждается, команда переключается на другую функцию продукта.

Достижение MVP соответствует окончанию стадии иследования и началу стадии эксплуатации.

С точки зрения жизненного цикла продукта, Lean Startup используется на стадии исследования, а Scrum – на стадии эксплуатации.

Рисунок 2.4 – Две стадии разработки продукта

Концепция Lean Startup предполагает малозатратный по ресурсам этап проверки гипотезы несколькими конечными пользователями.

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

Помимо итеративного и инкрементального процесса, какие еще можно выделить характеристики Scrum-спринта?

✓ Короткие итерации: продолжительность спринта варьируется от недели до месяца.

✓ Строгая последовательность: спринты не перемешиваются между собой.

✓ Четкий ритм: спринты имеют одинаковую продолжительность.

Рисунок 2.5 – Разница между инкрементальным и Agilе-подходом

Продолжительность спринтов всегда одинакова, что помогает команде держать ритм.

Спринт соответствует определенному временному отрезку. После начала спринта команда не может менять дату его окончания, даже если она уже достигла поставленной цели!

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

Рисунок 2.6 – Отрезок времени

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

Рисунок 2.7 – Стая слепней помогает отрабатывать спринтерский бег на коротких дистанциях

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

По части продолжительности. Здесь нет единого мнения, все зависит от контекста. Но она должна быть четко зафиксирована.

Чтобы определить продолжительность спринта, существует несколько критериев, на которые нужно обратить внимание:

✓ Производительность и результативность команды.

✓ Готовность заинтересованных сторон давать обратную связь.

✓ Простота в подготовке событий спринта – спринт предполагает дополнительную работу по организации событий.

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

Определение продолжительности спринта является одной из задач начинающей команды (см. главу 13).

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

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

Рисунок 2.8 – Спринты и процессы в параллели

Внутри спринта процесс не последовательный (С, затем A, затем К, затем T). Преобладающая идея – идея непрерывного потока, прерванного только в конце спринта.

Другой вариант – это так называемый последовательный цикл, разворачивающий последовательные процессы, по одному процессу на стадию.

Рисунок 2.9 – Последовательные процессы

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

Следовать этому подходу буквально означает:

✓ 100 % готовность спецификации до перехода к проектированию.

✓ 100 % готовность проекта до перехода к написанию кода.

✓ 100 % готовность кода до перехода к тестированию.

Это утопичная модель. В реальности команда всегда возвращается к предыдущим стадиям: на стадии тестирования команда возвращается к написанию спецификации – и так далее.

Agile-подход более прагматичен: работа над спецификацией и проектированием непрерывна. Архитектура развивается с новыми функциями.

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

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

Опытная Agile-команда в каждом спринте проводит 100 % тестов до того, как будет написано 100 % кода, и достигает 100 % готовности кода до того, как на 100 % написана спецификация.

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

✓ Ввод в эксплуатацию – это создание ценности путем предоставления пользователям версии продукта [14].

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

✓ В конце каждого спринта команда получает результат спринта.

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

Что насчет спринта? Включает ли последовательность процессов поставку конечным пользователям? Другими словами, всегда ли конец спринта соответствует вводу в эксплуатацию? Или для этого нужно ждать несколько спринтов?

Цель состоит в быстром предоставлении ценности. Решение о вводе в эксплуатацию основано на данной цели и не всегда совпадает с окончанием спринта. Это может быть во время спринта для одной команды или после нескольких спринтов для другой команды.

Течение и результат спринта, как правило, облегчают принятие решения. Например, в конце данного спринта принимается бизнес-решение о вводе в эксплуатацию в рамках следующего спринта.

Таким образом, ввод в эксплуатацию не связан со спринтом.

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

✓ Снижение рисков – результат спринта можно использовать внутри команды разработчиков, возможно, технических экспертов. Это позволит минимизировать риски, связанные с технической частью и способностью команды интегрировать различные компоненты. Это также даст возможность узнать о качестве изнутри. Такой вариант особенно распространен во время первых спринтов.

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

Развертывание в конце спринта, вне зависимости от ввода в эксплуатацию, дает возможность получить больше информации о результате работы команды.

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

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

Я рекомендую фиксировать сезон по продолжительности, как и спринт. Другими словами, все сезоны одинаковы по времени. Мы вернемся к этому в главе 16.

Как и в спринте, команда сама определяет продолжительность сезона.

Рисунок 2.10 – Релиз заменен сезоном. Наблюдается сопротивление переменам.

Оказывается, в этом может помочь деление времени на триместры. Посчитаем: триместр длится около 13 недель.

✓ Команда проводит двухнедельные спринты, выходит 6 спринтов за сезон, плюс остается неделя, о которой мы скоро поговорим.

✓ Команда проводит трехнедельные спринты, у нее выходит 4 спринта за сезон.

Цикл спринтов может продолжаться в течение длительного времени, например, нескольких сезонов. Есть также предпремьерный сезон, конец сезона и пост-финальный сезон.

Рисунок 2.11 – Спринты и сезоны

Период до начала спринтов составляет прелюдию.

Прелюдии посвящена целая глава (см. главу 13), мы к ней вернемся, когда познакомимся со всеми элементами Scrum.

Так как сезонов будет несколько, интерлюдия тоже будет не одна.

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

Зачем? Чтобы провести на другой скорости цикл инспекции/адаптации, который бы охватывал более устойчивые темы, чем те, что были в фокусе спринта.

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

Вот несколько вариантов того, чем можно заняться во время интерлюдии:

✓ празднование успеха команды,

✓ ретроспектива, посвященная окончившемуся сезону (см. главы 12 и 22),

✓ небольшое увеличение команды (см. главу 3),

✓ чистка бэклога (см. главу 8),

✓ прогнозы на следующий сезон (см. главу 16),

✓ открытый форум по вопросам Agility (см. главу 22),

✓ любая другая деятельность, не связанная с продуктом, – чтобы расслабиться или просто отвлечься.

Существует ли последний сезон?

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

✓ Трансфер c целью техобслуживания. Обычно ввод в эксплуатацию выполняется после разработки и другой командой. В некоторых организациях разработкой и обслуживанием занимаются разные люди. В Agile-подходе такого разделения нет. Те, кто занимается разработкой продукта, знают лучше остальных, как оказывать поддержку, исправлять ошибки и дальше его развивать. Следует помнить: в отличие от концепции проекта, цикл спринтов не заканчивается на первой версии. Он продолжается на протяжении всей жизни продукта, который развивается по мере релизов. Можно также сказать, что обслуживание начинается после первого ввода в эксплуатацию. Тем не менее, в жизни продукта может наступить момент, когда поток входных данных уменьшается и больше не оправдывает команду такого размера. В таком случае команда может сама решить, как ей дальше работать. Это отличный момент для начала использования Kanban (см. главу 20).

✓ Трансфер с целью релиза. Это тот случай, когда вводом в эксплуатацию занимается не Scrum-команда [15].

✓ DevOps – это подход, позволяющий непрерывное развертывание, в рамках которого члены Scrum-команды берут на себя определенные обязанности. Они обычно лежат на специалистах из стадии эксплуатации/технического обслуживания.

Таким образом, постлюдия – это не момент завершения работы над продуктом, а момент, когда команда распадается.

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

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

Давайте не забывать принцип Agile-манифеста об устойчивом ритме.

Что делать? Не думать о Scrum-спринте как о гонке, в которой команда всячески пытается найти секунду, чтобы отдышаться. Спринтуют здесь на самом деле не люди, а элементы бэклога.

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

Рисунок 2.12 – Одышка после тяжелого спринта

Ситуация: по V-модели тестирование – это стадия, выполненная независимыми тестировщиками. При переходе к Scrum эта схема сохраняется, причем, тестировщики смещены на один спринт от разработчиков.

Последствия: поднимается цена исправления ошибки.

Как сделать лучше? В итеративном Scrum-подходе тестирование не происходит после разработки, а внедрено в каждый спринт. Оно не откладывается на конец спринта, команда начинает проводить тесты с первых дней.

Тестирование проводится, скорее, с целью продвижения к цели, чем с целью контроля.

Такой способ позволяет уменьшить время между появлением ошибки в ПО и ее исправлением.

Ситуация. Команда переходит из одного спринта в другой на протяжении нескольких месяцев, а то и нескольких лет.

Последствия. Отсутствие фокуса на среднесрочной цели, усталость, рутина.

Как сделать лучше? Задать и поддерживать сезонный ритм.

Ситуация. Scrum ограничивается разработкой, для всего остального сохраняется традицонная V-модель.

Последствия. Оптимизация является локальной и не отражается в цепочке создания ценности. Scrum теряет смысл.

Как сделать лучше? Расширить место Scrum в системном подходе, описанном в этой книге. Заменить традиционные этапы стадиями исследования и эксплуатации.

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

Важность людей – человеческий фактор – является основным отличием Scrum и Agility. Ни программная инженерия, ни V-цикл, ни UML не придают человеческому фактору столь большую важность. Даже управление проектами и менеджмент недавно осознали ключевую роль людей в проектной работе, да и то чтобы быть в тренде. При этом поразительно, что на конференциях, посвященных Agility, участников больше всего интересуют темы, связанные с людьми. Популярны сессии по социологии отношений. Это соответствует первой ценности Agile-манифеста:

Сердце Scrum – это люди, которые составляют команду и находятся в постоянном взаимодействии. Но чтобы внедрить Scrum-подход, одной команды недостаточно.

Помимо команды есть те, кто интересуется достигнутыми результатами.

Чтобы привести команду к идеалу, необходимо учитывать и тех, кто состоит в команде, и тех, кто находится вне ее.

Все они – часть одной экосистемы.

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

Рисунок 3.1 – Экосистема

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

Экосистема также касается рабочего пространства, в котором работают команда и заинтересованные стороны.

Для компаний, которые выстроили многоуровневую иерархию и поддерживают культуру контроля, изменения, вызванные Scrum, кардинальны: доверие и самоорганизация стоят выше авторитета начальника.

Менеджмент не ликвидирован: он стал делом каждого. Эта парадигма не уникальна в Scrum, она является частью гораздо более широкого движения, ставящего под сомнение тейлоризм [16] и его принципы.

Scrum поддерживает образ живой системы, а не машины, состоящей из взаимозаменяемых шестеренок.

Такой образ строится на самоорганизации и общих ценностях.

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

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

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

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

Рисунок 3.2 – РУПОР Scrum

Следует отметить, что эти ценности появились только в версии Руководства по Scrum от 2016 года, и это изменение – единственное между версиями 2013 и 2016 годов (пр. пер: в оригинале получается аббревиатура FORCE, то есть сила).

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

Рассудительность и концентрация позволяют команде держать фокус на одной точке. Во время спринта команда сосредотачивается на цели, которую поставили на этапе планирования.

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

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

Рисунок 3.3 – Роли в Scrum-команде

Scrum-команда включает всего три роли:

✓ Две специфичные Scrum-роли, о которых пойдет речь в следующих главах: Владелец продукта (Product Owner, PO) и Scrum-мастер (Scrum-master, SM).

✓ Участник команды разработки (Development, DEV); разработка рассматривается здесь в широком смысле. Эта роль охватывает всех участников команды.

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

Рисунок 3.4 – Свойства Scrum-команды

• Подходящий размер

Чтобы принцип Scrum соблюдался, команда должна быть определенного размера.

Уровень удовлетворенности от принадлежности к команде варьируется в зависимости от размера команды. Исследования показывают, что оптимальное количество участников – семеро [стр. 13].

• Самоорганизация и коллективный разум

Так как это команда, нацеленная на результат, она наделена правом и властью работать так, как, на ее взгляд, будет наиболее эффективно.

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

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

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

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

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

Это же можно отнести к Scrum-команде, заменив разве что игру на разработку и открытая на agile.

• Кроссфункциональность

В идеале, Scrum-команда объединяет все компетенции, необходимые для завершения работы в спринте.

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

Поэтому, в зависимости от области разработки, Scrum-команда будет включать в себя людей с различными дополнительными навыками.

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

Даже кроссфункциональной команде будет необходимо время от времени привлекать заинтересованных лиц с компетенциями, которые в ней не представлены, чтобы добиться нужных результатов.

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

Развитие отношений и эффективное взаимодействие достигаются не только разнообразием компетенций, но и культур.

• Самобытность

Хорошая Scrum-команда обладает некой самобытностью, индивидуальностью, и каждый участник это ощущает. Добиться этого можно во время прелюдии (см. главу 13).

Индивидуальность команды подкрепляется физическим пространством, в котором участники находятся. Выделенный специально для команды офис со стенами или перегородками позволяет выражать и укреплять коллективную самобытность. Гораздо лучше, если все участники команды находятся в одном рабочем пространстве. Это то, что можно развить при помощи паттерна границ. Можно немного отклониться от этого принципа, когда один или два человека работают дистанционно [19], но не более того – особенно если язык и культура не являются общими для всей команды. Команда, разбросанная по всему земному шару, не станет настоящей Scrum-командой, потому что ее участники не смогут встретиться и узнать друг друга лучше во время прелюдии.

Самобытность группы строится на ее успехах. Мероприятия в конце спринта – это отличная возможность представить результаты заинтересованным сторонам, а затем отметить их вместе.

• Стабильность

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

Модель Такмана представляет стадии процесса создания команды:

✓ все начинается с формирования команды,

✓ затем – стадия конфронтации и борьбы за власть,

✓ на стадии нормирования взаимодействие участников налаживается,

✓ команда приступает к выполнению задач.

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

Стабильность позволяет лучше узнать друг друга, самоорганизация – постоянно развиваться. Все это делает команду результативной.

Рисунок 3.5 – Стабильность, а не застой!

• Приглашение

Для создания команды необходимо, чтобы несколько людей прошли совместно стадию прелюдии и начали первый спринт. Этого обычно достаточно.

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

Большинство людей рады присоединиться к Scrum-команде, если их личная этика согласуется с этикой команды и целью экосистемы.

• Ответственность

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

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

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

• Общие компетенции

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

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

✓ исчезают риски, связанные со знаниями и навыками, которыми обладает лишь один участник,

✓ каждый развивает новые компетенции.

• Взаимодействие и взаимопомощь

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

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

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

Как правило, Scrum способствует взаимной поддержке среди людей, позволяя им постоянно совершенствоваться.

• Естественное лидерство

В Scrum-команде нет начальника, как нет и технического лидера [20].

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

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

Это пользователи, клиенты, спонсоры, представители пользователей, маркетологи, менеджеры, люди, вовлеченные в инфраструктуру, качество и т. д.

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

Рисунок 3.6 – Заинтересованные стороны и команда

Все включаются в Scrum-процесс, но для разных ролей практики применимы по-разному.

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

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

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

Чтобы правильно выполнять свои обязанности, рекомендуется, чтобы они знали структуру Scrum и ее философию (см. главу 13).

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

Существует три типа обмена в зависимости от основных функций в Scrum-команде.

✓ Тот, что относится к выполнению работы. Мы детализируем этот тип чуть позднее, когда будем говорить об экспертных знаниях.

✓ Тот, что касается фасилитации командной работы. Взаимодействие внутри команды регулирует Scrum-мастер, а вне команды ему могут помогать Agile-коуч или агент изменений. Подробнее о роли Scrum-мастера можно узнать в посвященной ему главе.

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

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

Понятие границ применимо к человеческим экосистемам.

Это относится и к Scrum-команде, и обмену между ее участниками, SM и PO, о чем мы с вами говорим в этой книге.

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

• Внутренние границы

Это область обмена внутри экосистемы, между Scrum-командой и заинтересованными сторонами.

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

Обмен происходит во время бесед между участниками команды и заинтересованными сторонами (Scrum-события – обзор и ретроспектива).

• Внешние границы

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

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

Эффект границы, способствующий взаимному обогащению, возникает, когда разработчики из разных команд встречаются, например, в контексте обмена практиками.

Паттерн рабочих зон стимулирует обмен через эти границы.

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

В Scrum концепция зон влияет на логистику, расположение и обстановку внутри рабочего пространства, а также на каналы связи.

Рисунок 3.7 – Рабочие зоны

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

✓ Зона 1 – это пространство, в котором работают участники команды (DEV).

✓ Зона 2 соответствует территории Scrum-команды, где проводятся встречи и события. PO и SM развиваются в Зоне 1 в качестве участников команды, а в Зоне 2 – в своих специальных ролях.

✓ Зона 3 – это внутренная граница, где происходит обмен между командой и заинтересованными сторонами.

✓ Зона 4 – это местонахождение заинтересованных сторон. Участники команды время от времени должны заходить на эту территорию, чтобы совершать обмен знаниями, идеями и т. д.

✓ Зона 5 – это внешняя граница или места, куда иногда забредает кто-то из команды, чтобы почерпнуть идей.

Этот паттерн делает рабочее пространство, организованное для зон с 1 по 3, инструментом для комфортной социализации.

• Зона 1

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

Есть места для уединения, чтобы подумать или помедитировать.

• Зона 2

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

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

• Зона 3

Для встреч небольшим составом с заинтересованными сторонами. Маленькая комната и несколько кресел. Рекомендуется открытое помещение, обеспечивающее доступ заинтересованных сторон к достижениям команды. Такое пространство делает обмен между командой и заинтересованными сторонами конструктивным.

Рабочее пространство должно располагать к появлению новых идей через укрепление отношений.

Взаимодействие внутри команды имеет первостепенное значение.

Рассмотрим теперь отношения участников команды с другими людьми в экосистеме:

✓ в Зоне 3 с заинтересованными сторонами, находящимися в контакте с командой,

✓ в Зоне 4 с другими заинтересованными сторонами,

✓ в Зоне 5 с остальными людьми.

Рисунок 3.8 – Обмен участника команды с другими людьми

Люди, находящиеся вне команды, – не только ограничение, создающее зависимости, но и важный источник знаний.

Паттерн эксперта внутри границ. Определяем, кто заинтересованная сторона, какие у нее полномочия. Заинтересованная сторона будет помогать команде.

• Кто такой эксперт?

Это заинтересованная сторона, помогающая команде достичь результата.

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

По просьбе команды эксперт может подключиться к спринту.

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

• Ответственность

Эксперт, как заинтересованная сторона, присутствует на обзоре спринта. Участвует в других событиях спринта и активно взаимодействует с командой.

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

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

• Ограничение зависимости

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

✓ Создание команды, которая бы зависела от малого числа экспертов.

✓ Приглашение эксперта, в котором команда нуждается на регулярной основе.

✓ Предвосхитить этот момент и не начинать работу, не убедившись, что требуемый эксперт доступен.

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

Рисунок 3.9 – Даже очень хорошей команде иногда нужен эксперт

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

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

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

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

Последствия. Нет сотрудничества. Не развит коллективный разум. Только один человек разбирается в технической части вопроса. Когда он недоступен, вся команда застревает.

Как сделать лучше? Организовать парную работу, чтобы избежать гиперспециализаций.

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

Последствия: заинтересованные стороны могут входить в несколько экосистем. Но участник принадлежит только к одной Scrum-команде! Иначе он быстро «сгорит».

Как сделать лучше? Сократить количество мульти-проектов. В краткосрочной перспективе сосредоточиться на одной команде и приоритизировать задачи в бэклоге.

Ситуация. Во время спринта команде потребовалась экспертиза. Но участники не проверили, доступен ли эксперт.

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

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

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

Последствия. Разработчики под гнетом контроля, нет атмосферы доверия.

Как сделать лучше? Сблизить людей при помощи паттерна рабочих зон. Познакомить все заинтересованные стороны со Scrum. Объяснить их роль. Приглашать их на каждый обзор спринта. Праздновать успехи вместе.

Чтобы идти дальше

Книги

‣ Tobias Mayer, The People’s Scrum, 2013. Вдохновляющая книга о людях в Scrum, которая включает эссе, опубликованные Тобиасом Майером на странице его блога.

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

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

Но во главе компании стояли технологи. В конечном счете, именно технический директор решил, какие функции добавлять в продукт.

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

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

Именно об этой роли и моем опыте будет эта глава.

Но начнем с терминологии.

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

Рисунок 4.1 – Собственник продукта

В 2005 году я участвовал в тренинге по Scrum. Его вел уроженец Квебека Франсуа [21]. Материал курса был на французском языке. Product Owner, о котором речи тогда было мало, переводился как администратор продукта. Это название так и не прижилось во Франции. Я думаю, наши канадские братья также от него отказались.

В 2006 году, прочитав одну статью, я стал употреблять термин менеджер по продукту. В течение нескольких месяцев упоминал это словосочетание в постах в моем блоге.

Статья о Scrum во французской версии Википедии тоже использовала этот термин, подтверждая успех этого перевода. В переводе книги «Scrum и XP: заметки с передовой» на французский язык также можно встретить менеджера по продукту.

Но я перестал использовать этот термин и вернулся к Product Owner (пробовал даже переиначить на французский лад – productoneur). Слово менеджер не проходило для организаций: тот, кто занимал эту роль, не являлся менеджером по организационной иерархии.

Владелец продукта указывает направление, но у него нет иерархической ответственности за людей.

На данный момент французское сообщество Scrum использует формулировку Product Owner.

Вот мое определение этой роли:

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

Когда мы будем в дальнейшем говорить о Владельце продукта, мы будем иметь в виду либо человека, либо роль, которую он играет.

Владелец продукта влияет одновременно и на стратегию, и на тактику.

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

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

Роль Владельца продукта разнится от компании к компании. Но у него есть основные обязанности. Перечислим их.

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

Рисунок 4.2 – PO постановляет бэклог

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

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

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

Владелец продукта отвечает за информирование заинтересованных сторон о предварительных результатах работы команды.

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

Именно Владелец продукта определяет момент ввода в эксплуатацию пользователями.

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

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

В идеале, у Владельца продукта должны быть разнообразная подготовка и опыт.

Владелец продукта не обязан быть провидцем, как Стив Джобс. Но в отношении продукта ему стоит быть дальновидным. Уже в самом начале разработки у него должна быть концепция, которая в дальнейшем будет обрастать деталями и закрепляться.

Обычно эта концепция состоит из:

✓ причины, по которой создается продукт или услуга,

✓ цели следующей версии,

✓ ожидаемого влияния на заинтересованные стороны,

✓ списка основных функций, которые этому способствуют.

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

Знание бизнеса и основных рабочих процессов (core business) напрямую связано со знанием рынка и пользователей продукта.

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

Владелец продукта не обязан знать все о функциональности продукта: в крупных проектах это может быть затруднительно или требовать больших временных затрат.

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

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

Он консультируется с заинтересованными сторонами по важным вопросам. Если мнения не совпадают, у Владельца продукта есть полномочия принять окончательное решение.

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

В компаниях принятие решений часто осуществляется на уровне комитетов. Это прямая дорога к развитию конфликтов на почве противоречия интересов, затянувшихся решений, трудностей в расстановке приоритетов.

Рисунок 4.3 – Комитет к концу собрания

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

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

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

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

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

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

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

Во время оценочных сессий с командой Владелец продукта демонстрирует преподавательские способности, объясняя, что он предлагает добавить в продукт. И слушает мнение команды!

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

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

Scrum не предлагает какой-либо конкретный метод определения элементов бэклога, но наиболее частая практика – пользовательские истории.

Рисунок 4.4 – PO практикует паттерн историй

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

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

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

• Постоянная готовность

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

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

• Участие в Scrum-событиях

Владелец продукта является полноправным членом команды и участвует в собраниях.

Вот вариант, как Владелец продукта может распределить свое время для участия в Scrum-собраниях проекта с двухнедельными спринтами:

✓ собрание, посвященное планированию спринта: приблизительно два часа;

✓ ежедневный Scrum, минимум дважды в неделю: 60 минут на четыре сессии;

✓ доработка: примерно три часа;

✓ обзор спринта и ретроспектива: по часу на каждый этап.

Получается восемь часов, примерно 10 % его времени.

• Ежедневное участие

Помимо участия в событиях, Владелец продукта также должен:

✓ разрабатывать и поддерживать бэклог, корректировать приоритетные задачи;

✓ отвечать на вопросы о продукте;

✓ определять условия приемки;

✓ выполнять проверки по окончании работы над тем или иным элементом.

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

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

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

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

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

Владелец продукта входит в Scrum-команду. Но чтобы хорошо играть эту роль, очень важно тесно сотрудничать с людьми в экосистеме.

Рисунок 4.5 – Обмен с Владельцем продукта в зонах экосистемы

Физическое присутствие РО в команде:

✓ В идеале Владелец продукта находится в одном рабочем пространстве с командой. Но вполне достаточно, если он будет находиться рядом – так, чтобы команда могла к нему подойти и попросить разъяснений. И наоборот, чтобы он мог легко встретиться с командой.

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

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

Тесное сотрудничество с разработчиком – отличная возможность узнать о технической стороне историй, над которыми идет работа, поделиться идеями, как улучшить работу.

Рисунок 4.6 – Тесное сотрудничество

Это то, что относится к Зоне 3.

Бывает, что РО не имеет достаточных полномочий, чтобы решить, какую из заинтересованных сторон слушать в первую очередь.

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

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

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

Результат работы команды предназначен для людей – конечных пользователей. Владелец продукта ориентируется на них, когда направляет команду на пути к продукту (в зависимости от контекста конечные пользователи будут в Зоне 4 или в Зоне 5).

Поэтому важно, чтобы он регулярно с ними виделся и наблюдал за ними на их рабочем месте.

Это то, что входит в Зону 5.

✓ Для обмена опытом Владельцу продукта рекомендуется посещать конференции, посвященные этой роли и новым тенденциям, подходам.

✓ В рамках своей организации он может присоединиться к сообществу РО для обмена практиками или, если такого сообщества нет, создать его.

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

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

Она определяет, что должен делать продукт. Селина устанавливает критерии приемки – условия, которые позволят ей убедиться, что работа над тем или иным элементом окончена.

На этапе доработки Селина сформулировала для команды свое видение функции продукта. Вместе с участниками команды она определила условия приемки, которые помогут удостовериться, что результат работы соответствует требованиям.

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

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

Селина отвечает за результаты перед заинтересованными сторонами. Чтобы хорошо выполнять свою роль, она должна поддерживать с ними связь.

Ситуация. В связи с тем, что у Владельца продукта не хватало времени на общение с клиентами, организация, которая отвечает за разработку, представила роль proxy PO.

Последствия. Рroxy PО принимает решения, которые ставятся под сомнение Владельцем продукта.

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

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

Ситуация. К началу работы только у Scrum-мастера есть специальное образование. Решено, что Владелец продукта будет обучаться по ходу проекта.

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

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

В организациях, где есть разрыв между пользователями и ИТ-специалистами (владелец проекта/менеджер проекта), обучение лучше вести внешнему тренеру (или Scrum-мастеру). Он привносит свои знания и опыт и помогает разобраться в роли.

Ситуация. В организации пришли к выводу, что в основе работы лежит коммуникация между Владельцем продукта и командой. Решено, что Владелец продукта начнет писать истории, активно используя формулировку в качестве…, о которой мы поговорим позднее.

Последствия. Общения с разработчиками нет. РО одиноко сидит в углу и пишет.

Как сделать лучше? Участвовать в доработке всей командой (см. главу 7).

Impact mapping, story mapping, innovation games… Все это – инструменты, которые позволяют Владельцу продукта выходить за рамки Scrum. Мы коснемся этой темы чуть позже.

Рисунок 4.7 – Не нужно оставлять РО наедине с бэклогом

Чтобы идти дальше

Книги

‣ Хенрик Книберг, «Scrum и ХР: Заметки с передовой», 2006

Онлайн-ресурсы

‣ Brian Marick, «How to be a Product Director», эссе, Web, 2006

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

✓ Многие студенты-программисты на собеседовании гордо заявляют, что планируют стать руководителем проекта. Вероятно, учителя внушили им такое стремление.

✓ Недавно во время презентации Scrum в одной крупной компании все участники представились по кругу как руководители проектов. В компаниях зачастую остаются только руководители проектов, которые несут ответственность за результаты.

Никаких руководителей проектов в Scrum! Эта роль исключена.

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

В пятом издании этой книги я больше не пишу ScrumМастер одним словом, а разделяю их на два: Scrum-мастер (или SM). Такое написание привычно многим и используется, например, в объявлениях о работе.

Иногда приводят аналогии, чтобы объяснить эту роль: пастух, капитан, бульдог и т. д.

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

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

Термин Scrum-мастер вызывает сомнения по поводу своей второй части – мастер. Язык влияет на поведение: даже если термин Scrum-мастер новый для организации, часть мастер поможет встать на путь изменений и смены парадигмы.

В некоторых организациях с иерархической культурой роль SM, мастера Scrum, может восприниматься как роль менеджера, руководителя. На самом же деле у него нет власти над командой.

Вот мое определение роли:

Одним словом, это фасилитатор.

Рисунок 5.1 – SM – фасилитатор для команды

Одна из функций – мотивировать команду становиться все более самостоятельной.

Он стимулирует команду:

✓ подталкивая участников к кроссфункциональности,

✓ укрепляя их навыки в инженерии, чтобы не зависеть от внешних экспертов.

Если SM преуспевает, команда меньше в нем нуждается. В этом парадокс роли.

Во время разработки всегда бывают непредвиденные события. Некоторые могут замедлить или вовсе приостановить работу команды. По терминологии Scrum, такие события называются препятствиями (impediments) и могут сильно различаться по своей природе и значимости.

Scrum-мастер выявляет препятствия и помогает команде с ними справиться.

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

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

Он фасилитирует события спринта.

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

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

Он убеждает, не навязывая своих решений: Scrum-мастер не имеет иерархической власти над участниками команды, его лидерство проявляется естественным образом.

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

Формально Scrum-мастер не обязан разбираться в области, для которой команда разрабатывает продукт. Но знания и опыт в этой сфере облегчат общение с Владельцем продукта и позволят лучше вовлекать команду в работу над максимизацией ценности продукта.

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

Навыки общения необходимы для Scrum-мастера: он должен часто разговаривать с командой и руководством.

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

Scrum-мастер имеет большое влияние: он лидер, ориентир для команды. Знает, как создать условия для мотивации участников, чтобы те достигли результата.

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

Во время спринта сопровождает команду на пути к результату, фокусируя участников на цели спринта, которую определили совместно.

Важная долгосрочная задача Scrum-мастера – устранение препятствий. Есть такие, что возникают на почве конфликтов между участниками команды.

В спорах он выступает посредником, чтобы помочь найти приемлемое решение. Он подталкивает людей к консенсусу.

Рисунок 5.2 – SM играет роль посредника

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

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

Scrum требует прозрачности. Scrum-мастер обеспечивает соблюдение этого принципа.

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

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

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

Scrum-мастер не командует, не навязывает и не принуждает. Он служит команде и предлагает участникам свою поддержку.

Его главное качество состоит в том, чтобы оставаться незаметным:

✓ если спринт прошел успешно, он не присваивает себе лавры почета. Это заслуга всей команды;

✓ если во время работы возникают трудности, это не вина кого-либо из команды.

Работа Scrum-мастер зависит от уровня команды.

При становлении команды группа проходит последовательные стадии. Каждый уровень соответствует определенным задачам Scrum-мастера:

✓ сначала он обучает команду Scrum,

✓ потом он помогает команде применять Scrum,

✓ затем он мотивирует участников команды брать на себя инициативу,

✓ он развивает такое свойство команды, как коллективный разум.

Задачи SM, а особенно устранение препятствий, требуют времени.

Он участник команды и общается с остальными. Он должен регулярно с ними видеться – лично! – и не остается работать на своем месте.

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

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

Эта новая роль является олицетворением радикальных изменений. В случае организации с мощной иерархической культурой Scrum влияет на основы управления.

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

В некоторых командах Scrum-мастером становится опытный разработчик. Но чаще эту роль берет на себя руководитель проекта.

Бывает Scrum-мастер из добровольцев. Его можно избрать. Есть новый метод избрания SM в команде: выборы без кандидата. Об этом можно прочитать в работе «Мягкий разрыв»[22].

Само собой, функциям Scrum-мастера можно обучиться. Но человек, берущий на себя эту роль, должен ей подходить.

Некоторые черты характера позволяют обнаружить Scrum-мастера в команде:

✓ умение чувствовать эмоции команды,

✓ любознательность,

✓ уверенность, что люди делают все возможное в своей работе,

✓ желание перемен, даже если это представляется сложным,

✓ ориентация на коллектив,

✓ азартность.

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

Рисунок 5.3 – Обмен с SM внутри экосистемы

SM является частью команды. Но хорошему SM нужно быть в контакте с людьми в экосистеме.

Уникальность Scrum в том, что обязанности распределяются: Владелец продукта планирует и предвосхищает, Scrum-мастер поддерживает команду в том, что она делает по требованию PO.

Успех Scrum основан на давлении запросов Владельца продукта на команду – давлении, конструктивно контролируемом Scrum-мастером.

Этот обмен соответствует Зоне 3.

Scrum-мастер не коуч. Один и тот же человек может совмещать обе роли, но это редкий случай.

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

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

Этот обмен проходит в Зоне 4.

Человек, который становится Scrum-мастером, в иерархии компании часто находится под руководством менеджеров.

Хорошее знание Scrum позволит ему самоутвердиться, и это ограничит чрезмерное давление заинтересованных сторон, использующих свою власть и навязывающих свое мнение.

Этот обмен соотетствует Зоне 5.

Scrum-мастер делится практиками с коллегами.

Роль требует прекрасного знания Agile-культуры и владения Scrum. Этому, разумеется, можно научиться на практике, но можно узнавать новое из книг и статей.

Scrum-мастеру потребуется много времени на самообразование: смотреть видео, слушать подкасты и читать статьи.

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

Николя – Scrum-мастер команды Peetic. Его выбрали на эту роль. Он принял ее с радостью.

Сейчас идет третий спринт во втором сезоне.

Утром Николя листает электронную почту, потом идет к кофемашине – там уже собралась команда. Ребята обсуждают фильм. В 9:30 начинается ежедневный Scrum перед доской текущего спринта. В рамках прошлой ретроспективы предложили улучшение, касающееся продолжительности схватки. Николя следит, чтобы Scrum длился не более четверти часа.

Сразу после схватки он видится с Жюльеном и системным инженером. Разговор идет о препятствии, связанном с промежуточным сервером: он еще не запущен и на каждом спринте затрудняет развертывание.

Решение найдено, Николя обновляет таблицу препятствий. Ох, осталось всего три! Заодно проверяет, обновлены ли задачи после схватки. Все сделано, хорошо.

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

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

Рисунок 5.4 – Полуденный канал

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

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

Он пытается объяснить Себастьяну, что тот вполне мог бы справиться с проблемой в одиночку.

У Николя есть немного времени до собрания, чтобы проанализировать причины крупного бага на прошлой неделе. Он идет к участникам команды, которые занимаются историей «Отредактировать раздел с фотографиями собак». Помогает им пройти две проверки, связанные с этой историей. Она будет закончена сегодня вечером!

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

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

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

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

Последствия. Команда демотивирована. Самоорганизация отсутствует.

Как сделать лучше? Заменить Scrum-мастера в соответствии с паттерном вращающегося Scrum-мастера.

Например, в опытной команде роль Scrum-мастера может переходить от человека к человеку и меняться каждый спринт или после нескольких спринтов.

Таким образом, роль Scrum-мастера динамична. Она не достается тому, кто превращает работу в рутину или беспрекословное подчинение указаниям. Этот паттерн позволяет увидеть отношения участников и понять, какое поведение наиболее приемлемо на роли SM для конкретной команды.

Рисунок 5.5 – Вращающийся SM

Ситуация. При внедрении Scrum руководитель проекта стал Владельцем продукта, а на роль SM пригласили человека извне – буквально навязали его команде.

Последствия. Его легитимность не признана. Человек не способен устранять препятствия. Ко всему прочему, он не понимает проблем технического характера.

Как сделать лучше? Устраивать выборы без кандидатов.

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

Последствия. Scrum не применяется, работа команды встала.

Как сделать лучше? Научиться менять положение в команде.

Роль Scrum-мастера развивается вместе с командой: сначала он уделяет много времени обучению команды принципам Scrum, затем становится советчиком (экспертом, ментором, коучем).

Ситуация. SM делает все, что связано с логистикой. Он убирается, закупает необходимое. Единственный из команды пишет Post-it®.

Последствия. Остальные во всем на него полагаются и не участвуют в жизни команды. Scrum-мастера все достало.

Рисунок 5.6 – Scrum-мастер проверяет, все ли готово

Как сделать лучше? Коллективно обсудить правила жизни команды.

Чтобы идти дальше

Книги

‣ Rachel Davies, Liz Sedley, «Coaching Agile», Lulu, 2009. Эта книга дает очень хорошие советы Scrum-мастеру, хотя даже не упоминает эту роль

После решения о начале разработки продукта самая большая трудность – трансформировать первоначальное видение в нечто, что может использовать команда разработчиков.

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

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

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

Неужели нет французского слова для бэклога?

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

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

Рисунок 6.1 – «Я сказал дополнить бэклог, а не исполнить «Black dog»

Scrum-мастер – разработчику и фанату группы «Led Zeppelin»

В литературе о Scrum различают бэклог продукта и бэклог спринта.

✓ В 2008 я решил более не использовать термин бэклог спринта для обозначения плана на спринт. Я объясню свое решение в главе 9.

✓ Начиная с третьего издания этой книги, сокращаю бэклог продукта до бэклога.

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

Остается только прояснить грамматический род этого слова. Я слышал, кто-то считает, что бэклог женского рода. Но я буду, как большинство, думать, что это слово мужского рода.

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

Рисунок 6.2 – Свойства бэклога

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

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

Это нецелесообразно. Список невероятно длинный. Распределить задачи невозможно. Хотя бэклог и является, по сути, списком задач, это не значит, что с самого начала работы надо детально описывать, к чему команда подойдет не завтра и даже не послезавтра.

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

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

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

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

Бэклог следует жизни продукта и развивается вместе с ним. В современном мире продукты не статичны, они создаются и развиваются постепенно и постоянно.

Бэклог живет продолжительное время, претерпевая изменения с каждым сезоном:

✓ одни элементы добавляются,

✓ другие убираются,

✓ какие-то из них разбивают на несколько,

✓ порядок элементов корректируется.

Я ознакомился со многими спецификациями в различных областях разработки ПО. И каждый раз отмечал: невозможно все знать с самого начала проекта. Если вы все обсудите и постараетесь предвосхитить все возможные ситуации – конечно, обнаружите много важных функций. Но всегда будут такие, которые появятся только при общении с конечными пользователями.

Бэклог доступен для всех членов экосистемы. Каждый может привнести свой вклад в его развитие.

Только обратная связь от пользователей позволяет узнать, что они действительно ожидают от продукта.

Бэклог допускает внесение новых элементов, потому что невозможно все знать заранее.

Существует множество паттернов, чтобы адаптировать бэклог к контексту.

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

«Руководство по Scrum» формально не навязывает использование какого-либо термина для элементов бэклога, но употребляет аббревитуру PBI (Product Backlog Item).

Со временем элементы бэклога стали называться историями (stories). Истории становились все меньше и короче по определенным причинам – мы коснемся их позднее. Но в связи с этим проблема: маленькие обособленные части бэклога не понятны заинтересованным сторонам. А разработчик не может свести их в общую картинку и перестает разбираться в процессе.

Джефф Паттон [«Пользовательские истории»] заострил внимание на этой тенденции и использовал метафору астероидов. Он предложил создать карту, чтобы соотнести большие и маленькие части бэклога.

Учитывая размер элементов бэклога, не стоит забывать, что самым важным остается работа с ними.

После десяти лет практики я пришел к выводу, что бэклог состоит из двух частей.

✓ Та, что касается команды и содержит маленькие части, над которыми команда работает или планирует работать в скором времени

✓ Та, что служит для общения с заинтересованными сторонами и содержит большие части. Конечно, она также полезна и для команды.

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

Рисунок 6.3 – Бэклог и две его части

В литературе по теме можно найти в качестве эквивалентов такие термины, как feature (то, что я использовал в предыдущих изданиях этой книги) или capability. Наиболее близкое мне понятие – Minimal Marketable Feature, MMF (прим. пер.: коммерчески ценная функциональность) [23]. На мой взгляд, функциональность, появившаяся вследствие декомпозиции – это MMF.

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

Ключевая концепция заключается в поиске наименьшей значимой функциональности. Это задача Владельца продукта.

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

Термин user story – пользовательская история – появился в Экстремальном Программировании, а сейчас широко употребляется в Scrum.

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

Как и функциональность, история видна пользователям. Но есть два отличия:

✓ в эксплуатацию вводится сразу несколько историй,

✓ история разрабатывается в течение одного спринта.

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

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

Epic должен быть разделен на части и хорошо изучен, он нуждается в доработке. После разделения на части он исчезает.

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

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

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

В Scrum команда дважды повторяет этапы проговаривания и подтверждения. Первый раз, чтобы подготовить работу над историей, и второй – чтобы ее закончить.

1. Однажды у кого-то появляется идея, и он пишет ее на карточке (сейчас для этого чаще используются Post-it®).

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

3. Команда подтверждает, что она готова.

4. Команда реализует историю в рамках спринта, проговаривая весь процесс с Владельцем продукта.

5. Владелец продукта подтверждает, что работа завершена.

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

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

Рисунок 6.4 – Жизненный цикл истории

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

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

Двухфазный паттерн – фрактальный: он применим к жизненному циклу и истории, и функциональности.

• Жизненный цикл функциональности

Жизненный цикл функциональности зависит от контекста. На него влияет позиция Scrum в цепочке создания ценности. На начальном этапе – это принятие решения о начале разработки, на последнем – развертывание и ввод в эксплуатацию.

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

Владелец продукта придерживается принципа максимальный эффект при минимальных усилиях [24].

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

• Изображение при помощи kanban-таблицы

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

Такая таблица называется kanban (не следует путать с методом Kanban, о котором мы поговорим в главе 20).

Рисунок 6.5 – kanban-таблица для работы с функциональностями

Бэклог поставки является основным инструментом коммуникации с заинтересованными сторонами.

• Жизненный цикл истории

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

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

Суть этого паттерна – в распределении историй в соответствии с их текущим состоянием.

• Изображение при помощи лотков

Песочница идей

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

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

Обратная связь имеет большое значение в Аgile-методах, и первоначальным хранилищем для нее является песочница.

Лоток доработки

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

Этот лоток выглядит, как обычная воронка.

✓ Приоритетная история уже почти готова. Она небольшого размера.

✓ В середине воронки то, что перейдет к этапу разработки через несколько спринтов. Здесь находятся epics среднего размера.

✓ Наименее приоритетные истории будут разрабатываться еще позднее. Это большие, громоздкие epics, которые впоследствии будут разложены на части.

Рисунок 6.6 – Воронка

Поскольку лоток доработки – воронка, большие истории через нее не просочатся. В следующий лоток попадут только самые маленькие и доработанные.

Стартовый лоток для готовых историй

Scrum использует метафору гонки (спринт), и я предлагаю ее развить.

До спринтерских забегов готовые истории находятся в стартовых блоках. Назовем их стартовым лотком.

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

Истории участвуют в спринте. Это гонка, за которой мы внимательно следим. Мы вернемся к ней, когда будем говорить о событиях спринта.

Финишный лоток для завершенных историй

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

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

Преимущества паттерна лотков

Применение этого паттерна означает для команды (и особенно для Владельца продукта) следующее:

✓ четко видеть, что у каждой части в изображении своя цель, отличная от других;

✓ работать над каждой частью в соответствии с этапом, на котором она находится;

✓ не быть заваленными огромным количеством историй.

Рисунок 6.7 – Структура рабочего бэклога на основе этапов жизни

В этой главе мы рассмотрели бэклог в статике. Следующая будет посвящена бэклогу в динамике и процессу циркулирования историй и функциональностей в потоке.

Какую работу заносить в бэклог? Бывает, команда тратит время на технические аспекты или на исправление ошибок. Паттерн сториотип [26]может помочь команде разобраться, что стоит записывать в бэклог, а что вносить не нужно.

Этот паттерн основан на идее Филиппа Крухтена: визуализация элемента бэклога по двум основным направлениям [27]:

✓ Ценность – в зависимости от того, добавляет элемент новую или восполняет отсутствующую;

✓ Значимость – в зависимости от того, кому продукт предназначен.

Рисунок 6.8 – Четыре основных типа историй

Эта классификация помогает не забыть внести работу в бэклог. Она будет полезна вкупе с более детальной классификацией критериев завершенности (Definition of Done, DoD).

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

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

Эта история реализована при помощи кода. Он может включать и другие истории, не содержащие кода и имеющие значение для заинтересованных сторон.

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

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

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

Это работа, которая приносит ценность команде, но не видна заинтересованным сторонам.

Внесение технической работы в бэклог оправдано в следующих ситуациях:

✓ необходимо провести техническое исследование, чтобы принять решение о том, как реализовать пользовательскую историю;

✓ есть технические риски, которые надо устранить до реализации пользовательской истории;

✓ необходимо улучшить качество или способ работы команды: инфраструктуру, логистику, новые инструменты, обучение, и т. д.

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

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

Рисунок 6.9 – Попытка объяснить Владельцу продукта, что нужно сократить задолженность

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

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

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

Выявление технического долга и работа по его погашению – один из шагов на пути устойчивого развития.

Ситуация. Бэклог содержит абсолютно все задачи к выполнению – значит, он включает в себя все идеи и баги. Получается более сотни элементов разного размера и статуса.

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

Как сделать лучше? Постараться применить предложенные паттерны, особенно паттерн лотков.

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

Последствия. Два источника задач для команды, хаос.

Как сделать лучше? Сделать бэклог уникальным списком задач (одно из свойств бэклога).

Ситуация. Владелец продукта при приоритизации элементов бэклога использует инструмент типа электронных таблиц.

Последствия. Никто не видит бэклог, кроме самого Владельца продукта.

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

Ситуация. Исходя из принципа, что бэклог создается для продукта, в него входит только то, что напрямую касается самого продукта. Таким образом, команда иногда работает над элементами, которые не внесены в бэклог.

Последствия. Владелец продукта и заинтересованные стороны не знают об этом. Отсутсвует прозрачность.

Как сделать лучше? Вносить в бэклог все, даже если есть сомнения по поводу связи элемента бэклога и продукта. Использовать паттерн «сториотип», чтобы классифицировать истории.

Ситуация. Многие организации, переходящие к Scrum, действуют по схеме, в которой одна команда работает над несколькими проектами одновременно. Для каждого проекта свой бэклог.

Последствия. Невозможно приоритезировать задачи. Мультизадачность мешает работе.

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

Чтобы идти дальше

Книги

‣ Джефф Паттон, «Пользовательские истории. Искусство гибкой разработки ПО», Питер, 2017

‣ Dan Rawsthorne, Doug Shimp, «Exploring Scrum, The Fundamentals», CreateSpace Independent Publishing Platform, 2011

С появлением Scrum в наших краях понятие бэклога заиграло новыми красками, чему несказанно обрадовались любители историй. В корзину отправились большие технические документы, истории пришли им на смену. Мы зафиксировали все задачи на post-it и приступили к работе.

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

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

Эти истории не были готовы, не были хорошо доработаны.

Доработка – это аккуратный баланс между определением всего и бездействием перед началом спринта. Это снижающий риски минимум.

В английском языке ранее использовался термин груминг. В первом издании этой книги я перевел его глаголом причесывать: Владелец продукта причесывает бэклог. В третьем издании я изменил перевод на Владелец продукта культивирует бэклог и говорил о лотке культивации. Между тем, в маленьком «Руководстве по Scrum» версии 2013 года появился термин refinement».

Я использую перевод доработка начиная с четвертого издания.

Бэклог дорабатывается, как сыр.

Искусство доработки для Scrum-команды заключается в приготовлении историй в нужный момент.

Рисунок 7.1 – Очень долгая доработка может навредить

Цель доработки – бэклог с достаточным количеством готовых историй.

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

Доработка касается двух частей бэклога и применима как к функциям, так и к историям.

Неотъемлемой частью работы команды является прохождение через этап готово, а затем и завершено. Нельзя утверждать, что история готова на 100 % – это всегда зависит от команды. Только она может решить, готова ли история. Чтобы принять это решение, она может положиться на критерии готовности.

Какие именно рекомендации? Команды иногда опираются на давнюю статью (2003) Билла Уэйка, в которой он говорит об акрониме INVEST. Статья была написана еще до популяризации критериев готовности, поэтому неуместно адаптировать нашу концепцию в соответствии с ней. Я предлагаю использовать рекомендации, которые формируют паттерн 6К.

• Паттерн 6К

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

Рисунок 7.2 – 6К

✓ Какой вклад приносит история: что именно и кому?

✓ Как хорошо она разложена на части: достаточно ли она маленькая?

✓ Было ли коллективное обсуждение: как хорошо историю проговорили?

✓ Возможен ли краткий обзор: сможем мы использовать ее для демонстрации во время обзора?

✓ Обладает ли она критериями завершенности: чтобы она была готова, хорошо бы знать критерии ее завершенности.

✓ Какие риски: есть ли риски в реализации этой истории? Есть возможность их минимизировать?

• Пример контекстуализации 6К

Этот паттерн полезен для направления обсуждения во время доработки. Иногда в фокусе разговора связанные с историей данные (например, условия приемки), которые будут изучены с точки зрения качества.

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

Исходя из этого, паттерн 6К, соответственно адаптированный, может применяться и для функциональности:

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

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

✓ заинтересованные стороны будут сильнее вовлечены в обсуждение.

Для проверки гипотезы может потребоваться, чтобы соответствующие истории уже были завершены – если подходить с научной точки зрения, как в Lean Startup.

Для минимизации усилий необходимо иметь хорошее представление об историях. Это подразумевает участие всей команды.

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

Доработка бэклога осуществляется командой во время спринта с целью обеспечить успех следующих спринтов.

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

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

Чаще всего он привлекает к этому процессу команду: большая часть работы состоит из разговоров с участниками. Рекомендуется, чтобы вся Scrum-команда участвовала в доработке.

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

В процессе доработки бэклога поставки Владелец продукта привлекает больше заинтересованных сторон. У него может быть привилегированный собеседник.

Желательно, чтобы доработка носила постоянный характер и проходила в рамках командной работы – например, во время собрания по доработке бэклога.

Таким образом, доработка связана со Scrum-подходом, как и события спринтов, и нет необходимости в ее специальном включении в бэклог.

Есть два возможных варианта проведения собрания по доработке:

✓ Регулярное. Например, по средам. Это самый простой вариант для новичков в Scrum.

✓ По запросу. Scrum-мастер следит за готовностью историй, и в случае их недостатка организует собрание по доработке бэклога (см. главу 20 «Применение Kanban в Scrum»).

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

Собрание по доработке проходит по крайней мере один раз за спринт. Количество сессий зависит от длины спринта.

Наличие структурированного бэклога облегчает работу по его доработке.

✓ Учитывая, что цель состоит в своевременном наличии готовых историй, выделение этих историй в бэклоге облегчает их отслеживание.

✓ Идеи, запросы, обратная связь, которые Владелец продукта еще не обработал, находятся в песочнице.

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

Рисунок 7.3 – Доработка рабочего бэклога

Доработка бэклога поставки происходит на более высоком уровне.

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

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

Готовая функциональность должна иметь минимальные риски или не иметь их вовсе.

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

Рисунок 7.4 – Поток в рабочем бэклоге

Владелец продукта уверен в способности команды разрабатывать элементы, которые были доработаны вместе с ним.

Заинтересованные стороны видят – в частности, благодаря бэклогу поставки – что команда планирует к разработке.

Планирование следующего спринта (глава 9) будет проще и быстрее. Разработка среднесрочного плана (глава 16) также значительно облегчается.

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

1. Просмотреть список готовых историй. Если их недостаточно, подготовка новых историй – первоочередная задача. (П).

2. Изучить те, что находятся на доработке, чтобы выявить epics и разложить их на части. (Р).

3. Проанализировать песочницу и kanban-таблицу функциональностей с целью обновления списка историй к доработке. (О).

4. Выбрать, что можно удалить. (В).

5. Единогласно решить, что остается на этот сезон, а что уйдет в следующий. (Е).

6. Рассмотреть новые или разложенные элементы (Р).

7. Классифицировать истории в лотке доработки. (К).

Рисунок 7.5 – Доработка

Из описанной последовательности получается акроним ПРОВЕРКа. На практике действия не последовательны: иногда образуются петли и появляются дополнительные пункты.

Есть ли необходимость в заранее готовых историях? Если да, команда рассматривает наиболее приоритетные истории в лотке доработки.

Разговор с РО должен снабдить команду знаниями. Решение о готовности истории принимается, когда команда считает, что риски не закончить ее во время спринта уменьшены. Участники опираются на критерии готовности.

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

• Возможность краткого обзора на демо с условиями приемки

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

✓ Заявка принята – запись собаки на выставку прошла успешно.

✓ Заявка отклонена – запись не удалась, достигнут предел допустимых заявок.

Второе условие может соотноситься с той же историей или входить в другую, новую. Это искусство декомпозиции истории.

• А дальше – BDD

Условие приемки относится к исполнению истории. Поведение истории во время ее реализации зависит от начального состояния и параметров исполнения. Практика BDD (Behaviour Driven Development) позволяет описать это поведение на примере программируемого устройства.

Каждый тест формально состоит из трех элементов:

✓ состояние перед исполнением теста (речь о контексте теста);

✓ событие, которое запускает исполнение истории;

✓ состояние после реализации (речь об ожидаемом результате).

На английском это Given When Then.

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

Можно использовать BDD для условия принятия:

• Риски сведены к минимуму

Обсуждение рисков может иметь технический характер.

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

И продолжает в таком духе, пока не будет достаточно готовых историй.

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

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

Понимание, насколько необходимо разбить данную историю и как именно это сделать, требует опыта. Команде в этом поможет паттерн разделение.

• Паттерн «Разделение»

Этот паттерн предлагает 9 возможных путей для размышлений о декомпозиции истории.

Рисунок 7.6 – Паттерн «разделение истории»

Ниже примеры основных направлений.

Вариации на тему Данных

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

Разложение на части по бизнес-правилам

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

Оптимизация, отличная от производительности

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

Spike

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

Исследование под названием spike, или шип [28], помогает снизить риски при ее реализации.

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

1. переместить идею на этап доработки, чтобы включить в текущий сезон;

2. удалить ее;

3. решить, что это предложение больше истории, а то и epic истории, и переместить ее в kanban-таблицу функциональностей.

Рисунок 7.7 – Выход из песочницы

Нужно регулярно чистить бэклог.

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

Элементы, которые застаиваются в конце списка, являются первыми кандидатами на удаление.

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

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

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

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

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

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

Оценка помогает команде сделать прогноз на сезон.

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

Рисунок 7.8 – Оценка усилий

Другие проблемы и способы оценки мы рассмотрим в главах 16 «Планирование на среднесрочную перспективу» и 18 «Наглядность при помощи индикаторов».

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

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

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

Между историями могут быть зависимости, которые влияют:

✓ на другие истории,

✓ на людей, которые могут реализовать историю,

✓ на сроки.

Во время рассмотрения паттерна поставки/работы мы поняли, насколько важно общение с заинтересованными сторонами. Их следует вовлекать в процесс доработки бэклога поставки.

Рисунок 7.9 – Доработка бэклога поставки

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

Необходимо пересмотреть время доработки (когда?) и участников процесса (с кем?).

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

Нужные люди – в данном случае, это привилегированные собеседники Владельца продукта (см. главу 4).

Говоря о команде. Если при доработке рабочего бэклога необходима вовлеченность всех участников, то при доработке бэклога поставки их участие опционально. Достаточно одного или двух человек. Идеально иметь группу из 3–5 человек: РО, как минимум один участник от заинтересованных сторон и один участник от команды разработки.

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

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

Мы подробнее поговорим об этих критериях в главе 15: они особенно важны для первой сессии доработки первоначального бэклога.

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

Когда изучаешь эти зависимости и закономерности, стоит задать себе несколько вопросов.

✓ Во время какого этапа развития функциональности мы начинаем создавать соответствующие ей истории (первое время epics)?

✓ Какие истории нужно определить и завершить, чтобы можно было считать функциональность готовой?

✓ Если все истории, составляющие функциональность, завершены, что нужно сделать, чтобы завершить функциональность?

✓ Если команда проводит оценку, есть ли корреляция между историями и функциональностями?

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

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

Как сделать лучше? Оценка – это одно из (опциональных) действий этапа доработки. Использовать акроним ПРОВЕРКа, чтобы во время доработки сделать все необходимое.

Прочитать главу 16, посвященную основной цели покера планирования.

Ситуация. Команда разделилась на истории и определила зависимости от людей вне команды. Участники планируют ввести их в курс дела во время спринта.

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

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

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

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

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

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

Чтобы идти дальше

Книги

‣ Gojko Adzic, David Evans, «Fifty quick ideas to improve your User Stories», Neuri Consulting LLP, 2014

Рисунок 8.1 – «Уборка завершена!»

Эти вопросы часто возникают как в разработке, так и в жизни вообще. В Scrum они настолько важны, что есть целая практика, посвященная этому.

В конце спринта команда достигает определенного результата. Этого недостаточно: нужно, чтобы задачи были «завершены» – только тогда спринт можно считать успешно законченным.

Но что это вообще значит?

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

Цель этой главы – показать, как сделать, чтобы критерии завершенности совпадали для всей команды и заинтересованных сторон.

Темп в Scrum задается спринтом фиксированной и короткой продолжительности, который не может быть продлен и завершается определенным результатом.

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

Именно с целью снижения рисков в отношении содержания инкремента команда согласовывает цель спринта и доводит ее до сведения заинтересованных сторон.

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

Постановка цели спринта усиливает фокус команды, ее целеустремленность и вовлеченность. Это позволяет команде, словно экипажу корабля, придерживаться единого курса.

Детали этой Scrum-практики представлены в следующей главе.

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

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

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

Метафора спринта не применима к участникам команды (которые, скорее, бегут марафон), но сохраняет смысл, если представлять, что в качестве бегунов выступают истории.

Рисунок 8.2 – Участники дают команду «марш», и истории начинают спринтерский забег

Истории участвуют в забеге и, очевидно, финишируют не одновременно.

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

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

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

✓ Проверки на соответствие условиям приемки (кто, когда, кому).

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

✓ Проверки, заметные только команде (возможность поддержания, многократного использования, и т. д.).

Рисунок 8.3 – Три категории проверок завершенности

Назовем эти три категории так: функционирование, внешнее качество и внутреннее качество.

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

И тогда она создает список, действительный сразу для нескольких историй.

Нескольких, но не всех!

Истории, занесенные в один список, принадлежат к одному сториотипу, говоря языком Джеральда Месразоса, а затем Дэна Роастхорна в его «Exploring Scrum».

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

Завершить историю – это хорошо. Завершить функциональность – еще лучше!

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

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

В данном случае тоже можно применить деление на три категории, упомянутые выше.

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

Результат спринта содержит отдельно проверенные истории или функции. Но возможны и другие проверки.

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

Можно проводить проверки кода, что мы – по крайней мере, в начале – делаем не для каждой истории, а в целом, например, для тестового покрытия.

Как правило, в конце спринта результат развертывается в среде, доступной для заинтересованных сторон.

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

«Завершено» для сезона не отличается от «завершено» для спринта – за исключением того, что окончание сезона соответствует вводу в эксплуатацию.

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

В этом случае полезно определить, что требуется для продукта.

Следует ли проводить маркетинговые мероприятия? Тесты производительности? Нужно ли оформлять сопровождающие документы для ввода в эксплуатацию?

Здесь необходимо участие заинтересованных сторон: скорее всего, Scrum-команда не справится самостоятельно.

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

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

Критерии завершенности впервые разрабатываются во время прелюдии, перед первым спринтом.

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

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

Отдельным пунктом обсуждения является уровень, на котором следует разместить нефункциональные или кроссфункциональные требования (удобство использования, надежность, производительность, безопасность и т. д.).

Рисунок 8.4 – Критерии завершенности на нескольких уровнях

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

Список публикуется таким образом, чтобы вся команда его видела и одинаково понимала.

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

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

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

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

• Кто проводит проверку завершенности?

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

• Что делать, если проверка не пройдена?

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

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

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

Рисунок 8.5 – «Это конец»

Этап завершения – последний в жизненном цикле истории. После него ничего нет.

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

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

Во время ретроспективы рассматриваются причины, по которым не были пройдены те или иные проверки.

Критерии завершенности и готовности развиваются и меняются с каждым спринтом по нескольким причинам.

✓ Команда упустила какие-либо аспекты и подчеркнула их во время спринта. Другие же вошли в ее привычку и были удалены.

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

✓ Команда поднимает вопрос о добавлении новых сториотипов.

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

• Применение концепции сториотипа

У каждой команды свои сториотипы, так как они зависят от контекста.

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

Уорд Каннингем предложил концепцию технического долга [30]. Он провел аналогию с финансовым долгом: когда вы берете долги, проценты постепенно накапливаются – так и стоимость разработки со временем возрастает, если у программного обеспечения есть технические недостатки.

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

Профилактические меры относятся к критериям завершенности, в то время как меры курирования составляют истории типа погашения технического долга.

Неполное или неудачное применение критериев завершенности – обычная причина обнаружения ошибок.

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

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

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

Последствия. Критерии завершенности расплывчаты.

Как сделать лучше? Внести ограничение количества пунктов в списке, например, до десяти конкретных проверок.

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

Последствия. Критерии завершенности особо не используются командой.

Как сделать лучше? Повесить список критериев завершенности на стену команды, чтобы каждый участник его видел.

Чтобы идти дальше

Книги

‣ Dan Rawsthorne, Doug Shimp, «Exploring Scrum, The Fundamentals», CreateSpace Independent Publishing Platform, 2011

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

✓ Разработчик кода не особо любит вопросы о том, когда он закончит. Иногда руководитель проекта после нескольких дней настойчивых расспросов может получить в ответ жалостливое «хорошо, я постараюсь закончить завтра». Такая ситуация объясняется привычкой лидера запрашивать прогноз и затем оказывать давление.

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

✓ В организациях, где ИТ находится на приличной дистанции от других отделов, можно говорить о недостатке доверия. Никто не верит датам, объявленным руководителем ИТ-проекта. В том числе и разработчики.

Scrum не обещает чудес и не предсказывает будущее!

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

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

Это пища для размышления в самом начале спринта, которая подкрепляет команду на пути к цели.

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

Рисунок 9.1 – Единая цель команды

На английском планирование спринта звучит как sprint planning, а его результат – бэклог спринта, он же sprint backlog. Иногда этот термин употребляется и французами… Со своей стороны, я не использую бэклог спринта (с первого издания этой книги) по следующим причинам:

✓ использование этого термина порождает путаницу с другим бэклогом,

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

В этом отличие от «Руководства по Scrum». По данному вопросу я скорее склоняюсь к позиции «Scrum3.0».

На самом деле в спринте участвует не команда, а истории.

Чтобы преуспеть в спринте, истории должны начинать забег со стартовых блоков. Это знак того, что они готовы.

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

Коллективное планирование важнее результата: размышления и обсуждения во время этого ритуала объединяют команду.

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

Планирование спринта – катализатор самоорганизации.

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

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

Планирование – событие, которое начинает спринт. Оно ограничено во времени, как и другие события спринта.

В ранее издававшихся публикациях о Scrum планирование спринта было представлено в двух частях: определение границ и цели спринта и определение необходимых задач и их оценка.

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

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

Главный результат: команда концентрируется на своей цели в спринте.

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

Это объект коммуникации.

✓ Фраза, которая его описывает, видна всей команде на протяжении спринта.

✓ Цель доводится до сведения заинтересованных сторон, которые будут знать, во что вовлечена команда.

Рисунок 9.2 – Две цели спринта

За спринт история проходит три этапа, представленных через метод лотков: готовая история, история в процессе и завершенная история.

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

Их совокупность называется план спринта.

Рисунок 9.3 – План спринта, в данном случае – с задачами к историям в процессе

Для изображения этого плана рекомендуется использовать доску.

Есть несколько путей, ведущих к результату. Вот одна из цепочек действий и паттернов планирования спринта.

✓ Команда помещается в контекст спринта (введение).

✓ Участники команды вместе с РО уверяются в готовности бэклога к началу спринта.

✓ Участники становятся самоорганизованной командой и приступают к определению задач.

✓ После обозначения задач команда начинает двигаться к цели спринта.

✓ Спринт запущен (заключение).

• Корректировка

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

Такое случается редко.

• Предварительная цель

Владелец продукта дает предварительную цель на данный спринт, которую он представил заинтересованным сторонам в ходе обзора.

Цель будет консолидирована во время собрания.

• Доступность

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

Нужно отметить дни, когда на помощь команде приходят эксперты. Для наглядности можно составить визуальный календарь.

Scrum-мастер бдительно следит за возможными зависимостями между участниками команды и/или экспертами. Сложности возникают, если навыки и знания не передаются. Чтобы не допустить этого, у команды есть возможность изменить порядок историй.

• Календарный вопрос

Владелец продукта напоминает остальным место этого спринта в текущем сезоне.

Называется предполагаемая дата окончания спринта.

Так как длительность спринтов фиксирована во времени, речь, скорее, о простой установке конкретной даты и дня.

Дата завершения выбирается однократно и меняться больше не может.

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

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

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

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

Рисунок 9.4 – Готовые истории в плане спринта

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

Команда уже определила правила, эксплицитные [32] или имплицитные [33], если они прошли этап прелюдии (см. главу 13). В этом спринте участники отказываются от правил в пользу их улучшения посредством самоорганизации команды.

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

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

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

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

Роение (swarming) состоит во временном разделении команды. Созданная подгруппа собирается вокруг истории и работает над ней до ее завершения.

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

Другой аспект паттерна касается количества историй, которые могут параллельно находиться в работе. В частности, ограничивает количество историй в процессе (это ограничение называется WIP [34]-лимитом в Kanban, см. главу 20). Количество может меняться в зависимости от размера команды и уровня специализации.

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

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

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

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

Задача – это работа, необходимая для реализации истории, но не несущая ценности сама по себе.

Задача описывается просто.

✓ Название и описание работы. Для обозначения задачи достаточно названия и текста, скомпанованного во время собрания и позволяющего понять, что необходимо сделать.

✓ Позднее можно к этому добавить, кто будет работать над этой задачей. Она может быть выполнена одним или несколькими участниками. Рекомендуется работа в паре (см. главу 19).

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

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

Критерии завершенности и список проверок не дают команде забыть о задачах.

Задачи определяются локально: если используется роение, то каждой подгруппой со своим референтом, после чего следует коллективная реституция [35].

Существуют ли задачи без истории?

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

Для других историй это будет сделано по ходу спринта.

Истории сохраняют последовательность во время спринта. Наименее приоритетные остаются на конец, и у команды есть время на их декомпозицию.

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

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

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

Рисунок 9.5 – Задачи в таблице

Приверженность и вовлечение входят в список ценностей Scrum. На что же они влияют при планировании?

• На список историй или на скорость команды?

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

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

• Приверженность цели спринта!

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

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

Примеры цели спринта:

– спринт 1 – аутентификация пользователей.

– спринт 2 – открыть онлайн-магазин корма для животных.

– спринт 3 – запустить оплату через Paypal.

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

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

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

Рисунок 9.6 – Цель определяет направление

• Взятие задач к выполнению

Участники команды сами берут себе задачи, учитывая при этом порядок историй. Нет смысла начинать сразу все задачи: достаточно, чтобы у каждого была работа на первый день спринта. Остальные задачи команда будет разбирать позднее. Они будут выполняться в ходе спринта в зависимости от доступности каждого участника.

Обычно взятие задач не является проблемой для команды. Паттерн роения позволяет избежать колебаний. Самоорганизация в действии.

Самоорганизация – это здорово. А что делать со сложной, но важной работой, за которую никто не взялся?

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

Я работал со многими Scrum-командами и никогда не видел, чтобы существовала какая-то такая работа, которую никто не хотел брать на себя. Есть несколько причин, почему этого не происходит.

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

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

– Переход из директивного режима в автономный режим расширяет возможности каждого.

• Начало работы

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

Рисунок 9.7 – План спринта, в данном случае, без задач, в конце планирования

Если команда применяет паттерн работы, задачи соотносятся с историями, которые команда начала в первую очередь.

Участники обсуждают прогресс утром следующего дня в ходе схватки перед доской.

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

Последствия. Команда считает, что теряет время. Она упускает самое важное – цель спринта. Появляется микроменеджмент.

Как сделать лучше? Оценка задач в часах давно устарела. Это замедляет работу. Что касается оценки историй по пунктам, это стоит делать не во время планирования, а во время доработки.

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

Последствия. Команда подвергается давлению, это отрицательно сказывается на мотивации.

Как сделать лучше? Владелец продукта предлагает цель и определяет порядок историй для спринта. Команда решает, какие истории она берет в работу.

С другой стороны, команда может предложить внести изменения в приоритетный порядок историй, а Владелец продукта принимает или отклоняет это предложение.

Ситуация. Во время прошлого спринта команда потратила много времени на планирование, и Scrum-мастер – в погоне за эффективностью – сам составляет список готовых задач и назначает их участникам.

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

Как сделать лучше? Scrum – это концепция автономной и уполномоченной команды. Все делается коллективно, в одном месте и в одно время. Есть смысл попробовать паттерны роения и работы.

Ситуация. Думая, что поступают правильно, все участники команды вкладываются в проект на 100 %. Scrum-мастер подготовил диаграмму сгорания задач (burndown chart). Вот только, как всегда, неожиданные события замедляют ход спринта, блокируя или замедляя выполнение одной или нескольких задач.

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

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

Ситуация. Команда несерьезно относится к доработке и пропускает этот этап или посвящает ему недостаточно времени. Участники считают, что эффективнее все сделать во время этапа планирования.

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

Как сделать лучше? Практиковать доработку.

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

Фредерика Брукса, автора книги «Мифический человеко-месяц», спросили: каким образом проект может опаздывать на год? Он ответил еще сорок лет назад: отставание состоит из задержек на один день [36].

Чтобы быстро осознать и отреагировать на отставание проекта, следует каждый день проводить схватку.

Схватка в регби – это квинтэссенция коллективных усилий. Схватка в Scrum тоже имеет командный характер и основана скорее на обмене, чем на приложении усилий.

В Экстремальном Программировании это собрание называется stand up meeting, из чего мы сразу понимаем, что мероприятие проводится стоя.

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

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

Рисунок 10.1 – Схватка – знаменательный момент обмена

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

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

Цитируя Хельмута фон Мольтке, «ни один план не переживает встречи с противником». Команда может столкнуться с двумя формами непредвиденных событий:

✓ те, что являются неотъемлемой частью спринта, называются препятствиями,

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

Рисунок 10.1 – Схватка – знаменательный момент обмена

Непредвиденными мы называем события, которые не запланированы в начале спринта.

Во время сессии доработки, и уж тем более во время сессии планирования, команда постаралась минимизировать все риски (задавая вопрос какие риски? – согласно паттерну 6К). Препятствие – это риск, который команде не удалось сократить или предугадать заранее.

Препятствия выявляются в ходе спринта.

Желание приводить все в порядок и делать наглядным подталкивает к составлению таблицы препятствий, где были бы описаны:

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

✓ их вляние (определенное историями или задачами, выполнение которых невозможно или замедлено),

✓ дата их обнаружения.

Рисунок 10.3 – Таблица препятствий

Задача Scrum-мастера – в их устранении. Может потребоваться участие всей команды. Если команда не в силах устранить препятствие, оно может быть эскалировано на уровень экосистемы.

Команде ничего не мешает во время спринта. Scrum-мастер защищает ее от внешнего вмешательства, в частности со стороны заинтересованных сторон.

Но Scrum-мастер может о чем-то не знать или не сможет сказать нет, когда именно этот ответ ожидает команда. Это говорит о незнании этики команды тем, кто обладает более высокими полномочиями и делает этот срочный запрос.

Можно выделить два типа трудностей:

✓ добавление работы вне бэклога,

✓ выход участника из команды на какое-то время.

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

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

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

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

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

План спринта корректируется не только в случае перечисленных сложностей и изменений, но и по завершении задач и историй.

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

Частота: каждый день спринта.

Длительность: менее четверти часа.

Во сколько: это выбирает сама команда. Чаще всего, схвака происходит утром: это отличный способ начать рабочий день. Далее в этой главе мы будем рассматривать именно такой вариант схватки – проходящей утром.

Описать схватку очень легко. Это встреча, во время которой все участники команды отвечают на три простых вопроса: что было сделано? что будет сделано? с какими препятствиями они столкнулись?

Прочитав это описание, вы можете ошибочно подумать, что речь идет о проверке работы команды.

Фактически же схватка ускоряет достижение цели спринта. Схватка – это форма инспекции и адаптации на каждый день.

✓ Инспекция – просто выслушивание того, что говорят участники.

✓ Адаптация закрепляет собрания или обсуждения в распорядке дня. В ходе этих мероприятий команда может устранить препятствия или завершить истории.

В этом собрании принимает участие вся команда, включая Владельца продукта.

Scrum-мастер является гарантом проведения схватки и соблюдения всех правил.

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

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

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

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

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

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

Рисунок 10.4 – Команда плывет по течению к цели спринта

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

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

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

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

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

Вспомним, что цель спринта состоит из двух частей:

✓ цель, касающаяся продукта, определенная во время планирования спринта,

✓ цель, касающаяся процесса (кайдзен), выявленная во время ретроспективы.

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

• Польза индикаторов

Следует ли полагаться на индикаторы для выявления отклонений?

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

✓ burndown-график задач,

✓ burndown-график историй.

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

Индикаторы предназначены исключительно для пользования команды.

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

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

Устраненные препятствия сохраняются до конца спринта: список препятствий полезен во время ретроспективы (см. главу 12).

Команда объединяется.

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

✓ Основываясь на этой информации, команда адаптируется и самоорганизуется, чтобы устранить препятствия и достичь цели спринта.

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

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

Рассмотрим случай, когда схватка проводится в начале рабочего дня.

• Поделиться тем, что было сделано

Каждый участник отвечает на первый вопрос:

что я вчера сделал для достижения цели спринта?

Все рассказывают, над какими задачами вчера работали, делятся успехами.

• Рассказать, что будет сделано

Каждый участник отвечает на второй вопрос:

чем я займусь сегодня для достижения цели спринта?

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

Рисунок 10.6 – Изменения таблицы (история скоро будет завершена)

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

• Выявить препятствия

Каждый участник отвечает на третий вопрос:

вижу ли я какие-то препятствия, которые мешают мне или команде достигнуть цель спринта?

Участники не дожидаются схватки, чтобы поделиться обнаруженным препятствием – здесь речь скорее о выявлении сомнений и менее явных препятствий. Scrum-мастер должен разобраться, какие реальные трудности стоят за этими сомнениями.

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

Если у участников есть предполагаемые решения, скорее всего, команда пустится в обсуждение, а схватка – не время для этого. Scrum-мастер должен остановить дискуссию и предложить продолжить ее позднее в течение дня.

В регби схватка происходит после нарушения и является способом возобновить игру. Ежедневная схватка в Scrum точно так же позволяет команде возобновить работу и синхронизироваться, настроившись на цель спринта.

С собранной в рамках схватки информацией об историях и препятствиях участники приобретают объективные знания о прогрессе команды. Адаптация проявляется в том, что команда пересматривает самоорганизацию для достижения цели спринта.

Паттерн история рассказывает себя сама в некотором роде соответствует молу [37] по отношению к схватке при игре в регби: активное участие зависит от ситуации на поле в данный момент.

Этот способ работы адаптирован для команд, применяющих паттерн роения (см. главу 9 «Планирование спринта»). Отличие разве что в ответе на три вопроса.

• История рассказывает себя сама

При этом подходе три вопроса задаются не каждому участнику команды, а каждой истории, находящейся в процессе.

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

Затем команда переходит к следующей истории. Таким образом, обсуждаются все истории, которые находились в работе с момента последней схватки.

Рисунок 10.7 – Команда соблюдает порядок историй в соответствии с таблицей

• Распределение историй

Истории распределяются между участниками команды. Когда кто-то завершил задание, возникают вопросы, которые обсуждаются коллективно: останется он работать над этой историей, присоединится к завершению другой или, может, возьмется за новую историю?

Продолжение схватки совпадает с классическим подходом.

• Риски и преимущества

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

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

Ситуация. Scrum-мастер следит за индикаторами и прогрессом команды, но в пылу работы команда совершенно забывает о цели спринта.

Последствия. Потеря фокуса команды, все сидят по углам и работают над чем-то своим.

Как сделать лучше? Обеспечить наглядность цели, написав ее на доске. Направлять команду к достижению цели при помощи трех вопросов.

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

Последствия. Команда теряет время.

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

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

Ситуация. Команда отчитывается перед Scrum-мастером, как перед руководителем.

Последствия. Утрата инициативности. Во время схватки Scrum-мастер становится руководителем проекта.

Как сделать лучше? Участникам следует обращаться ко всей команде, а не только к Scrum-мастеру. Распределение задач – это дело всей самоорганизующейся команды, а не Scrum-мастера. В данном случае он – только для поддержки.

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

Ситуация. Для создания красивого burndown-графика каждый участник делится, сколько времени он провел над выполнением задач.

Последствия. Потерянное время.

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

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

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

Последствия. Команда не заряжается необходимой энергией в начале рабочего дня. Работа превращается в рутину.

Как сделать лучше? Scrum-мастер (или любой участник группы) может предложить варианты проведения схватки.

✓ Все высказываются по очереди слева направо, справа налево и т. д.

✓ Каждый отвечает на три вопроса сразу, а на следующий день – на каждый вопрос по очереди.

Для сплочения команды можно использовать аксессуары:

✓ музыка, оповещающая участников о начале схватки;

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

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

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

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

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

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

Обзор касается результатов работы команды во время спринта. Это двухсторонняя коммуникация между командой и заинтересованными сторонами.

Обзор проходит в последний день спринта. За ним идет ретроспектива. Продолжительность обзора зависит от продолжительности спринта.

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

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

Вся Scrum-команда участвует в собрании. Модератором встречи выступает Владелец продукта. При этом настоятельно рекомендуется участие заинтересованных сторон.

В случае, если присутствуют заинтересованные стороны, это Scrum-событие является самым крупным по количеству участников. Обзор – событие для всех, входящих в экосистему. И это мероприятие является отличной возможностью вовлечь их в обсуждение и принятие решений о будущем продукта.

Команда довольна, что показала качественный результат. Заинтересованные стороны убедились, что все работает, и обсудили продукт.

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

Рисунок 11.1 – Момент обмена результатами

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

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

Вот возможная цепочка действий для данного собрания.

✓ Перед началом обзора команда готовит необходимое для успешного проведения демонстрации.

✓ Владелец продукта начинает собрание с цели спринта.

✓ Для каждой завершенной истории команда осуществляет демонстрацию и собирает обратную связь.

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

• Логистика

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

Если участники не могут присутствовать, можно использовать видеосвязь.

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

• Репетиция

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

Во время демо будут представлены только завершенные истории, никаких наполовину завершенных и почти завершенных! Это возможность избавиться от окончательных сомнений.

• Техническая работа

Техническая работа предназначена для команды, не для заинтересованных сторон. Обзор этой части будет проходить внутри команды.

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

В таком случае, это можно запланировать на утреннюю часть обзора, чтобы не забыть в пылу окончания спринта.

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

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

Владелец продукта показывает список историй. Он может использовать Post-it® для обозначения тех, что были завершены в данном спринте.

Команда представляет инкремент при помощи поочередной демонстрации историй.

• Кто проводит демо?

Демонстрацию может провести наиболее вовлеченный разработчик. Риск в данном случае заключается в отсутствии однородности презентации. Некоторые разработчики докладывают слишком быстро для аудитории пользователей. Если для истории применялся паттерн роения, все участники отвечают за демонстрацию своей истории.

Докладчиком может выступить Владелец продукта: он отлично знает, как взаимодействовать с заинтересованными сторонами.

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

• Подготовка сценария

Демонстрация – это не маркетинговая презентация со всей мишурой и не скоростное прохождение тестов.

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

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

Все запросы и комментарии помещаются в песочницу.

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

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

Рисунок 11.2 – График скорости команды

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

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

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

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

Обзор преследует две цели:

✓ собрать обратную связь,

✓ принять решение о будущем продукта.

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

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

Чтобы оптимизировать участие, можно применить паттерн обзор в трех частях:

1) внутренний обзор, предназначенный исключительно для Scrum-команды (зоны 1 и 2),

2) внешний обзор с участием пользователей и/или их представителей (все зоны, в особенности 4 и 5),

3) обзор для руководства (зоны 2 и 3).

Каждая из частей длится не более часа.

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

✓ демонстрацию пользовательских историй, репетицию того, что будет показано во время внешнего обзора;

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

✓ первое обсуждение цели следующего спринта.

Он состоит из следующих шагов:

✓ обозначить цель,

✓ провести демонстрацию,

✓ собрать обратную связь.

Эта часть включает в себя:

✓ оценку влияния,

✓ решение о будущем продукта.

Рисунок 11.3 – Будущее продукта

Такой способ проведения обзоров имеет свои плюсы:

✓ внешний обзор становится короче и эффективнее, с фокусом на демо;

✓ обратная связь от команды собирается даже до проведения демо;

✓ пересматривается не только завершенное, но готовое;

✓ техническая работа подробно изучается теми, кому она предназначена;

✓ у PO и SM есть время на подготовку индикаторов к обзору для руководства.

Наконец, разделение на части предлагает возможность провести ретроспективу между внутренним обзором и внешним обзором. Это иногда более практично с организационной точки зрения.

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

Последствия. Изменения могут вызвать регрессию.

Как сделать лучше? Не рекомендуется вносить никаких изменений в код в последний момент.

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

Последствия. Заинтересованные стороны растеряны и теряют доверие к команде.

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

Рисунок 11.4 – Команда показывает только то, что завершено

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

Последствия. Теряется фокус на продукт.

Как сделать лучше? Для заинтересованных сторон важен именно продукт с историями, которые он содержит.

Способы работы команды – предмет обсуждения во время ретроспективы, а не обзора.

Ситуация. Команда забывает пригласить заинтересованные стороны. Обзор протекает в границах Scrum-команды.

Последствия. Теряется интерес к проведению обзора.

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

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

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

Можно напомнить приглашенным лицам, что это незавершенный продукт и что другие функции будут добавлены позднее. Хороший способ сделать это – представить kanban-таблицу функциональностей.

Ситуация. Увлеченные демонстрацией, участники Scrum-команды забывают запросить обратную связь.

Последствия. Отсутствие обратной связи.

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

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

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

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

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

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

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

Scrum – это не процесс. Однако ретроспектива – это улучшение процесса. Не противоречит ли одно другому?

Нет! Процесс не навязывается команде. Это команда создает процесс, основываясь на структуре, предложенной Scrum, особенно во время ретроспективы.

Термин ретроспектива в основном используется в художественной сфере, чтобы расположить творения создателя в хронологическом порядке: вот телеканал «France 3» этим летом предлагает для зрителей ретроспективу Хичкока, или в газете «La Dépêche» появляется статья о ретроспективе Сауры в музее Les Abattoirs. Часто ретроспектива посвящена шедеврам тех, кого уже нет в живых…

Рисунок 12.1 – Спесивый (высокомерный) Scrum-мастер выставил burndown-графики в экспозиции-ретроспективе своих спринтов

Во время ретроспективы команда задается вопросами о том, как она поработала во время прошедшего спринта. Это один из столпов эмпирического подхода – инспекция, ведущая к адаптации. В данном случае, в отношении окончившегося спринта.

Ретроспектива позволяет извлечь выгоду из применяемых практик, чтобы избежать повторения одних и тех же ошибок, обмениваться различными точками зрения и адаптироваться ко всевозможным новшествам (например, технологиям, используемым для разработки, или Agile-техникам).

Ретроспектива – это момент в конце спринта, когда команда останавливается, размышляет и рассуждает о своем опыте.

Как говорил Жебе (прим. пер.: Жорж Блондо, французский художник) в комиксе «Год 01»: мы останавливаемся и думаем.

Рисунок 12.2 – Необходимость в ретроспективе

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

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

Ретроспектива проводится сразу за обзором – но уже без участия заинтересованных сторон: собрание проводится в максимально доверительной и комфортной среде.

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

Ретроспектива дает участникам возможность узнать, как улучшить работу: кто вносит вклад в результат, лучше знает, как дальше развиваться. Цель ретроспективы – коллективное обучение, а не поиск виноватых.

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

Напоминание об общих ценностях усиливает командную этику.

Команда может оценить уровень своей удовлетворенности. Это важный показатель здоровья команды.

Команда заканчивает ретроспективу нацеленной на улучшение в рамках будущего спринта.

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

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

Вот логичная цепочка действий во время собрания.

✓ Модератор, обычно это Scrum-мастер, убеждается, что окружающая среда способствует выражению мнения каждого участника команды.

✓ Команда собирает все данные по прошедшему спринту.

✓ Затем она выявляет области для улучшения работы.

✓ Она отбирает то, что будет улучшено в будущем спринте и определяет цель.

✓ Она пересматривает свои ценности и практики для адаптации Scrum в будущем спринте.

Речь идет о том, чтобы каждый чувствовал себя уверенно и мог свободно говорить во время ретроспективы. Чтобы коллективная рефлексия была доброжелательной, Scrum-мастер напоминает о первом принципе: каждый сделал все возможное для успеха спринта.

Рисунок 12.3 – Напоминание правил

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

Перед тем как продолжить, Scrum-мастер напоминает, какие области были запланированы к улучшению во время прошлой ретроспективы, и объективно оценивает, была ли выполнена цель. Очень важно показать команде: что-то изменилось! Это придает ей желание дальше развиваться и предлагать новые идеи для улучшения.

• Внешний фасилитатор

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

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

Делать этого не стоит: ретроспектива дает команде возможность избежать худшего. Взгляд со стороны может помочь в выявлении основных проблем команды.

• Смена целей ретроспективы

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

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

Основной подход – задать каждому участнику три вопроса, что несколько похоже на ежедневную схватку (глава 10).

✓ Что хорошо сработало?

✓ Что было нехорошо?

✓ Что мы можем улучшить?

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

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

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

Затем все события комментируются в соответствии с их восприятием участниками команды: приятные, разочаровывающие, раздражающие…

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

Команде важно собрать конкретные данные, которые ей помогут в будущем спринте.

Информация, собранная на предыдущем этапе, дополняется идеями по улучшению, которые предлагают участники команды.

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

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

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

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

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

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

Что касается идей по улучшению, определенных, но не отобранных для следующего спринта – их надо сохранить. Например, сфотографировать то, что было зафиксировано на Рost-it®.

По окончании ретроспективы команда возвращается к основным моментам Scrum. Вот вопросы, которые участники могут обсудить:

✓ ценности команды, приверженность коллективной этике,

✓ соответствие предназначения команды и экосистемы,

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

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

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

Здесь все просто. Лучший художник в команде рисует морскую звезду. Ее пять лучей соответствуют пяти зонам: продолжить, больше, меньше, начать, прекратить.

У участников есть несколько минут, чтобы обдумать, что можно поместить в каждую из этих зон. Рефлексия индивидуальна и протекает в тишине, пока каждый из участников не написал хотя бы 3 post-it (что именно должно быть написано, указано ниже).

Затем все по очереди помещают свои post-it на соответствующие лучи звезды, проговаривая вслух, что они имеют в виду. Обсуждение открытое. После него команда переходит к отбору.

Рисунок 12.4 – Морская звезда при переходе к пермакультуре

Здесь 4 этапа.

1. Ай!

Каждый участник берет по каштану. Модератор собрания просит взять орех в левую руку (правую для левшей) и сжать кулак. Ай-яй, он колючий!

Это должно напомнить о болезненных моментах прошедшего спринта. Участники берут в другую руку маркеры и фиксируют эти мучительные, трудные моменты на Post-it®.

2. Ого!

Участники заглядывают внутрь скорлупки и изучают, что внутри. Они удивлены: под скорлупой орех красивый (если только он не гнилой).

Ого, какой же он красивый! Это моменты спринта, которые их удивили, приятно взволновали, все новое, что они узнали. Это надо записать на Post-it®.

3. Рррр!

Внутри скорлупок красивые орехи. Участники достают самый красивый и хотят его съесть. Чтобы добраться до мякоти, надо снять жесткую коробочку. Они пытаются содрать ее ногтями, разгрызть зубами. У них не получается, они злятся. Рррр!

Эта досада – все, что замедляло команду, мешало ей на пути к цели. И опять это необходимо зафиксировать на Post-it®.

4. Мммм!

Как только коробочку удается снять, перед участниками остается лишь мякоть, белая и нежная, которую можно съесть. Мммм, как вкусно! А, главное, сытно.

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

Рисунок 12.5 – Четыре этапа ретрокаштана

Затем команда переходит к группированию и отбору.

Эта игра, называемая Speed boat, или скоростной катер, – одна из Innovation Games, используемой для сбора чувств и эмоций пользователей продукта.

Кто-то из участников рисует катер, море и небо. Катер – это команда.

Вдали участник намечает порт, который означает цель команды (например, цель сезона).

Затем наступает момент рефлексии о пути команды к цели. Каждый участник фиксирует на post-it две вещи:

✓ якори, которые замедляют команду и расположены под катером,

✓ двигатели, которые продвигают команду к ее цели и расположены над катером.

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

Ситуация. Чтобы вся команда высказалась во время ретроспективы, Scrum-мастер опрашивает всех по кругу о том, что было хорошо во время спринта, а что – плохо.

Последствия. Рутина, ничего нового.

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

Ситуация. Команда предлагает идеи для улучшения, но спустя несколько спринтов понимает, что ничего толком не изменилось.

Последствия. Нет ничего более досадного для команды, чем видеть, что ничего не меняется.

Как сделать лучше? Scrum-мастер должен убедиться, что все идеи для улучшений реализуются на практике.

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

Ситуация. При обсуждении проблем кто-то из участников был признан виновным.

Последствия. Ухудшение атмосферы внутри команды.

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

Рисунок 12.6 – Ретроспектива не должна превращаться в сведение счетов

Ситуация. Во время ретроспективы все открыто высказываются. Но комментарии участников – это негативная критика.

Последствия. Команда подавлена.

Как сделать лучше? Цель – улучшение работы команды, поэтому сбор данных касается в основном моментов, которые прошли не совсем хорошо, не так хорошо, как могли бы.

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

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

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

Последствия. Неустойчивая экосистема.

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

Чтобы идти дальше

Онлайн-ресурсы

‣ Corinna Baldauf, «Retromat», Web

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

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

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

И тем не менее, нулевого спринта не существует.

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

А в Scrum самое важное – это люди.

В чем мы сейчас и убедимся.

Нет такого понятия, как нулевой спринт. Такой термин отсутствует в Руководстве по Scrum Швабера и Сазерленда.

Почему мы тогда о нем говорим?

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

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

Прелюдия – то, что подготавливает, предваряет и начинает. Она готовит команду и ее экосистему, предваряет Scrum и начинает цикл спринтов и сезонов.

Рисунок 13.1 – Прелюдия

Прелюдия к Scrum – время между решением внедрить Scrum и началом первого спринта.

Решение обычно сопровождается поручением руководства кому-то из сотрудников заняться подготовкой к внедрению Scrum.

Прелюдия завершается, когда достигнуты результаты, перечисленные выше. До тех пор можно ее продлевать. Еще, конечно, можно сдаться и не внедрять Scrum в этих условиях.

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

1. жизнеспособная Scrum-команда,

2. Scrum-команда в согласии с заинтересованными сторонами,

3. жизнеспособная экосистема.

Все по-разному выходят на этап прелюдии – зависит от того, что было ранее. Это во многом объясняет и разницу в продолжительности прелюдии.

Вот несколько возможных вариантов.

✓ Ранее применялся Lean Startup, но, чтобы начать использовать MVP, было решено перейти к Scrum. Небольшая группа, которая вела работу, стала ядром Scrum-команды.

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

✓ Решение о переходе к Scrum было принято после кризиса в проекте, который запущен давно. В этом случае команда более или менее сформирована.

✓ Это совершенно новый проект с новой для организации командой, для нее Scrum не в новинку.

Факторы, влияющие на продолжительность прелюдии:

1. существование команды до прелюдии,

2. степень понимания продукта и ожиданий пользователей,

3. уровень знания Scrum будущими участниками команды и заинтересованными сторонами, а также их настрой,

4. необходимые действия для контекстуализации [40] Scrum.

Чем больше у команды опыт, тем меньше проблем будет во время прелюдии. Желательно, чтобы она длилась неделю-две, не более месяца – в худшем случае.

Шаблон – это практика обмена элементами, необходимыми для принятия коллективного решения. Вот шаблон, который я предлагаю для прелюдии:

Рисунок 13.2 – Шаблон прелюдии

Шаблон заполняется во время прелюдии и в установленном порядке. Заполнение подразумевает три больших последовательных этапа:

✓ первый, чтобы убедиться в жизнеспособности Scrum-команды (1, 2),

✓ второй – убедиться, что Scrum-команда находится в согласии с заинтересованными сторонами (3, 4, 5, 6),

✓ и последний, чтобы убедиться в жизнеспособности экосистемы (7, 8, 9, 10).

Мы уже разобрали, что означает готовый бэклог, и в главе 15 подробно рассмотрим, как команде к нему прийти в первый раз.

Короче говоря, к концу прелюдии необходимо иметь:

✓ список функциональностей на сезон (3–4 месяца),

✓ достаточно готовых историй к первому спринту.

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

Это позволит понять, насколько экосистема жизнеспособна.

• Участники Scrum-команды (графа 1 в шаблоне)

Создание команды – в первую очередь, так как все дальнейшие действия выполняются уже при наличии сформированной команды.

Рисунок 13.3 – Действия во время прелюдии

Мы не будем обсуждать, как подбирать команду. Участниками могут быть только те, у кого есть время и желание пуститься в это приключение, потому что нельзя заставлять людей входить в состав Scrum-команды против их воли. Приглашать их куда более уместно.

В главах 3–5 мы уже рассмотрели роли участников Scrum-команды, Владельца продукта и Scrum-мастера.

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

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

• Командная этика (графа 2 в шаблоне)

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

Я предлагаю оперировать таким понятием, как командная этика.

Командная этика полезна с точки зрения эффективности команды. В долгосрочной перспективе она способствует мотивации участников и их обучению [41].

Так как начинающие участники, как правило, не способны определить для себя понятие командной этики, я предлагаю рассмотреть ее на примере чего-то более универсального – пермакультуры.

Забота о нашей планете

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

Забота о людях

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

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

Обмен результатами

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

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

• Оценка жизнеспособности Scrum-команды (на основе граф 1 и 2)

Жизнеспособность команды подразумевает, что каждый из участников:

✓ добровольно отправился в это приключение,

✓ нашел свою нишу, то есть, роль, которая полностью его удовлетворяет и приносит пользу команде,

✓ придерживается этики команды и поддерживает ее самобытность,

✓ вовлечен в работу команды на определенное время.

Рисунок 13.4 – Команда тестирует свою жизнеспособность

Как убедиться в том, что команда достигла этого во время прелюдии? Спрашивая непосредственно у участников команды.

✓ Если окажется, что потенциальный участник команды не придерживается коллективной этики, ему лучше покинуть группу.

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

✓ Если жизнеспособность команды подтверждается, участники продолжают. Но мы уже знаем, что Scrum-команда не одинока.

• Экосистема

В системологическом подходе прелюдия является отличным моментом, чтобы задать себе главный вопрос – почему? – и подумать о месте команды в экосистеме.

Недостаточно просто создать команду, ведь ее окружают заинтересованные стороны.

Заинтересованные стороны: пользователи, клиенты – в общем, те, кого волнует продукт, реализуемый Scrum-командой. Они являются частью экосистемы, которая помимо самой команды включает продукт и его использование.

• Заинтересованные стороны (графа 3 в шаблоне)

Команда составляет список заинтересованных сторон, желательно при их участии. Для идентификации значимости заинтересованных сторон можно использовать модель Митчелла.

Рисунок 13.5 – Характеристики заинтересованных сторон

Модель основываеся на наличии у заинтересованных сторон трех характеристик, раскрывающихся в их общении с командой:

✓ власть, способность навязать свою волю,

✓ срочность, субъективное убеждение в том, что их просьба является срочной,

✓ знания, легитимность и признание другими их компетенций и действий. Мы называем это знаниями, так как заинтересованная сторона – потенциальный эксперт, о котором мы говорили в главе 3.

Человек может обладать сразу несколькими характеристиками.

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

Это упражнение по соотнесению характеристик позволяет составить список заинтересованных сторон и выявить их значимость в отношениях с командой.

• Scrum, охватывающий заинтересованные стороны (графа 4 в шаблоне)

Во время прелюдии встает вопрос о знании Scrum заинтересованными сторонами и об их вовлеченности в развитие экосистемы.

В зависимости от уровня их осведомленности следует организовать обучение.

Говоря о характеристиках, необходимо:

✓ обучить заинтересованные стороны – по меньшей мере тех, кто обладает одновременно двумя или тремя характеристиками,

✓ снизить риски в отношении тех, кто обладает характеристиками власти или срочности,

✓ усилить роль тех, кто обладает характеристикой знания, и обеспечить их доступность.

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

• Предназначение экосистемы (графа 5 в шаблоне)

Термин (эволюционного) предназначения пришел из холакратии [42]. Его подхватил Фредерик Лалу в своей книге «Переосмысление организаций»[43] и привел в качестве одного из трех понятий, необходимых для достижения статуса бирюзовой компании – другими словами, последней и наиболее успешной стадии организации.

В работах Лалу предназначение относится к однородному обществу внутри единой организации.

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

Презназначение экосистемы Peetic состоит в повышении благосостояния владельцев животных.

• Контекстуализация Scrum (графа 6 в шаблоне)

Мы поговорим о контекстуализации в главе 14. При работе над шаблоном команда обменивается наиболее важными для экосистемы аспектами:

✓ предполагаемая продолжительность спринтов и сезонов,

✓ предполагаемые день и время Scrum-событий,

✓ адаптация Scrum-практик с учетом контекста,

✓ другие практики, используемые в Scrum-формате.

• Оценка баланса между командой и экосистемой

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

Это позволяет влиять на содержание продукта, вводя функциональности, соответствующие командной этике.

Рисунок 13.6 – Согласование командной этики с предназначением

Прежде чем идти дальше, изучим, что находится в графах 3, 4, 5 и 6 шаблона. Графа 6 напоминает заинтересованным сторонам, в чем заключается их участие в Scrum, и то, что они гарантируют свою доступность во время спринта.

Одна из задач прелюдии – укрепление хороших отношений между командой и заинтересованными сторонами. Если это невозможно, применение Scrum неприемлемо.

Успешная прелюдия должна помочь согласовать командную этику с предназначением экосистемы.

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

✓ продолжить, осуществив переход к следующему этапу,

✓ завершить этап, добившись согласия,

✓ остановиться, если команда не на одной волне,

✓ выход отдельных лиц из команды или из списка заинтересованных сторон по соображениям совести [44].

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

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

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

В главе 15 представлены способы создания первоначального бэклога, составленного из историй. Необходимые для этого инструменты (impact mapping и story mapping) могут использоваться в прелюдии. Все зависит от возможностей команды.

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

• Среда разработки (графа 7 в шаблоне)

Следует организовать среду разработки и обучить участников команды работе с новыми инструментами.

• Понятные правила игры (графа 8 в шаблоне)

Участники команды, которые будут вместе играть в Scrum, придерживаются одних правил. На этапе прелюдии это вопрос согласования, чтобы можно было начать, а в дальнейшем команда может менять эти правила.

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

Примеры правил команды:

✓ способ принятия решений,

✓ список собранных данных в конце спринта, метрики,

✓ способ работы со срочными задачами (и в целом понятие срочности для команды).

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

• Рабочие зоны (графа 9 в шаблоне)

Что такое рабочие зоны, мы узнали в главе 3. Они создаются именно во время прелюдии.

Очень важно сразу определить зоны 1–3, чтобы облегчить наиболее важное общение и обмен:

✓ Зона 1 – это рабочее пространство для участников команды,

✓ Зона 2 также принадлежит команде, в ней проводятся такие события, как схватка,

✓ Зона 3 создана для встреч с наиболее важными заинтересованными сторонами.

• Критерии завершенности (графа 10 в шаблоне)

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

Во время прелюдии команда разрабатывает первые критерии завершенности.

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

• Команда, способная к производству

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

Для производства необходимы ресурсы: материалы, среда, позволяющая разрабатывать, интегрировать, тестировать, и т. д.

Чтобы доказать, что она способна, лучшее – продемонстрировать это на простом примере. Участники выбирают одну из историй в бэклоге и работают над ней.

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

• Оценка жизнеспособности экосистемы

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

Решение о том, что делать дальше, принимается на этом совещании:

✓ все отлично, можно приступать к спринту 1,

✓ нет, продолжать в этих условиях нецелесообразно.

Рисунок 13.7 – Экосистема жизнеспособна!

Прелюдия необходима при создании или перевороте экосистемы, когда появляется новая команда или новые заинтересованные лица. Понятие нового субъективно. Можно, как вариант, опираться на треть обновленного коллектива.

Прелюдия, само собой, проводится при создании команды. Но она возможна при устоявшейся команде и новых заинтересованных сторонах. Или если команда завершила работу над одним продуктом и приступила к другому и в другой области, где и заинтересованные стороны тоже будут другими.

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

Мы уже видели, что в экосистему могут входить люди из разных организаций. Например, клиент, который заключил контракт с фиксированной ценой с компанией-разработчиком ПО (о влиянии на Scrum можно прочитать в главе 14).

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

Бывает ли прелюдия, в которой одновременно участвуют несколько Scrum-команд?

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

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

Мы детальнее узнаем о работе в формате Scrum несколькими командами в главе 21.

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

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

Как сделать лучше? Приоритизировать, базируясь на рисках. Устранить наиболее значительные технические риски в спринте 1.

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

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

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

Ситуация. Переход к Scrum осуществлен, но руководство, как обычно, требует детальный план работы, начиная с прелюдии.

Последствия. Команда теряет время на бессмысленные расчеты. Не получается оценить производительность команды во время прелюдии.

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

План на среднесрочную перспективу не фигурирует в списке ожидаемых результатов прелюдии.

Если просьба очень настойчивая, смотреть главу «Планирование на среднесрочную перспективу».

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

Последствия. Команда не согласована с экосистемой.

Как сделать лучше? Разрабатывать шаблон прелюдии сообща.

Чтобы идти дальше

Книги

‣ Frederic Laloux, «Reinventing Organizations», Diateino, 2017

Онлайн-ресурсы

‣ Joshua Kerievsky, Modern Agile

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

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

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

Рисунок 14.1 – Фреймворк Scrum адаптирован и наполнен

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

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

В то время как Agile-ценности и принципы являются универсальными, практики варьируются в зависимости от ситуации.

Scrum насчитывает около пятнадцати практик, которые, грубо говоря, соответствуют главам этой книги:

✓ Роли: Владелец продукта, Scrum мастер, самоорганизующаяся команда.

✓ События: спринт, доработка бэклога, планирование спринта, схватка, обзор спринта, ретроспектива.

✓ Артефакты: результат спринта, бэклог, план спринта, список препятствий.

✓ Критерии готовности и завершенности.

Являются ли они обязательными? Ответ неоднозначен и часто становится причиной споров. Поскольку Scrum – это не более чем фреймворк, я считаю, что Scrum-практики должны быть обязательными (как первая ступенька в Shu Ha Ri), а способ их реализации уже может меняться в зависимости от контекста.

Термин паттерн, употребляемый в разных областях, очень близок к понятию практики.

В Scrum паттерн может использоваться при применении той или иной практики. Некоторые из них мы уже рассмотрели в предыдущих главах, например, роение или 6К.

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

Также в конце каждой главы можно ознакомиться со списком антипаттернов.

Очень важно не попасть в ситуацию применения какого-либо из антипаттернов.

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

Юрген Аппело, опираясь на восемь разных источников, попытался собрать известные практики в своем блоге «The Big List of Agile Practices».

Во Франции «l’Institut Agile» опубликовал список из шестидесяти Agile-практик и составил карту, которая дает представление об их происхождении [45].

Классифицировать практики можно разными способами – например, в зависимости от определенных характеристик.

✓ Происхождение практики, то есть, на основе какого подхода она появилась (Scrum, XP, Kanban, и т. д.).

✓ Действия или области разработки (архитектура, написание кода, тестирование и т. д.).

Практики, регулярно дополняющие Scrum, представлены в трех категориях:

• Для определения продукта

Если Scrum применяется при создании нового продукта, желательно добавить в него практики, упрощающие первоначальное составление бэклога. В следующих главах мы коснемся таких практик как impact mapping, story mapping, пользовательская история и приемочные тесты.

• Для управления проектом

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

• Для разработки ПО

Сегодня внедрение Scrum в основном ориентировано на разработку программного обеспечения. Но Scrum не подразумевает использование конкретных техник инжиниринга для разработки, а оставляет выбор за командой. В этом основное отличие от Экстремального Программирования, которое предлагает использование определенных методов разработки ПО.

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

Разработка вписывается в рамки одной или нескольких организаций. У организации есть культура, ноу-хау – другими словами, условия, влияющие на проекты, в которых будут внедряться Scrum и Agility. Очевидно, процесс будет сложнее в компаниях, чьи ценности и принципы далеки от перечисленных в Agile-манифесте.

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

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

Scrum-мастер, как гарант Scrum, играет ключевую роль в контекстуализации. Если он в этом новичок, он может обратиться за помощью к консультанту, называемому Agile-коучем.

Команда также приглашается к участию.

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

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

Во время первого Agile tour в Тулузе в 2008 мы с Филиппом Крухтеном представили ситуационную Agility.

Идея в том, что контекст разработки может быть определен при помощи нескольких характеристик. Мы предложили модель, основанную на работах Филиппа.

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

Рисунок 14.2 – Характеристики для определения контекста проекта

В этом разделе речь не о пригодности или непригодности Scrum для того или иного контекста с его основными характеристиками.

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

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

Адаптация – это про паттерны, представленные в главах с 1 по 12; дополнение – это про пракики, которые будут рассмотрены в главах с 15 по 22.

За перечисленными паттернами и антипаттернами следует номер главы, в которых они представлены.

Характеристики относятся к области, в которой разрабывается продукт.

• Динамика изменения

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

Возможность изменений во время разработки – зачастую есть фактор перехода к Agility. Люди часто думают: по правде говоря, мы не особо понимаем, что хотим, но думаем, что это изменит что-то в процессе разработки. Традиционный подход не работает, попробуем Аgile.

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

Поэтому важно, чтобы динамика изменений была высокой.

Высокая динамика изменений

✓ Попробовать паттерн: ограничение в процессе (20)

✓ Избегать антипаттерны: бэклог тикетов (6), планирование vs доработка (9)

✓ Дополнительная практика: применение Kanban в Scrum (20).

• Критичность

В случае сбоя программного обеспечения на кону могут стоять люди и экономика.

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

Высокая критичность

✓ Попробовать паттерны: эксперт внутри границ (3), сториотип (6)

✓ Избегать антипаттерны: цикл по V-модели (2), границы и зависимости (7), возвращение к начальному проектированию (13)

✓ Дополнительная практика: все инженерные практики (глава 19) – в частности, те, что касаются тестирования; планирование на среднесрочную перспективу, чтобы предвосхитить аудиты.

• Развертывание

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

Число развернутых экземпляров варьируется от одного до нескольких миллионов.

Единичное развертывание

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

✓ Попробовать паттерны: сезонный ритм (2), 6К (7).

✓ Избегать антипаттерны: искажение по незнанию (14), Dark Scrum (14).

✓ Дополнительная практика: продолжительное развертывание (19).

Многократное развертывание

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

✓ Попробовать: критерии завершенности (9), цикл по V-модели (2).

✓ Дополнительная практика: планирование на среднесрочную перспективу (20) для синхронизации со всеми людьми, вовлеченными в цепочку создания ценности.

Характеристики зависят от команды разработчиков.

• Масштаб проекта

Масштаб проекта соответствует количеству вовлеченных в него людей. Идеальный размер команды – от пяти до девяти человек. Однако по результатам опроса, который я провел в июне 2013 года, 10 % команд состоят из 1–3 человек, и примерно столько же – из 10 и больше.

Несколько команд

При количестве человек от 10 и более следует создавать несколько Scrum-команд.

✓ Попробовать паттерн: бэклог поставки/рабочий бэклог (6).

✓ Избегать антипаттерны: фокус на скорость команды (16), неоконсерваторы (21).

Глава 21 посвящена применению Scrum несколькими командами.

Маленькая команда

Практика показывает, что применение Scrum возможно в небольших командах при количестве участников менее четырех.

✓ Попробовать паттерн: вращающийся Scrum-мастер (5).

✓ Избегать антипаттерны: Scrum-мастер – разработчик (5), призрачная работа (6).

• Кроссфункциональность команды

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

Scrum-команда – сами участники или с привлечением экспертов – должна делать все необходимое для получения продукта к концу спринта. Если она не приходит к ожидаемым результатам, она не кроссфункциональна.

Слабо кроссфункциональная команда

✓ Попробовать паттерн: эксперт внутри границ (3), 6К (7) – с целью минимизации рисков.

✓ Избегать антипаттерны: специалисты (3), недоступные эксперты (3), улучшение других (12).

✓ Дополнительные практики: парное программирование (19) и вообще работа в паре с целью обучения.

• Географическая разобщенность

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

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

Удаленная работа

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

✓ Избегать антипаттерны: затянувшаяся схватка (10), контекстуализация при помощи инструментов (14), использование в одиночку (17).

Разобщенность, одна культура

Участники команды находятся в разных местах – возможно, даже разных странах. Но все говорят на одном языке и регулярно встречаются.

✓ Попробовать паттерны: лотки (6), работа (9).

✓ Избегать антипаттерны: смещенная стадия тестирования (2), цикл по V-модели (2), недоступный эксперт (3), Scrum-мастер – микро-шеф (5).

Разобщенность, разные культуры

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

Данные характеристики относятся к состоянию ПО, с которым работает команда.

• Архитектура

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

Если архитектура программного обеспечения нестабильна, это означает, что присутствуют технические риски. Лучше уменьшить их как можно скорее. При этом довольно сложно определить, что именно нужно для этого сделать.

Нестабильная архитектура

✓ Следовать практике, несмотря на все трудности: обзор спринта с проведением демо.

✓ Попробовать паттерны: бесконечный спринт (2), сториотип (6) с целью определения технических работ, разделение (7) – с целью декомпозиции историй.

✓ Избегать антипаттерны: архитектор в башне из слоновой кости (19).

• Возраст системы

Возраст определяется размером и качеством уже существующего кода в разрабатываемом ПО.

Scrum проще внедрить на новом программном обеспечении. Если продукт включает части существующего (устаревшего) кода, команда будет вынуждена продолжать работу с этим кодом более или менее хорошего качества и, возможно, с техническим долгом.

Устаревший код

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

✓ Дополнительные практики: практики из Экстремального Программирования (глава 19).

Характеристики относятся к компании или компаниям, в которых работает Scrum-команда.

• Экономическая модель

Иными словами, способ получения бюджета для разработки. Возможны разные контексты.

✓ Контракт клиент-поставщик: разработка основана на контракте с фиксированной ценой между заказчиком и компанией-разработчиком. Это, скорее всего, усложняет реализацию ряда практик. В еще большей степени это касается согласования ценностей и принципов.

✓ Open Source: те, кто работает над проектами с открытым исходным кодом, часто находятся в разных странах и вовлечены в разработку на условиях частичной занятости.

✓ Разработка внутренней командой требует наименьших усилий по адаптации. Это вариант издательств.

Контракт клиент-поставщик

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

✓ Попробовать паттерны: бэклог поставки/рабочий бэклог (6), так как необходимо установить связь между функциональностями и спецификациями, относящимися к тендеру; сезонный ритм (2) – для уточнения начала и конца действия контракта.

✓ Избегать антипаттерны: proxy РО (4), так как роль Владельца продукта должна быть на стороне заказчика и включена в команду, что часто оказывается довольно сложно реализовать и увеличивает риски успешной адаптации; приверженность под давлением (9), спринт под управлением цифр (9), участники прелюдии не участвуют в спринте 1 (13), измерение потраченного времени (18).

Open source

Поскольку команда работает неполный рабочий день, следует уточнить концепцию спринта; см. как применить Kanban в Scrum (глава 20).

Инженерные практики (19) позволяют команде работать удаленно.

• Управление

Речь о важности ограничений, наложенных организацией на жизненный цикл и отчетность проектов.

Легкое управление не требует особой адаптации.

Сильное и иерархичное управление

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

✓ Попробовать паттерны: сезонный ритм (2) и все, что представлено в главах о бэклоге (7 и 8).

✓ Избегать антипаттерны: цикл по V-модели (2) для сосуществования Scrum со стадиями и контрольными точками организации, чрезмерная трата времени на оценку (16), газовый завод (17).

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

Scrum-мастер вовлечен в обсуждение выбранных индикаторов.

Изучение характеристик проекта позволяет определить практики, которые нужно адаптировать.

Идеальный для перехода к Scrum проект должен обладать следующими характеристиками.

✓ Команда из семи человек, при этом все находятся в одном офисе.

✓ Новое ПО с известной архитектурой.

✓ Продукт с невысокой критичностью, который легко развертывается.

✓ Разработка происходит внутри команды, ее участники обладают необходимыми техническими компетенциями.

✓ Понимающее руководство.

Чем дальше характеристики проекта от вышеперечисленных, тем больше усилий необходимо приложить команде во время прелюдии.

Изображение ниже дает наиболее общее представление об усилиях, необходимых для адаптации.

Рисунок 14.3 – Контекст проекта

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

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

Scrum-мастер модерирует коллективную работу по контекстуализации и гарантирует применение и адаптацию Scrum.

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

Характеристики, определяющие контекст, меняются со временем. Некоторые (например, управление) могут за несколько месяцев приблизиться к центру графика, в то время как другие удаляются от него – как, например, размер команды (в том случае, если проект расширяется).

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

В этот момент можно определиться с новыми паттернами.

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

Это наглядно показывает модель Agile Fluency, которая использует бизнес-ценность (business value), производимую командой, чтобы определить, насколько она освоила Agility. На пути к Agile команда проходит через несколько зон.

Использование основных элементов Scrum соответствует первой зоне, практическое внедрение инжиниринга и критериев завершенности – второй зоне, практики по определению продукта вкупе с изменением культуры – третьей.

Мы вернемся к этому в главе 22.

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

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

Как сделать лучше? Scrum, и в частности, критерии завершенности, позволяют выявить проблемы – это одно из его главных преимуществ. Но усилия, необходимые для устранения технического долга, определяет сама команда.

Ситуация. Команда применяет практики в строгом соответствии с книжками и рассказами других.

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

Рисунок 14.4 – Обратите внимание на деконтекстуализацию: счастливый обладатель новенькой книжки сразу хочет применить все знания на практике

Как сделать лучше? Как мы убедились, что нет строгого, сугубо теоретического Scrum. Четко определен только фреймворк. Все проекты разные, отличаются контекстами и реализацией практик.

Ситуация. Команде не удается применить Scrum. Участники говорят себе, что не все получается сразу. Поэтому они внедряют Scrum постепенно, используют фрагменты разных практик. Исходя из принципа, что Scrum адаптируется, команда вводит в работу только то, что просто.

Последствия. Полученные результаты разочаровывают. Улучшения нет – особенно, если команда забывает или игнорирует ретроспективы.

Как сделать лучше? В Agility много опциональных практик, это правда, но Scrum – это цельный фреймворк, который нельзя разбивать на части и использовать только то, что удобно и просто.

Мы уже поговорили о Shu Ha Ri, и эту ситуацию можно резюмировать концепцией Shu, первой фазы:

Команда следует Scrum-практикам, фреймворк не подлежит обсуждению. Команда должна адаптировать практики под контекст.

Ситуация. Для сохранения бэклога команда использует информационные технологии. Scrum адаптируется к этим инструментам.

Последствия. Теряются все преимущества визуального управления.

Как сделать лучше? Нужно подождать несколько спринтов, прежде чем решить, действительно ли нужны эти инструменты.

Чтобы идти дальше

Онлайн-ресурсы

‣ Philippe Kruchten, The Context of Software Development, Web, 2009

‣ James Shore, Diana Larsen, Your Path through Agile Fluency, Web, 2018

Ранее мы изучили, как структурировать и регулярно дорабатывать бэклог. Бэклог – система из упорядоченных, взаимосвязанных элементов, постоянно пополняемая новыми записями и завершенными историями.

Этот механизм регулирования позволяет бэклогу развиваться на протяжении длительного времени и во благо экосистемы.

Однако бэклог не появляется сам по себе. Для его создания нужны определенные условия, регулирующие обратную связь.

В этой главе представлены идеи для разработки первоначального бэклога.

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

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

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

Рисунок 15.1 – Коллективная разработка первоначального бэклога

К этому моменту Scrum-команда уже должна быть сформирована и участвовать в совещаниях.

• Во время прелюдии

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

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

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

• В конце сезона

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

О сложности говорится в первом предложении Руководства по Scrum:

Скрам – это фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов.

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

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

• Цель сезона

Определенное во время прелюдии предназначение задает курс экосистемы, никак при этом не указывая на конкретные даты. Заинтересованные стороны также определяются бессрочно.

Для разработки первоначального бэклога нужно какое-то временное ограничение. Сезон – вполне премлемый отрезок времени.

• Воздействие

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

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

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

• Риск

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

Следовательно, понятие риска, функционального или технического, имеет важное значение при разработке первоначального бэклога.

Бэклог в первую очередь описывает поведение системы. Это ответ на вопрос что.

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

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

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

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

Рисунок 15.2 – Три новых понятия и рабочие совещания

• Цель и воздействие – помощники в понимании проблемы

На этапе прелюдии, а именно во время определения предназначения экосистемы, мы уже задавались главным вопросом почему. Мы также ответили на вопрос кто, определив заинтересованные стороны (см. главу о прелюдии).

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

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

• Решение, соответствующее проблеме

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

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

Таким образом, первоначальный бэклог зависит от рисков.

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

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

Представленные инструменты (impact mapping и story mapping) позволят добавить новые элементы и продемонстрировать новые взаимосвязи при помощи карт.

• Impact mapping

Impact mapping [Аджич, «Impact Mapping»] – это простая и эффективная техника стратегического планирования. Она помогает согласовать работу команды разработчиков с бизнес- целями. В этом уже одна из причин наличия Владельца продукта в Scrum-команде. Impact mapping позволяет пойти дальше и согласовать работу команды с поставленной целью.

Карта влияния – impact map – изображается в виде карты разума (mindmap), которая содержит следующие составляющие продукта:

✓ цель в центре карты;

✓ заинтересованные стороны на первом уровне;

✓ ожидаемое воздействие на втором уровне;

✓ наконец, функциональности, которые являются решениями для того или иного воздействия.

Рисунок 15.3 – Impact mindmap

Такая карта дает краткое и изящное представление о продукте.

• Story mapping

Story mapping – это практика, широко распространившаяся благодаря перу Джеффа Паттона.

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

Рисунок 15.4 – Частичный взгляд на story

Два аспекта, рассматриваемые при разработке карты – это последовательность (по горизонтали) и необходимость (по вертикали).

Рабочая встреча занимает от нескольких часов до одного дня – в зависимости от контекста.

Карта создается на стене, столе или прямо на полу с помощью Post-it®. Преимущество пространственного представления в том, что оно допускает коллективную работу. В процессе участвует вся команда.

• Взаимосвязи между элементами

Карты наглядно показывают множество видов взаимосвязей между элементами.

✓ Способствует (в обратном направлении достигается за счет). Пример: функциональность способствует воздействию (impact mapping).

✓ Предшествует (или следует в обратном направлении). Одна функциональность предшествует другой (story mapping).

✓ Состоит из. Функциональность состоит из историй.

✓ Важнее, чем. Одна история важнее другой для достижения цели.

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

✓ цель сезона,

✓ список функциональностей на сезон (3 месяца),

✓ достаточно готовых историй для первого спринта.

Эти элементы используются во время прелюдии. Проверяем, что экосистема согласована и возможен запуск первого спринта.

✓ Благодаря технике impact mapping команда, помимо цели, определяет воздействие на заинтересованные стороны.

✓ Результатом применения практики story mapping также является выявление рисков.

Существует множество путей к достижению результатов. Здесь мы не будем полагаться на Руководство по Scrum, которое ничего не говорит по данному вопросу. В него не включены ни инструменты, ни концепции, представленные в этой главе. Мы будем ориентироваться на системный подход, основанный на важнейших вопросах и опирающийся на такие инструменты, как impact mapping и story mapping.

✓ Для ответа на вопрос почему предлагается определить цель и ожидаемое воздействие на заинтересованные стороны.

✓ Для ответа на вопрос что определяются функциональности и истории для наполнения рабочего бэклога и бэклога поставки.

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

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

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

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

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

Можно сначала определить желаемое воздействие – и уже затем цель. Мой опыт показывает, что иногда так даже проще.

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

Цель для команды Peetic

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

– продавать 12 собачьих будок в месяц,

– продавать 20 тренингов от заводчиков в месяц,

– иметь 1000 подписчиков через месяц после запуска сайта.

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

Определение цели сезона позволяет всем участникам экосистемы достичь полного взаимопонимания и находиться на одной волне. Это необходимо для разработки первоначального бэклога.

Обсуждение касательно воздействия на заинтересованные стороны укрепляет взаимопонимание.

• На какие заинтересованные стороны?

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

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

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

• Выявление возможного воздействия

Здесь следует задать вопрос: какое значительное воздействие на жизнь заинтересованной стороны поспособствует цели сезона?

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

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

Рисунок 15.5 – Карта, включающая цель, участников и воздействие

• Измерение воздействия

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

• Приоритизация на основе воздействия

Не стоит разрабатывать карту воздействия по уровням, то есть, сначала определить все заинтересованные стороны, затем – воздействие на них и т. д.

Целесообразнее будет задумываться о воздействии только на те заинтересованные стороны, которые наиболее важны для цели сезона, и разрабатывать только те функциональности, которые имеют наивысший приоритет.

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

Это первая часть нашего любимого принципа: максимальный эффект при минимальных усилиях.

• Составить список функциональностей

Исходя из воздействия

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

Рисунок 15.6 – Карта воздействия, включающая функциональности

Степень детализации функциональностей на данном этапе не сильно важна. Главное – составить этот первый список.

Функциональности помещаются на impact map в зависимости от своего воздействия.

Другим способом

Impact map размещает функциональности по отношению к их воздействию. Это помогает идентифицировать их и не начинать со списка покупок (функциональностей), которые могут не соответствовать цели.

Но можно получить список функциональностей и без анализа их воздействия.

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

• Упорядочить функциональности

На что обращать внимание при упорядочении функциональностей в бэклоге поставки?

Исходя из критериев

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

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

Основываясь на этих критериях, модели могут быть использованы для упорядочения функциональностей:

– БСЦ2: Бизнес-ценность + Сокращение рисков + Ценность знаний / Цена

– Цена задержек, поделенная на время

Нужно всегда принимать во внимание зависимости и восприятие ценности. Коллективное обсуждение этого вопроса очень важно во время сессии доработки функциональностей.

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

Исходя из воздействия

Приоритеты, определенные для воздействия, влияют на приоритеты для функциональностей.

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

Построение «позвоночника»

Первым шагом в технике story mapping является создание позвоночника на первой строке. Функциональности перечисляются в хронологическом порядке, чтобы определить логическую последовательность (цепочку создания ценности) в соответствии с использованием продукта заинтересованными лицами. Это ось последовательности, которая служит для напоминания use cases.

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

Помимо приоритизации на основе воздействия, story mapping учитывает также зависимости и риски.

• Разделение функциональностей на истории

Затем наиболее приоритетная функциональность разбивается на истории, каждая из которых помещается на Post-it®. Функциональность может насчитывать с десяток историй. Они располагаются в несколько рядов: верхние ряды – для самых необходимых историй. Вопрос о необходимости ставится перед Владельцем продукта: тебе действительно нужна эта история для достижения цели? Если ответ да, она остается на верхних рядах. Если нет, уходит ниже.

Цель состоит в том, чтобы получить из историй и функциональностей, расположенных на первых рядах, минимальный набор, который позволил бы заинтересованным сторонам использовать продукт.

• Добавить риски

Участники команды помечают истории, которые, как им кажется, несут определенные риски (технические и др.).

Они добавляют Post-it® другого цвета на карту рядом с соответствующими историями. Чтобы минимизировать указанный риск, можно создать новую историю.

Истории, чья цель в сокращении рисков, обычно имеют высокий приоритет. Если так, они помещаются в самый верх карты.

На одной такой встрече команда может определить двадцать-тридцать историй и внести их в бэклог.

Порядок, определенный при story mapping, сохраняется для историй, которые пойдут непосредственно в доработку. Функциональности возвращаются в kanban-таблицу. Участникам нужно распределить их на те, что служат цели сезона, и остальные.

Рисунок 15.7 – Наполнение бэклога

Story mapping позволяет сократить работу над продуктом в двух направлениях:

✓ убирая ненужные функциональности,

✓ убирая ненужные истории среди оставшихся.

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

• Первая доработка

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

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

• Появление минимальной функциональности

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

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

Рисунок 15.8 – Разделение функциональности (1) на истории (2) и группирование в минимальную фнкциональность (3).

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

При этом следует убедиться, что ожидаемое воздействие сохраняется.

Это разделение на части может проводиться во время story mapping.

• Разработка, направляемая гипотезами

Цель этого паттерна – в сокращении функциональных рисков. При этом обеспечивается ценность функциональности путем экспериментирования с пользователями.

Мы предполагаем, что <эта функциональность>

Окажет <это воздействие>

Мы убедимся, когда увидим <этот измеряемый сигнал>

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

Таблица 15.1

Пример на трех уровнях:

✓ История: как владелец бассет-хаунда, я могу задать вопрос эксперту.

✓ Функциональность: коучинг породистых собак онлайн.

✓ Воздействие: 10 % прибыль благодаря подписавшимся на новую услугу.

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

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

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

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

✓ качество исполнения: удобство использования, надежность, производительность,

✓ качество развития: ремонтопригодность, портативность,

✓ ограничения проектирования, развертывания, соответствие стандартам.

В зависимости от этого меняется и влияние на элементы Scrum.

Если нефункциональное требование оказывает сильное влияние на продукт, его можно использовать для контекстуализации Scrum (см. главу 14).

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

✓ реализовать за один спринт, следуя определению завершенности,

✓ протестировать.

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

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

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

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

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

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

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

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

Ситуация. Команда перешла к Scrum, но во время прелюдии просто переименовывает огромную, детализированную спецификацию в бэклог и чрезмерно подробно рассматривает каждую историю.

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

Как сделать лучше? Сперва сосредоточиться на наиболее приоритетных функциональностях.

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

Последствия. Нет согласованности между командой и бизнес-целями.

Как сделать лучше? Попробовать техники impact mapping и story mapping.

Чтобы идти дальше

Книги

‣ Гойко Аджич, «Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке», Альпина Паблишер, 2017

‣ Джефф Паттон, «Пользовательские истории. Искусство гибкой разработки ПО», Питер, 2017

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

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

В этой главе мы увидим, что среднесрочное планирование может помочь при ответе на все эти вопросы.

Для полного взаимопонимания давайте сперва разберемся в значении некоторых понятий.

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

✓ планирование на среднесрочную перспективу (сезон),

✓ поставка конечным пользователям (ввод в эксплуатацию),

✓ техническая реализация (развертывание).

Вот мои обновленные определения:

В предыдущих изданиях я называл этот период релизом. Соответственно, план релиза стал планом сезона.

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

Рисунок 16.1 – Все сезоны имеют одинаковую продолжительность.

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

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

Ввод в эксплуатацию содержит развертывание в среде производства и активацию доступа для пользователей [46].

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

Им будет интересно заранее узнать, что запланировано на конец сезона.

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

Команде следует установить фиксированную дату окончания сезона и придерживаться ее, используя идею временного интервала, как в спринте.

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

✓ о приоритетных элементах в доработке;

✓ о чистке историй, которые, в конечном итоге, не несут большой ценности.

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

Agile-планирование переворачивает традиционный треугольник содержание-стоимость-время [47], при этом:

✓ дата, стоимость и качество определены заранее и не подлежат обсуждению;

✓ содержание (scope) может корректироваться.

Рисунок 16.2 – Перевернутый треугольник

Планирование сезона основано на этом принципе и нацелено на увеличении ценности продукта путем выбора функциональностей.

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

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

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

✓ сезоны длятся по 3 месяца и включают 6 спринтов по 2 недели,

✓ ввод в эксплуатацию конечными пользователями проводится в конце каждого сезона,

✓ команда уже завершила один сезон и измерила свою скорость – это 4,

✓ команда практикует сессии доработки и умеет разбивать работу на маленькие истории,

✓ команда рассчитала, что epic примерно в два раза больше обычной истории.

Рисунок 16.3 – План сезона в соответствии с примером

Этот простой подход основан на разделении, измерении и подсчете и не требует сложных, детальных оценок.

Результат планирования отражается непосредственно в бэклоге через паттерн лотков.

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

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

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

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

Планирование сезона состоит из:

✓ Определения объема работы на сезон.

✓ Вычисления средней скорости команды на основе имеющихся данных – достаточно разделить количество завершенной работы за период (например, сезон) на количество пройденных спринтов.

✓ Вычисления производительности. Самое простое – взять в качестве производительности среднюю скорость команды. Это все равно что прогнозировать погоду: не сильно рискуешь ошибиться, если ориентируешься на погоду накануне.

✓ Отражения полученных данных в бэклоге. Двигаясь от наиболее приоритетной готовой истории к наименее приоритетной в лотке доработки и применяя вычисленную производительность команды, нужно определить содержание каждого спринта.

✓ Внесения неопределенностей. Все прогнозы имеют элемент неопределенности. Но это не мешает принимать решения.

• Истории или функциональности?

Планирование обычно практикуется по отношению к историям и при использовании рабочего бэклога.

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

Однако план, основанный на историях, может быть не очень информативным для заинтересованных сторон.

Рисунок 16.4 – Корректируемое содержание сезона

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

• Считать или оценивать?

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

Покер планирования

Покер планирования [48] стал очень популярен среди Scrum-команд. Это техника групповой оценки с использованием карточек. Она сочетает в себе экспертную оценку и оценку по аналогии.

Каждый участник получает колоду карт с указанием определенного числа для оценки истории.

Обычно используется около десяти чисел, взятых из последовательности Фибоначчи: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Я советую остановиться на 13 – это дает шкалу из шести значений, которых более чем достаточно.

Чтобы начать сеанс, нужно сперва выбрать историю для оценки.

Желательно подобрать историю среднего размера и присвоить ей значение от 3 до 5.

Процесс покера планирования

– Владелец продукта представляет историю.

– Участники команды задают вопросы, чтобы лучше ее понять, коротко ее обсуждают.

– Все участники одновременно переворачивают выбранную ими карту для оценки истории.

– Каждый объясняет свой выбор. Первыми высказываются те, кто дал самую высокую и самую низкую оценку.

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

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

Рисунок 16.5 – Заядлые игроки в покер планирования

Оценка сходства

Первый сеанс покера планирования может занять аж полдня. Его возможно ускорить при помощи оценки сходства.

Оценка сходства проводится при помощи Post-it® для всех историй поочередно. Для каждого возможного значения создается отдельная строка.

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

Размер футболки

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

Вот почему мы рекомендуем ограничить количество значений.

Есть еще более простая техника, использующая размеры футболок. Достаточно трех размеров: S, M, L. Такой способ дает возможность не прибегать к числовым значениям, что делает процесс оценивания простым и честным.

Подсчет

Простая техника, которую мы использовали во введении – это подсчет. Сначала нужно определить: представленный элемент – это epic или история? Затем просто посчитать истории. Гипотеза один epic равняется двум историям позволяет быстро получить объем работы, которую необходимо выполнить.

Есть несколько способов, как измерить среднюю скорость команды за один спринт.

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

✓ По количеству функциональностей. Поскольку они больше историй, количество завершенных за сезон функциональностей будет, соответственно, меньше. Измерять среднюю скорость команды в данном случае следует в конце сезона.

✓ В баллах. Средняя скорость команды измеряется суммой баллов за завершенные истории в течение одного спринта.

Чтобы вычислить производительность, требуется значение скорости команды в прошедших спринтах.

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

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

• Сколько нужно предшествующих данных о работе команды?

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

Если команда только начала работу над продуктом, она может начать планировать спустя несколько спринтов.

• Учет сезонных изменений

Скорость команды зависит от продолжительности спринта и состава команды.

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

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

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

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

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

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

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

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

Есть разные способы показать пределы неопределенности (рисунки 16.6 и 16.7).

Рисунок 16.6 – План сезона с учетом неопределенностей

Элемент лотка в правом нижнем углу находится в первом ряду, тот, что над ним – во втором, самый верхний – в последнем. Нижняя стрелка, идущая от сезона, составляет нижний предел – минимум того, что команда в состоянии завершить. Верхняя стрелка составляет верхний предел, то есть максимум для команды. Бесполезно перегружать изображение данными о спринтах, которые будут еще совсем не скоро (в данном случае спринты 4 и 5).

Это изображение, включающее неопределенности, позволяет:

✓ убедиться, что все необходимое для сезона включено в нижний предел;

✓ легко и понятно сообщать заинтересованным сторонам о своих прогнозах.

Чем дольше команда работает в текущем сезоне, тем меньше неопределенностей, потому что появляются реальные данные о ее работе.

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

Должна ли команда в начале сезона принимать какие-либо обязательства в отношении результата, как она это делает в начале спринта?

Прежде всего, не стоит путать прогнозирование и обязательство. План сезона состоит из прогнозов – возможно, он позволит принять обязательства.

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

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

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

Итак, никаких обяазательств касательно содержания. А что насчет цели на сезон?

Цель сезона – та же цель спринта, только на более высоком уровне. Она заранее обговорена и принята с началом сезона.

Техника impact mapping, представленная в главе 15, позволяет направить команду в сторону цели сезона. Сама цель указывается в центре карты и может сопровождаться проверяемыми количественными элементами.

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

Насколько Agility совместима с контрактом с фиксированной ценой? Ответ совсем прост и следует из того, в чем мы только что убедились: без надежных данных о работе команды обязательства в отношении результата бессмысленны.

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

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

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

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

План сезона состоит из предстоящих спринтов и их ожидаемого содержания в виде историй или, если применимо, соответствующих функций.

Он регулярно обновляется – в отличие от заранее составленного подробного плана, который становится непреложным ориентиром. План развивается с учетом всевозможных изменений.

• Изображения плана сезона

Мы рассмотрели план сезона в лотках. Это простое изображение позволяет все видеть на одной схеме без дублирования историй.

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

Рисунок 16.7 – План сезона с учетом неопределенностей

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

Нет смысла быть сверхточным в прогнозировании того, что будет только через несколько спринтов. Это можно отразить в плане, ограниченном лишь рамками сезона.

В план добавлены неопределенности: они расположены на соответствующих границах.

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

Рисунок 16.8 – Бэклог с зоной неопределенности

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

Вернемся к первым вопросам команды Peetic.

– Сможем ли мы использовать управление подписками для выставки собак в марте?

Да. В плане представлены функциональности, и это одна из функциональностей, которые команда обязательно реализует.

– Через сколько времени мы сможем анонсировать запуск приложения на планшет?

Эта функциональность запланирована на следующий сезон, который завершится в августе.

– Какой бюджет необходим для разработки версии 2 приложения?

Команда Peetic выбрала сезон с фиксированными датами. Бюджет обговаривается заранее, его легко определить на основе размера команды и продолжительности.

– Когда нам понадобится компонент онлайн-платежей?

Через два спринта, когда будет разработана функциональность корзина.

Ситуация. Те, кто привык к подробным спецификациям, считают, что сезон закончится, когда бэклог опустеет. Вот только он никогда не бывает пустым.

Последствия. Бэклог живет, развивается и представляет собой постоянно пополняемый поток. Стремиться к пустому бэклогу не стоит. Я знаю одну команду, которая пыталась этого добиться на протяжении 18 спринтов – и безуспешно!

Как сделать лучше? Использовать паттерн сезонного ритма, чтобы запланировать даты начала и окончания сезона. Планировать несколько сезонов наперед не имеет смысла.

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

Последствия. Все уже перечислено выше. Скорость команды используется для давления на команду.

Бывает даже, что под контроль ставится индивидуальная скорость, что является полнейшей чепухой.

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

Ситуация. Команде кажется, что она слишком много времени тратит на оценку.

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

Как сделать лучше? Поговорить об этом во время ретроспективы и предложить более простые способы оценки. Научиться разбивать работу на маленькие части (см. паттерн разделение в главе 8).

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

Последствия. В плане нет смысла.

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

Чтобы идти дальше

Книги

‣ Майк Кон, «Agile. Оценка и планирование проектов», Альпина Паблишер, 2021

‣ Vasco Duarte, NoEstimates, How to measure project progress without estimating, Oiko Sofy, 2014

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

Некоторые могут пойти еще дальше и интерпретировать первую строку из Agile-манифеста – люди и взаимодействие важнее процессов и инструментов – как совет вовсе не пользоваться инструментами во время Agile-разработки.

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

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

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

Цель этой главы – познакомить вас с инструментами, которые могут стать эффективными помощниками для Scrum-команды. Мы поговорим о компьютерных приложениях, а также играх, досках и, конечно, Post-it®.

О том, что в компании применяется Scrum, зачастую можно судить по цветным стикерам на стенах.

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

Можно, например, использовать карточки с клейким краем, чтобы свободно их перемещать.

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

Их использование особенно рекомендуется для мониторинга спринта. Scrum-доска – это идеальное место для проведения ежедневных схваток.

Рисунок 17.1 – Война Post-it®

Post-it® легко клеятся и бывают разных цветов. Но, в отличие от обычных карточек, у них можно использовать только одну сторону, что вынуждает быть максимально кратким и писать большими буквами, чтобы написанное было видно издалека.

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

Рисунок 17.2 – Владелец продукта собирает бэклог после рабочей встречи

Если нужны еще доказательства того, что стикеры – это настоящий инструмент, советую ознакомиться со статьей Матти Шнайдера, который провел сравнительное исследование 23 моделей [50].

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

Онлайн-таблицы позволяют, пусть и частично, уменьшить этот недостаток.

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

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

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

Есть инструменты платные и бесплатные, многорежимные – в общем, самые разные.

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

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

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

Если команда находится в одном рабочем пространстве, я советую использовать стикеры.

Рисунок 17.3 – Настенная доска – лучшее решение для плана спринта!

Это дает много преимуществ: делегирование задач, визуальный мониторинг и т. д.

Если команда использует несколько инструментов, лучше хранить информацию в одном месте и избегать дублирования записей, например, повтора задачи на Post-it®, а затем в каком-либо электронном инструменте. При одновременном использовании инструмента для бэклога и Post-it® для спринта стоит следить за избыточностью информации.

Доска – один из важнейших инструментов Scrum-команды. Она способствует визуальному управлению.

Классическая Scrum-доска применяется для плана спринта. Она представлена в трех колонках для историй (готовые, в процессе, завершенные) и, соответственно, тремя колонками для задач (сделать, в процессе, сделано) в тех историях, что сейчас в процессе.

• Советы по созданию красивой доски

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

Вот несколько советов, как этого добиться.

✓ Аккуратно приклеивать Post-it®, чтобы стикеры не загибались. Их следует осторожно отрывать от блока справа или слева, но не снизу.

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

✓ Использовать разные цвета, причем для самых разных целей. Можно ввести определенную цветовую кодировку.

✓ Ввести обозначение по размерам. Часто Post-it®, используемые для задач, меньше, чем для историй. Некоторые команды на моей практике использовали размер Post-it® как индикатор размера задачи.

✓ Использовать расположение. Столбцы обычно шире, чем Post-it®, что позволяет при помощи их расположения визуализировать ход выполнения задачи. Или делать себе напоминалки: если поместить только что завершенную задачу сильно левее от столбца готово, то во время ежедневной схватки легко вспомнить и сообщить об этом событии остальной команде. Некоторые наклеивают стикер на границу между двумя колонками.

✓ Использовать магниты с аватарами. Чтобы было ясно, кто взял ту или иную задачу, можно указывать инициалы исполнителя на соответствующем Post-it®. А можно использовать аватары разработчиков, это наглядно и весело. К тому же – если у разработчика всего один или два магнита – это ограничит мультизадачность.

✓ Использовать печать или переворачивать завершенные истории. На доске иногда бывает только одна колонка для историй. Если нет стартового лотка, можно переворачивать стикеры или проставлять на них штамп ЗАВЕРШЕНО – чтобы отделить завершенные истории от остальных.

• Избавление от дополнительных колонок

Команды, которые слышали о Kanban, склонны добавлять в доску больше столбцов, например, к проверке или для теста.

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

Чтобы избежать этих ошибок применяется паттерн роение, представленный в главе 9 «Планирование спринта». См. также главу 20.

Рисунок 17.4 – Scrum против дополнительных колонок. И колонн.

• Доска для препятствий

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

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

Устранение препятствий не должно затягиваться. Дата выявления также полезна на этапе ретроспективы, когда рассматривается хронология основных событий спринта.

• Доска историй и функциональностей

Как мы узнали из глав о бэклоге, история на протяжении жизненного цикла развивается слева направо.

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

Два этапа, на которых выполняются какие-либо значимые действия – это доработка и реализация (в процессе).

Рисунок 17.5 – Замечательная доска для историй

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

• Многоуровневая доска

Можно представить сразу два уровня на одной таблице. Например, добавить три столбца задач.

Рисунок 17.6 – Двухуровневая доска (Scrum!): история и задача

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

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

Можно поместить календарь и отмечать доступность экспертов и отпуска участников команды.

Niko-niko [51], размещенный на входной двери, позволит ежедневно отмечать и следить за настроением участников команды.

Заинтересованным сторонам будет интересно увидеть рядом с kanban-доской функциональностей еще план сезона и такой индикатор, как burndown-график задач.

Игра – это тоже в некотором роде инструмент для Scrum-команды. Игры можно использовать для обучения и для работы, то есть, для достижения определенных результатов.

Играть, не отвлекаясь от работы – кажется, неплохой оксюморон? В «Третьей промышленной революции» Джереми Рифкин утверждает:

В XIX и XX веках условием, дававшим право считаться человеком, было индивидуальное усердие, а цель жизни заключалась в превращении в производительного работника. На протяжении многих поколений люди становились машинами в бесконечной гонке за достижением материального благополучия: мы жили для того, чтобы работать. Третья промышленная революция и эра сотрудничества открывают перед человечеством возможность освободиться от оков механизированной жизни, встроенной в утилитарный мир, и почувствовать себя свободным: жить, чтобы играть. Французский философ Жан-Поль Сартр усматривал близкое сходство между свободой и игрой. Он писал, что «по мере того, как человек осознает себя свободным и начинает распоряжаться своей свободой… его деятельность превращается в игру». В дополнение к этому я могу лишь спросить: разве может кто-нибудь чувствовать себя более свободным, чем тогда, когда он играет?

Сказано так красиво и убедительно, что отпадает всякая необходимость добавлять к игре определение серьезная (serious game), чтобы не показаться вдруг слишком легкомысленным. Рифкин использует термин глубокая игра как способ эмпатичного взаимодействия с другими.

Рисунок 17.7 – «Я сомневаюсь: дать вам прибавку или лишить премии?»

✓ Чтобы приобщиться к Agile-культуре. Эти игры направлены на Agile-трансформацию организации, приобщение к новой культуре с ее ценностями и принципами. Среди очень многих выделю, к примеру, Draw the drawing game и Lego Scrum.

✓ Чтобы научиться работать в команде. Большое количество игр! Многие были созданы вне Agile-культуры, направлены на так называемый тимбилдинг – искусство командообразования.

Мы уже поговорили о некоторых их них. Наиболее известная в этой категории – пожалуй, покер планирования, чья цель – в оценке размера историй.

✓ Для определения продукта. Аgilitу подталкивает к командной работе, и лучший способ определить продукт – провести собрание в игровом формате. Сюда отлично подойдут Innovation Games [Хоманн, «Бизнес-игры»], в которые играют совместно с пользователями. Заинтересованные стороны, представители бизнеса, обычно являются участниками таких игр.

✓ Во время спринтов. Команда может веселиться и во время спринтов, но особенное время для игры – это ретроспектива. Здесь игры направлены на обеспечение комфортной атмосферы и сбор информации.

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

Встает очевидный вопрос, особенно во время прелюдии: с кем играть?

Ответ прост: с правильными людьми. Это принцип, о котором вспоминают на открытых совещаниях. Не нужно специально ждать чьего-то присутствия. Игра запускается – и кто участвует, и являются правильными людьми.

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

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

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

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

Если у вас есть конкретная цель, касающаяся обучения или совместной работы, не нужно медлить: создавайте свою игру или адаптируйте уже существующую. Можно почерпнуть идеи в [Макануфо, «Game Storming»], участвовать в конференциях, где предлагается множество игр.

Существует даже не-конференция, посвященная играм. Она проводится ежегодно где-нибудь во Франции (в 2018 году состоялась в Лавале в Майенне), и на ней можно предлагать и тестировать новые, только-только разработанные игры.

Ситуация. Инструмент используется только одним человеком, а не командой. Например (и особенно это относится к любителям Excel), только Владелец продукта имеет доступ к бэклогу. Или Scrum-мастер единолично обновляет задачи всей команды в плане спринта.

Последствия. Обмен ограничен или его вовсе нет.

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

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

Последствия. Доска перестает быть простой в использовании. Участники больше не ограничивают себя в масштабах таблицы.

Как сделать лучше? Не стоит пытаться вместить все в одну доску. Мы знаем, что в Scrum есть три уровня: функциональность, история, задача. Для них нужны как минимум две разные доски.

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

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

Как сделать лучше? В статье об Agile-инструментах [52] Кент Бек утверждает, что лучше инвестировать в один (или несколько) элементарных инструментов, адаптированных к нашему процессу, чем пытаться адаптироваться к более сложным и большим инструментам, созданным для других процессов и подходов.

Ситуация. Игры проводятся при помощи классических материалов (флипчартов) в классических местах.

Последствия. Теряется игровой формат, это препятствует креативности.

Как сделать лучше? Некоторые игры нуждаются в дополнительном оборудовании. В дополнение к запасу Post-it® у Scrum-мастера должен быть укромный уголок с запасом наклеек, пусть даже совсем детских, конфет, клеевых подушечек «Patafix» и хронометром – и это только минимальный набор!

Ситуация. Команда пользуется инструментами с устаревшим интерфейсом.

Последствия. Теряется инновативность, это препятствует креативности.

Как сделать лучше? Agile-движение – это радикальное изменение. И как мне кажется, оно должно охватывать и техническую сторону вопроса.

Новые интерфейсы веб-приложений позволяют еще больше сблизиться с Post-it®, даже с некоторыми дополнительными преимуществами.

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

Чтобы идти дальше

Книги

‣ Люк Хоманн, «Бизнес-игры. Создание революционных продуктов с помощью клиентов», Символ-Плюс, 2008

‣ Джеймс Макануфо, Санни Браун, Дэйв Грей, Gamestorming – Jouer pour innover, VF, 2014.

‣ Джереми Рифкин, «Третья промышленная революция», Альпина нон-фикшн, 2017

Онлайн-ресурсы

‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/

‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum

‣ Agile Games France, Википедия

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

Значение, которое обычно придается индикаторам (знаменитым KPI, Key Performance Indicators, или ключевым показателям эффективности), в результате просто утрачивается. Но индикаторы нужны для наглядности: они предоставляют информацию, которая не указывается на досках, а именно динамику.

Традиционный индикатор Scrum – это burndown-график, он же диаграмма сгорания задач. Этот индикатор является средством для отслеживания выполненных задач. Часто используемый неправильно, он имеет ограничения в определенных условиях, для которых приемлемы другие индикаторы. Мы представим их в этой главе.

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

Некоторые метрики относятся к величинам, не известным в момент, когда команда в них нуждается. Возникает необходимость оценивания. Для этого можно использовать story points. Во второй части мы вернемся к оцениванию, оно предмет многих дискуссий в Agile-сообществе.

Во время спринта на ежедневной основе можно собирать следующие данные:

✓ количество завершенных задач;

✓ успешное прохождение условий приемки;

✓ настроение участников команды.

В каждодневном подсчете завершенных историй нет смысла, так как это прекрасно видно на доске спринта.

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

Весьма интересный индикатор, основанный на измерении задач – burnup-график спринта.

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

Рисунок 18.1 – Burnup-график спринта в задачах (в понедельник команда расправилась с одной историей)

Новый тип метрик вдохновлен Agile-методами, относящимся к степени удовлетворенности людей.

Рисунок 18.2 – Индикатор настроения, полученный при помощи Teammood (teammood.com)

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

Рисунок 18.3 – Индикатор скорости команды во время спринтов

Препятствие – определенный факт, замедляющий команду или вовсе блокирующий ее дальнейшую работу: упавший сервер, недоступная заинтересованная сторона и т. д.

План сезона указывает на работу, которую осталось проделать в текущем сезоне. Burndown-график показывает динамику.

Рисунок 18.4 – Вurndown-график сезона

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

Рисунок 18.5 – Вurnup-график сезона

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

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

• Скорость команды основывается на оценке

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

Оценка с помощью Agile-методов привнесла новые решения, но вокруг нее по-прежнему много дискуссий. Это, в конце концов, довольно непростой вопрос.

В Scrum оценка остается сложной задачей, но подход к ней другой:

Так лучше. Но несмотря на это, в story points много неопределенности. Средняя скорость команды, используемая для планирования сезона, более надежна, но скорость команды во время спринта остается довольно неопределенным показателем.

• Скорость команды измеряет работу

Что на самом деле измеряет скорость команды? Давайте сначала посмотрим, какие единицы измерения вообще используются.

Не человеко-дни…

Поскольку все спринты имеют одинаковую продолжительность, а команда стабильна, использование такой единицы измерения по определению привело бы к постоянной скорости команды. Особенность скорости команды – она измеряет то, что завершено (истории).

…Но story points

Если команда производит оценку в момент поставки (как представлено в главе 7 Доработка бэклога), скорее всего, она оценивает story points, исходя из сложности.

Во всяком случае, оценка связана с работой, завершенными задачами. Она не относится к продуктивности.

Поскольку определение производительности относится к результату, следует также учитывать добавленную ценность. Измерение ценности, получаемой в результате каждого спринта, ближе к производительности – той концепции, что используется в экономике. Таким образом, увеличение скорости команды не означает, что производительность также увеличится.

• Ценность и размер

Другими словами, если история большая – это не значит, что ее ценность будет выше.

При большом спектре историй размер и ценность статистически коррелируют: в среднем, чем больше размер, тем выше ценность (рисунок 18.6, XYZ).

Рисунок 18.6 – Соотношение ценности и размера

Но очевидно, что это не всегда так (рис. 18.6, A имеет бóльшую ценность, чем X, хотя они одного размера): мы знаем о существовании функций, которые просты в разработке и очень полезны (или, наоборот, есть газовые заводы, которые долго разрабатываются и в итоге не несут никакой ценности).

Поскольку скорость команды не является отражением ее производительности, предлагаю обсудить бизнес-ценность.

Максимальная бизнес-ценность – вот провозглашенная цель Scrum и Agile-методов. Чем выше ценность элемента, тем выше его приоритет. Поскольку приоритет определяет порядок, в котором реализуются элементы бэклога, наиболее ценные элементы разрабатываются в первую очередь.

Ценность также основана на оценках

Но оценить добавленную ценность истории непросто.

Пора уже пределить, что подразумевается под бизнес-ценностью (business value): рентабельность инвестиций, чистая приведенная стоимость? Даже при большом количестве исследований оценка финансовой ценности одной истории – задача не из легких.

Как и оценка размера, оценка стоимости относительна и может производиться без единиц измерения. Владелец продукта сортирует истории по их ценности – это происходит во время приоритизации и называется порядковой, или ординалистской [54], полезностью.

Чтобы выйти за рамки этого порядка, следует оценить ценность каждого элемента (измерить кардинальную полезность).

• Ценность имеет больше смысла для функциональности

Пользовательская история имеет определенную бизнес-ценность. В отличие от нее, технические работы и технический долг не обладают ценностью, видимой пользователям. Но от них зависят пользовательские истории – следовательно, им можно присвоить косвенную ценность. С другой стороны, ошибки снижают ценность историй.

Быстро замечаешь, что на уровне истории как таковой бизнес-ценности нет. Пользовательская история сама по себе слишком мала для отдельного развертывания. Целесообразнее говорить о ценности, которую привносят функциональности.

• Трудности с измерением ценности

Ценность – очень субъективное понятие. Хотя техники и рабочие встречи и позволяют распределить и классифицировать элементы по их ценности, использование даже каких-либо относительных чисел для индикаторов вызывает сомнения.

Более того, это невозможно проверить.

В теории она представляет собой S-образную кривую (в работах Алистера Кокберна)⁴⁵, но это всего лишь теория с целью наглядно продемонстрировать, что бизнес-ценность хорошо растет, когда риски минимизированы (ценность знаний), и достигает порога предельного значения, если мы остаемся в рамках того же содержания [55].

• От ценности к полезности и воздействию

Оказывается, ценность часто путают со стоимостью.

Impact mapping (глава 15) подсказывает, что следует обратить внимание на воздействие в отношении участников процесса. Вместо того, чтобы опираться на сомнительные оценки, лучше строить гипотезы и как можно раньше их проверять.

Рисунок 18.7 – Тонкая грань между ценностью и полезностью

• В заключение

В Scrum нет определенного индикатора продуктивности, основанного на скорости команды или бизнес-ценности.

Организации, бывает, задаются вопросом: стали ли они Agile? Или, по сравнению с другими, на каком они сейчас уровне Agility?

Иногда сравнивают уровень Agility между разными командами внутри одной организации. Некоторые оценивают применяемые командой практики. Вызывают специалиста – он измеряет внедрение правильных практик, создает графики и получает индикаторы, и таким образом определяет уровень Agility.

Но такой подход не имеет ничего общего со Scrum. Как мы узнали из главы 14 «Контекстуализация Scrum», каждый случай индивидуален. Мы не будем рассматривать никакие индикаторы для мониторинга практик. В духе Agility, скорее, оценка удовлетворенности людей и достигнутых результатов.

Удовлетворенность разработчиков команды отслеживается при помощи ежедневного индикатора настроения. Можно даже привлечь к участию заинтересованные стороны.

В центре нашего обсуждения продуктивности были результаты, и я не думаю, что советовать индикаторы оценки уровня Agility будет хорошей идеей.

Но я совершенно точно рекомендую найти свой путь к достижению Agility. Мы подробнее об этом поговорим в главе 22 «Закрепление Agile-практик».

Ситуация. Традиционная практика управления проектами, заключающаяся в оценке продолжительности выполнения задачи перед началом работы, подсчете реально затраченных часов и анализа разницы, используется командой и после внедрения Scrum.

Последствия. Измерение затраченного времени требует, собственно, времени. Оно ненадежно и приводит к мысли, что цель проекта – в оценивании, а не в создании продукта. Оно способствует узконаправленности в ущерб кроссфункциональности и вредит духу команды.

Наконец, оно не особо помогает. Если даже мы и наблюдаем расхождение между оценкой и фактически затраченными часами, не можем сказать, является это следствием неправильного оценивания, некомпетентности или неверного определения работы.

Как сделать лучше? В Scrum не ведется подсчет часов, потраченных на задачу или историю. Важен сам факт их завершения.

Ситуация. Команда использует затраченные усилия для калибровки спринта: она оценивает истории на этапе планирования спринта, чтобы определить, сколько влезет в один спринт.

Последствия. Команда тратит время. Скорость команды становится инструментом контроля.

Как сделать лучше? Я не рекомендую практику калибрования скорости команды во время спринта и советую делать больший упор на приверженность цели (см. главу 9 «Планирование спринта»).

Points: оценка усилий или сложности?

На основании чего проводить оценку? Одни считают, что следует подсчитывать вложенные усилия, другие – сложность задачи.

Лучше избегать оценивания на основе приложенных усилий. Мало что можно сказать об усилиях на момент попадания истории в лоток доработки. Подсчет усилий потребует их частого пересмотра, особенно при планировании или даже во время спринта.

После участия в огромном количестве сессий по покеру планирования я могу смело утверждать, что участники чаще всего очень хорошо осознают разницу между относительной трудностью и усилием.

Время, которое требуется для завершения истории (усилие), зависит от технического долга и состава «пчелиного роя», о которых еще ничего не известно на момент оценивания – то есть, вероятно, задолго до реализации. Вот почему оценивание относится только к восприятию сложности одной истории по сравнению с другими. Встает вопрос о повторной оценке, если технический долг увеличивается.

В предыдущем издании я говорил об усилиях, но не о размере. Я изменил мнение после многократного опыта, подкрепленного чтением книги «Exploring Scrum» [Роастхорн, Exploring]. В ней Дэн Роастхорн развил концепцию Рона Джеффриса об относительной сложности.

Оценка размера, основанная на относительной сложности, включает в себя объем информации, которую нужно обработать для одной истории. История может быть простой, но состоять из множества фрагментов. Это не просто техническая сложность. Речь обо всем, что необходимо сделать для завершения истории.

Ситуация. Узнав об индикаторах, бывший менеджер проекта, а ныне Scrum-мастер, с большим рвением составляет всевозможные графики и представляет их руководству.

Последствия. Он тратит много времени за составлением графиков. Некоторые индикаторы предназначены для команды и совершенно бесполезны для заинтересованных сторон – например, burndown-график спринта.

Как сделать лучше? Недостаточно просто составлять графики, нужно понимать, для кого какой индикатор предназначен. Гениальность – в простоте.

Рисунок 18.8 – Измерение и индикатор

Чтобы идти дальше

Книги

‣ Норман Балларжон, «Petit cours d’autodéfense intellectuelle», издания Lux, 2006. Книга, чтобы научиться считать и правильно толковать индикаторы.

‣ Dan Rawsthorne, Doug Shimp, «Exploring Scrum, The Fundamentals», CreateSpace Independent Publishing Platform, 2011

Онлайн-ресурсы

‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/

‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum

Scrum стал чрезвычайно популярным и бесспорно успешным среди разработчиков программного обеспечения. Но некоторым командам по-прежнему не удается создавать качественные продукты. Речь о тех командах, что внедрили Scrum, позабыв об инженерных практиках.

В сети регулярно появляются колкие, но справедливые комментарии об их важности – например, этот пост @pierreroth64 в Твиттере:

В ином случае это гарантированное кровопролитие и несправедливо ужасная реклама Scrum.

Scrum не сосредоточен на инженерных практиках разработки ПО, их применение совершенно добровольно, ведь Scrum может использоваться и в других областях.

Но для программного обеспечения их применение вызвано самими критериями завершенности, и команда замотивирована ими пользоваться для достижения результата.

Было бы ошибкой полагать, что эти практики являются необязательными и что качество продукта не является целью Scrum. Код должен быть максимально качественным. Scrum несовместим с принципом быстро, но плохо.

Цель этой главы – объединить Scrum с практиками разработки программного обеспечения. Мы обсудим самые распространенные из них и посмотрим, как они вписываются в Scrum-фреймворк.

Мы коснемся только тех практик, что появились в Экстремальном Программировании (XP). Однако старые методы разработки – управление версиями, отслеживание правил кодирования, просмотр кода и т. д. – также необходимы для обеспечения качества разработки ПО.

Непрерывная интеграция – это практика разработки программного обеспечения, при которой участники команды часто интегрируют свою работу. Обычно каждый человек проводит интеграцию ежедневно, что означает несколько интеграций в день.

• Важная практика

Регулярная интеграция кода каждого разработчика – практика, важная при последовательной разработке.

В результате компиляции и объединения всех компонентов получается сборка, используемая для прохождения тестов и получения обратной связи от Владельца продукта. С точки зрения Scrum, эта сборка соответствует микро-инкременту, который к концу спринта станет инкрементом для показа во время обзора.

• Процесс

При каждом коммите разработчика инструмент на сервере интеграции (например, Jenkins или Travis) инициирует цепочку действий [58]. Цепочка обычно следующая:

✓ Компиляция и проверка.

✓ Запуск модульных тестов.

✓ Запуск тестов интеграции и приемочных тестов.

✓ Запуск инструмента, который проверяет синтаксис и корректность кода (например, Linter).

✓ Запуск инструмента, который проверяет качество кода (например, Sonar).

✓ Составление отчета.

✓ Подготовка версии ПО, готовой к использованию.

Если сборка завершается ошибкой, команда останавливается, чтобы как можно быстрее найти проблему и решить ее: нельзя оставлять интеграцию сломанной, одна ошибка обычно влечет за собой следующие.

Чтобы быстро устранить причину поломки, нужно запустить отладчик.

• Когда следует начать?

Желательно овладеть непрерывной интеграцией до начала первого спринта. Если команда решает применить эту практику во время сезона, установка сервера и ПО попадает в бэклог в качестве технической работы.

Команда должна обсудить важность этого подхода с Владельцем продукта, объяснить его преимущества – в частности, более быстрое получение обратной связи. Хороший Владелец продукта обязательно согласится.

• Преимущества

Непрерывная интеграция позволяет в любой момент иметь работающий программный продукт. Это, несомненно, мотивирует как команду, так и пользователей. Она усиливает прозрачность процесса и гарантирует, что результат работы каждого участника виден остальным.

• Непрерывное развертывание

Непрерывную интеграцию продолжает новая практика, которая называется непрерывное развертывание. Она заключается в развертывании результата интеграции в среде, доступной заинтересованным сторонам или конечным пользователям.

Такой ввод в эксплуатацию позволяет получить обратную связь еще быстрее и пройти тесты в более представительной среде.

Чтобы больше об этом узнать, можно обратиться к [Саке, DevOps].

Разработчик, который пишет код, проверяет его кусочек за кусочком: это называется модульным тестом.

Разработка через тестирование включает рефакторинг.

• Сначала тест

В первую очередь пишется модульный тест для одного компонента, что позволяет определить его желаемое поведение. В принципе, программист пишет только один тест за один раз, после чего – код для его успешного прохождения. С написанным тестом это значительно проще. Программист следует процессу, добавляя новые тесты и минимальный код для их прохождения. Таким образом, он внедряет изменения в продукт.

Она способствует быстрому проектированию и хорошему знанию кода разработчиками. По сути, это форма неявной документации.

• Рефакторинг

Рефакторинг – это процесс улучшения кода без изменения его поведения. Улучшение качества достигается за счет упрощения и оптимизации текущего решения: команда убирает дублирование кода и делает его более простым и легким для восприятия. И, следовательно, для поддержания.

После каждого изменения необходимо снова проводить тесты, чтобы убедиться: поведение кода осталось прежним. Рефакторинг может выполняться без предварительной разработки тестов, но именно в объединении этих процессов в одну формулу состоит принцип разработки через тестирование.

Рисунок 19.1 – Практика разработки через тестирование

• Когда следует начать?

Для нового ПО – чтобы избежать технического долга

После формирования команды лучшим вариантом будет сразу создать условия для разработки через тестирования с самого начала работы над продуктом, еще до старта первого спринта первого сезона. Желательный уровень, на котором применять данную практику, определяется в критериях завершенности.

Задачи, касающиеся модульных тестов, в плане спринта могут быть указаны отдельно или включены в блок задач, относящихся к коду. Это зависит от опыта команды: если среди участников новички, лучше будет сделать отдельную запись.

Для существующего ПО – чтобы погасить технический долг

Если команда работает над существующим программным обеспечением, вероятно, присутствуют части без модульных тестов, которые нуждаются в рефакторинге.

Прежде чем приступить непосредственно к погашению этого долга, следует определить компоненты, нуждающиеся в рефакторинге, и порядок работы над ними.

Рефакторинг и написание тестов требуют времени, так как обычно код сложно протестировать. Поэтому все действия, направленные на улучшение качества кода, помещаются в бэклог. Владелец продукта должен позаботиться, чтобы они были выполнены в нужное время, лучше – как можно раньше.

Парное программирование – это практика, заключающаяся в работе двух разработчиков за одной рабочей станцией с целью улучшения качества кода.

Один разработчик сидит за клавиатурой, другой следит за экраном, предлагая идеи. Совместная работа выполняется с двух точек зрения: первая направлена на детали кода, а вторая – на общую структуру.

Рисунок 19.2 – Игра в четыре руки

• Когда следует начать?

Момент начала использования этой практики – решение команды. Работать таким образом весь день невозможно, да и не требуется: процесс довольно интенсивный и напряженный. Необходимо регулярно меняться ролями внутри пары и между парами внутри команды. Обсуждать перемещения можно во время ежедневных схваток.

Эта практика особенно рекомендуется для сложных частей ПО.

• Преимущества

Работа в паре ориентирована на улучшение качества продукта: технический долг всегда меньше в отношении тех частей, что реализованы двумя участниками.

Такой подход также упрощает обмен знаниями и компетенциями в команде.

• Что дальше?

Пинг-понг программирование состоит в постоянной ротации двух участников: один пишет тест и передает управление другому, второй пишет код и делает рефакторинг, затем пишет тест – и они меняются.

Моб-программирование [59] расширяет эту практику до размеров всей команды.

Она может распространяться и за пределами команды разработчиков: пары могут состоять из участника команды и Владельца продукта или даже кого-то из заинтересованных сторон.

Ранее различали этапы предварительного проектирования и рабочего проекта. Сейчас широко используется термин программная архитектура. Архитектура относится к организации компонентов и их взаимодействию. Проще говоря, архитектура глобальна и позволяет направлять выбор при проектировании компонента или разрабатывать историю.

Если судить по стереотипам, традиционный подход склоняется к тому, чтобы иметь всю архитектуру с самого начала, а при Agile-методологии архитектура развивается с каждой итерацией.

В Scrum-фреймворке, может, и не рекомендуется замораживать архитектуру слишком рано, но и не запрещается прорабатывать ее сразу во время прелюдии. Все зависит от контекста. В любом случае, не стоит выходить за рамки текущего сезона и принимать преждевременных решений.

Какая бы часть архитектуры ни была сделана до первого спринта, нужно помнить, что работы прибавится во время спринтов: архитектура эволюционирует, и невозможно все создать заранее и сразу ввиду сложности компьютерных систем.

Большие задачи заносятся в бэклог отдельными пунктами. Работа, связанная с архитектурой, может потребовать поддержки со стороны эксперта. Нужно предусмотреть это заранее, чтобы гарантировать его доступность. Как и в случае с остальными историями, не имеющими видимой ценности, необходимо обсудить важность этой работы с Владельцем продукта и приоритизировать задачи.

Документ архитектуры, если он существует, обновляется с каждым спринтом и заносится в критерии завершенности. Но важно качество архитектуры, и понятно это должно быть не из документа.

Практика стихийного проектирования отражается в регулярных задачах, относящихся к проектированию. Во время спринта команда с этим сталкивается дважды.

✓ На этапе планирования спринта, а точнее, во время роения команда коллективно работает над проектированием истории. Результат работы развивается в процессе спринта и может быть изображен на диаграмме последовательности, показывающей взаимосвязи между компонентами. Или другим образом, подходящим участникам.

✓ На этапе разработки истории написание тестов в первую очередь (разработка через тестирование) подходит и для проектирования. Этот процесс выполняется одним разработчиком или в паре.

Во время спринта может потребоваться технический анализ. Такое исследование называется spike (в русском языке наиболее часто употребляется вариант «спайк» – ред.). Необходимость в его проведении выявляется на моменте доработки. Затем spike вносят в бэклог в соответствии с расставленными приоритетами.

В конце спринта, уже после спайка, команда подбирает решение и способна подготовить историю, что соответствует пункту спайк в паттерне разделение истории, представленном в главе 7.

На данном этапе команда подтверждает, что история завершена с функциональной точки зрения. В седьмой главе мы с вами рассмотрели условия приемки и паттерн 6К.

История должна обладать условием приемки, а лучше несколькими (но не большим количеством). Каждому условию соответствует один или несколько приемочных тестов.

• Кто определяет тест?

Scrum ставит акцент на команде без привязки к конкретным ролям. В ней нет явной роли тестировщика, но это совсем не значит, что команда не проводит тестов! Некоторые по-прежнему придерживаются идеи, что тестирование выполняет заказчик. Это может побудить разработчиков делегировать все задачи Владельцу продукта или даже заинтересованным сторонам.

И это не лучшая идея: из-за обилия задач и компетенций Владелец продукта чаще всего не в состоянии брать на себя ответственность еще и за этот блок работы. Более того, этот этап выполняется коллективно и благоприятствует общению внутри команды.

В итоге не имеет значения, кто определяет тесты. Важно, чтобы все друг друга понимали и дело было сделано в нужное время. Это становится коллективной ответственностью.

⁃ Как определить тест?

Мы поговорили о BDD как о языке условия приемки. На конкретном примере перейдем к тесту приемки.

Разница между условием приемки и приемочным тестом в том, что тест содержит значения, которые составляют пример. Вот почему мы говорим о спецификации на примере с набором историй и приемочных испытаний.

Все больше распространяются инструменты, ориентированные на BDD – такие как Cucumber – позволяющие облегчить переход к автоматизированному тестированию.

Тем не менее, BDD – это, прежде всего, подход, содействующий коммуникации между Владельцем продукта и разработчиками.

Во время спринта приемочные испытания можно выполнять по ходу разговора.

Приемочный тест проверяется как можно раньше. Как только все прошло проверку, история принята и считается завершенной. Для избежания регрессий во время и после спринта тесты должны быть повторно воспроизведены – отсюда важность автоматизации.

• Продолжить разговор

Совокупность историй, их условий и приемочных тестов заменяют подробную функциональную спецификацию с существенным преимуществом: общение происходит напрямую.

Во время спринта часто бывает, что тесты меняются, завершаются, иногда даже добавляются новые, особенно после разговоров с Владельцем продукта.

Чтобы подчеркнуть, что история принята, можно определить задачу и включить ее в таблицу задач спринта. А можно пойти дальше и поместить тесты в таблицу вместо задач: тогда Post-it®, связанные с историей, будут относиться к тестам или, в более широком смысле, к условиям приемки.

• Проверить как можно раньше

Разработка истории происходит быстро во время спринта. В группе из нескольких человек она длится от одного до трех дней.

Для проверки необходимо запустить тесты на последней версии программного обеспечения. Если какие-то тесты ее не проходят, быстро вносится исправление (после добавления Post-it® в таблицу). Минимальная цель – пройти все тесты до окончания спринта. Более амбициозная цель – пройти их несколько раз в течение спринта, после каждого завершения истории или изменения в коде.

Чтобы избежать регрессии, для каждой новой версии следует повторять все тесты. По этой причине следует подумать об их автоматизации.

• Принять условие и завершить историю

На основе результатов выполнения тестов и с учетом проверок критериев завершенности Владелец продукта объявляет историю завершенной. В ином случае сообщает команде о том, что не так.

Рисунок 19.3 – История принимается не всегда

Владелец продукта может делегировать это, если команда использует роение или если он в данный момент недоступен и не может сделать это быстро.

В крупных организациях обычно разделяют процессы разработки продукта и обновлений после ввода в эксплуатацию. Фаза техобслуживания наступает после первичной разработки. При этом команды, процедуры и инструменты чаще всего отличаются.

В Scrum этого разделения нет: сезоны продолжаются, Scrum-фреймворк и Agile-практики все так же применимы, тот же бэклог и, желательно, те же команды.

Можно продолжать работать в рамках Scrum, дополняя его техниками из Kanban, подробнее об этом в главе 20.

Определение ошибки зависит от проекта и точек зрения участников. Определение устранения ошибки, предложенное мною в главе 6 «Структура бэклога», не соответстует общепризнанному.

• В текущей истории

Дефект, который был обнаружен в истории, находящейся в разработке, является условием непринятия: история не завершена. Участники команды, работающие над историей, просто добавляют задачу, необходимую для его исправления.

Этот дефект не помещается в бэклог, не говоря уже об использовании инструмента отслеживания ошибок: было бы пустой тратой времени и сил.

Так что он не считается ошибкой.

• В завершенной истории

Случается, что ошибка обнаруживается в истории, которая была разработана в предыдущем спринте и на данный момент считается завершенной. А зря, так, к сожалению, часто бывает. Под эту категорию также попадают ошибки в частях продукта, разработанных до того, как в проект был внедрен Scrum.

Чем значительнее ошибка, тем сильнее она снижает полезность истории.

✓ Критическая ошибка затрудняет функционирование одной или нескольких историй, их полезность при этом становится нулевой.

✓ Серьезная ошибка ограничивает функционирование, полезность истории уменьшается.

✓ Незначительная ошибка означает, что история теряет часть своей ценности, ее использование затрудняется.

Если у истории отсутствует условие приемки, это не ошибка, а новая пользовательская история. В бэклог вносятся только незначительные ошибки, которые не требуют дополнительного условия принятия.

Ошибки, отраженные в бэклоге, обрабатываются в соответствии с рабочим процессом: они дорабатываются и упорядочиваются. Владелец продукта должен решить, является ли исправление (некритической) ошибки более важным, чем разработка новой пользовательской истории.

• Ошибка в существующем коде

Если команда внедрила технику разработки через тестирование, она сначала пишет модульные тесты, которые воспроизводят ошибку (красный этап), а затем пишут код для прохождения тестов (зеленый этап). Таким образом, команда улучшает общее качество ПО.

Ситуация. Архитектор, принимающий важные решения, не состоит в команде и не участвует в коллективной работе.

Последствия. Команда вынуждена соглашаться со всеми решениями. Она демотивирована и теряет способность проявлять инициативу.

Как сделать лучше? В Scrum-команде отсутствует роль архитектора. Agility на практике означает, что эксперт может подавать пример и пачкать руки, при этом он активно сотрудничает с другими участниками команды.

Ситуация. Начинающие Scrum-команды не завершают истории в течение спринта. Некоторые истории длятся спринтами!

Последствия. Участники команды должны возвращаться к коду, написанному в прошлом спринте.

Как сделать лучше? Такого рода проблема вызвана разделением ролей разработчика и тестировщика. Если тестировщик получает программное обеспечение для тестирования в самом конце спринта, в лучшем случае он обнаружит ошибки, которые уже не сможет исправить до завершения спринта. Скорее всего, он просто перенесет тесты на следующий спринт. Практики BDD и роение помогают избежать этой проблемы.

Ситуация. Все участники команды работают по одному.

Последствия. Все заканчивается тем, что задача или история не могут быть завершены, потому что кто-то из участников не справился.

Как сделать лучше? Лучшим решением этой проблемы будет предложение другому участнику работать в паре.

Ситуация. Те, кто разрабатывает ПО, иногда воспринимаются как исполнители. Их подталкивают к быстрому написанию кода в ущерб качеству.

Последствия. Накапливается технический долг.

Как сделать лучше? Постоянно развиваться в применении практик разработки.

Для этого следует рассматривать практики как один из важнейших элементов разработки, что не всегда соблюдается менеджерами или Владельцами продукта.

Движение Software Craftmanship зародилось с целью продвижения этой идеи, которая была сформулирована в Манифесте Software Craftsmanship [60].

Чтобы идти дальше

Книги

‣ Ричард Шеридан «Работа мечты. Как построить компанию, которую любят», МИФ, 2014

‣ Ален Саке, Mettre en œuvre DevOps, Dunod, 2018.

‣ Corey Haines, Understanding the Four Rules of Simple Design

Онлайн-ресурсы

‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/

‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum

Scrum кажется простым. Но вот уже двадцатую главу я стараюсь объяснить, как лучше его применить в работе. Kanban отчасти похож на него, и его столь же сложно описать. Он был создан Дэвидом Андерсоном несколько лет назад и с тех пор сильно изменился. Первоначально Kanban рассматривался как Agile-метод, основанный на концепции вытягивающей системы [61], которую впервые применила Toyota для разработки программного обеспечения. Сближение со Scrum дало гибридный термин ScrumBan, а также множество идей, изложенных в том числе в книге «Kanban & Scrum, Getting the best of both». В 2009 году я участвовал в переводе этой книги и докладывал эту тему на конференциях.

Kanban позиционировали как новый метод улучшения процесса разработки. В конце предисловия ко второму изданию книги Лорана Мориссо [Morisseau, «Kanban»] я резюмировал Kanban следующим образом:

Не просто еще один Agile-метод, но новый сервис-ориентированный метод улучшения процессов в соответствии с ценностями и принципами Agility, который способствует постепенному переходу и направлен за пределы проектов, на сами организации, пусть даже крупные, а то и за пределы ИТ.

Мое последнее предложение отразило миссию Kanban: быть методом управления, точнее, даже управления изменениями, и охватывать и другие области, помимо разработки программного обеспечения.

При написании этой главы я не преследовал цели предложить Kanban в качестве альтернативы Scrum. Я хотел бы показать, как в определенных ситуациях Kanban может дополнить, обогатить Scrum. Я начал это делать в предыдущих главах, предложив изображать рабочий процесс при помощи паттерна лотков, а также использовать паттерн роения – это все практики, появившиеся в Kanban. В самом начале я представил Scrum как поток событий – и в этом он похож на Kanban.

Scrum, очевидно, во многом вдохновлен Kanban-паттернами.

В этой главе я детальнее рассмотрю Kanban в качестве метода улучшения, применяемого к Scrum. Цель в том, чтобы при помощи других паттернов найти подход к проблемам, возникающим в определенных ситуациях, где применяется Scrum.

Здесь я обратился к командам, уже внедрившим Scrum в свою работу. Провел опрос и узнал о наиболее частых проблемах. Представляю их ниже в виде карты (подробнее об инструменте impact mapping можно узнать в главе 15).

Рисунок 20.1 – Карта воздействия для улучшения

Цель опрошенных команд – гибко реагировать на изменения. Воздействия, относящиеся к тем или иным ролям, представляют собой ожидаемые ответы на возникшие проблемы.

Решения для достижения этих воздействий уже были представлены в предыдущих главах: роение, доработка и т. д. Жирным шрифтом на рисунке 20.1 выделены другие практики, или Kanban-паттерны, о которых мы узнаем в данной главе.

Речь в основном о ситуациях, когда команда сталкивается с высокой динамикой изменений (критерии контекстуализации в главе 14 «Контекстуализация Scrum»).

Kanban – это метод улучшения в виде постепенного и плавного изменения. Он заключается в следующих принципах:

✓ Начинать с того, что есть.

✓ Настроиться на постепенное изменение.

✓ Уважать текущий процесс, роли и обязанности.

В нашем подходе «Kanban в дополнение к Scrum» мы исходим из рамок Scrum с его спринтами, событиями, ролями и бэклогом.

Kanban предлагает шесть практик:

1. Визуализация рабочего процесса.

2. Ограничение незавершенной работы.

3. Измерение рабочего потока и управление им.

4. Четкая формулировка и прояснение правил управления процессом.

5. Имплементация циклов обратной связи.

6. Коллективное улучшение.

Порядок следования принципам соответствует степени, в которой Kanban применяется в работе.

Можно отметить, что остальных принципов мы хотя бы частично коснулись в предыдущих главах.

Ограничения используются, чтобы сделать поток более понятным и предсказуемым в системе. Цель в том, чтобы избежать перегрузки и обеспечить доступность.

Часто используется аналогия с дорожным движением: ограничение скорости позволяет уменьшить количество пробок и создать условия для беспрепятственного движения. Этот, казалось бы, парадокс еще больше сбивает с толку в мире работы, где совершенно непонятно, как замедление процесса может улучшить общую производительность.

В частности, ограничение связано со столбцом доски (или лотком). Как только достигнут определенный предел элементов в столбце, новая запись невозможна, и перед командой встает вопрос, что делать дальше.

Это верхний предел, который помогает команде избежать захламления задач. По достижении этого предела участники обсуждают имеющиеся задачи, поощряется взаимопомощь.

Все, что здесь представлено, остается в Scrum-фреймворке, сохраняется структура и, в частности, спринты. Мы несколько изменили процесс планирования спринта, чтобы сделать его более гибким: в работу запускаются только начатые истории (см. главу 9).

Kanban-практика, которую мы накладываем на этот процесс, ограничивает работу. Давайте посмотрим, какие паттерны нам в этом помогут на уровне задач, историй и функциональностей.

Начнем с введения верхнего предела для самого маленького элемента: задач.

На Scrum-доске спринта задачи разделены по трем колонкам: к выполнению, в процессе или к завершению, завершено. Добавить, под предлогом Kanban, еще один столбец в план спринта было бы очень плохой идеей: это создает очередь выполнения и многозадачность.

Ограничение текущих задач способствует обсуждению внутри команды и улучшает ситуацию. Это отправная точка для дальнейшего продвижения.

Одним из сложнейших для выполнения является принцип Scrum не беспокоить команду во время спринта. Он часто не соблюдается в организациях, которые только-только внедрили Scrum. Принцип нарушается – и команда не достигает цели спринта.

Kanban предлагает смягчить этот принцип и рассматривать срочные задачи как поток изменений на уровне задач.

Если появляется срочная задача, команда добавляет ее в таблицу задач, при этом их количество также ограничено.

Любое нарушение этого принципа ставит под сомнение цель спринта. Всякий раз, когда команда переключается на выполнение срочной задачи, стоит поднять вопрос о корректировке цели спринта. Если срочная задача потребовала у команды значительного количества времени, скорее всего, имеет смысл ее пересмотреть. Однако изменение цели спринта имеет последствия для заинтересованных сторон, о чем тоже нельзя забывать.

Рисунок 20.2 – Горячая линия для срочных задач

Ограничение помогает снизить риск постоянных корректировок. Однако применить этот принцип на практике непросто: человеку, пришедшему к команде со срочной задачей, будет сложно принять ответ не сейчас. Возможно, за этим последуют изменения в культуре.

Ограничивается количество срочных задач вообще или только тех, что в процессе выполнения? Или и то, и другое?

Команда, которая пробует эту технику, должна сама прийти к ответу, а также договориться о числе, при котором достигается предел. Пределы устанавливаются эмпирическим путем. Разумно браться за срочные задачи по очереди.

Команде нужно решить, как действовать в случае возникновения срочной задачи: взяться за ее выполнение немедленно, после завершения задачи или после завершения истории. Желательно все же не отвлекать разработчика от его работы.

Можно попробовать визуализировать срочные задачи с введенным ограничением. Это поможет команде меньше отвлекаться во время спринта. Команде, которую часто отвлекают, эту практику следует применять с осторожностью. Ее следует использовать только на временной основе.

Рисунок 20.3 – Срочные задачи в таблице

Напомню, для каждого спринта можно создавать резервные пустые истории и наполнять их возникающими срочными задачами.

Для понимания паттерна ограничение незавершенной работы следует сперва прочитать главу 9 «Планирование спринта».

• Быстрая реакция на изменения

Команды, которые овладели принципами и ценностями Scrum и соблюдают ритм спринта, иногда разочаровываются, что не могут быстро внедрить срочные изменения.

Мы знаем, что во время планирования спринта, в самом конце, истории переходят в колонку в процессе.

Они готовы и ожидают своего момента, уступая место более срочным, которые могли быть обнаружены командой уже после начала спринта.

Таким образом, команда может быстрее реагировать на изменения во время спринта и уменьшить давление со стороны на этапе планирования.

• Явное ограничение

Паттерн ограничение незавершенной работы состоит во введении явного ограничения на количество историй в процессе. В классическом Scrum ограничение исходит из продолжительности спринта.

На схеме мы видим ситуацию, когда команда добавила две истории во время спринта.

Процесс планирования спринта выглядит следующим образом: собрание заканчивается, когда достигается предел, и команда пополняет список, когда истории заканчиваются.

Рисунок 20.4 – Ограничение незавершенных задач

Следуя принципу приверженности и вовлечения, команда не ставит под сомнение концепцию цели спринта. Это означает, что первые истории среди тех, что не вошли в спринт, также будут реализованы.

Во время спринта можно провести дополнительные сессии планирования, если по результатам схватки было решено пополнить список историй.

Рисунок 20.5 – Повтор событий спринта

• Преимущества

Основное преимущество заключается в том, что команда лучше реагирует на изменения.

Индикаторы спринта, как, например, burndown-график, становятся ненужными.

Упрощается создание доски спринта. Для историй и задач в процессе необходимо меньше места, и их количество стабильно от спринта к спринту (введенное ограничение меняется нечасто).

Можно ввести ограничение по типу историй, чтобы каждому из них присвоить определенную производительность.

• Риски

Этот паттерн требует быть осторожным в отношении следующих пунктов:

✓ Поэтапное планирование затрудняет определение цели спринта и ее достижение.

✓ Добавление историй во время спринта требует хорошего понимания критериев готовности.

✓ Простота процесса может сподвигнуть Владельца продукта запросить еще больше изменений во время спринта.

Для лучшего понимания паттерна ограничение с самого начала необходимо сначала ознакомиться с главами 6 и 7.

Далее можно расширить принцип, внеся ограничение размера частей бэклога (истории в доработке, готовые истории).

Паттерн лотков состоит в визуализации рабочего процесса, что совпадает с первым принципом Kanban. Ограничение лотков позволит еще сильнее сократить список задач.

Поскольку песочница предназначена для общего сбора запросов и идей, не рекомендуется ее ограничивать – в ином случае это станет препятствием.

• Ограничение в стартовом лотке

При достижении верхнего предела команда начинает обсуждение. Достижение нижнего предела столбца означает, что пора добавить новые элементы, чтобы избежать их нехватки в дальнейшей работе.

Рисунок 20.6 – Ограничение в стартовом лотке

• Ограничение в лотке доработки

Паттерн ледяного лотка уже сам по себе является способом ограничения размера лотка доработки. Если он используется командой, то нет нужды, чтобы как-либо еще ограничивать размер лотка доработки – кроме тех случаев, когда это возможность не допустить преждевременного разделения epic-истории на части.

Ограничение имеет смысл, если лоток доработки еще не ограничен рамками сезона.

Внесение ограничения приводит к уменьшению размера бэклога. В нормальных условиях число историй, на котором надо вводить ограничение, вдвое больше количества готовых историй.

Ограничивать истории хорошо, ограничивать функциональности еще лучше. Верно ли это утверждение? Давайте проверим.

Функциональности помещаются в kanban-таблицу, столбцы которой представляют рабочий процесс.

Внесение ограничения в столбце приводит к уменьшению списка незавершенных функциональностей. Давление, вызванное ограничением, побуждает к обсуждению того, что важнее для команды: начать или закончить?

В том случае – если функциональность вводится в эксплуатацию конечными пользователями сразу после ее завершения – ограничения помогут сгладить процесс, тем самым сократив так называемое время цикла.

Рисунок 20.7 – Ограничение функциональностей

Приносить ценность с помощью функций – хорошо, еще лучше – убедиться, что есть реальное воздействие на участников.

Организации, использующие технику impact mapping для стратегического планирования, в некотором роде применяют Kanban, исследуя только одно воздействие за раз (плюс обратная связь).

Kanban предлагает новые метрики.

Его легко измерить, достаточно в нужный момент добавить к функциональности дату.

Но с другой стороны, создание индикатора, использующего время такта – как, например, контрольный график – мне не кажется целесообразным, учитывая небольшое количество функциональностей.

Одним из индикаторов в Kanban является накопительная диаграмма потока. Она показывает количество элементов по вертикали. Если речь об историях, то считается количество элементов в лотках. Получается накопительная диаграмма лотков.

Рисунок 20.8 – Накопительная диаграмма лотков

Им действительно сложно пользоваться, признаю, это потребует усилий. Но не таких больших, если команда использует паттерн лотков. Этот индикатор трудно интерпретировать. По сути, это комплексный инструмент анализа, для которого нужно иметь достаточно данных. Но усилия, приложенные для его создания, вознаграждаются огромным объемом получаемой при его помощи информации.

Анализ ситуаций, когда следует остановить Scrum, не является основной целью этой главы: в ней мы больше фокусируемся на применении Kanban в дополнение к Scrum. Но существует риск их неправильного использования. Иногда все же встает вопрос об остановке Scrum и применении одного Kanban. Для этого действительно могут быть веские причины. А могут и не быть.

Один из рисков – внесение ограничения только на задачи. Мы также говорили об основном риске в преамбуле: команде, еще не овладевшей Scrum, не стоит соединять его с Kanban. В ином случае у нее, вероятно, не получится ни то, ни другое.

Среди доводов тех, кто говорит: «Мы останавливаем Scrum, чтобы перейти на Kanban», некоторые мне кажутся очень сомнительными:

✓ собрания занимают слишком много времени,

✓ спринт – это смирительная рубашка, ограничивающая команду,

✓ зачем сохранять спринт, если развертывание проходит вне установленного ритма?

На это можно ответить: это не просто собрания, и в Kanban команду ждет то же самое. Фактически, много времени занимает процесс оценки, и в целом можно продолжать Scrum без него.

Давление на команду часто возникает из-за неправильно понятых обязательств. Но эту проблему тоже можно решить.

Можно также установить особый ритм, чтобы, например, договориться о регулярных встречах с заинтересованными сторонами.

Кроме того, на мой взгляд, применять Kanban труднее, чем Scrum. Он требует статистических знаний, которыми обладают очень немногие разработчики.

• Слишком много срочных задач

Как уже было сказано в первой главе, Scrum подходит не для всех ситуаций, особенно если команда постоянно сталкивается с изменениями.

Как понять, подходит контекст команды или нет?

• Ритм спринта больше не нужен

Scrum-команда, успешно внедрившая в свою работу Kanban, может задаться вопросом об остановке спринтов.

Она овладела принципом ограничений и ловко управляет потоком историй.

Она чувствует себя достаточно опытной, чтобы рассинхронизировать планирование, обзор и ретроспективу. Она проводит их по требованию, то есть, в случае необходимости, а не ориентируясь на ритм спринта.

Если команда останавливает спринты, можно утверждать, что это больше не Scrum. Главное – оставаться Agile.

Рисунок 20.9 – Можно быть Agile, не отвлекаясь на события

Во втором издании этой книги (2010 год) появилась глава «Scrum в больших масштабах». С тех пор эта тема расширилась, разные структуры были предложены и проданы, то есть прошли сертификацию и стали предметом обсуждения на конференциях.

Я неоднократно участвовал в переходе проектов на более крупные масштабы. Я также много читал и наблюдал. И моя позиция изменилась: я вернулся к простоте – я бы сказал, вернулся к Scrum. На мой взгляд, Scrum в большом масштабе имеет право на существование, но только в том случае, если для него не создаются новые роли.

Я переименовал главу, так ее основная цель стала яснее. Действительно, scaling Scrum (или, в более широком смысле, Agility в крупном масштабе) стал темой, о которой все говорят и задают много вопросов. В этой книге я решил отдельно рассмотреть Scrum для разработки продукта несколькими командами (что является предметом данной главы) и Agility для трансформации организаций (о чем мы узнаем в следующей).

Scrum создан для разработки сложных продуктов. Срок их службы может быть продолжительным, и в Scrum-фреймворке он регулируется последовательностью сезонов и командой, о которой мы узнали в предыдущих главах.

В фокусе этой главы Scrum на несколько команд. Интуитивно понятно, что необходимость в нескольких командах коррелирует с разработкой масштабных продуктов – настолько крупных, что для них требуется нечто большее, чем одна Scrum-команда. Но о каких ситуациях идет речь?

И хотя мы будем стараться все упростить, применять Scrum в больших масштабах сложнее, чем с одной командой.

Рисунок 21.1 – Scrum и масштабы

Лучше по возможности избегать больших масштабов, ну или хотя бы не запускать проект на несколько команд с самого начала.

В большинстве случаев этого и не требуется. Продукт часто не такой уж и большой, и одна команда может сделать многое.

Но если продукт слишком объемный, иногда можно разбить его на независимые части (подсистемы) и сформировать Scrum-команду для каждой из них. Крупномасштабный Scrum не нужен, по крайней мере, на первых порах.

Если в нем действительно возникнет необходимость, переходить к нему стоит постепенно: начать с одной команды, затем создать еще одну и т. д.

Когда я только начинал работать в Scrum-фреймворке, ответ на вопрос о масштабах процесса был прост: мета-Scrum! И в качестве примера практики это был Scrum of Scrums, схватка схваток. Помимо ежедневных схваток каждой команды была еще одна с представителями от каждой команды!

Я не сразу осознал, что за этой, казалось бы, упрощенной схемой скрывается фрактальный аспект подхода.

Суть фрактального подхода в том, что одни и те же концепции применимы на разных уровнях. То, что допустимо на уровне одной команды, применимо и к другим.

Большинство паттернов, которые будут представлены в этой главе, являются частью LeSS [62].

Как сохранить силу Scrum при работе в больших масштабах? Как избежать возврата к подходу командование и контроль, когда координируешь сразу несколько команд?

В книге «Lean Enterprise» в качестве ответа на эти вопросы автор предлагает принцип миссии.

Речь идет об определении миссии организации, ее четкой формулировке, объяснении, почему она важна, – и наконец, о том, чтобы позволить людям, отвечающим за выполнение, достичь ее. При этом не нужно составлять подробных планов и следить за их исполнением.

Этот принцип направлен на согласование – ту же цель, что и у подхода для создания первоначального бэклога (см. главу 15). При работе нескольких команд этот принцип гарантирует их самоорганизацию и автономность, что важно для реализации Scrum в хороших условиях.

Для лучшего понимания этого раздела рекомендую сперва ознакомиться с главами 3, 4 и 5.

Экосистема одной команды состоит из ее участников и заинтересованных сторон. Для нескольких команд заинтересованные стороны одни и те же. Экосистемы в большом масштабе отличаются взаимоотношениями команд.

В этой новой среде существует понятие общей цели, определенной во время прелюдии. Принцип границ, который способствует обмену знаниями и опытом, применим и к отношениям между командами.

Как организовать несколько команд, работающих над одним и тем же продуктом?

Они должны уметь самоорганизовываться, чтобы приносить результаты. Результат – это функциональность. Такой паттерн распределения работы известен как продуктовая команда [Larman, «Feature team»].

Понятие функциональности детально рассмотрено ранее, и это упрощает понимание концепции продуктовой команды.

Это перекликается с понятием кроссфункциональности команды.

Продуктовая команда – это Scrum-команда с ее классическими характеристиками (свойства Scrum-команды представлены в главе 3). Она должна быть подходящего размера, самоорганизованной, кроссфункциональной, самобытной и стабильной. Кроссфункциональность имеет особое значение для обеспечения командой ценности, ограничивая при этом зависимости от других команд.

Каждая продуктовая команда представляет собой Scrum-команду, которая реализует свои функциональности, разбивая их на истории. У каждой команды есть свой Scrum-мастер.

С ролью Владельца продукта все обстоит несколько иначе.

Владелец продукта – это роль, связанная одновременно и с продуктом, и с командой. При больших масштабах над одним продуктом работает несколько команд, что, разумеется, влияет на роль PO.

Связь между ролью и продуктом сохраняется (и это подчеркивается в наименовании роли): у продукта есть только один РО, который работает с несколькими командами. Это действенный принцип – в случае, если количество команд остается небольшим, до трех или даже четырех, и если команды немногочисленны.

Рисунок 21.2 – Один Владелец продукта для нескольких команд

Иногда же возникает необходимость иметь других Владельцев продукта, например, по одному для каждой основной функциональности. Есть вариант создать роль Владельца продукта для каждой команды или для каждых двух-трех команд.

Таким образом, формируется группа РО для одного продукта.

Это тоже команда, и у нее, как у любой другой, есть свой Владелец продукта. Эта роль называется РО из РО, начальник РО или менеджер по продукту. Многие решения принимаются коллегиально, но при необходимости окончательное слово будет за человеком, исполняющим данную роль.

В главе 3 были представлены зоны, соответствующие разным уровням взаимосвязей между участниками процесса. В многокомандном контексте в зону 3 также включены взаимоотношения между командами.

Далее мы увидим, как события Scrum побуждают команды к общим встречам. Более того, между ними возникают взаимосвязи, необходимые для работы над функциональностью. В некоторых случаях применим паттерн роения: функциональность, находящаяся под ответственностью одной команды, реализуется при поддержке других команд.

Создание сообществ для обмена практиками – это еще один способ обмена опытом и, соответственно, укрепления сотрудничества между командами. Это особенно важно для обмена техническими навыками, необходимыми для работы со сложными системами.

Когда задействовано столько человек, вряд ли они все смогут находиться в одном рабочем пространстве. Для комфортного сотрудничества следует обратиться к инструментам для совместной работы на расстоянии, что не исключает возможности видеться друг с другом регулярно – например, в конце сезона.

Для лучшего понимания этого раздела рекомендую сперва ознакомиться с главой 2.

Рисунок 21.3 – Последовательность сезонов в жизненном цикле продукта

В Scrum отсутствует фаза проекта для первой разработки, за которой следовала бы фаза техобслуживания: жизнь продукта состоит из спринтов и сезонов.

Когда несколько команд разрабатывают один продукт, каждая из них проводит свой спринт. Но команда не устанавливает собственный темп и продолжительность спринта. Применяется паттерн сезонного ритма:

Рисунок 21.4 – Паттерн сезонного ритма в больших масштабах

Суть паттерна в том, что он увеличивает частоту интеграции для всех команд. Не возникает ситуаций, когда приходится ждать поставку от запаздывающей команды, чтобы собрать все части воедино. Частая интеграция улучшает качество и снижает риски. Ускоряется обратная связь, что ограничивает цену изменения.

Точно как и спринты, сезоны команд синхронизированы: одна дата начала, одна дата завершения. Все следуют одному ритму.

Общая для всех команд цель каждого сезона – добиться максимальной ценности продукта в заданные и известные временные рамки. Вот наш треугольник: дата и стоимость определены заранее, содержание, ориентированное на увеличение ценности, может корректироваться.

Рисунок 21.5 – Корректировка в космической программе

В конце сезона два момента, на которые стоит обратить внимание.

✓ Для ретроспективы и планирования нужен высокий уровень синхронизации между командами.

✓ Состав команд может меняться.

В целом паттерн сезонного ритма идет рука об руку с вводом в эксплуатацию в конце сезона. Но важно помнить, что ввод в эксплуатацию не связан с непосредственным завершением спринтов и сезонов: ввод в эксплуатацию должен произойти как можно скорее, что действительно и для Scrum в больших масштабах.

Прелюдия с участием нескольких команд бывает нечасто. Лучше начинать с малого, с одной команды, и постепенно добавлять в процесс новые. Если же это действительно необходимо, все команды используют один шаблон прелюдии и техники, которые представлены ниже.

Для лучшего понимания этого раздела рекомендую сперва ознакомиться с главами 6 «Структура бэклога», 7 «Доработка бэклога» и 8 «Определение критериев завершенности».

Философия заключается в сохранении концепции единого бэклога для нескольких команд.

Паттерн рабочего бэклога/бэклога поставки предполагает использование kanban-таблицы функциональностей, что интересно и в масштабе одной команды. Если же в процессе задействовано несколько команд, такая таблица становится обязательным инструментом. Упорядоченность элементов в таблице имеет фундаментальное значение для общего понимания приоритетов.

Также при помощи такой таблицы можно разделить работу между командами. Функциональность, как правило, – это ответственность одной команды, на что указывает какой-либо атрибут (например, цвет), добавленный к каждому элементу.

Рисунок 21.6 – Таблица функциональностей для трех команд

Итак, у команд есть бэклог поставки (представленный в виде таблицы функциональностей). Он один для продукта, даже если продукт большой.

Должны ли команды, работающие над одним и тем же продуктом, иметь общий бэклог со всеми историями? Или у каждого есть своя часть в общем бэклоге? Это решать командам!

Командам важно знать, что они будут делать во время спринта. Поэтому у каждой из них должен быть свой собственный план спринта.

Традиционная доработка (помимо того, что выполняется каждой командой) проводится еще и на более высоком уровне – уровне функциональностей. Во время сессии доработки решается, какие новые функциональности команды возьмут в работу.

Рисунок 21.7 – Доработка в больших масштабах практикуется в Авероне[63]

Это собрание предшествует сессии доработки на уровне каждой команды.

В нем участвует группа Владельцев продукта, эксперты и представители команд (в случае, если у команды нет своего собственного Владельца продукта).

Действия во время крупномасштабной доработки следующие:

✓ разбить большие функциональности на части,

✓ обсудить, какие пойдут в работу, выявить зависимости и риски, определить готовность,

✓ упорядочить функциональности,

✓ определить, какая команда отвечает за реализацию функциональности; другие, соответственно, участвуют в роении.

Критерии готовности и завершенности одни для всех команд – так обеспечивается единый уровень качества. Роль критериев не меняется с увеличением количества команд.

Критерии разрабатываются коллективно во время прелюдии. Особое внимание следует уделить критериям завершенности для функциональности.

Этот раздел требует знания глав 9 о планировании спринта, 10 о ежедневных схватках, 11 об обзоре спринта и 12 о ретроспективе.

Каждая команда – одновременно с другими – проводит свое обычное планирование спринта. В случае, если команды находятся в одном рабочем пространстве, все они располагаются перед бэклогом. Владелец продукта перемещается от группы к группе.

Кроме того, проводится небольшое общее собрание, чтобы вспомнить и, возможно, скорректировать распределение функциональностей, напомнить цель сезона и, прежде всего, синхронизироваться командами.

Крупномасштабная схватка – тот самый легендарный Scrum of Scrums. Это напоминает мне большую схватку в регби, о которой писал Даниэль Эрреро [Эрреро, «Rugby»]. Только в нашем случае в ней участвуют не все сразу.

Этот паттерн упрощает коммуникацию между несколькими командами.

Схватки могут проходить не одновременно, так что один участник может принять участие в нескольких схватках. За ними следует схватка схваток, которая, возможно, проводится не так часто – например, раз в два дня. На этой встрече присутствуют представители от каждой команды, Scrum-мастера или другие лица, которые лучше всего подходят для обсуждения между командами.

Во время этой схватки схваток может быть выявлено препятствие, в котором задействованы сразу несколько команд. В таком случае в течение дня нужно провести встречу с представителями всех затронутых команд для устранения препятствия (продолжая сравнение с регби: именно со схватки начинается общее сражение).

Обзор проводится коллективно с участием всех, кто работает над продуктом. На демонстрации показывается совместно разработанный инкремент продукта. Это предполагает, что непрерывная интеграция осуществляется на уровне продукта и всеми командами.

Владелец продукта (или группа РО) проводит эту встречу, которая, по сравнению с обзором от одной команды, очевидно, займет больше времени. На нее приглашены команды и все заинтересованные стороны.

Каждая команда проводит свою ретроспективу. По запросу команды возможна организация общей ретроспективы. Вероятно, она будет проведена с началом следующего спринта. Команда делает запрос о проведении ретро, когда сталкивается с организационным препятствием, или чтобы внести изменения в общие критерии завершенности.

В конце сезона проводится общая ретроспектива для всех команд. Она охватывает большее количество вопросов и занимает больше времени. Ретроспектива может занять весь день, и команды могут провести ее иначе. Например, это может быть встреча в виде открытого форума, на который приглашены все участники и заинтересованные стороны.

Рисунок 21.8 – События спринта для нескольких команд

Ситуация. Организации переходят на Scrum в больших масштабах. Некоторые менеджеры считают, что необходимо индустриализировать процесс.

Последствия. Это создает большую путаницу, так как участники вынуждены работать по методологии, которую им навязывают.

Как сделать лучше? Даже если Scrum в больших масштабах кажется хорошей идеей, лучше переходить к нему только в случае реальной нужды.

Рисунок 21.9 – Новые методы следует искать только в случае масштабной проблемы

Ситуация. Есть несколько команд, и организация навязывает им одни и те же методы. Методы сформированы коучами, которые установили в организации определенные рамки. Менеджеров успокаивает эта структура: она дает им ощущение, что контроль по-прежнему в их руках.

Последствия. В итоге получается все то же самое, только вид сбоку (откуда и название антипаттерна). Созданы новые роли. Способы работы навязаны командам, которые, в свою очередь, лишены автономии.

Как сделать лучше? Использовать принцип миссии. Каждая команда свободна выбирать свой способ работы и самоорганизовываться, чтобы достигать поставленных целей. Одни команды могут выбрать Scrum, другие – Kanban.

Ситуация. Менеджеры крупных проектов, привыкшие составлять подробные планы, делают то же самое с историями и даже задачами.

Последствия. Скорость команды под пристальным наблюдением, что, конечно, оказывает давление на участников.

Как сделать лучше? Учитывая, насколько разработка сложных систем может быть неопределенной, не нужно строить слишком далеких планов. И не стоит эти планы слишком сильно детализировать. В их основе должны быть элементы побольше, чем истории.

Ситуация. В 2012 году большой интерес вызвала публикация крупного эксперимента с участием нескольких команд [Книберг, «Spotify»]. После нее некоторые предложили сделать этот опыт образцом крупномасштабной Agility.

Последствия. Все говорят о гильдиях (guilds) и отрядах (squads). Люди копируют, игнорируя контекст.

Как сделать лучше? Книберг напоминает, что проведенный эксперимент – это не образец для подражания, но очень интересный опыт в строго определенном контексте. На что стоит обратить внимание, так это на создание продуктовых команд, применение инженерных практик и коммуникацию между командами.

Чтобы идти дальше

Онлайн-ресурсы

‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/

‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum

‣ Крэйг Ларман и Бас Водда, Fonctionnalité Team Primer, VF, 2010

‣ Martin Fowler, LargeAgileProjects, 2003

‣ Хенрик Книберг и Андерс Иварссон, Agilité à grande échelle chez Spotify, VF, 2012.

Команда сформирована, создала свою экосистему во время прелюдии и установила ритм спринтов и сезонов. Каждый раз в конце спринта она проводит ретроспективу, чтобы обсудить, каким образом улучшить рабочий процесс в следующем спринте.

Это все замечательно. Но насколько этот процесс жизнеспособен? Идеи пермакультуры в Scrum внедряются с целью создания устойчивой экосистемы.

В VUCA-мире (нестабильном, неопределенном, сложном и неоднозначном) множество ловушек. И часто они возникают вне созданной экосистемы. Системология побуждает нас обратить внимание и сосредоточиться на более крупной системе – той, что окружает экосистему Scrum, то есть на всей организации или даже на совокупности нескольких. Чтобы процесс был устойчивым и жизнеспособным, вероятно, этим организациям придется пройти через трансформацию.

Цель этой последней главы – предложить пути для трансформации, чтобы закрепить Agile-практики на уровне команды, экосистемы и, если необходимо, организаций.

Scrum-команда поддерживает Agility преимущественно благодаря ретроспективе спринта (глава 12). Это быстрый и регулярный способ совершенствования и адаптации.

Ретроспектива – дело команды. В этот момент участники фокусируются на том, что они могут улучшить самостоятельно. Это замечательно. Но есть то, что можно улучшить только на уровне экосистемы и с привлечением заинтересованных сторон.

Постоянная адаптация в условиях Scrum будет эффективной только в случае стабильной команды. Как мы поняли из главы 3, стабильность – один из важнейших аспектов Scrum-команды.

Стабильность не означает бездействие: возможно привлечение новых участников или выход кого-либо из команды. Но никакие изменения не должны нарушать свойства Scrum-команды.

Выявленные командой препятствия могут мешать или полностью останавливать разработку продукта. Препятствия могут возникать из-за:

✓ Scrum-практик;

✓ практик, дополняющих Scrum, в частности инженерных;

✓ сопротивления заинтересованных сторон Scrum;

✓ управления организацией, которое слишком ограничивает экосистему.

Для первых двух причин команда обычно может найти решения самостоятельно. Третья и четвертая касаются экосистемы.

Ретроспектива спринта – это практика, направленная на регулярное улучшение и поддержание духа Scrum-команды. Но эта практика ограничивается рамками одной команды.

Цель ретроспективы сезона – в развитии всей экосистемы.

Благодаря паттерну сезонного ритма эта ретроспектива имеет регулярный характер. На нее приглашаются все участники экосистемы. Она длится полдня или полный рабочий день.

Она может проходить как ретроспектива спринта, разве что занимать больше времени, так как она охватывает более длительный период и проводится с большим количеством участников.

Чтобы установить курс на постоянное улучшение экосистемы, я рекомендую использовать модель Agile Fluency и практиковать Ката Совершенствования [64], которые побуждают оценивать прогресс в течение всего сезона, а не только в конце.

• Модель Agile Fluency

Эта модель [Шор, Fluency] использует восприятие бизнес-ценности, создаваемой командой, чтобы определить уровень владения Agility. Модель любопытна тем, что помогает согласовать усилия с ожиданиями. Применяемая для команды, она показывает, что амбициозные цели требуют изменений в организации.

Рисунок 22.1 – Модель Agile Fluency (перевод и адаптация Джеймса Шора и Дианы Ларсен © 2018).

Каждая зона соответствует уровню владения Agile.

Модель помогает команде определить свой текущий уровень и уровень, который она стремится достичь.

• Ката Совершенствования

Ката Совершенствования [65] появилась на основе концепции Lean. Майк Ротер, разработчик Ката, предлагает четырехфазный подход:

✓ Определить ожидаемое воздействие (что мы хотим?).

✓ Определить текущую ситуацию (где мы сейчас?).

✓ Определить промежуточную цель на пути к ожидаемому воздействию.

✓ Экспериментировать с целью достижения поставленной цели.

В нашем контексте Ката Совершенствования представляет собой дополнительный инструмент для проведения ретроспективы сезона.

Вместе с моделью Agile Fluency она помогает ответить на два поставленных вопроса и определить промежуточную цель, учитывая продолжительность сезона.

Вот как выглядит процесс в первый раз:

✓ Участники знакомятся с моделью Agile Fluency (отлично срабатывает аналогия с музыкальными группами).

✓ Затем они вместе думают, в каком направлении хотят двигаться по модели. Они устанавливают курс на один-два года. Участники фокусируются на ожидаемом воздействии (этот этап может быть проведен в виде рабочей встречи под названием ретро-футуристическое воздействие, представленной в главе 15).

✓ Они определяют свой уровень на данный момент и решают, на каком уровне модели хотят оказаться.

✓ Они договариваются о промежуточной цели на три месяца (продолжительность сезона), которая способствовала бы достижению воздействия. Для этого полезно опираться на практики и паттерны, которые, по мнению участников, могут помочь им на пути к цели.

По мере развития экосистемы команда может привлечь одного или двух новых людей, но в какой-то момент придется разбить состав на две команды. Участники сами решают, как им организоваться. Для поддержания экосистемы важно сохранять баланс между командами и обмен между участниками.

Рисунок 22.2 – Роение

Роение практикуется, когда Scrum-мастер (или кто-либо из участников) запускает новую команду для разработки другого продукта.

Лучший для этого момент – конец сезона. Таким образом, новый сезон начинается с новыми с командами.

Чтобы устранить препятствие, иногда приходится его передавать на уровень руководства организации.

С первой главы мы советовали начинать с фазы Shu, то есть приступать к внедрению Scrum со следования практикам, и уже много страниц спустя – контекстуализировать Scrum. Одно не противоречит другому. Возникающее таким образом трение позволяет быстро преодолевать препятствия в двух классических ситуациях:

✓ если команде не удается начать с фазы Shu из-за контекста;

✓ если она хочет перейти с Shu на На.

Разрешение этих препятствий требует участия руководства или других лиц. А для их окончательного устранения часто необходима трансформация организации.

Не всегда достаточно изменений на уровне экосистемы. Когда существует большой культурный разрыв между культурой организации и духом Scrum, приходится задать себе вопрос об Agile-трансформации всей организации.

Напомним себе цель Scrum, о которой мы говорили в первой главе:

Внедрение Scrum в рабочий процесс одной команды, или даже нескольких команд, начинается без трансформации всей организации. Вопрос об Agile-трансформации встает, когда организация осознает: для достижения результата ей нужно меняться, в частности, изменить свою структуру, а иногда и культуру. Вернемся к нашему определению Agility:

Это определение позволяет нам выразить, что такое Agile-трансформация:

Можно заменить слово Agile на Digital или любое другое, что сейчас в моде. Фактически, чтобы закрепить Scrum в экосистеме, необходимо провести культурное выравнивание организации.

Рисунок 22.3 – Scrum-мастер добивается успеха в Agile-трансформации

При устранении организационных препятствий часто оказывается, что их первопричина кроется в проблемах, связанных с культурой. И если ничего не менять в культуре организации, вероятнее всего, препятствия вернутся.

Корпоративной культурой часто пренебрегают. Поставив на первый план краткосрочные финансовые цели, компании не стремятся стать слаженными коллективами, группами взаимодополняющих людей с осознанием принадлежности – как у настоящей Scrum-команды.

Корпоративная культура – важный параметр Agile-трансформации. Внедрение Scrum с его новым языком и новыми обычаями неизбежно влияет на культуру организации.

Компании, уделяющие внимание корпоративной культуре, лучше других подготовлены к трансформации. Те, кто рассматривает Scrum в качестве инструмента повышения производительности и игнорируют культурный аспект, с большей вероятностью потерпят неудачу.

Трансформация будет тяжелой в тех компаниях, где не разделяют культуру Scrum – культуру сотрудничества. Процесс может быть непростым и занять больше времени в организациях, которые придерживаются культуры контроля, а не индивидуальных компетенций [Сахота, «Transformation»].

А вообще, вместо того, чтобы трансформировать организации, не пора ли открывать организации будущего?

• Модель Reinventing Organizations

В книге об организациях будущего («Reinventing Organizations») Фредерик Лалу представляет пять стадий развития компании. Каждая стадия соответствует определенному цвету:

✓ Красная (импульсивная)

✓ Фиолетовая (традиционная)

✓ Оранжевая (успешная)

✓ Зеленая (плюралистическая)

✓ Бирюзовая (эволюционная)

При помощи этой модели можно разобраться в причинах трения, возникающего между Scrum-командой и ее окружением.

Бирюзовая организация, по определению Лалу, полностью соответствует Agile-культуре. Scrum-команда в такой организации может успешно развиваться и адаптироваться.

В зеленой организации возможны неслаженность и разногласия. В оранжевой организации будет больше конфликтов, а в фиолетовой – еще больше. В таких случаях необходимо выравнивать организацию либо путем ее изменения, либо через предоставление экосистеме полной автономии.

Трансформация – это управление изменениями. При классическом управлении в крупной организации цикл имплементации изменения через пилотный проект выглядит следующим образом:

Рисунок 22.4 – Классический процесс управления изменениями

Этот подход можно применить и для нашей Agile-трансформации. Вот только он чрезмерно линейный и скорее нисходящий, что делает его не совсем пригодным для сложной трансформации. Кроме того, все организации разные, и у каждой трансформация своя.

В книге «Reinventing Organizations» Фредерик Лалу цитирует остроумный ответ Жана-Франсуа Зобриста, когда последнего спросили, каким образом можно оживить организацию [66]: разбирайтесь с этим сами!

Совершенно верно. Но для этого есть инструмент и принципы.

При общем подходе Agile-трансформация происходит с применением Scrum. Рассматривать трансформацию как проект или программу и передавать ее в руки специалистов по процессам – определенно не лучшая идея.

Однако в крупных организациях есть агенты изменений, которые регулярно проводят реорганизации. Правда, изменения, навязанные сотрудникам, в большинстве случаев не эффективны.

Agile-трансформация основывается на понятии приглашения. Приверженность будет только сильнее, если она будет добровольной.

В крупных организациях трансформация начинается с группы или отдела. При этом важно участие начальника отдела или организации.

Подход Open Space Agility, разработанный Дэном Мезиком, предлагает регулярный цикл, который отлично сочетается с сезонным ритмом. Обряд перехода – это событие, придающее особую важность организационной культуре, которая помогает людям освоиться при сложных переходах.

Это событие протекает в виде открытого форума [67].

В день проведения открытого форума участники выкупают вопросы и темы для обсуждения.

В конце встречи собираются полученные в ходе обсуждения конкретные идеи для будущей трансформации. Желательно, чтобы в течение сезона были запущены не все идеи сразу.

Для получения дополнительной информации о данной технике рекомендую прочитать «День Open Agile Adoption» [Перно, «OOA day»].

Трансформация опирается на ценности и принципы Scrum.

Шесть свойств Scrum, представленных в первой главе, являются фундаментальными принципами трансформации организации.

• Появление

Идеи трансформации исходят не сверху или от обособленной группы экспертов. Они появляются в самих людях, на основе их жизненного опыта и их чувств. Не обязательно при этом участвовать в обсуждении и предлагать свои идеи, это происходит добровольно.

Этот принцип также говорит о том, что не существует заранее установленной программы, которая бы задавала направление дискуссии. Практикуя Open Space Agility, участники сами предлагают важные для них темы.

• Приоритизация

Как показывает ретроспектива спринта, всегда есть что улучшить, и идей больше, чем команда может реализовать. Здесь тот же принцип, только в более долгосрочной перспективе, поэтому идеи по улучшению процесса расставляются в порядке приоритетности.

• Предприимчивость

Трансформация требует временных и финансовых затрат. Инвестор трансформации устанавливает рамки и бюджет, а заинтересованные стороны определяют лучший способ действий. Самоорганизация способствует развитию культуры, подталкивает людей проявлять инициативу, освободиться от предрассудков, продвигать революционные идеи.

Рисунок 22.5 – Революционная идея

• Прозрачность

Решения принимаются коллективно, это усиливает командную приверженность и вовлеченность. Предпочтительны методы голосования, учитывающие второстепенные результаты. Действия, предпринятые в соответствии с решениями, доступны и видны всей организации. В этом может помочь Kanban-доска.

• Практика

Со Scrum и Agility никогда не знаешь обо всем заранее. Здесь требуется эмпирический подход с петлями обратной связи от заинтересованных сторон трансформации. Нет и речи о том, чтобы заранее на бумаге описать весь процесс. Цель трансформации поддерживается менеджером, инвестором инициативы. Эта цель задает направление, и прогресс проверяется и адаптируется самими участниками процесса.

• Постоянный ритм

Как и в Scrum-фреймворке, заданный ритм упрощает процесс трансформации. В идеале он совпадает с ритмом сезона. Конец сезона – отличный момент, чтобы пригласить людей к участию в процессе.

Закончим на возвращении к Scrum. Как и в предыдущих главах, я предлагаю список антипаттернов и паттернов, но в данном случае – прибегнув к названиям моих презентаций на конференциях.

В 2016 я выступил на нескольких конференциях с темой «Scrum? Срам!» («Scrum? mon scrotum!»), а затем в 2017 – с «Scrum? Сезам!» («Scrum? mon sérum!»).

Названия вдохновлены памфлетом Доминика Дюпаня «Quality my Q⁵⁴», в котором он выступает против искажения идеи качества [68].

Я хотел бы показать, как может быть искажен Scrum, и способы, как можно этого избежать.

Я выявил пять основных причин искажения Scrum.

Рисунок 22.6 – Пять причин

• Незнание

При всей популярности Scrum он остается малоизученным. Часто люди не понимают самих основ Agile-разработки.

Примеры: тесты проводятся в рамках спринта, следующего после реализации, а не во время демонстрации в конце спринта.

• Мизонеизм

Мизонеизм означает сопротивление инновациям. В Scrum речь идет о социальных инновациях, от которых иногда отказываются в пользу привычных практик.

Примеры: команда отказывается от таблиц со стикерами в пользу инструмента управления тикетами, ретроспектива превращается в обычный отчет.

• Страх

Scrum эффективен только в атмосфере доверия. Но иногда организация (фиолетовая или оранжевая, по модели Ф. Лалу) придерживается иерархической системы контроля.

Примеры: команда разработчиков находится под руководством бывшего менеджера проекта, который в нынешних условиях стал Scrum-мастером (или Владельцем продукта), давление и навязанная скорость команды.

• Недооценивание

Scrum часто воспринимается как метод разработки в рамках более крупного процесса. Scrum применяется только для разработки ПО, после этапа спецификации и до момента ввода в эксплуатацию.

Это приводит к циклу по V-модели.

• Гордыня

Бывает, команда утверждает, что вот у них все иначе, они адаптировали Scrum к своему контексту. Адаптация Scrum часто приводит к его искажению. Команда решила не тратить времени на изучение основ (Shu) и считает себя достаточно опытной, чтобы применять свой собственный метод (На). Гордыня участников мешает их прогрессу.

Примеры: команда заявляет, что успешно применяет ScrumBan, хотя на деле участники просто добавили столбцы в план спринта, команда работает без Владельца продукта, потому что считает, что справляется и так.

В 2017 я добавил способы предотвращения искажения Scrum. Новая презентация называлась «Scrum? Сезам!».

Рисунок 22.7 – Сезам

• Против мизонеизма

Люди отрицают социальные инновации, когда не понимают, зачем они нужны.

Критично важно осознавать, почему был осуществлен переход к Scrum и Agility вообще.

Для этого необходимо коллективное осмысление ожидаемых преимуществ перехода. В этом помогает модель Agile Fluency, устанавливающая цель и дату.

• Против незнания

Существует много способов узнать о Scrum больше. Речь в основном о том, как можно достичь цели. В первую очередь следует изучить принципы, и уже потом практики.

Команды могут прийти к этому сами, читая книги или записавшись на онлайн-курс, или получив образование [69] и участвуя в Agile-конференциях. Есть также Agile-ассоциации, книжные клубы и т. д.

• Против страха

Защищать людей, создавать атмосферу доверия – это самое важное: это позволяет им идти на риски и полностью реализовать свой потенциал.

Доверительная обстановка формируется уже во время прелюдии.

Стоит начать с разделения рабочего пространства на зоны.

• Против недооценивания

Сокращение Scrum до нескольких действий по разработке не позволяет команде получить максимальной отдачи от подхода. Поскольку понятие ценности является фундаментальным, Scrum-команда должна нести ответственность за всю цепочку создания ценности.

Команда должна перейти от общего – понятий, рассмотренных в главах с 13 по 15 (создание команды, разработка первоначального бэклога) – к частному с практиками DevOps (непрерывное развертывание).

• Против гордыни

Прежде чем пытаться изменить правила игры, хорошо бы некоторое время смириться с ними и попробовать им следовать.

Понять, что делать, можно только на практике и путем закрепления привычек.

Знание паттернов дает возможность для маневров, что позволяет без искажений адаптироваться к контексту.

Рисунок 22.8 – Открывая организации будущего: переход к пермакультуре

Чтобы идти дальше

Книги

‣ Jurgen Appelo, #Workout: Games, Tools & Practices to Engage People, Improve Work and Delight Clients, Happy Melly Express, 2014

‣ Dan Mezick, The culture game, FreeStanding Press, 2012

‣ Лоран Сарразен и др., Rupture Douce, les quatre saisons, 2014

Онлайн-ресурсы

‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/

‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum

‣ Dan Mezick, Open Space Agility, Web

‣ Michael Sahota, Agile Adoption and Transformation, VF, 2013

‣ Пабло Перно, Open Agile Adoption en une journée, Web.