Простое руководство по Теории и Практике Скрама
Версия 2.0
Пит ДимерGoodAgilewww.goodagile.com

Габриель Бенефилд
Evolvewww.evolvebeyond.com

Крэг Ларман
www.craiglarman.com

Бас Водди
Odd-e
www.odd-e.com

A note to readers: There are many concise descriptions of Scrum available online, and this primer aims
1Примечание для читателей: Существует много кратких описаний Скрама в сети, а это руководстводля начинающих помогает достичь следующего уровня в понимании практики. Оно не является
конечным шагом в изучении Скрама; командам, которые рассматривают возможность переходана Скрам, рекомендуется вооружиться книгой Скрам. Гибкое управление продуктом и бизнесом КенаШвабера или Scrum. Гибкая разработка ПО Майка Кона, также воспользоваться многими
превосходными вариантами обучения и коучинга по Скраму, которые доступны; больше
информации вы можете найти на сайте scrumalliance.org. Выражаем благодарность КенуШваберу, Джеффу Сазерленду и Майку Кону за их щедрый вклад.

Последняя версия Азбуки Скрама (Scrum Primer) расположена по адресу:http://www.infoq.com/minibooks/Scrum_PrimerПереводы можно найти по адресу: http://www.scrumprimer.org/© 2012 Пит Димер, Габриель Бенефилд, Крэг Ларман, Бас Водди

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

ОбзорСкрам - фреймворк разработки, в котором кросс-функциональные команды разрабатывают
продукты или проекты в итеративно-инкрементальном стиле. Он структурирует процесс
разработки в циклы, называемые Спринтам. Эти итерации не могут быть длиннее четырёх
недель (обычно две недели), и идут одна за одной без остановки. Спринты ограничены по времени они заканчиваются в определённые даты, независимо от того, была ли закончена работа или нет,и никогда не продлеваются. Обычно Скрам-команды выбирают длину Спринта один раз, а затем
придерживаются её до того, как внедрят улучшения и смогут её сократить. В начале каждого
Спринта кросс-функциональная Команда (около 7 человек) выбирает элементы (требования
пользователей) из приоритизированного списка. Команда договаривается об общей цели, вкоторую они верят и могут поставить в конце Спринта, что-то осязаемое и что будет
действительно ”готово”. Во время Спринта новые элементы не могут быть добавлены; Скрам
принимает изменения только в следующий Спринт, но текущий короткий Спринт предназначендля достижения небольшой, четкой и относительно стабильной цели. Каждый день Команда
собирается ненадолго, чтобы провести инспекцию прогресса и адаптировать следующие шаги,необходимые для завершения оставшейся работы. В конце Спринта Команда проводит его обзор
вместе с заинтересованными лицами, демонстрирует то, что готово. Люди получают обратную
связь, которая может быть учтена в следующем Спринте. Скрам подчёркивает, что работающий
продукт должен быть по-настоящему “готов“ в конце Спринта; в случае с разработкой
программного обеспечения это означает, что система интегрирована, полностью
протестирована, содержит документацию для конечных пользователей и потенциально готова кпоставке. Ключевые роли, артефакты и события приведены на Иллюстрации 1.

3

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

РолиВ Скраме всего три роли: Владелец Продукта, Команда и Скрам-мастер. Вместе они известны, какСкрам-команда.
Владелец Продукта (Product Owner, PO) несёт ответственность за максимизацию возврата наинвестиции (ROI) путём определения новой функциональности для продукта, перевода её вприоритизированный список, решая, что должно быть сверху этого списка на следующий
Спринт, и непрерывной реприоритизации и прояснения этого списка. Владелец продукта несёт
ответственность за доходы и расходы (PNL, profit and loss) продукта, если это коммерческий
продукт. В случае внутреннего продукта в компании Владелец продукта не несёт ответственность
за ROI в смысле коммерческого продукта (который генерирует доход), но на нём всё же лежит
ответственность за максимизацию ROI в смысле выбора - каждый Спринт - самых ценных
элементов. На практике, ‘ценность’ является нечётким термином, поэтому на приоритизацию
могут влиять: желание удовлетворить ключевых клиентов, соответствие стратегическим целям,снижение рисков, улучшение и ряд других факторов. В некоторых случаях Владелец Продукта иклиент один и тот же человек; это обычная практика для внутренних приложений. В других
случаях клиентами могут быть миллионы человек с разными потребностями, поэтому тут рольВладелец Продукта похожа на должность Менеджера Продукта (Product Manager, PM) илиМенеджера по Маркетингу (Product Marketing Manager) в разных организациях. Однако Владелец
Продукта — это нечто отличное от традиционного Менеджера Продукта, потому что он активнои часто взаимодействует с Командой, приоритизирует, учитывает мнения всех заинтересованных
лиц (stakeholders, SH), и делает обзор результатов каждый Спринт, а не делегирует решения поразработке Менеджеру Проекта (Project Manager, PM). Важно отметить, что в Скраме существует
один и только один человек, который играет эту роль - и несёт полную ответственность запродукт - Владелец Продукта, и он(а) ответственны за ценность работы; хотя этому человеку необязательно работать в одиночку.
4Команда (Team), официально называемая Командой Разработки (Development Team, DT),создаёт такой продукт, на какой указывает Владелец Продукта: приложение или веб-сайт,например. Команда в Скраме “кросс-функциональна” - она содержит все виды экспертизы,необходимые для поставки потенциально готового продукта каждый Спринт - она“самоорганизованная” (самоуправляемая), с высокой степенью автономии и ответственности.
Команда решает, как много элементов (из предложенного Владельцем Продукта набора) взять вразработку в Спринте, и как лучше всего это сделать.
Каждый член Команды просто член команды. Заметьте, что в группе, которая внедряет Скрам, нетчетких должностей; здесь нет бизнес-аналитика, нет администратора баз данных, нетархитектора, нет тимлида, нет UX/UI-дизайнера, нет программиста. Они работают вместе втечение каждого Спринта любым способом, подходящим для достижения цели, которую онипоставили перед собой.
Поскольку есть только члены команды, Команда не только является кросс-функциональной, нотакже демонстрирует множественное обучение (multi-learning): каждый человек, безусловно,имеющий более сильные стороны в определённой области, также продолжает изучать и другие
направления. Каждый человек имеет первичные, вторичные, и даже третичные навыки, чтоозначает “следуй туда, где есть работа” (go to where the work is); он берёт на себя задачи в менее
знакомых ему областях, чтобы помочь завершить элемент полностью. Например, человек спервичными навыками в дизайне мог бы иметь вторичный навык в автоматизации тестирования;кто-то с первичными навыками в написании технической документации мог бы также помочь санализом и написанием кода.
Команда в Скраме состоит из 7 плюс/минус 2 людей, и для программного продукта Команда
могла бы включать людей с навыками аналитики, разработки, тестирования, проектирования
интерфейсов, проектирования баз данных, архитектуры, документации, и так далее. Команда
развивает продукт и предоставляет идеи Владельцу Продукта, как сделать продукт лучше. ВСкраме, Команды более продуктивны и эффективны, если все её члены на 100 процентов
выделены на работу в одном продукте в течение всего Спринта; Команда избегает
многозадачности в нескольких продуктах или проектах, чтобы предотвратить увеличение ихстоимости из-за рассеянного внимания и переключение контекста. Стабильные команды
достигают высокой продуктивности, поэтому избегайте смены членов Команды. Продуктовые
группы с большим количеством людей могут организоваться в несколько Команд, каждая изкоторых может концентрироваться на разной функциональности продукта, с тесной
координацией их совместных усилий. Как только одна команда начинает постоянно делать всюработу (планирование, анализ, программирование и тестирование) в задачах, ориентированныхна конечного клиента, то такую Команду называют фиче-командой.
Скрам-мастер (Scrum Master, SM) помогает продуктовой группе изучить и внедрить Скрам дляполучения бизнес ценности. Скрам-мастер делает всё, что в его власти, чтобы помочь Команде,Владельцу Продукта и организации быть успешными. Скрам-мастер не является руководителем
членов Команды или менеджером проекта, тимлидом или их представителем. Вместо этого,Скрам-мастер служит Команде; он(а) защищает Команду от внешнего воздействия, помогает
устранить препятствия и внедрить современные инженерные практики. Он(а) учит, тренирует инаставляет Владельца Продукта, Команду и всю остальную организацию в правильном
использовании Скрама. Скрам-мастер — коуч и учитель. Скрам-мастер удостоверяется, что все(включая Владельца Продукта и менеджмент) понимают принципы и практики Скрама, и онпомогает вести организацию через зачастую трудные изменения, необходимые для успеха вгибкой разработке ПО. Поскольку Скрам делает заметными множественные препятствия иугрозы эффективности Команды и Владельца Продукта, то важно иметь вовлечённого Скраммастера, энергично работающего над разрешением данных проблем, иначе Команде и Владельцу
продукта будет сложно добиться успеха. Скрам-мастер должен быть выделенной ролью напостоянной основе, однако в маленькой Команде член команды может играть его роль (неся приэтом меньшую нагрузку из регулярной работы). Великие Скрам-Мастера могут иметь любой опытили специализацию в прошлом: Инженерия, Дизайн, Тестирование, Продуктовый Менеджмент,Менеджмент Проектов или Менеджмент Качества.
5Скрам-мастер и Владелец Продукта не могут быть одним и тем же человеком, потому что ихфокусы настолько различны, что часто их совмещение ведёт к путанице и конфликтам. Одни изнежелательных результатов совмещения этих ролей проявляется в микроменеджменте (micromanaging) Владельца Продукта, что противоречит самоуправляемости команд, которую требует
Скрам. В отличие от обычного менеджера Скрам-мастер не говорит людям что делать и неназначает им задачи - он фасилитирует [англ. facilitate, помогает чему-то случиться, прим.
переводчика] процесс, поддерживают Команду в её самоорганизации и самоуправлении. Если впрошлом Скрам-мастер занимал руководящую должность в Команде, он должен в значительной
степени изменить своё мышление и стиль взаимодействия, чтобы Команда была успешна вСкраме.
Замечание: В Скраме в принципе нет роли менеджера проекта. Потому что она не нужна;традиционные обязанности менеджера проекта разделены и распределены между тремя ролямив Скраме, в большей степени Команде и Владельцу Продукта, нежели Скрам-мастеру. Работа поСкраму вместе с менеджером проекта указывает на полное непонимание Скрама, что приводит кконфликту ответственности, неясным полномочиям, и неоптимальным результатам. Иногда (экс)менеджер проекта может вступить в роль Скрам-мастера, но успех в этом случае сильно зависитот индивидуальных особенностей, и того, насколько хорошо он понимает фундаментальные
отличия между двумя ролями, как в повседневных обязанностях, так и в образе мышления,необходимом для успеха. Хороший способ полностью понять роль Скрам-мастера и начать
развивать основные навыки, необходимые для успеха - это посетить тренинг
Сертифицированный Скрам-мастер (Certified Scrum Master, CSM) от компании Scrum Alliance.

