Кен Швабер и Джефф Сазерленд

Руководство по
ScrumИсчерпывающее руководство по Scrum:Правила игрыНоябрь 2020Назначение Руководства по ScrumМы разработали Scrum в начале 1990-х. Чтобы помочь людям во всем мире лучше понимать
Scrum, в 2010 году мы написали первую версию Руководства по Scrum. С тех пор мы развивали
Руководство, внося небольшие конструктивные дополнения. Мы создали и поддерживаем еговместе.
Руководство по Scrum содержит определение Scrum. Каждый элемент фреймворка служит
определенной цели, необходимой для достижения общей ценности и результатов от применения
Scrum. Изменение ключевых идей или структуры Scrum, исключение каких-либо элементов или неследование правилам Scrum приводит к сокрытию проблем, ограничивает преимущества Scrum ипотенциально даже делает его бесполезным.
Мы следим за тем, как Scrum все больше используется в постоянно растущем комплексном мире.
Мы приятно удивлены, как Scrum применяется не только при разработке программных продуктов,для которой он изначально создавался, но и во многих других областях, где выполняется
комплексная работа. По мере распространения Scrum помогает выполнять работу разработчикам,исследователям, аналитикам, ученым и другим специалистам. Мы используем в Scrum слово
«developers» не для того, чтобы исключить, а чтобы упростить. Если вы получаете пользу от Scrum,считайте себя включенным в число developers.
При использовании Scrum можно находить, создавать и применять паттерны, процессы и идеи,которые не противоречат описанному в этом документе фреймворку. Они сильно отличаются другот друга и зависят от контекста, в котором применяется Scrum, и поэтому их описание выходит зарамки целей Руководства по Scrum. Используемые в рамках Scrum подходы могут быть очень
разными и описаны в других местах.
Кен Швабер и Джефф Сазерленд, Ноябрь 2020

© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share-Alike license of Creative Commons,accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary
form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share-Alike license of Creative Commons.

1Назначение Руководства по Scrum ............................................................................................................ 1Определение Scrum .................................................................................................................................... 3Теория Scrum ............................................................................................................................................... 3Прозрачность ........................................................................................................................................... 4Инспекция ................................................................................................................................................ 4Адаптация ................................................................................................................................................ 4Ценности Scrum ........................................................................................................................................... 4
Scrum Team .................................................................................................................................................. 5
Developers ................................................................................................................................................ 5
Product Owner .......................................................................................................................................... 6
Scrum Master ............................................................................................................................................ 6События Scrum ............................................................................................................................................. 7
Sprint ......................................................................................................................................................... 8
Sprint Planning .......................................................................................................................................... 8
Daily Scrum ............................................................................................................................................... 9
Sprint Review .......................................................................................................................................... 10
Sprint Retrospective................................................................................................................................ 10Артефакты Scrum ....................................................................................................................................... 11
Product Backlog ...................................................................................................................................... 11Приверженность: Product Goal ........................................................................................................ 11
Sprint Backlog ......................................................................................................................................... 12Приверженность: Sprint Goal............................................................................................................ 12
Increment ................................................................................................................................................ 12Приверженность: Определение готовности ................................................................................... 13Заключение ................................................................................................................................................ 13Благодарности ....................................................................................................................................... 13Люди ................................................................................................................................................... 13История Руководства по Scrum ........................................................................................................ 14Переводчики .......................................................................................................................................... 14Изменения Руководства по Scrum от версии 2017 к 2020 ................................................................. 15Словарь терминов ................................................................................................................................. 162Определение Scrum
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать
ценность с помощью адаптивных решений комплексных проблем.
Вкратце, Scrum требует, чтобы Scrum Master способствовал возникновению среды, в которой:1. Product Owner упорядочивает работу по решению комплексной проблемы в ProductBacklog.
2. Scrum Team в ходе Sprint превращает выбранную работу в Increment, несущий ценность.
3. Scrum Team и заинтересованные лица инспектируют результаты и вносят правки дляследующего Sprint.
4. Повторить.
Scrum — прост. Попробуйте применить его как есть и решите, помогают ли его философия, теорияи структура достигать целей и создавать ценность. Фреймворк Scrum намеренно неполный, иопределяет только части, необходимые для реализации теории Scrum. Scrum основан на опыте
использующих его людей. Scrum не предоставляет людям подробных инструкций, а вместо этого
правила Scrum задают ориентиры для отношений и взаимодействий людей.
Фреймворк позволяет применять различные процессы, техники и методы. Scrum служит оберткойдля существующих практик, или подсвечивает их ненужность. Scrum наглядно показывает
относительную эффективность текущих методов управления, среды и подходов к работе, чтобы
можно было производить улучшения.

