Последнее время меня часто спрашивают, что такое Scrum, люди, которые имеют весьма отдаленное отношение к ИТ. В связи с этим я решила объяснить простыми словами, что же значит Scrum. Так что господа Scrum-последователи не судите меня строго.

Scrum (Скрам) — это не аббревиатура, этот термин взят из регби, который обозначает схватку вокруг мяча.

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

Основные термины, которые используются в методологии:

Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач.

Scrum-мастер — это человек, которого можно назвать руководителем проекта, хотя это не совсем так. Главное, что это человек, «зараженный Scrum-бациллой» на столько, что несет ее как своей команде, так и заказчику, и соответственно следит за тем, чтобы все принципы Scrum соблюдались.

Scrum-команда — это команда, которая принимает все принципы Scrum и готова с ними работать.

Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз).

Бэклог (backlog) — это список всех работ. Можно сказать, что это ежедневник общего пользования 🙂

Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог.

Product-бэклог — это полный список всех работ, при реализации которых мы получим конечный продукт.

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

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

Попробую объяснить все это на примере работы PR-агентства, как бы это могло выглядеть, если бы они работали по Scrum.

Компания клиент «Икс» хочет провести через 2 месяца масштабное мероприятие для своих партнеров и журналистов. Услуги по организации такого мероприятия компания «Икс» заказала у агентства «Зет». Компанию «Икс» представляет PR-менеджер, который отвечает за организацию мероприятия со стороны клиента. В терминологии Scrum — этот человек называется Владелец продукта . Со стороны агентства за организацию мероприятия отвечает account-менеджер (Scrum-мастер ), в подчинении которого находится команда (Scrum-команда ). На совместном совещании (планировании спринта ) компания и агентство решают, что они будут отчитываться-планировать каждые 2 недели (длина спринта ). На первые 2 недели они запланировали список задач (спринт-бэклог ), однако команда оценила, что не все из этого списка они успеют выполнить. Тогда PR-менеджер (он же Владелец продукта ), говорит какие из этого списка задач более приоритетные на ближайшие 2 недели, после чего команда берется за выполнение заданий. Единственное что здесь должно быть учтено, что на момент планирования первого спринта должен быть спланирован весь список заданий на 2 месяца (product-бэклог ), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено.

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

Scrum на простом языке

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

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

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

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

Планирование

В начале спринта Скрам команда проводит спринт планирование для:

• Общение по определению объема работ, которые предполагается сделать во время этого спринта;
• Выбор элементов Бэклога продукта, которые могут быть завершены в один спринт;
• Подготовка спринта, определение необходимых работ, чтобы закончить некоторые элементы Бэклога продукта;
• Определение тайм-боксов – четырех-часовых лимитов на двухнедельные спринты (пропорциональная продолжительность для остальных спринтов);
  • В течение первой половины, вся скрам-команда (а это команда-разработчиков, scrum-мастер, а также product owner- владелец продукта) выбирают работы-задачи из Бэклога, которые могут быть достигнуты в этом спринте;
  • Во второй половине команда разработчиков декомпозирует работы (задания), необходимые для предоставления этих элементов Бэклога продукта, в результате чего подтверждается спринт;
    • Некоторые элементы Бэклога продукта могут быть разделены или переориентированы если выявленные работы, не достижимы в этом спринте.

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

Ежедневный scrum в начинается в одной и той же комнате. Это централизованное расположение помогает команде начать вовремя. Каждый день во время спринта команда проводит ежедневный скрам (обычно стоя) с конкретными руководящими принципами:

• Ежедневный скрам. Все члены команды разработчиков должны готовиться. Ежедневный Скрам…
  …начинается точно по времени, даже если некоторых членов команды не хватает;
  …должен начаться каждый день в одном и том же месте и в одно и то же время;
  …ограничен (timeboxed) пятнадцатью минутами.
• Могут присутствовать посторонние, хотя обычно только команда scrum обменивается мнениями о текущей ситуации;
• Особенностью ежедневного скрам-митинга является то, что каждый участник группы отвечает на 3 локоничных и простых вопроса:
  • Мои вчерашние выполненные задачи? Каким образом я помог команде-разработчиков достигнуть цели-спринта?
  • Какие я ставлю себе задачи на сегодня, чтобы нам совместно достичь цели-спринта?
  • Наблюдаю ли я какие-либо ограничения, мешающие мне или команде разработчиков достигнуть цели-спринта?