В дополнение к этим трём ролям также существуют заинтересованные лица, которые делают
вклад в успех продукта, включая руководителей, клиентов и конечных пользователей. Некоторые
заинтересованные лица, такие как функциональные руководители (например, руководители
инженеров), могут обнаружить, что их роль, хотя и не перестаёт быть ценной, меняется припереходе на Скрам. Например:•они поддерживают Команду, уважая правила и дух Скрама•они помогают убирать препятствия, которые обнаружили Команда и Владелец Продукта•они предоставляют свой опыт и экспертизуВ Скраме люди, которые раньше тратили время, играя роль “няни” (раздача задач, подготовка
статусных отчётов и другие формы микроменеджмента), могут посвятить его тому, чтобы стать
“гуру” или “служителями” (servant) для Команды (обеспечивая наставничество, коучинг, помогаяв устранении препятствий, в решении проблем, предлагая творческий вклад и направляя развитие
навыков членов Команды). При такой перестановке менеджерам необходимо изменить их стиль
руководства; например, использовать Сократовские вопросы, чтобы помочь Команде найти
решение проблемы, а не решить, что делать, и передать Команде на исполнение.

Бэклог ПродуктаПри переходе продуктовой группы на Скрам перед стартом первого Спринта им необходим
Бэклог Продукта (Product Backlog), приоритизированный (упорядоченный 1, 2, 3, ...) список
задач, ориентированных на клиента.
Бэклог Продукта существует (и развивается) на протяжении всего жизненного цикла продукта;это дорожная карта (roadmap) продукта (Иллюстрации 2 и 3). В любой момент Бэклог Продукта
является единственным, исчерпывающим представлением “всего, что могло бы быть сделано
Командой, в порядке приоритета”. Для продукта существует только единственный Бэклог
Продукта; это означает, что Владелец Продукта необходим, чтобы принимать решения оприоритетах на всём спектре, предоставляя интересы всех заинтересованных лиц (включая
Команду).

6Приоритет

Элемент

1Как покупатель, Я хочу положить книгу в корзину
(см. наброски UI в wiki)Детали
(ссылка на Wiki)Первоначальная
оценка

Обновлённая Оценкав Спринте

1

2

...

5

...

2

...

13

4

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

...

20

5

Обновить версию Apache до 2.2.3 на всех серверах ...

13

3

7

Диагностировать и исправить ошибки в порядке
исполнения скриптов (bugzilla ID 14823)
Как покупатель, Я хочу создавать и сохранять
список желаний

8Как покупатель, Я хочу добавлять и удалять
элементы в в моём списке желаний

6

...

3

...

40

...

20

2

3

4

5

6

Иллюстрация 2. Бэклог Продукта