Теория Scrum
Scrum основан на эмпиризме и бережливом мышлении. Эмпиризм утверждает, что источником
знаний является опыт, а принятие решений основывается на наблюдениях. Бережливое
мышление сокращает потери и фокусируется на главном.
Scrum использует итеративный, инкрементальный подход для оптимизации предсказуемости иуправления рисками. Scrum вовлекает группы людей, которые в совокупности обладают всеми
навыками и опытом для выполнения работы, и по мере необходимости делятся знаниями иприобретают нужные навыки.
Четыре формальных события для инспекции и адаптации Scrum объединяет в событие-контейнер
— Sprint. Эти события успешно работают, потому что они реализуют эмпирические столпы Scrum:прозрачность, инспекцию и адаптацию.

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

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

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

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

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

Scrum TeamОсновная единица Scrum — небольшая команда людей, Scrum Team. Scrum Team состоит изодного Scrum Master, одного Product Owner и Developers. Внутри Scrum Team нет подкоманд ииерархий. Это сплоченное объединение профессионалов, в любой момент времени
сфокусированных на одной цели — Product Goal.
Scrum Teams являются кросс-функциональными, то есть их участники обладают всеми навыками,необходимыми для создания ценности в каждом Sprint. Также они самоуправляемы, то есть самирешают, кто, что, когда и как делает.
Scrum Team достаточно маленькая, чтобы оставаться проворной, и достаточно большая, чтобы
выполнять значительную работу в течение Sprint — обычно состоит не более чем из 10 человек. Вцелом, мы обнаружили, что небольшие команды лучше общаются и более продуктивны. ЕслиScrum Teams становятся слишком большими, участникам следует рассмотреть возможность
реорганизации в несколько сплоченных Scrum Teams, каждая из которых сфокусирована на одноми том же продукте. Следовательно, у них должна быть та же Product Goal, тот же Product Backlog,тот же Product Owner.
Scrum Team выполняет все продуктовые активности: сотрудничество с заинтересованными
лицами, верификацию, обслуживание, эксплуатацию, эксперименты, исследования, разработку ивсе то, что может потребоваться. Они структурированы и уполномочены организацией управлять
своей собственной работой. Работа в Sprints в устойчивом темпе улучшает фокусировку исогласованность Scrum Team.
Вся Scrum Team несет ответственность за создание ценного, полезного Increment в каждом Sprint.
Scrum определяет три конкретные зоны ответственности в составе Scrum Team: Developers,
Product Owner и Scrum Master.

Developers
Developers — это люди в Scrum Team, которые привержены созданию любого аспекта готового киспользованию Increment в каждом Sprint.

5Конкретные навыки, необходимые Developers, зависят от предметной области выполняемой
работы и могут быть очень разными. Однако Developers всегда несут ответственность за:••••создание плана на Sprint — Sprint Backlog;стремление к качеству посредством соблюдения определения готовности;ежедневную адаптацию своего плана для достижения Sprint Goal; а также,взаимную подотчетность друг перед другом как профессионалами.

Product Owner
Product Owner несет ответственность за максимизацию ценности продукта, получаемого врезультате работы Scrum Team. Способы достижения максимальной ценности могут быть очень
разными и зависят от организаций, Scrum Teams и конкретных людей.
Product Owner также несет ответственность за эффективное управление Product Backlog, в томчисле он:••••разрабатывает и точно коммуницирует Product Goal;создает и четко объясняет элементы Product Backlog;упорядочивает элементы Product Backlog; а также,обеспечивает прозрачность, доступность и понимание Product Backlog.