Любое ограничение (например, камень преткновения, риск, проблема, задержка зависимостей, необоснованность предположения), выявленных на ежедневном scrum-митинге должно быть записано скрам мастером и перенесено на scrum доску. Детальное обсуждение во время ежедневного скрам-митинга не производится.

Обзоры и ретроспективы

Команда проводит два мероприятия в конце спринта: обзор и ретроспектива спринта.

Действия команды во время обзора спринта:

• Обзор работ, которые были выполнены и планирование работ, которые не были завершены;
• Представлена готовые работы для заинтересованных сторон (например демо)

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

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

В ретроспективе спринта, команда:

• Размышляет о прошлом спринте;
• Определяет и согласовывает процесс непрерывного совершенствования действий.

Руководящие принципы для ретроспектив спринта:

• В ретроспективе спринта лишь два главных вопроса: что было хорошего во время спринта? Что можно улучшить в следующем спринте?
• Рекомендуемая продолжительность – 1-1,5 часа на двухнедельный спринт(пропорционально для других длительностей спринтов)
• Это событие закреплено за скрам мастером

Дополнительно

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

Уточнение Бэклога

Уточнение Бэклога (некоторые называют груминг Бэклога) – это непрерывный процесс пересмотра элементов Бэклога и проверка того, что в нем правильно расставлены приоритеты и он составлен таким образом, который позволяет говорить о том, что задачи достаточно четкие и исполняемые для команды.

Элементы Бэклога:

• могут быть разбиты на несколько более мелких;
• критерии приемки могут быть уточнены;
• зависимости, последователи и подготовительные работы могут быть определены и согласованы при техническом согласовании.

Хотя данная практика не входит в основной скрам, уточнение Бэклога было принято как способ управления качеством элементов Бэклога, с рекомендуемым объемом до 10% времени спринта.

Скрам скрамов

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

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

Работа построена по аналогии с ежедневным скрам-митингом, и каждый представитель готовит свои ответы на следующие четыре вопроса:

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

Как Джефф Сазерленд прокомментировал,

С тех пор как я изначально дал определение скрам скрамов (Кен Швабер работал в IDX в то время со мной), я могу точно сказать, что скрам скрамов – это не “Мета Скрам”. Скрам скрамов, каким я его использовал, несет ответственность за предоставление рабочих версий софта от всех команд в конце спринта, или за релизы во время спринта. Ответственность за это несет Мастер скрам скрамов. Так скрам скрамов – это механизм более оперативной поставки ПО.

Это руководство для разработчиков ПО и тестеров поможет понять гибкую методику SCRUM и начать работать по ней.

Узнайте базовые, но важные термины, используемые в процессе Agile Scrum вместе с реальным примером полного процесса.

SCRUM - это процесс в гибкой методике, которая представляет собой сочетание итеративной и добавочной моделей.

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

Некоторые из ключевых особенностей SCRUM:

• Организованная и целеустремленная команду
• Никаких требований документов, достаточно иметь точные тексты по существу.
• Функциональная команда работает как единое целое.
• Тесная связь с пользователем, помогающая чтобы понять особенности.
• Имеется точная временная ось максимум 1 месяц.
• Вместо того, чтобы делать все действия за раз, Scrum делает все понемногу на заданном промежутке
• Прежде чем совершать какие-либо действия рассматриваются характеристики и доступность ресурсов.

Чтобы хорошо понять эту методику, важно понимать ключевые термины SCRUM.

Важные термины SCRUM:

1. Scrum-команда

Scrum-команда – это команда из 7 +/– 2 члена. Члены команды представляют собой смесь из компетентных разработчиков, тестеров, людей из база данных, операторов техподдержки, т. д., а также владельца продукта и scrum-мастера. Все эти люди работают в тесном сотрудничестве в течении заданного рекурсивного промежутка для разработки и выполнения указанных функций.

2. Спринт

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

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

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

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

4. Scrum-мастер

Scrum-мастер является координатором команды scrum. Он/она следит за тем, чтобы команда scrum была продуктивной и прогрессивной. В случае каких-либо помех scrum-мастер находит и устраняет их для команды.