Иллюстрация 3. Визуальное Управление: Элементы Бэклога Продукта на стене
Бэклог Продукта включает множество видов элементов, в первую очередь новую
функциональность для пользователей (“разрешить всем пользователем класть книги в корзину”),но также и основные цели по инженерному улучшению (напр., “переписать код системы с C++ наJava”), улучшения (напр. “ускорить наши тесты”), исследовательскую работу (“исследовать
решения для ускорения проверки кредитной карты”) и, возможно, известные дефекты
(“диагностировать и исправить ошибки порядка исполнения скриптов”), если только их немного
(системы с большим количеством дефектов обычно имеют отдельную систему управления
дефектами).
Элементы Бэклога Продукта могут быть сформулированы в любом понятном и поддерживаемом
виде. Вразрез с популярным недопониманием Бэклог Продукта не содержит “пользовательские
истории” (user stories); он просто состоит из элементов. Эти элементы могут быть выражены вформате пользовательских историй, сценариев использования или любом другом формате
описания требований, который группа сочтёт полезным. Но какой бы ни был выбран подход,большинство элементов должны быть сконцентрированы на поставке ценности клиенту.
7Хороший Бэклог Продукта является ИСЧЕРПЫВАЮЩИМ...
Подробно детализирован. Самые приоритетные элементы наиболее хорошо нормализованыпо размеру, прояснены и детализированы, чем остальные с более низким приоритетом, так какони попадут в работу раньше. Например, 10% верхушки Бэклога может состоять из очень
небольших, хорошо проанализированных элементов, а остальные 90% из более крупных.
Оценён. Элементы для текущего релиза должны иметь оценку, и, кроме того, следует
рассматривать возможность переоценки в каждом Спринте, поскольку все учатся и появляется
новая информация. Команда предоставляет Владельцу Продукта оценку своих усилий для каждого
элемента Бэклога Продукта, также, возможно, оценивая технические риски. Владелец Продукта идругие заинтересованные лица предоставляют информацию о ценности продуктовых запросов,которые могут включать получение дохода, снижение издержек, бизнес риски, важность для рядазаинтересованных лиц и т.д.
Актуален. В ответ на обучение и вариативность, Бэклог Продукта постоянно проясняется.
Каждый Спринт элементы могут быть добавлены, удалены, изменены, разделены, или у нихможет измениться приоритет. Поэтому Бэклог Продукта постоянно обновляется Владельцем
Продукта, чтобы отразить изменения в потребностях клиентов, новые идеи или сведения,действия конкурентов, возникающие технические препятствия и т. д.
Приоритизирован. Элементы верхушки Бэклога Продукта приоритизированы илиупорядочены в порядке 1-N. Обычно, самые высокоприоритетные элементы должны принести
наибольшую *отдачу от ваших вложений* [в ориг. идиома “bang for your buck”, прим.
переводчика]: больше бизнес-ценности за меньшую стоимость. Другая мотивация увеличить
приоритет элемента в том, чтобы разобраться с высоким риском раньше, чем он разберётся с вами. [в ориг.
игра слов “tackle high risks early, before the risks attack you”, прим. переводчика].
Традиционная разработка обычно не выделяет важность поставки элементов с самой высокой
отдачей от ваших вложений, но Скрам это делает, поэтому Владельцу Продукта необходимо
научиться, как определять “бизнес ценность”. Это такое обучение, в котором Скрам-мастер может
помочь Владельцу Продукта. Что значит “бизнес ценность”? Некоторые продуктовые группы
используют относительные очки ценности для каждого Элемента Бэклога, которые
представляют собой синтез “предположительных” факторов, включая рост доходов, сокращение
расходов, предпочтения заинтересованных лиц, рыночную дифференциацию и т.д. Некоторые
делают вложения в конкретный элемент для одного или нескольких клиентов, платящих за егоразработку, и поэтому определяют ценность на базе точного (краткосрочного) дохода от этого
элемента. В других продуктовых группах такая оценка конкретных элементов слишком
расфокусирована или гранулярна; они применяют более широкий поход, основанный на бизнес
выгоде ("увеличить количество подписок на 10% к 1-му сентября"), в котором ценность создаётся
только тогда, когда несколько элементов, способствующих результату, поставляются вместе. Вэтом случае Владелец Продукта должен определить следующий инкремент Минимально
Жизнеспособного Продукта (Minimum Viable Product, MVP).
Оценка затрат обычно производится в относительном виде (отражающем объём работы,сложность и неопределённость) и использует в качестве единицы измерения “очки историй”(story points) или просто “очки” (points).
Это только предложение; Скрам не определяет технику для выражения или приоритизации
элементов Бэклога Продукта, а также технику оценки затрат или её единицы измерения.
Обычно в Скраме применяется техника отслеживания того, сколько работы было закончено вкаждом Спринте; например: в среднем выполнено работы на 26 очков за Спринт. Зная этуинформацию можно прогнозировать дату релиза, к которой будут закончены все задачи, илисколько задач будет закончен к установленной дате, если в среднем это значение остаётся
неизменным. Это среднее называют “скоростью” (velocity). Скорость выражается в тех жеединицах, что и оценка элементов Бэклога Продукта.

8Элементы в Бэклоге Продукта могут значительным образом отличаться по размеру или затратам.
Большие разбиваются на более мелкие во время Уточнения Бэклога Продукта или Планирования
Спринта, а маленькие, наоборот, могут быть объединены. Элементы Бэклога Продукта длянескольких следующих Спринтов должны быть небольшими и прояснены достаточно, чтобы
быть понятными Команде, тем самым давая возможность прогнозу на Планировании Спринта
стать реалистичным; такой размер называется “реализуемый” (actionable).
Важные инженерные улучшения, которые требуют много времени и денег, также должны быть вБэклогое Продукта, раз уж они могут оказаться одним из вариантов инвестиций бизнеса, и вконечном итоге решения на их счёт должны быть сделаны бизнес-ориентированным Владельцем
Продукта. Обратите внимание, что в Скраме команда имеет независимые полномочия вотношении того, сколько элементов из Бэклога Продукта они решают взять в Спринт, поэтомуони могут самостоятельно выполнять незначительные инженерные улучшения, поскольку ихможно рассматривать, как часть обычных затрат на выполнения бизнес задач, и как то, чтотребуется разработчику для правильного выполнения своей работы. При этом в каждом Спринте
бóльшая часть времени Команды обычно должна отводиться целям Владельца Продукта, а не навнутренние инженерные задачи.
Один из мифов о Скраме, что он предостерегает вас от написания исчерпывающей
документации; в реальности это решение лежит на Владельце Продукта и Команде, какой
уровень детализации требуется, и он может меняться от одного элемента Бэклога Продукта кдругому, в зависимости от осведомлённости Команды или других факторов. Укажите, что важно,в минимально необходимом виде - другими словами, не описывайте все возможные детали
элемента, просто чётко укажите, что необходимо для его понимания, и дополните этопостоянным диалогом между Командой, Владельцем Продукта и заинтересованными сторонами.
Элементы Бэклога Продукта с низким приоритетом, над которыми не будут работать в течение
ближайшего времени, обычно являются "крупнодроблёными" (большие, с менее ясными
требованиями). Высокоприоритетные и детализированные Элементы Бэклога Продукта, которые
скоро будут реализованы, обычно содержат больше деталей.

Критерии Готовности
Результат работы в каждом Спринте официально называется Потенциально Готовым к Поставке
Инкрементом Продукта (Potentially Shippable Product Increment). Перед стартом первого Спринта
Владелец Продукта, Команда и Скрам-мастер должны определить всё, что нужно, чтобы Элемент
Бэклога Продукта стал потенциально готовым к поставке. Все действия, которые необходимы дляпоставки продукта, должны быть включены в определение Потенциально Готового к Поставке
и, следовательно, должны быть выполнены во время Спринта.
К сожалению, когда команды начинают использовать Скрам, у них зачастую не получается
достичь цели по поставке Потенциально Готового Инкремента каждый Спринт. Это обычно
происходит потому, что команде не хватает автоматизации, или она не является достаточно
кросс-функциональной (например, технические писатели еще не включены в состав кроссфункциональной Команды). Команде необходимо постоянно совершенствоваться, чтобы
предоставлять Потенциально Готовый к Поставке Инкремент Продукта каждый Спринт, но дляначала им потребуется сформировать базовый уровень своих существующих возможностей.
Результат этого фиксируется в Критериях Готовности (Definition of Done, DoD).
Перед стартом первого Спринта Владелец Продукта и Команда должны договориться оКритериях Готовности, которые являются частью действий, необходимых для создания
Потенциально Готового к Поставке Инкремента Продукта (для хороших Команд онисовпадают). Команда будет планировать работу в Спринте в соответствии с настоящими
Критериями Готовности.
Хороший Владелец Продукта всегда будет стремиться к тому, чтобы Критерии Готовности быликак можно ближе к Потенциально Готовому к Поставке, поскольку это повысит прозрачность
разработки и уменьшит задержки и риски. Если Критерии Готовности не равны Потенциально
9Готовому к Поставке, тогда работа откладывается до релиза, что вызывает этот риск и задержки. Этаотложенная работа иногда называется неготовой работой (undone work).
Скрам-команда должна постоянно улучшаться, что отражается в расширении их Критериев
Готовности.