Product Owner может выполнять это работу сам или делегировать ее выполнение другим лицам.
Тем не менее, Product Owner остается ответственным за нее.
Чтобы Product Owners могли в этом преуспеть, вся организация должна уважать их решения. Этирешения отражены в содержании и порядке элементов Product Backlog, а также винспектируемом Increment во время Sprint Review.
Product Owner — это один человек, а не комитет. Product Owner может отражать в Product Backlog
потребности многих заинтересованных лиц. Желающие изменить Product Backlog могут сделать
это, попытавшись убедить Product Owner.

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

6

Scrum Masters — настоящие лидеры, которые служат Scrum Team и всей организации.
Scrum Master служит Scrum Team несколькими способами, в том числе:••••коучит участников команды в части самоуправления и кросс-функциональности;помогает Scrum Team фокусироваться на создании Increments с высокой ценностью,соответствующих определению готовности;способствует устранению препятствий, мешающих прогрессу Scrum Team; а также,убеждается в том, что все события Scrum происходят, позитивны, продуктивны и невыходят за рамки ограничений по времени.

Scrum Master служит Product Owner несколькими способами, в том числе:••••помогает находить техники эффективного определения Product Goal и управления ProductBacklog;помогает Scrum Team осознать необходимость четких и лаконичных элементов ProductBacklog;помогает применять эмпирическое планирование продукта в комплексной среде; а также,фасилитирует взаимодействие с заинтересованными лицами по запросу или принеобходимости.

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

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

7

Sprint
Sprints — это пульс Scrum, где идеи превращаются в ценность.
Это событие фиксированной продолжительности не более одного месяца для обеспечения
согласованности. Новый Sprint начинается сразу после завершения предыдущего.
Вся работа, необходимая для достижения Product Goal, включая события Sprint Planning, Daily
Scrum, Sprint Review и Sprint Retrospective, выполняется в рамках Sprints.
В ходе Sprint:••••не вносятся изменения, которые могут поставить под угрозу Sprint Goal;не снижается качество;Product Backlog уточняется по мере необходимости; а также,по мере появления новых знаний содержание работы может быть уточнено ипересмотрено с Product Owner.

Sprints создают условия для предсказуемости, обеспечивая инспекцию и адаптацию прогресса вдостижении Product Goal как минимум один раз в месяц. При большей длительности Sprintвозможны: потеря актуальности Sprint Goal, повышение комплексности, рост рисков. Более
короткие Sprints позволяют пройти большее количество циклов обучения, и ограничить риски
стоимости и трудозатрат меньшим отрезком времени. Каждый Sprint можно считать коротким
проектом.
Существуют различные техники прогнозирования прогресса, например, burn-down, burn-up икумулятивные диаграммы потока. Несмотря на то, что их польза доказана, они не могут заменить
важность эмпиризма. В комплексных средах неизвестно, что произойдет. Принятие решений,ориентированных на будущее, может базироваться только на том, что уже произошло.
Sprint может быть отменен, если Sprint Goal потеряла актуальность. Только Product Owner имеет
право отменить Sprint.

Sprint Planning
Sprint Planning инициирует Sprint, планируя работу, которую необходимо выполнить в этом Sprint.
Результатом события становится план, созданный совместными усилиями всей Scrum Team.
Product Owner обеспечивает готовность участников к обсуждению наиболее важных элементов
Product Backlog и их связи с Product Goal. Scrum Team может приглашать на Sprint Planning дляконсультаций и других людей.

8В ходе Sprint Planning рассматриваются следующие темы:Тема первая: почему этот Sprint ценен?
Product Owner предлагает, как можно повысить ценность и практичность продукта в текущем
Sprint. Затем вся Scrum Team совместно определяет Sprint Goal, которая объясняет, почему Sprintценен для заинтересованных лиц. Sprint Goal должна быть сформулирована до окончания Sprint
Planning.