5. Пользовательская история

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

Как <тип пользователя>

я хочу <доступная цель>

для достижения <результат/причина>

Например:

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

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

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

6. “Эпопеи”

Эпопеи являются неясными пользовательскими историями. Или же, можно сказать, что это пользовательские истории, которые не определены и хранятся для будущих спринтов. Просто попробуйте связать это с жизнью, представьте, что вы уходите в отпуск. Так как вы уезжаете на следующей неделе, у вас все распланировано: бронирование номера в отеле, осмотр достопримечательностей, собрана дорожная сумка др. Но что насчет вашего отпуска в следующем году? У вас есть только смутная мысль, что вы можете пойти в место XYZ, но у вас нет никакого детального плана.

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

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

7. Журнал пожеланий по продукту

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

8. Журнал пожеланий спринта

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

9. Очки за пользовательскую историю:

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

Каждой пользовательской истории определяется балл из ряда Фибоначчи (1, 2, 3, 5, 8, 13, 21). Чем выше число, тем сложнее история.

Если точнее, то

• Если вы ставите 1 / 2 / 3 очка, это означает, что история небольшая и имеет низкую сложность.
• Если вы даете 5 / 8 очков, то это средняя сложность и
• 13 и 21 очко – история очень сложная.

Здесь сложность заключается в разработке и в объеме тестовых работ

Чтобы решить, сколько очков дать, scrum-команда начинает мозговой штурм коллективно это решает. Может случиться так, что команда разработки даст конкретной истории 3 очка, потому что для них это может быть 3 строки кода замены, но команда тестирования даст 8 очков, потому что им кажется, что эта замена кода будет больше влиять на модули, поэтому объем работы при тестировании будет больше. Но сколько бы очков вы ни дали, вы должны обосновать свое решение. Таким образом, происходит мозговой штурм и команда решает, сколько очков поставить.

Всякий раз, когда вы решаете сколько очков поставить, учитывайте следующие факторы:

• Отношение истории к другим приложениям/модулям,
• Набор навыков ресурса
• Сложность истории
• Повествовательное обучение,
• Критерии приемки пользовательский историй

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

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

Диаграмма сгорания задач представляет график, который показывает предполагаемые v/s реальных усилий задач scrum.

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

Пример: Чтобы понять это, посмотрите на рисунок:

Я выбрал:

• Двухнедельный Спринт (10 дней)
• 2 ресурса фактической работы спринта.

«История»-> колонка показывает пользовательские истории, взятые для спринта. «Задача»-> столбец показывает список задач, связанных с пользовательскими историями.

«Объем работы»-> колонка показывает объем работы. Сейчас эта мера является общим объемом работы для завершения задачи. Она не изображает объем работы какого-то конкретного человека.

«День 1 – день 10»-> – столбец (столбцы) показывает/-ют время, оставшееся до завершени истории. Обратите внимание, что это НЕ то время, что уже прошло, НО время, которое еще остается.

«Предполагаемый объем работы»-> показатель общих объема работы. Для «Старта» это просто итог всей задачи: СУММА (C5: C15)

Общий объем работы, который должен быть выполнен за 1 день, составляет 70 / 10 = 7. Таким образом, в конце первого дня объем работы должен уменьшиться до 70-7 = 63. Аналогичным образом это рассчитывается для всех дней до 10го, когда предполагаемый объем работ должен равняться нулю (строка 16)

«Оставшийся объем работы»-> исходя из названия, это – объем работы, оставшийся до завершения истории. Также может случиться, что фактический объем работы становится больше или меньше, чем предполагалось.

Вы можете использовать функции и диаграммы в Excel для создания этой диаграммы сгорания задач.

Этапы диаграммы сгорания задач:

1. Введите все истории (колонка A5 – А15)
2. Введите все задачи (колонка B5-B15)
3. Введите дни (1-день – 10-й день)
4. Введите начальный объем работы (суммируйте задачи C5-C15)
5. Примените формулу для расчета «предполагаемого объема работы» на каждый день (от дня 1 до дня 10). Введите формулу в D15 (с16-$C$ 16/10) и перетяните ее на все дни.
6. На каждый день введите фактический объем работы. Введите формулу в D17 (СУММА (D5:D15)) суммировать оставшийся объем работы и перетащите ее на все остальные дни.
7. Выберите это и создайте диаграмму следующим образом:

11. Скорость команды

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

Например : Для конкретного спринта: общее количество пользовательских историй – 8. Каждая из них имеет определенное количество очков

Таким образом, скорость – это сумма очков = 30

12. Определение “готово”:

История СДЕЛАНА в Scrum, только тогда, когда есть развитие, полное обеспечение качества и возможность попасть в производство.

Деятельность в SCRUM:

#1: Совещание по планированию

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

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

#2: Выполнение задач спринта

Исходя из названия, это работа scrum-команды для выполнения своей задачи и перемещения пользовательской истории в статус “готово”.

#3: Ежедневное scrum-совещание (звонок)

Во время цикла спринта, каждый день scrum-команда встречается не более чем на 15 минут (это может быть звонок, который рекомендуется проводить в начале дня). На собрании ставится 3 вопроса:

1. Что сделал член команды с момента прошлой встречи
2. Что член команды планирует сделать сегодня
3. Имеются ли какие-нибудь препятствия для команды

Над решением этих проблем работает Scrum-мастер. В том случае столкновения участника с любого рода трудностями, scrum-мастер помогает их решить.

#4: Обзор итогов

В конце каждого цикла спринта SCRUM-команда снова встречается и демонстрирует владельцу продукта осуществление пользовательских историй. Владелец продукта может сличить истории в соответствии с их критериями приемки. Это опять же ответственность Scrum-мастера – председательствовать на этой встрече.

#5: Ретроспективное совещание

Ретроспективное совещание происходит после обзора итогов. SCRUM-команда собирается, обсуждает и документирует следующие моменты:

1. Что было сделано хорошо в предыдущем спринте (наилучшая практика)
2. Что было сделано не очень хорошо
3. Извлеченные из этого уроки
4. Элементы действий.

Scrum-команда должна продолжать следовать лучшим методам работы, игнорировать «не лучшую практику» и выполнять уроки, извлеченных в ходе последующих спринтов. Ретроспективное совещание помогает постоянно совершенствование процесс SCRUM.

Как выполняется процесс? Пример!

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

Шаг #1 : Представим SCRUM-команду из 9 человек, в составе которых 1 владелец, 1 Scrum-мастер, 2 тестера, 4 разработчика и 1 администратор базы данных.

Шаг #2 : Спринт цикл, например, будет длиться 4 недели. Итак, у нас 1 месяц спринта: с 5 июня по 4 июля.

Шаг #3 : Владелец продукта имеет приоритетный список пользовательских историй в журнале пожеланий по продукту.

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

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

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

Общее количество рабочих часов = 9

Минус 1 час для перерыва, минус 1 час для встреч, минус 1 час для писем, обсуждений, устранения неполадок и др.
Таким образом, фактические рабочие часы = 6

Общее количество рабочих дней во время спринта = 21 день.
Общее количество доступных часов = 21 * 6 = 126

Участник находится в отпуске 2 дня = 12 часов (это варьируется для каждого члена, некоторые могут взять отпуск, некоторые не могут.)
Количество фактических часов = 126-12 = 114 часов.

Это означает, что участник обычно будет доступен на 114 часов во время этого спринта. Поэтому он будет разделять свою индивидуальную спринт задачу таким образом, что за 114 часов она будет достигнута.

• Окончательный мнение о пользовательской истории из журнала пожеланий по продукту составлено, и история перемещается в журнал пожеланий спринта.
• Для каждой истории, каждый участник команды объявляет свои определенные задачи. Если требуется провести обсуждение этих задач, то можно измерить или изменить их размер (вспомним ряд Фибоначчи!).
• Scrum-мастер или команда вводит свои индивидуальные задачи и их время для каждой истории в программу.
• После того, как будут завершены все истории, Scrum-мастер отмечает начальную скорость и Спринт официально начинается.

Шаг #6 : После начала спринта, каждый участник команды начинает работать над назначенными задачами.

Шаг #7 : Команда ежедневно встречается на 15 минут и обсуждает 3 вопроса:

• Что они делали вчера?
• Что они планируют сделать сегодня
• Есть ли какие-нибудь помехи?