Планирование Спринта
Описание: Встреча по подготовке к Спринту, обычно разделенная на две части (первая часть “что делать” и вторая часть - “как делать”).
Участники: Первая Часть: Владелец Продукта, Команда, Скрам-мастер. Вторая Часть: Команда,Скрам-мастер, Владелец продукта (необязательно, но должен быть доступен для вопросов).
Длительность: Каждая часть занимает не более, чем один час из расчёта на одну неделю
Спринта [т.е. не более восьми часов для четырёхнедельного Спринта, прим. переводчика].
Планирование Спринта (Spring Planning) происходит в начале каждого Спринта. Оноразделено на два отдельных части, первое из которых называется Первая Часть Планирования
Спринта (Sprint Planning Part One).
На Первой Части Планирования Спринта Владелец Продукта и Команда пересматривают
высокоприоритетные элементы в Бэклоге Продукта, в реализации которых заинтересован
Владелец Продукта в этом Спринте. Обычно эти элементы были хорошо проанализированы впредыдущем Спринте (во время Уточнения Бэклога Продукта), так что на этом событии
возникают лишь незначительные уточняющие вопросы. Во время этого события Владелец
Продукта и Команда обсуждают цели и контекст для этих высокоприоритетных элементов вБэклоге Продукта, передавая Команде представление о ходе мыслей Владельца Продукта. Первая
часть посвящена пониманию, что и почему хочет видеть Владелец Продукта. В конце первой
части (всегда занятый) Владелец Продукта может уйти, хотя он должен быть доступен (например,по телефону) во время второй части события.

В Первой Части Команда и Владелец Продукта может также предложить Цель Спринта (Sprint
Goal). Это краткое отражение бизнес-задач Спринта, которое в идеале связано с ними. ЦельСпринта также дает Команде гибкость в определении объёма и способа работ в Спринте, потомучто даже если им, возможно, и придется удалить какой-то элемент (поскольку Спринт ограниченпо времени), они, тем не менее, должны взять на себя обязательство предоставить что-тоосязаемое и “готовое” в духе Цели Спринта.
Насколько большими должны быть элементы, попадающие в Спринте? Каждый элемент должен
быть разделен на достаточно мелкие части, чтобы его оценка занимала значительно меньше
времени, чем весь Спринт. Обычно считается, что элемент достаточно мал, если согласно оценкевся Команда может завершить его за одну четверть Спринта или меньше.
Вторая Часть Планирования Спринта (Sprint Planning Part Two) нацелена на то, какреализовать элементы, которые команда решает взять на себя. Команда прогнозирует количество
элементов, которые они могут выполнить к концу спринта, начиная с верхушки Бэклога Продукта
(другими словами, начиная с элементов, имеющих наивысший приоритет для Владельца
продукта), и далее по порядку элементов в списке. Это ключевая практика Скрама: Команда,а не Владелец Продукта, решает, сколько работы она будет выполнять. Это делает прогноз
более надежным, поскольку Команда делает его на основе собственного анализа и планирования.
Несмотря на то, что Владелец Продукта не контролирует, сколько элементов берёт на себяКоманда, он(а) знает, что элементы взяты из верхней части Бэклога Продукта - другими словами,элементы, которые он(а) оценил, как наиболее важные. Команда имеет возможность лоббировать
элементы, которые находятся внизу Бэклога; обычно это происходит, когда Команда и Владелец
Продукта понимают, что что-то менее приоритетное и простое целесообразно сочетается свысокоприоритетными элементами.
Планирование Спринта часто длится несколько часов, но не более четырех часов длядвухнедельного спринта – Команда делает основательный прогноз, чтобы завершить работу, и10это требует тщательной проработки, чтобы достичь успеха. Первая и Вторая Части имеют
одинаковую продолжительность; для двухнедельного спринта каждая часть длится максимум двачаса.
Скрам не определяет, как именно проводить вторую часть планирования спринта. Некоторые
команды используют скорость, полученную в предыдущих спринтах, чтобы определить, к какому
результату нужно стремиться. Другие команды будут использовать более детальный подход,сначала рассчитывая свою ёмкость (capacity).
При оценке ёмкости Команда во Второй Части Планирования Спринта вычисляет, сколько
времени каждый член команды может посвятить работе, связанной со спринтом. Большинство
команд полагают, что члены команды могут сосредоточиться на работе, связанной со Спринтом,только 4-6 часов в день - остальное время уходит на электронную почту, обеденные перерывы,социальные сети, встречи и кофе. После определения ёмкости команде необходимо выяснить,сколько элементов Бэклога Продукта они могут выполнить за это время, и как они будут ихвыполнять. Это часто начинается с обсуждения дизайна на доске. Как только общий дизайн будет
понят, Команда разбивает Элементы Бэклога продукта на мелкие задачи. Прежде чем приступитьк работе с Элементами Бэклога продукта, Команда может сосредоточиться на создании задач поулучшению, обсуждаемых на Ретроспективе предыдущего Спринта. Затем Команда выбирает
первый элемент в Бэклоге Продукта - элемент с наивысшим приоритетом для Владельца
Продукта - и постепенно продвигается вниз, пока окончательно не ‘заполнит’ всю свою ёмкость.
Для каждого элемента они создают список работ, который состоит либо из разбитых на задачи
элементов Бэклога Продукта, либо, если элемент настолько мал, что на его реализацию
потребуется всего пара часов, то из него самого. Этот список работы в Спринте называется
Бэклог Спринта (Sprint Backlog) (Иллюстрации 4 и 5).
Элемент Бэклога
Продукта

Задача

Волонтёр

Первоначальная
Оценка

Изменить БД

5Создать страницу (UI)8Как покупатель, Я хочу Создать страницу (JavaScript)положить книгу вНаписать автоматические приёмочные
корзину
тестыОбновить раздел помощи для покупателей

Новая Оценка оставшейся
работы на конец дня...
1

2

3

4

5

6

13
13
3

...

Объединить DCP код и законченные тесты
слоёвУлучшить
производительность Закончить машинный заказ для pRankобработки транзакций
Изменить DCP и читателя дляиспользования pRank в HTTP API