Тема вторая: что может быть готово в этом Sprint?
Developers обсуждают с Product Owner, какие элементы Product Backlog выбрать для включения втекущий Sprint. Scrum Team может попутно уточнять эти элементы, чтобы улучшить понимание иповысить уверенность.
Выбор элементов, которые получится завершить за Sprint, может оказаться трудной задачей.
Однако, чем больше Developers знают о своей прошлой производительности, своих возможностяхна следующий Sprint и своем определении готовности, тем более уверенно они могут
прогнозировать работу на следующий Sprint.

Тема третья: как будет выполняться выбранная работа?
Developers для каждого выбранного элемента Product Backlog планируют работу, необходимуюдля создания Increment, соответствующего определению готовности. Это часто делается путем
декомпозиции элементов Product Backlog на более мелкие задачи продолжительностью не более
одного дня. То, как это делается, остается на усмотрение разработчиков. Никто не указывает им,как превращать элементы Product Backlog в Increments ценности.
Sprint Goal, выбранные элементы Product Backlog, плюс план их реализации вместе называются
Sprint Backlog.
Sprint Planning ограничено по времени максимум восемью часами для одномесячного Sprint. Дляболее коротких Sprints событие обычно короче.

Daily ScrumЦель Daily Scrum — инспекция прогресса в достижении Sprint Goal, адаптация Sprint Backlog помере необходимости, корректировка запланированной предстоящей работы.
Daily Scrum — это 15-минутное событие для Developers, входящих в Scrum Team. Для снижения
комплексности событие проводится в одно и то же время, в одном и том же месте, каждый
рабочий день в ходе Sprint. Если Product Owner или Scrum Master активно работают надэлементами из Sprint Backlog, то они участвуют в событии в качестве Developers.

9

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

Sprint ReviewЦель Sprint Review — инспекция результата Sprint и выявление возможностей для адаптации.
Scrum Team представляет результаты своей работы ключевым заинтересованным лицам, иобсуждает прогресс в достижении Product Goal.
Во время события Scrum Team и заинтересованные лица анализируют, что было достигнуто в ходеSprint, и что изменилось в их окружении. На основе этой информации участники совместно
решают, что делать дальше. Product Backlog также может быть скорректирован с учетом новых
возможностей. Sprint Review — это рабочая сессия, и не сводится к презентации.
Sprint Review является предпоследним событием Sprint и ограничено по времени максимум
четырьмя часами для одномесячного Sprint. Для более коротких Sprints событие обычно короче.

Sprint RetrospectiveЦель Sprint Retrospective — запланировать повышение качества и эффективности.
Scrum Team инспектирует то, как прошел последний Sprint в отношении людей, взаимодействий,процессов, инструментов и определения готовности. Инспектируемые элементы зависят отпредметной области выполняемой работы и могут быть очень разными. Выявляются
предположения, которые сбили Scrum Team с пути, и исследуется их происхождение. Участники
Scrum Team обсуждают, что прошло хорошо во время Sprint, с какими проблемами онистолкнулись, и как эти проблемы были (или не были) решены.
Scrum Team определяет наиболее полезные для повышения эффективности изменения.
Улучшения с самым высоким влиянием реализуются в кратчайшие сроки. Они могут даже бытьдобавлены в Sprint Backlog следующего Sprint.
Sprint Retrospective завершает Sprint. Оно ограничено по времени максимум тремя часами дляодномесячного Sprint. Для более коротких Sprints событие обычно короче.
10Артефакты ScrumАртефакты Scrum отражают работу или ценность. Они спроектированы для максимизации
прозрачности ключевой информации. Таким образом, все, кто инспектирует их, имеют
одинаковую основу для адаптации.
Каждый артефакт содержит приверженность, которая предоставляет информацию дляподдержания прозрачности и сфокусированности, и по которой оценивается прогресс.
•••Для Product Backlog это Product Goal.
Для Sprint Backlog это Sprint Goal.
Для Increment это определение готовности.

