Московский Государственный Технический Университет имени Н. Э. Баумана

Жуков Р.В.

«Обзор Agile-методологии управления проектами Scrum »

«Технологии проектирования»

Москва, 2013

Оглавление

Краткий список терминов и определений 3

История возникновения 3

Основные термины 4

Собрания 6

Роли 7

Жизненный цикл проекта 8

Scrum – это набор ценностей. 11

Минусы Scrum 11

Список литературы 11

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

Краткий список терминов и определений

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

Выпуск (release) – временной отрезок, в ходе которого над продуктом ведется работа. Фиксирован по времени. Имеет список задач, подлежащих решению в этот выпуск. Часто завершается выпуском новой версии продукта. Состоит из спринтов.

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

Пожелание заказчика (user story) – функциональность, которую заказчик хочет реализовать в проекте.

Резерв продукта (Product Backlog) – список пожеланий заказчика, которые необходимо реализовать в проекте, отсортирован по важности.

Резерв выпуска(Release Backlog) – список пожеланий заказчика, которые необходимо реализовать в текущем выпуске.

Резерв спринта(Sprint Backlog) – список пожеланий заказчика, которые необходимо реализовать в текущем спринте.

Очки истории (Story Points) – абстрактные очки сложности пожеланий заказчика.

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

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

Владелец Продукта - это человек, отвечающий за разработку продукта.

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

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

История возникновения

Подход впервые описали Хиротака Такэути и Икудзиро Нонака в статье The New Product Development Game (1986г). Авторы этой провели исследования среди японских компаний и выявили, что старый подход к разработке продуктов, в котором каждая фаза разработки следует только после предыдущей, малопродуктивен.

Рис. 1. Последовательная разработка продукта.

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

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

Рис. 2. Пересечение фаз разработки в некоторых компаниях.

Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Швабером и Джефом Сазерлендом на OOPSLA’96 в Остине. С тех пор данная методология претерпевала незначительные изменения и доработки, однако кардинальных отличий не было. В 2001 году Швабер совместно с Майком Бидлом детально описал данный метод ведения проектов в книге «Agile Software Development with SCRUM». В настоящее время на рынке программных разработок данный подход очень востребован, существует множество учебников, статей и советов по поводу его использования и внедрения. Так же существует сайт scrum.org , который посвящен данной методологии.

Основные термины

Спринт — итерация в скрам, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в резерве проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесенном в резерв проекта.

Резерв проекта (Product backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). Резерв проекта открыт для редактирования для всех участников скрам процесса.

Резерв спринта (Sprint backlog) — содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта.

Пожелание заказчика (User Story) — требуемая функциональность, которую добавляют в резерв часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам так и заказчикам.

Очки истории (Story Points) — абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах. Обычно используют одну из следующих шкал: ряд Фибоначчи (1,2,3,5,8,13,21,34,55); линейную шкалу (1,2,3,4 … n); степень двойки (1,2,4,8 … 2ⁿ); размеры одежды (XS, S, M, L, XL).

График сгорания задач (Burndown chart) — Диаграмма, показывающая количество сделанной и оставшейся работы. Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом. График должен быть общедоступен. Существуют разные виды диаграммы:

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

• диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

Рис.3 График сгорания задач

Собрания

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

Происходит в начале новой итерации Спринта.

• Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;

• На основе выбранных задач создается резерв спринта. Каждая задача оценивается в идеальных человеко-часах;

• Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;

• Обсуждается и определяется, каким образом будет реализован этот объём работ;

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

(первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из резерва продукта;

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

Ежедневное совещание (Daily Scrum meeting)

• начинается точно вовремя;

• длится не более 15 минут;

• проводится в одном и том же месте в течение спринта.

• В течение совещания каждый член команды отвечает на 3 вопроса:

• Что сделано с момента предыдущего ежедневного совещания?

• Что будет сделано с момента текущего совещания до следующего?

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

Обзор итогов спринта (Sprint review meeting)

• Проводится после завершения спринта.

• Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.

• Привлекается максимальное количество зрителей.

• Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).

• Нельзя демонстрировать незавершенную функциональность.

• Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта.

Ретроспективное совещание (Retrospective meeting)

• Проводится после завершения спринта.

• Члены команды высказывают своё мнение о прошедшем спринте.

• Отвечают на два основных вопроса:

• Что было сделано хорошо в прошедшем спринте?

• Что надо улучшить в следующем?

• Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).

• Ограничено 2-мя часами.

Роли

В методологии Scrum всего три основных роли: Скрам Мастер, Владелец продукта, Команда.

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

Основные обязанности Скрам Мастера таковы:

• Создает атмосферу доверия,

• Участвует в митингах в качестве фасилитатора

• Устраняет препятствия

• Делает проблемы и открытые вопросы видимыми

• Отвечает за соблюдение практик и процесса в команде

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

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

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

• Отвечает за формирование «видения продукта»

• Управляет ожиданиями заказчиков и всех заинтересованных лиц

• Координирует и приоритизирует резерв продукта

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

• Взаимодействует с командой и заказчиком

• Отвечает за приемку кода в конце каждой итерации

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

Команда (Team) – непосредственно исполнители задач.