5813Иллюстрация 4. Один из вариантов создания Бэклога СпринтаВ конце Планирования Спринта Команда ставит реалистичную цель в отношении того, что, поих мнению, они смогут выполнить к концу Спринта. Обычно это называлось Обязательством наСпринт (Sprint Commitment) - Команда обязуется сделать всё возможное, чтобы достичь своей
цели. К сожалению, это иногда неправильно истолковывалось как обещание, написанное
кровью, а не как то, что команда осознанно “идёт на это”. Чтобы избежать этой путаницы, цельСпринта теперь называется ‘прогнозом’ (forecast), который сообщается Владельцу Продукта.
Скрам поощряет чтобы работники имели разносторонние навыки, а не только “работающих вточности с должностной инструкцией”, как например “тестировщик”, занимающийся только
тестированием. Другими словами, члены Команды “идут туда, где есть работа” и помогают, чеммогут. Если задач на тестирование много, то все члены Команды могут помогать. Это не означает,что все являются универсальными; несомненно, некоторые люди особенно опытны втестировании (и так далее), но члены Команды работают вместе и учатся друг у друга новым
11навыкам. Следовательно, во время создания и оценки задач на Планировании Спринта нетнеобходимости - и нецелесообразно - считать людей потенциальными исполнителями по всемзадачам, “которые они могут сделать лучше всего”. Скорее, лучше вызываться добровольцем наодну задачу за раз, только когда пришло время браться за новую задачу, принимая во внимание
выбор задачи, которая будет специально включать обучение (возможно, в паре с экспертом). Этоодна из причин, по которой не следует заранее назначать задачи на людей во время
Планирования Спринта, скорее, это следует делать ‘по мере необходимости’ во время Спринта.
С учётом всего сказанного, есть редкие случаи, когда Джон может выполнять конкретную задачу,потому что обучение других невозможно или займет слишком много времени - возможно, Джон- единственный человек, обладающий какими-либо художественными навыками рисования
изображений. Другие члены Команды не смогли бы нарисовать “человечка из палочек”, дажеесли бы от этого зависела их жизнь. В этом редком случае - и если это не редкость и не становитсявсе реже по мере того, как Команда обучается, то что-то не так - может потребоваться спросить,выполнимы ли все запланированные задачи по рисованию, которые должны быть сделаны
Джоном в рамках Спринта.
Многие команды представляют Бэклог Спринта в виде доски задач размером со стену (часто
называемой Скрам-доской (Scrum Board)), где задачи (написанные на Post-It стикерах)переносятся во время Спринта по столбцам с пометками “Сделать” (To Do), “В Работе” (Work In
Progress) и “Готово” (Done). См. Иллюстрацию 5.

Иллюстрация 5. Визуальное управление - Задачи Бэклога Спринта на стене
Один из столпов Скрама заключается в том, что после того, как Команда устанавливает цельСпринта, любые дополнения или изменения должны быть отложены до следующего Спринта.
Это означает, что если в середине Спринта Владелец Продукта решит, что есть новый элемент,над которым он(а) хотел бы, чтобы команда поработала, он не сможет внести изменения доначала следующего Спринта. Если появляются внешние обстоятельства, которые существенно
изменяют приоритеты и означают, что Команда будет зря тратить время, если продолжит работу,то Владелец Продукта или Команда могут прекратить Спринт. Команда останавливается, и новое
12Планирование Спринта инициирует новый Спринт. Обычно это вносит огромную деструкцию;что сдерживает Владельца Продукта или Команду прибегать к такому радикальному решению.
Существует мощное положительное влияние, исходящее от Команды, которая защищена отизменения целей во время Спринта. Во-первых, Команда приступает к работе с абсолютной
уверенностью, что её цель не изменится, что усиливает её сосредоточенность на усилиях позавершению. Во-вторых, это дисциплинирует Владельца Продукта, заставляя его по-настоящему
подумать над теми элементами, которые он(а) считает приоритетными в Бэклоге Продукта ипредлагает взять Команде в Спринт.

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

Ежедневный Скрам
Описание: Обновление информации и координация между участниками Команды.
Участники: Участие Команды обязательно; Владелец Продукта опционально; Скрам-мастер
обычно присутствует, чтобы убедиться, что Команда его проводит.
Длительность: Не более 15 минут.

Как только начинается Спринт, Команда начинает регулярно использовать другую ключевую
практику Скрама: Ежедневный Скрам (Daily Scrum). Это короткое (15 минут или менее)событие случается в назначенное время каждый рабочий день. Участвует каждый член Команды.
Чтобы его не затягивать, рекомендуется, чтобы все проводили его стоя. Это возможность
Команды синхронизировать свою работу и сообщить друг другу о препятствиях. В Ежедневном
Скраме каждый член Команды один за другим сообщает три вещи другим членам Команды: (1) “Чтобыло сделано с момента последней встречи?”; (2) “Что будет сделано до следующей встречи?”;и (3) “Какие препятствия стоят на пути?”. Обратите внимание, что Ежедневный Скрам - это нестатусное собрание, на котором нужно отчитываться перед менеджером; это время, когда
самоорганизующаяся Команда делится друг с другом тем, что происходит, чтобы
скоординировать свои действия. Если на пути команды препятствия, то Скрам-мастер отвечаетза помощь членам команды в их устранении. Во время Ежедневного Скрама нет или почти нетуглубленного обсуждения, основная тема - дать ответы на три вопроса; если обсуждение всё жетребуется, оно проводится сразу после Ежедневного Скрама на одной или нескольких
параллельных последующих встречах, хотя в Скраме никто не обязан их посещать. Последующая
встреча является обычным мероприятием, на котором члены Команды (все или некоторые)предпринимают шаги по адаптации информации, услышанной ими на Ежедневном Скраме:другими словами, еще один цикл инспекции и адаптации. Для команд, плохо знакомых соСкрамом, обычно рекомендуется, чтобы менеджеры или другие лица, обладающие значимым
авторитетом, не посещали Ежедневный Скрам. В этом есть риск заставить Команду чувствовать
себя “под контролем” - испытывать давление, чтобы сообщать о значительном прогрессе каждый
день (нереалистичное ожидание), и скрывать имеющиеся проблемы - это подрывает
самоуправление Команды и способствует микроменеджменту. Было бы более полезно, если бызаинтересованная сторона вместо этого обратилась к команде после встречи и предложила
помощь с любыми препятствиями, которые замедляют прогресс Команды.
13Отслеживание Прогресса в Спринте
Команда в Скрам самоуправляема, и для того, чтобы делать это успешно, она должна знать, какэто делается. Каждый день члены Команды обновляют свою оценку оставшейся до завершения
работы в Бэклоге Спринта (Иллюстрация 6). Обычно также кто-то суммирует всю оставшуюся
работу для Команды в целом, и отмечает её на Диаграмме Сгорания Спринта (Sprint Burndown
Chart) (Иллюстрации 7 и 8). На этом графике каждый день отображается новая оценка того,сколько Команде осталось работы в этом Спринте. В идеале, это наклонный нисходящий график,который находится на траектории достижения “нулевого остатка работы” к последнему днюСпринта. Потому он зовётся диаграммой сгорания. И хотя иногда она и выглядит хорошо, зачастуюэто не так; это реальность продуктовой разработки. Важно то, что он показывает Команде ихпрогрес в достижении цели не с точки зрения того, сколько времени было потрачено в прошлом
(несущественный факт с точки зрения прогресса), а с точки зрения того, сколько работы осталосьв будущем - то, что отделяет Команду от её цели. Если линия на Диаграмме Сгорания не стремится
вниз ближе к завершению Спринта, тогда Команде необходимо адаптироваться, например,чтобы уменьшить объём работы или найти способ работать более эффективно, сохраняя приэтом устойчивый темп.
Хотя Диаграмму Сгорания Спринта можно создать и отобразить с помощью электронных
таблиц, многие команды считают более эффективным отображать её на бумаге, на стене своей
рабочей комнаты, обновляя её ручкой или фломастером; это “низко технологичное/высоко
ощущаемое” (low-tech/high-touch) решение работает быстро, просто и часто более наглядно, чемкомпьютерная диаграмма.
Элемент Бэклога
Продукта