Приверженность существует для подкрепления эмпиризма и ценностей Scrum для Scrum Team иее заинтересованных лиц.

Product Backlog
Product Backlog — это упорядоченный и постоянно обновляемый список того, что необходимо дляулучшения продукта. Это единственный источник работы, выполняемой Scrum Team.
Элементы Product Backlog, которые могут быть реализованы Scrum Team до состояния готовностив течение одного Sprint, считаются готовыми для взятия в Sprint в ходе события Sprint Planning.
Они достигают такого уровня прозрачности после активностей по уточнению. Уточнение ProductBacklog — это процесс разбиения элементов Product Backlog на более мелкие и конкретные
элементы, и их дальнейшего уточнения. Это постоянная деятельность по добавлению деталей,таких как описание, порядок и размер. Атрибуты элементов зависят от предметной области
выполняемой работы и могут быть очень разными.
Оценку размера элементов производят Developers, которые будут выполнять работу. Product
Owner может влиять на Developers, помогая им понять элементы и обсуждая компромиссы.

Приверженность: Product Goal
Product Goal описывает будущее состояние продукта, которое может выступать в качестве
конечной цели, используемой Scrum Team при планировании работы. Product Goal входит в состав
Product Backlog. Остальная часть Product Backlog появляется, чтобы определить, «что» будет
способствовать достижению Product Goal.
Продукт — это средство доставки ценности. У него есть четкие границы, известные
заинтересованные лица, четко определенные пользователи или клиенты. Продукт
может быть услугой, физическим продуктом или чем-то более абстрактным.

11

Product Goal — это долгосрочный ожидаемый результат Scrum Team. Они должны достичь одной
цели (или отказаться от нее), прежде чем приступить к следующей.

Sprint Backlog
Sprint Backlog состоит из Sprint Goal (почему), набора выбранных на Sprint элементов ProductBacklog (что), а также осуществимого плана действий по поставке Increment (как).
Sprint Backlog — это план, созданный силами Developers для самих Developers. Это наглядная идоступная в режиме реального времени картина работы, которую Developers планируют
выполнить в ходе Sprint для достижения Sprint Goal. Поэтому Sprint Backlog обновляется напротяжении всего Sprint по мере появления новых знаний. В нем должно быть достаточно
деталей, чтобы Developers могли инспектировать свой прогресс во время Daily Scrum.

Приверженность: Sprint Goal
Sprint Goal — единственная цель на Sprint. Несмотря на то, что Developers привержены Sprint Goal,она обеспечивает гибкость с точки зрения выбора конкретной работы, необходимой для еедостижения. Sprint Goal также обеспечивает связность и сфокусированность, побуждая Scrum
Team работать совместно, а не над отдельными инициативами.
Sprint Goal создается во время Sprint Planning, а затем добавляется в Sprint Backlog. Developersпомнят о Sprint Goal в ходе работы над задачами Sprint. Если работа не соответствует ожиданиям,они взаимодействуют с Product Owner, чтобы пересмотреть содержание Sprint Backlog в рамках
Sprint, не изменяя Sprint Goal.

Increment
Increment — это конкретная ступенька к достижению Product Goal. Каждый Increment является
дополнением ко всем предыдущим. Они тщательно проверяются для обеспечения совместной
работы всех Increments. Чтобы предоставить ценность, Increment должен быть пригодным дляиспользования.
В рамках одного Sprint можно создать несколько Increments. Итоговые Increments представляютсяв ходе Sprint Review, тем самым поддерживая эмпиризм. Однако Increment может быть поставлен
заинтересованным лицам еще до окончания Sprint. Sprint Review не должно считаться
единственным моментом для поставки ценности.
Работа не может считаться частью Increment, если она не соответствует определению готовности.

