Scrum

Scrum — это платформа для запуска проектов, основанная на гибких принципах и показателях. Она определяет набор действий, которые помогут команде быстрее достигать поставленных заказчиками целей. Эти действия обеспечивают заказчикам возможность проверять промежуточные результаты, руководить ходом работ и влиять на них иным образом. При этом подходе не предпринимается попытка полностью определить проект в самом его начале. Работа команды разбивается на короткие итерации (также называемые спринтами), и план действий уточняется по мере выполнения поставленных задач. Сведения о гибких принципах и показателях, лежащих в основе методологии Scrum, см. в статье Принципы и значение гибкой разработки, Джеф Сазерленд (Jeff Sutherland).

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

Содержание раздела Подготовка проекта Планирование проекта Планирование спринта Выполнение спринта Отслеживание проекта

Подготовка проекта

Перед запуском проекта необходимо выполнить следующие задачи:

• установить экономическое обоснование;

• собрать команду;

• настроить инфраструктуру команды.

Чтобы установить экономическое обоснование, необходимо выявить бизнес-потребности и обосновать их, определить концепцию проекта и получить финансирование. В книге Джеффри Мура (Geoffrey Moore) "Crossing the Chasm" представлено неплохое руководство по созданию концепций. Дополнительные сведения см. на следующем веб-ресурсе: Crossing the Chasm.

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

И наконец, созданная команда должна настроить свою инфраструктуру. Например, необходимо установить сервер Visual Studio Team Foundation Server и систему Visual Studio Application Lifecycle Management (ALM), создать и, возможно, настроить командный проект и определить рекомендации по проектированию. Дополнительные сведения см. в разделах Начало работы с Visual Studio Application Lifecycle Management, Настройка командного проекта и Рекомендации по проектированию.

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

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

Построение списка невыполненных работ по продукту

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

	Создание описаний функциональности пользователей. В своей книге "User Stories Applied" Майк Кон (Mike Cohn) определяет описания функциональности пользователей следующим образом: "Описание функциональности пользователя определяет функции, которые будут полезны для пользователя или покупателя системы или программного обеспечения". Иными словами, описания функциональности пользователей создаются с точки зрения конечного пользователя. Примеры. "Мне, как постоянному клиенту, требуются блюда, которые я заказывал раньше". Дополнительные сведения см. в разделе Создание удобного описания требований пользователей к продукту.
	Определение приоритетов описаний функциональности пользователей. Приоритеты описаний функциональности пользователей определяются владельцем продукта в списке невыполненных работ по продукту. При этом владелец согласует с заказчиками цели и задачи проекта и вместе с командой выполняет анализ рисков и зависимостей. Владелец продукта указывает приоритеты путем назначения описаниям функциональности определенных рангов, определяющих порядок, в котором команда должна реализовывать описания. Для анализа и сравнения ценности описаний функциональности пользователей владелец продукта может использовать целый ряд методов. Если команда уже использует хорошо зарекомендовавший себя метод определения приоритетов, менять его не следует. Некоторые методы определения приоритетов тесно связаны с концепцией гибкого сообщества, например с моделью Кано удовлетворенности клиентов и принципом относительных весов Карла Вигерса (Karl Wiegers). (Дополнительные сведения об относительных весах см. в статье по адресу: First Things First: Prioritizing Requirements.) Другие методы определения приоритетов, такие как определение приоритетов затрат, чистая приведенная стоимость, расчетный период окупаемости и коэффициент окупаемости, широко применяются за пределами гибкого сообщества. Эти методы также вполне эффективны, и их можно использовать для определения приоритетов в списке невыполненных работ по продукту проекта Scrum. Дополнительные сведения см. в разделе "Part II: Estimating Size" книги на следующем веб-ресурсе: Agile Estimation and Planning.
	Оценка описаний функциональности пользователей. Каждое описание функциональности пользователя совместно оценивается участниками команды в баллах описаний функциональности. В своей книге "Agile Estimation and Planning" Майк Кон (Mike Cohn) определяет баллы описания функциональности следующим образом: "Баллы описания функциональности — это единицы измерения для выражения общего размера описания функциональности, компонента или другого элемента работы". Баллы описания функциональности представляют собой относительные значения, которые невозможно сразу перевести в определенное количество часов. Баллы описаний лишь помогают команде определить общий размер описания функциональности пользователя. Эти относительные оценки являются менее точными, поэтому для их определения требуется меньше усилий. Со временем оценки будут уточняться. Благодаря определению баллов описаний функциональности команда получает общий размер описаний функциональности пользователей на начальном этапе и в дальнейшем, когда участники команды приступают к реализации описаний, разрабатывает более детальную оценку трудозатрат.