Задача
Изменить БДСоздать страницу (UI)Как покупатель, Я Создать страницу (JavaScript)хочу положить книгув корзину
Написать автоматические приёмочные тесты
Обновить раздел помощи для покупателей

Первоначальная
Волонтёр
Оценка

Новая Оценка оставшейся
работы на конец дня...
1

2

3

4

5

Санджей

5

4

3

0

0

0

Джинг

3

3

3

2

0

0

Трейси и
Сэм

2

2

2

2

1

0

Сара

5

5

5

5

5

0

Санджей и
Джинг

3

3

3

3

3

0

5

5

5

5

5

5

3

3

8

8

8

8

5

5

5

5

5

5

49

48

44

43

34

6

...
Объединить DCP код и законченные тесты
слоёвУлучшить
производительность Закончить машинный заказ для pRankобработки транзакций
Изменить DCP и читателя для использования
pRank в HTTP API
...

...

...

Всего

50

Иллюстрация 6. Ежедневное Обновление Оставшейся Работы в Бэклоге Спринта

14Новая Оценка оставшейся работы

60

50

текущая оценка оставшейся
работы команды

40

30

20

10

0
0

1

2

3

4

5
Дни

6

7

8

9

10

Иллюстрация 7. Диаграмма Сгорания Спринта

Иллюстрация 8. Визуальное Управление: Нарисованная от руки Диаграмма Сгорания Спринта

Уточнение Бэклога Продукта
Описание: Разделение больших элементов, анализ элементов, переоценка элементов иизменение приоритетов для будущих Спринтов.
Участники: Команда; Владелец Продукта будет присутствовать на всём мероприятии, если онявляется экспертом, который может помочь с подробным уточнением. В противном случае
он(а) может присутствовать только частично, чтобы задать направление или изменить
приоритеты; те, кто понимают требования и могут помочь команде; Скрам-мастер будет
присутствовать на первых событиях, чтобы научить Команду проводить это событие
эффективно, в противном случае может не присутствовать.
15Длительность: Обычно не более 10% усилий Команды в Спринте, хотя может быть и больше вслучае “сложных для анализа” элементов. Например, в двухнедельном Спринте, один деньполностью может уходить на уточнение.
Одна из малоизвестных, но ценных рекомендаций в Скраме заключается в том, что некоторая
доля каждого Спринта должна выделяться всей Командой на Уточнение Бэклога Продукта
(Product Backlog Refinement, PBR) или “причесывание” (grooming) для поддержки будущих
Спринтов. Оно включает в себя подробный анализ требований, разделение больших элементовна более мелкие, оценку новых элементов и повторную оценку существующих элементов. Скрам
ничего не говорит о том, как выполняется эта работа, но часто используемый метод - этоцеленаправленная групповая сессия в середине или конце Спринта, где Команда, Владелец
Продукта и другие заинтересованные стороны могут посвятить себя этой работе без перерыва.
Это активность по уточнению не для элементов, выбранных на текущий Спринт; она дляэлементов на будущее, скорее всего, на следующие один или два Спринта. Благодаря этойпрактике планирование Спринта становится относительно простым, поскольку Владелец
Продукта и Скрам-команда начинают планирование с чёткого, хорошо проанализированного итщательно оценённого набора элементов. Признаком того, что сессия по уточнению непроводится (или проводится неэффективно), является то, что на Планирования Спринта
возникают важные вопросы, новые данные, путаница и ощущение незавершенности; затем
работа по Планированию часто перетекает в сам Спринт, что обычно нежелательно.

Обзор Спринта
Описание: Инспекция и адаптация инкремента продукта.
Участники: Команда, Владелец Продукта, Скрам-мастер. При необходимости другие
заинтересованные стороны, приглашенные Владельцем Продукта.
Длительность: Не более одного часа из расчёта на одну неделю Спринта.
В конце Спринта проводится Обзор Спринта (Sprint Review), на котором обсуждаются
результаты спринта. На этой встрече присутствуют Владелец Продукта, члены Команды и Скраммастер, а также клиенты, пользователи, заинтересованные стороны, эксперты, руководители ивсе, кто заинтересован. Продолжительность для двухнедельного Спринта составляет не более
двух часов. Любой присутствующий может задавать вопросы и вносить свой вклад.

Обзор часто ошибочно называют “демонстрацией”, но это не отражает истинного намерения
данной встречи. Ключевая идея Скрама - это инспекция и адаптация. Видеть и знать, чтопроисходит, чтобы затем обработать эту обратную связь в повторяющихся циклах. Обзор
Спринта - это инспекция и адаптация продукта. Это время для Владельца Продукта, чтобы
получить новую информацию о продукте и Команде (поэтому оно называется Обзором
Спринта); а также для Команды, чтобы получить новую информацию от Владельца Продукта ирынка. Следовательно, критически важным элементом обзора является углубленное обсуждение
между Командой и Владельцем Продукта с целью изучения ситуации, получения рекомендаций
и т. д. Обзор, конечно же, включает использование текущей версии живого программного
обеспечения, созданного Командой во время Спринта, но если в центре внимания обзора
находится только просмотр продукта, а не обсуждение, возникает дисбаланс.
“Живое программное обеспечение” на Обзоре Спринта - это не “презентация”, которую делает
Команда - здесь нет никакого показа слайдов. Оно предназначено для непосредственной
инспекции запущенного вживую программного обеспечения, работающего, например, втестовом окружении или песочнице. В комнате для Обзора необходимы один или несколько
компьютеров, на которых люди смогут инспектировать и использовать работающее
программное обеспечение. Предпочитайте активную сессию, в которой реальные пользователии Владелец Продукта самостоятельно взаимодействуют с программным обеспечением, а непассивную демонстрацию от Команды.
16Старайтесь тратить не более 30 минут на подготовку к Обзору Спринта, иначе это может бытьпризнаком того, что что-то идёт не так.

Ретроспектива Спринта
Описание: Инспекция и адаптация процессов и окружения.
Участники: Команда, Скрам Мастер, Владелец Продукта (необязательно). Другие
заинтересованные лица могут участвовать только по приглашению Командой.
Длительность: Не более 45 минут из расчёта на одну неделю Спринта.
Обзор Спринта включает инспекция и адаптацию продукта. Ретроспектива Спринта (Sprint
Retrospective), следующая за обзором, включает в себя инспекцию и адаптацию процессов иокружения. Это возможность для Команды обсудить, что работает, а что нет, и договориться обизменениях, которые нужно попробовать. Иногда Скрам-мастер может выступать в качестве
активного фасилитатора Ретроспективы, но иногда лучше найти незаинтересованного
стороннего наблюдателя, чтобы провести событие; хорошая практика для Скрам-мастеров
заключается в том, чтобы помогать друг другу с проведением ретроспектив в своих Командах,что обеспечивает “перекрёстное опыление” между ними.
Существует множество техник проведения Ретроспективы Спринта, и книга Agile ретроспектива.
Как превратить хорошую команду в великую. (Дерби, Ларсен 2006) предоставляет полезный каталог
таких техник.
Многие команды проводят ретроспективы, сосредотачиваясь только на проблемах, что очень
плохо. Это может привести к тому, что люди будут считать ретроспективы несколько
удручающими или вовсе негативными событиями. Вместо этого убедитесь, что каждая
ретроспектива также фокусируется на положительных или сильных сторонах; есть несколько
книг по *модели благодарного запроса* (appreciative inquiry), которые предлагают более
подробные советы.
Ретроспективы, которые всегда используют одну и ту же технику, могут наскучить; поэтому современем используйте различные техники.

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