Шаг #8 : Scrum-мастер ежедневно отслеживает прогресс с помощью «Диаграммы сгорания задач»

Шаг #9 : В случае каких-либо помех Scrum-мастер решает их.

Шаг #10 : 4 июля команда собирается вновь для обзора итогов. Каждый член команды демонстрирует реализованную пользовательскую историю владельцу продукта.

Шаг #11 : 5 июля команда собирается снова для ретроспективного совещания, где они обсуждают

• Что прошло хорошо?
• Что прошло не хорошо
• Элементы действий.

Шаг #12 : 6 июля команда снова встречается для совещания предварительного планирования следующего спринта, и цикл продолжается.

(Нажмите, чтобы увеличить изображение)

Программы, которые могут быть использованы для деятельности SCRUM:

Есть много инструментов, которые могут широко использоваться для отслеживания деятельности scrum. Вот некоторые из них:

• XPlanner
• VersionOne
• Sprintometer
• ScrumNinja

Заключение:

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

Многие временные организации вдохновляют команду (в качестве задачи scrum) посвятить пару часов самостоятельному обучению и развитию. Также во время обзора члены группы показывают что они изучили, а иногда представляют программы или приложения, которые они разработали. Лично я ценю этот метод, потому что он дает людям шанс расширить свои знания, а также показать свои навыки.

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

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

Основные принципы организации работы в Scrum командах

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

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

2. Требования разбиваем на небольшие, ориентированные на пользователей, функциональные части, которые максимально независимы друг от друга, в результате чего мы получим беклог продукта. Затем упорядочите элементы беклога по их важности и произведите относительную оценку объемов каждой истории. Выделите отдельного человека – владельца продукта, который будет отвечать за требования и их приоритеты, замыкая на себя всех заинтересованных лиц.
3. Всю работу ведем короткими от 1 до 4 недель фиксированными итерациями – спринтами, поставляя в конце каждого из них законченный функционал, который можно при необходимости вывести на рынок – инкремент продукта . Команда согласно своей скорости набирает задачи на неизменяемую по времени итерацию – спринт. Каждый день проводится скрам-митинг, на котором команда синхронизирует свою работу и обсуждает проблемы. В процессе работы члены команды берут в работу элементы беклога согласно приоритету.
   

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

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

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

В деталях обо всем этом вы можете узнать из книги «Scrum – революционный метод управления проектами» Джефа Сазерленда, а мы продолжим разговор на тему практик. Познакомившись с ними, вы сможете понять, как реализуется Scrum-проект.

Ежедневные Скрам-встречи

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

Проводит ежедневные встречи скрам-мастер. Поочередно каждому участнику он задает вопросы:

• Что ты сделал вчера?
• Что ты сделаешь сегодня?
• С какими проблемами ты столкнулся?

Все открытые вопросы скрам-мастер заносит в список «Пункты действий». Здесь очень подходит формат «Что? Кто? Когда?». Вот простой пример такого списка:

• Обсудить детали дизайна бэкграунда
• Толя и Коля
• Сразу после обеда

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

Встречи по обзору спринта

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

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

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

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

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

Аварийная остановка спринта

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

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

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

Артефакты в Scrum

В любом Scrum-проекте есть три основных артефакта (документа):

• Журнал продукта (Product Backlog)
• Журнал спринта (Sprint Backlog)
• График спринта (Burndown Chart)

У каждого из артефактов есть свои особенности.

Журнал продукта

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

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

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

Журнал спринта

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

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

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

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

График спринта

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

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

Таковы общие особенности Scrum-методологии. Если у вас возникло желание разобраться в этом методе более детально, то вам поможет в этом Джеф Сазерленд – познакомьтесь с уже упоминаемой книгой «Scrum – революционный метод управления проектами». А нам остается только подвести итоги этого краткого обзора Скрам.

Выводы о Scrum

Итак, относящийся к системе методов гибкого управления Agile, Scrum можно смело назвать настоящей находкой для людей, чья деятельность связана с проектами. Среди его достоинств выделяется, в первую очередь, ориентированность и адаптивность. Метод позволяет изменять требования к проекту в любое время (пусть и не дает гарантии того, что эти изменения будут реализованы). А такая возможность очень привлекает заказчиков.

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

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

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

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

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

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