Определение производительности команды

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

Если команда уже измерила свою скорость работы, собрав данные о числе описаний функциональности пользователей, реализованных командой за определенный период времени, можно использовать эти данные. Он предоставляет наиболее точную оценку производительности команды. Если такие данные отсутствуют, но команда начала выполнение проекта с помощью системы Visual Studio ALM и платформы MSF для гибкой разработки программного обеспечения версии 5.0, эти показатели будут собраны в ходе проекта. Дополнительные сведения см. в разделе Отчет "Состояние всех итераций" (гибкая разработка).

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

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

Создание плана выпуска

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

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

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

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

Дополнительные сведения см. в разделе Книга "Планирование продукта".

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

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

• Разбиение пользовательского описания функциональности на более мелкие описания функциональности.

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

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

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

• "Могут ли критерии поиска задаваться в свободной форме или необходимо выбирать из списка доступных типов?"

• "Если блюда, соответствующие критерию поиска, можно получить у нескольких поставщиков, как должны сортироваться результаты?"

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

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

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

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

Дополнительные сведения см. в разделе Собрание по планированию спринта.

Выбор описаний функциональности пользователей

Описания функциональности пользователей, которые являются кандидатами для реализации в спринте, выбираются командой. Команда определяет описания функциональности с наивысшим приоритетом, количество баллов которых не превышает ее оценочную производительность. Предположим, например, что описания функциональности пользователей с наивысшим приоритетом имеют 8, 3, 7, 6 и 2 балла. Если производительность команды составляет 25 баллов описаний, она может включить в список невыполненных работ спринта первые четыре описания функциональности.

Дополнительные сведения см. в разделе Книга "Отставание итераций".

Определение задач

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

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

Оценка задач

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

Принятие обязательств по реализации описаний функциональности пользователей

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

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

Выполнение спринта

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

Завершение описаний функциональности пользователей

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

Дополнительные сведения о назначении задач и обновлении их состояния см. в разделе Задача (гибкая разработка).

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

В своей книге "Extreme Programming Explained" Кент Бек (Kent Beck) рассказывает о том, почему гораздо эффективнее исправлять ошибки на ранних этапах работы. Учитывая этот факт, команда должна понимать приоритеты заказчика. Возможно, заказчик больше ценит качество продукта, чем поддержку большего количества функций. Владелец продукта обязан знать такого рода информацию, поскольку заказчики контролируют рабочий процесс команды.

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

Дополнительные сведения см. в разделе Ошибка (гибкая разработка).

Отслеживание хода выполнения спринта

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

Отчет "Выработка и темп работ" (гибкая разработка)

Отчет "Индикаторы качества построения"

Отчет "Ход выполнения плана тестирования"

Отчет "Ход выполнения описаний функциональности" (гибкая разработка)

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

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

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

• Удаление пользовательского описания функциональности из списка невыполненных работ спринта.

• Отмена спринта.

Завершение спринта

По мере приближения завершения спринта необходимо убедиться в том, что все описания функциональности пользователей или требования полностью выполняются командой. Например, необходимо проверить, что приемочные тесты проходят успешно, и каждое описание функциональности пользователей отвечает установленным командой критериям. Дополнительные сведения о том, что понимается под полным выполнением, см. на следующей веб-странице: Mitch Lacey & Associates, Inc.

Отчет "Состояние ошибки"

Отчет "Тенденции ошибок"

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

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

Отслеживание проекта

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

Подготовка к следующему спринту

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

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

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

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

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

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

Отслеживание хода подготовки к выпуску

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

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

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

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

Отчет "Состояние всех итераций" (гибкая разработка)

Отчет "Обзор описаний функциональности" (гибкая разработка)

Отчет "Ход выполнения описаний функциональности" (гибкая разработка)

Можно создавать настраиваемые отчеты и запросы рабочих элементов для отслеживания хода выполнения работ. Дополнительные сведения см. в разделах Создание и настройка отчетов для Visual Studio ALM, а также управление ими и Поиск ошибок, задач и прочих рабочих элементов.

Завершение выпуска

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

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

См. также

Основные понятия

Рекомендации по проектированию

Выбор шаблона процесса

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

Другие ресурсы

MSF для гибкой разработки программного обеспечения версии 5.0