17Приоритет

Элемент

Детали
Первоначальная
(ссылка на Wiki)оценка

Обновлённая Оценка вСпринте

1

2

3

3

Как покупатель, Я хочу положить книгу вкорзину (см. наброски UI в wiki)Как покупатель, Я хочу удалять книги изкорзины
Улучшить производительность обработки
транзакции (см. целевые метрики
производительности в wiki)

...

13

13

0

0

4

Исследовать решение для ускорения проверки
кредитной карты (см. целевые метрики
производительности в wiki)

...

20

20

20

0

5

Обновить версию Apache до 2.2.3 на всехсерверах

...

13

13

13

13

6

Диагностировать и исправить ошибки в порядке
исполнения скриптов (bugzilla ID 14823)
...

3

3

3

3

7

Как покупатель, Я хочу создавать и сохранять
список желаний

...

40

40

40

40

Как покупатель, Я хочу добавлять и удалять
элементы в моём списке желаний
...

...
...

20
...

20
...

20
...

20
...

537

580

570

500

1
2

8

...

5

0

0

0

...

2

0

0

0

4

5

6

Иллюстрация 9. Обновлённый Бэклог Продукта
Между Спринтами нет никакого промежутка времени - Обычно Команды из Ретроспективы
Спринта после обеда переходят в Планирование Спринта на следующую утро (или после
выходных).
“Устойчивый ритм” является одним из принципов гибкой разработки, и только постоянно
работая разумное количество часов каждый день, Команды могут продолжать этот цикл сколь
угодно долго. Производительность со временем растет за счет эволюции практик работы
Команды и устранения препятствий на её пути, а не из-за переработок или снижения качества.

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

Управление Релизами
Иногда задают вопрос, как при итеративной модели можно осуществлять долгосрочное
релизное планирование. Следует рассмотреть два случая: (1) планирование первого релиза
нового продукта, и (2) планирование очередного релиза существующего продукта.
В случае нового продукта или существующего продукта, который только что перешёл на Скрам,необходимо выполнить первоначальное Уточнение Бэклога Продукта перед первым Спринтом,когда Владелец Продукта и Команда формируют надлежащий Бэклог Продукта по принципам
Скрама. Это может занять от нескольких дней до недели и включает в себя сессию совместной
работы (иногда называемую Первоначальным Уточнением Бэклога Продукта илиПланированием Релиза), подробный анализ требований и оценку всех элементов, определённыхдля первого релиза.

18

Удивительно, но в Скраме в случае существующего продукта, уже имеющего Бэклог Продукта,не должно быть необходимости в каком-либо специальном или дополнительном планировании
следующего релиза. Почему? Потому что Владелец Продукта и Команда должны проводить
Уточнение Бэклога Продукта каждый Спринт (пять или десять процентов усилий в каждом
Спринте), непрерывно готовясь к будущему. Этот режим непрерывной разработки продукта устраняет
необходимость в драматически прерывистых этапах подготовки-выполнения-завершения,которые можно увидеть в жизненном цикле традиционной последовательной разработки.
Во время первоначального Уточнения Бэклога Продукта и во время непрерывных Уточнений
Бэклога Продукта в каждом Спринте, Команда и Владелец Продукта будут планировать релиз,уточняя оценки, приоритеты и содержание по мере того, как они учатся.
Некоторые релизы ориентированы на дату; например: “Мы выпустим версию 2.0 нашего проектак началу выставки 10 ноября”. В этой ситуации Команда завершит столько Спринтов (и создатькак можно больше функциональности), сколько сможет за отведенное время. Другие продукты
требуют создания определённой функциональности, прежде чем их можно будет назвать
завершёнными, и продукт не будет запущен, пока эти требования не будут удовлетворены,сколько бы времени это не заняло. Поскольку Скрам делает упор на создание потенциально
готового к поставке кода в каждом спринте, Владелец Продукта может решить начать делать
промежуточные релизы, чтобы позволить клиентам как можно раньше воспользоваться
преимуществами готовой работы.
Поскольку невозможно знать все заранее, то основное внимание уделяется созданию иуточнению плана, который задаст общее направление релиза, и прояснению, как будут
приниматься компромиссные решения (например, уменьшить состав релиза или передвинуть егодату). Думайте об этом как о дорожной карте, ведущей вас к конечному пункту назначения; какие
именно дороги вы выбираете и какие решения вы принимаете во время путешествия, можно
определить в пути.
Пункт назначения важнее самого путешествия.

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

Фокус на Продукте или ПриложенииДля приложений или продуктов – ориентированных либо на внешний рынок, либо напользователей внутри организации – Скрам уводит команды от старой модели, ориентированнойна проекты, к модели непрерывной разработки приложений/продуктов. Больше нет проектов с началом,серединой и концом. А значит, нет традиционного менеджера проектов. Скорее, есть просто
постоянный Владелец Продукта и долгоживущая самоуправляемая Команда, которые
сотрудничают в “бесконечной” серии Спринтов фиксированной длины, пока продукт илиприложение не будет отправлено в отставку. Вся необходимая работа по управлению “проектом”выполняется Командой и Владельцем Продукта, который является внутренним бизнеспользователем или сотрудником отдела Управления Продуктами. Он не управляется ИТменеджером или сотрудником Офиса Управления Проектами.
Скрам также можно использовать для настоящих проектов, которые являются разовыми
инициативами (а не для создания или развития долгоживущих приложений); тем не менее, в этомслучае управление проектом также осуществляют Команда и Владелец Продукта.
Что делать, если в одном или нескольких существующих приложениях недостаточно новой
работы, чтобы гарантировать выделенную долгоживущую Команду для каждого приложения? В
19этом случае стабильная и долгоживущая Команда может взять на себя элементы из одного
приложения в одном Спринте, а затем элементы из другого в следующем Спринте; в этойситуации Спринты часто довольно короткие, например, не более одной недели.
Иногда бывает недостаточно новой работы даже для вышеописанного решения, и Команда
может взять на себя элементы из нескольких приложений в течение одного Спринта; Однако
будьте осторожны с этим решением, поскольку оно может привести к непродуктивной
многозадачности для нескольких приложений. Основная тема продуктивности в Скрам - этососредоточение команды на одном продукте или приложении в течение одного Спринта.

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