12Приверженность: Определение готовности
Определение готовности — это формальное описание состояния Increment, при котором онсоответствует требованиям качества, предъявляемым продукту.
В момент, когда элемент Product Backlog стал соответствовать определению готовности,рождается Increment.
Определение готовности обеспечивает прозрачность, предоставляя всем единое общее
понимание того, какая работа была выполнена в рамках Increment. Если элемент Product Backlog
не соответствует определению готовности, его нельзя выпускать или даже показывать на Sprint
Review. Вместо этого он возвращается в Product Backlog для дальнейшего рассмотрения.
Если определение готовности для Increment является частью единых стандартов организации, все
Scrum Teams должны использовать его в качестве необходимого минимума. Если оно неопределено стандартами организации, то Scrum Team должна создать определение готовности,подходящее поставляемому продукту.
Developers должны неукоснительно следовать определению готовности. Если несколько Scrum
Teams работают над общим продуктом, они должны совместно определить и соблюдать одно и тоже определение готовности.

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

Благодарности
ЛюдиСреди тысяч людей, способствовавших развитию Scrum, следует выделить тех, кто внес наиболее
весомый вклад на заре его становления: Джефф Сазерленд (Jeff Sutherland) работал с Джеффом
МакКенной (Jeff McKenna) и Джоном Скамниотейлзом (John Scumniotales); Кен Швабер (Ken
Schwaber), работал вместе с Майком Смитом (Mike Smith) и Крисом Мартином (Chris Martin),вместе они работали над созданием Scrum. Многие другие люди внесли свой вклад в развитие
Scrum в течение следующих лет. Без их содействия Scrum вряд ли обладал бы текущей степенью
проработанности.

13История Руководства по ScrumКен Швабер и Джефф Сазерленд впервые представили на конференции OOPSLA 1 в 1995 году. Вдокладе были отражены знания, полученные ими за прошедшие годы, и было впервые даноформальное определение Scrum.
Руководство по Scrum описывает Scrum в том виде, в котором он был разработан и дополнялся
Джеффом Сазерлендом и Кеном Швабером на протяжении более чем 30 лет. В других источникахвы можете найти шаблоны, процессы и идеи, которые дополняют фреймворк Scrum. Все этидополнения могут повысить продуктивность, ценность, креативность и удовлетворенность
результатами работы.
С детальной историей развития Scrum можно ознакомиться в других материалах. Здесь жеотметим лишь те организации, которые первыми опробовали Scrum и подтвердили егоэффективность: Individual Inc., Newspage, Fidelity Investments и IDX (сегодня — GE Medical).

Переводчики
Оригинал этого Руководства на английском языке был предоставлен авторами, перечисленными
выше. В создании перевода Руководства по Scrum на русский язык принимали участие:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
1

Дмитрий Блинов, dmitriy.blinov@mail.ru, dblinov.com, facebook.com/dblinov
Илья Павличенко, fancydev@gmail.com, agilix.ru, facebook.com/illya.pavlichenkoСергей Лобин, sergey@agilix.ru, facebook.com/2heohРоман Дорошенко, roman@agilix.ru, facebook.com/doroshenko.romaЕвгения Кузнецова, evgenia@agilix.ru, facebook.com/jkbercanМаксим Баталин, maxalin@gmail.com, agilelab.org
Сергей Господчиков, uln@rambler.ru, facebook.com/s.gospodchikovАнна Шатрова, 7319162@gmail.com, facebook.com/productOwnerLifeАнастасия Бутова-Никишина, butova.nikishina.a.s@gmail.com
Мадина Ефанова, m.zhumatayeva@gmail.com
Дмитрий Орлов, dmitriy.v.orlov@yandex.ru, facebook.com/OrlovDmitriyVИгорь Титов, igor.ev.titov@gmail.com, facebook.com/igor.ev.titovДанила Шалыгин, shal1928@yandex.ru, facebook.com/dshal1928Антон Соловей, solovey.anton@gmail.com, facebook.com/solovey.antonИван Бударин, ibudarin87@gmail.com, facebook.com/ivan.budarinМаша Сосновец, msosnovets@gmail.com, facebook.com/maria.sosnovetsОлеся Мойса, mojsa@physics.msu.ru, facebook.com/olesya.moysaАлександр Селяев, selyaev.alec@gmail.com, facebook.com/alex.selyaev
Саша Бондарчук, Alexander.bondarchuk@gmail.com

