Введение

Скрам (Scrum) стал популярен, потому что он работает. Правда, эта техника достигла нынешней известности не мгновенно. Скрам развился как технология разработки продуктов в середине 1980-х годов в Японии и был усовершенствован в США в 1990-х годах. Скрам пробовали, писали о нем – и статьи, и просто в блогах, – но наиболее важным было то, что в процессе этого он постоянно улучшался. В конечном итоге была получена какая-то критическая масса успешных проектов, и про Скрам заговорили.

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

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

Блистательная мысль

Нет плохого способа начать работать со Скрамом – главной ошибкой будет вообще не пробовать.

Рис. 5.1. Фреймворк Скрам

Рис. 5.2. Цикл спринта

 

Фреймворк

Как и все хорошие идеи, Скрам часто интерпретируется неверно. Чтобы снизить вероятность того, что идеи будут поняты неправильно, Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeff Sutherland) создали «Руководство по Скраму» (Scrum Guide). Оно постоянно обновляется, доступно бесплатно на www.scrumguides.org и является единственным документом, объясняющим суть Скрама. Изменения вносятся редко; весь текст занимает 16 страниц вместе с содержанием и стоит того, чтобы с ним ознакомиться.

Скрам объединяет принципы «бережливого управления» и принципы Agile. Это не инструмент управления проектами, это принципы организации выпуска продукта – между этими двумя понятиями есть важные различия. Когда все идет хорошо, легко даже позабыть, что используется Скрам. Он предназначен только для поддержки хода работ, и об этом важно помнить.

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

• Теория: главное, знать фундаментальные принципы, не нужно особенно в нее углубляться.

• Роли команды: Владелец Продукта, Скрам-мастер и команда разработки: это основные роли.

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

• Артефакты: журнал требований (бэклог) продукта, журнал требований спринта и другие.

Блистательное определение

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

Мы не могли бы дать лучшее определение.

Управляйте не временем, а приоритетами.

Деннис Уэйтли (мотивационный спикер)

 

Самоорганизующиеся команды

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

 

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

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

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

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

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

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

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

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

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

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

Блистательный эффект

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

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

 

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

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

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

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

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

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

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

Блистательный эффект

Скрам-мастера – невоспетые мастера на все руки: посредники, помощники, советники и разрешители проблем.

Хороший Скрам-мастер делает работу над проектом намного проще.

 

Команда разработки

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

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

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

Блистательный эффект

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

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

 

Ключевые Скрам-события

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

Пять Скрам-событий:

• спринт – общий цикл для остальных событий;

• планирование спринта – происходит в самом начале работы;

• ежедневная летучка (дейли Скрам) – происходит каждый день (без исключений);

• обзор итогов – проводится в конце спринта;

• ретроспектива – подводит итоги.

 

Спринт

Спринт – жестко фиксированный по времени, от одной до четырех недель, временной период (time-box) для всех остальных Скрам-событий. Обычно команды выбирают длину спринта в две недели, но идеальной продолжительности нет – во всех вариантах будут присутствовать и плюсы, и минусы. Если есть сомнения, лучше начать с одно- или двухнедельного спринта и посмотреть, как пойдут дела.

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

Блистательный совет для сохранения времени

В «Руководстве по Скраму» не упоминаются пользовательские истории – у владельца продукта могут быть и другие способы объяснить свои идеи. Пользовательские истории в основном просто самый популярный метод.

Не распыляйтесь, тратя время на другие варианты, – идите по проторенному пути.

 

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

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

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

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

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

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

Блистательный пример

Команда разработки решает, какой объем работы войдет в спринт, но Владелец продукта и Скрам-мастер тоже принимают в этом участие.

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

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

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

• Если ответ «нет», разберитесь в причинах. Например, если история слишком большая, ее следует разбить на подзадачи. Если ответ все еще «нет», продолжайте обсуждение.

• Повторяйте этот процесс, пока журнал спринта не станет, возможно, непростым, но главное – выполнимым.

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

• Сделано!

 

Ежедневная летучка

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

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

– Да, иногда наши совещания бывают весьма динамичными

Ежедневное совещание придерживается очень простого формата: каждому члену команды задается три вопроса.

• Что вы делали вчера? Отслеживание прогресса.

• Что вы будете делать сегодня? Обсуждение плана.

• Какие затруднения у вас возникают? И это – самый главный вопрос.

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

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

Блистательный пример

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

• Шумный наблюдатель – тот, кто не входит в состав команды, но будет пытаться встать и вмешаться в обсуждение. Скрам-мастер должен объяснить, что любые посторонние могут только наблюдать! Любые замечания можно выслушать потом.

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

• Отвлекающий – прерывает встречу, часто непреднамеренно, но всегда с отрицательными последствиями. Совет: придерживайтесь сценария; все послушают о вашем неудачном свидании в другое время.

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

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

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

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

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

 

Обзор итогов

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

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

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

• Удовлетворение ожиданий заинтересованных сторон: уже на ранней стадии разработки они видят, что получат! И никаких сюрпризов в последнюю минуту.

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

Блистательный пример

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

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

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

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

• Все карточки помещаются на стол, а Скрам-мастер поясняет, все ли было закончено, а если нет, то почему.

• Скрам-мастер обновляет пользовательские истории, входящие в спринт.

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

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

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

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

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

 

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

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

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

Сосредоточивайтесь на том, что впереди, а не оглядывайтесь постоянно назад.

Колин Пауэлл (бывший государственный секретарь США)

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

Блистательный пример

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

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

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

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

 

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

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

Журнал требований продукта

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

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

Журнал требований спринта

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

Диаграмма сгорания задач

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

Блистательная мысль

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

Блистательная мысль

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

Особенно будьте внимательны в случае задач, которые завершены на 99 %.

 

Завершающие слова

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

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

Блистательный итог

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

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

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

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

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

• Лучший способ начать – это просто начать!