20Хорошая новость заключается в том, что, хотя первый Спринт обычно очень сложен дляКоманды, но преимущества Скрама обычно становятся заметными к его концу, что заставляет
многие новые Скрам-команды восклицать: “Скраму сложно следовать, но безусловно это в целом
намного лучше того, что мы делали раньше!”21Приложение А: Дополнительные МатериалыПро Скрам опубликовано много материалов. В этом справочном разделе мы хотели бы указатьна некоторые дополнительные онлайн-материалы и несколько книг.
Онлайн-материалы:• The Lean Primer - Введение в Бережливое Мышление, оказавшее сильное влияние на Скрам.
http://www.leanprimer.com• The Distributed Scrum Primer - Дополнительные советы для не сидящих вместе команд.
http://www.goodagile.com/distributedscrumprimer/• The ScrumMaster Checklist - Контрольный список, которыми пользуются хорошие Скраммастера.
http://www.scrummasterchecklist.org/• Азбука Фиче-команд (Feature Team Primer) - Масштабирование Скрама с помощью Фичекоманд,http://www.featureteams.org• Руководство по Скраму (Scrum Guide) - Официальное описание Скрама.
http://www.scrum.org/Scrum-Guides• Agile Contracts Primer - Как составлять Скрам-совместимые контракты.
http://www.agilecontracts.org/
Книги:• Leading Teams - Ричард Хэкман (Richard Hackman)• Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum Крэг Ларман (Craig Larman), Бас Водди (Bas Vodde)• Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore ProductDevelopment with Large-Scale Scrum - Крэг Ларман (Craig Larman), Бас Водди (Bas Vodde)• Скрам. Гибкое управление продуктом и бизнесом - Кен Швабер (Ken Schwaber)• Scrum. Гибкая разработка ПО - Майк Кон (Mike Cohn)

22Приложение Б: Определения
Бэклог Продукта (Product Backlog)Приоритизированный список требований, с оценкой времени, необходимого для ихпревращения в готовый функционал продукта. Оценки тем точнее, чем выше приоритет
элемента в Бэклоге Продукта. Список меняется по мере возникновения или изменения условий
ведения бизнеса или технологий.

Бэклог Спринта (Sprint Backlog)Список работ Команды в Спринте. Он часто разбивается на набор более подробных задач.
Список появляется во время Планирования Спринта и может быть обновлен Командой во время
Спринта путём удаления элементов или добавления новых задач по мере необходимости. Каждая
задача Бэклога Спринта будет отслеживаться во время Спринта и будет показывать
предполагаемый оставшийся объём работ.
Владелец Продукта (Product Owner)
Лицо, ответственное за управление Бэклогом Продукта, чтобы максимизировать ценность
продукта. Владелец Продукта несёт ответственность за представление интересов всех, ктозаинтересован в проекте и его конечном продукте.
Ежедневный Скрам (Daily Scrum)Короткое событие, проводимое каждой Командой ежедневно, во время которого члены Команды
инспектируют и синхронизируют свою работу и прогресс, сообщают Скрам-мастеру опрепятствиях для их устранения. Последующие встречи для адаптации предстоящей работы иоптимизации Спринта могут проводиться после Ежедневного Скрама.
Готово (Done)Определяет, что считать завершенным, по взаимному согласию всех сторон и соответствует
стандартам, конвенциям и руководствам организации. Когда на Обзоре Спринте сообщается очем либо как о “готовом”, оно должно соответствовать этому согласованному определению.
Диаграмма Сгорания (Burn Down)Показывает отношение оставшейся работы ко времени в Спринте, Релизе или Продукте.
Источником необработанных данных являются Бэклог Спринта и Бэклог Продукта, при этомоставшаяся работа отслеживается по вертикальной оси, а периоды времени (дни Спринта илиСпринты) - по горизонтальной оси.
Задача Бэклога Спринта (Sprint Backlog Task)
Одна из задач, которую команда или её члены создают по мере необходимости, чтобы
превратить прогнозируемые Элементы Бэклога продукта в функциональность системы.

Заинтересованное лицо (Stakeholder)Заинтересованное в результате проекта лицо, являющееся инвестором, или планирующее
пользоваться им или тот, на кого результат проекта может каким-то образом повлиять.
Инкремент (Increment)Функциональность продукта, разрабатываемая Командой во время каждого Спринта,потенциально готовая к поставке или для использования заинтересованными сторонами,представляемыми Владельцем Продукта.
Инкремент Потенциально Готового к Поставке Продукта (Increment of Potentially
Shippable Product)Функциональность. Готовый фрагмент продукта или системы в целом, который может бытьиспользован Владельцем Продукта или заинтересованными лицами, если они захотят этого.
23Команда (Team)Самоуправляемая кросс-функциональная группа людей, которая разрабатывает новый инкремент
продукта каждый Спринт.
Команда Разработки (Development Team)Другое название Команды.
Оценённая Оставшаяся Работа (элементы Бэклога Спринта) (Estimated Work Remaining(Sprint Backlog items))Количество часов, которое требуется, согласно оценке члена Команды, для работы над какойлибо задачей. Эта оценка обновляется в конце каждого дня, по мере работы над задачами Бэклога
Спринта. Оценка представляет совокупные оставшиеся усилия, независимо от количества людей,выполняющих работу.

Спринт (Sprint)Итерация (или один повторяющийся цикл регулярной работы), в результате которой
производится новый инкремент продукта или системы. Обычно занимает не менее недели, нострого не более одного месяца. Длительность фиксирована на протяжении всей работы, и всеКоманды, работающие над одной и той же системой или продуктом, используют циклодинаковой длины.
Обзор Спринта (Sprint Review meeting)Событие (не более двух часов для двухнедельного Спринта) в конце каждого спринта, на котором
Команда взаимодействует с Владельцем Продукта и заинтересованными сторонами иинспектирует результаты Спринта. Обычно оно начинается с обзора завершённых элементов
Бэклога Продукта, продолжается обсуждением возможностей, ограничений и рисков изаканчивается дискуссией того, что лучше всего стоит делать дальше (это, в свою очередь, может
привести к изменениям в Бэклоге Продукта). Только готовую функциональность продукта
можно демонстрировать.
Ограничение по времени (Time box)Период времени события или встречи, который не может быть превышен. Например,Ежедневный Скрам ограничен по времени пятнадцатью минутами и завершается в любом случаепо их истечении. Встреча может закончиться раньше истечения отведённого для неё отрезка
времени. Спринт длится равно столько, сколько было под него заложено.
Планирование Спринта (Sprint Planning meeting)Первое событие каждого Спринта (не более четырёх часов для двухнедельного Спринта).
Событие разделено на две двухчасовых части, каждая из которых также ограничена по времени.
В первой части Владелец Продукта представляет команде элементы Бэклога Продукта снаивысшим приоритетом. Команда сотрудничает с Владельцем Продукта, чтобы определить,какой объем Бэклога Продукта она может превратить в готовую функциональность за время
предстоящего Спринта. Во второй части Команда планирует, как этого добиться через
проектирование и декомпозицию работы, чтобы понимать, как они будут достигать ЦелиСпринта.
Ретроспектива Спринта (Sprint Retrospective meeting)Встреча, на которой вся Команда обсуждает только что завершившийся Спринт и определяет,что можно изменить, чтобы добиться более приемлемых результатов в следующем Спринте илисделать его более продуктивным. Обычно Скрам-мастер выступает в роли фасилитатора.
Скрам (Scrum)Означает механику при игре в регби, позволяющую вернуть вышедший из игры мяч в обратно,не является аббревиатурой.
24

Скрам-мастер (Scrum Master)Лицо, ответственное за Скрам-процесс, его правильную реализацию и максимизацию егопреимуществ.
Элемент Бэклога Продукта (Product Backlog Item)Функциональные, нефункциональные требования и задачи, оцененные, упорядоченные постепени важности для бизнеса и наличию зависимостей. Точность оценки зависит от приоритетаи детализации элемента Бэклога Продукта, причем элементы с наивысшим приоритетом,которые могут быть выбраны в следующем Спринте, являются очень детальными и точными.

25