Object-Oriented Programming Systems, Languages and Applications.

14

•
•
•
•
•
•
•

Наталия Зегнитц, nsegnitz@gmail.com, facebook.com/natalia.segnitzАндрей Дема, demaao@mail.ruЛевон Гончаров, levon@agileverse.ru, agileverse.ru, facebook.com/levon.goncharovНиколай Шаповалов, nikolay.shapovalov@gmail.com
Эдуард Дулич, edulich@gmail.com, facebook.com/eduard.dulichГригорий Кузнецов, kuznetsovga@gmail.com, facebook.com/kuznetsovgaСообщество Scrum Russia, facebook.com/groups/scrum.ruИзменения Руководства по Scrum от версии 2017 к 2020Еще менее предписывающийС годами Руководство по Scrum становилось чуть более предписывающим. Версия 2020 нацеленана возвращение Scrum в состояние минимально достаточного фреймворка путем удаления
предписаний или смягчения языка. Например, удалены вопросы Daily Scrum, смягчены
формулировки атрибутов элементов Product Backlog, смягчены формулировки относительно
улучшений, выявленных в ходе Sprint Retrospective, и их опциональном размещении в Sprint
Backlog, сокращен раздел об отмене Sprint, и многое другое.

Одна команда, сфокусированная на одном продукте
Цель состояла в том, чтобы исключить концепцию отдельной команды внутри команды, которая
привела к поведению взаимоотношений «прокси 2» и «мы/они» между Product Owner и командой
разработчиков 3. Теперь есть только одна Scrum Team, сфокусированная на общей цели, с тремя
разными зонами ответственности: Product Owner, Scrum Master и Developers.

Добавление Product GoalРуководство по Scrum 2020 привносит концепцию Product Goal, призванную сфокусировать Scrum
Team на достижении более широкой цели. Каждый Sprint должен приближать продукт к итоговой
Product Goal.

Дом для Sprint Goal, определения готовности и Product GoalПредыдущие Руководства по Scrum описывали Sprint Goal и определение готовности, лишьнезначительно выделяя их. Они были не совсем артефактами, а чем-то связанным с артефактами.
Версия 2020 года дает больше ясности по этому поводу, добавляя Product Goal. Теперь каждый изтрех артефактов содержит «приверженность». Для Product Backlog есть Product Goal, для Sprint
Backlog есть Sprint Goal, для Increment есть определение готовности (теперь без кавычек 4). Онисуществуют, чтобы обеспечить прозрачность и сфокусировать на прогрессе по каждому артефакту.
Proxy — с англ., доверенный, уполномоченный. В современной ИТ- и бизнес-лексике означает формально
назначенное лицо с функцией передачи информации, но без функции принятия решений.
3Концепция подкоманды Dev Team существовала в Руководстве по Scrum версии 2017 года и предыдущих.
4В версии 2017 года оно называлось Definition of “Done”, а теперь Definition of Done.
2

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

Три вопроса события Sprint PlanningВ версии 2017 были описаны два вопроса Sprint Planning: «Что» и «Как». В Руководстве по Scrum2020 года особое внимание уделяется третьему вопросу — «Почему» — относящейся к Sprint Goal.

Общее упрощение языка для более широкой аудиторииВ Руководстве по Scrum 2020 года особое внимание уделяется устранению избыточных и сложных
утверждений, а также устранению любых оставшихся ссылок на работу в отрасли ИТ (например,тестирование, система, проектирование, требования и пр.). Руководство по Scrum теперь занимает
менее 14 5 страниц.

Словарь терминов

5

Scrum

Скрам

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

Daily ScrumЕжедневный Скрам

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

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

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

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

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

DevelopersРазработчики

Product Backlog

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

Product GoalЦель продукта

Sprint Backlog

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

Sprint GoalЦель спринта

IncrementИнкремент

Менее 13 страниц в оригинале на английском языке без учета перечня изменений.

16