Scrum

Разработка программного обеспечения

Процесс разработки ПО
Шаги процесса
Анализ  Проектирование  Программирование  Документирование  Тестирование
Модели
Итеративная  Спиральная  Каскадная  V-Model  Dual Vee Model
Методологии
Agile (XP, Lean, Scrum и др.)  Cleanroom  OpenUP  RAD  RUP  MSF  DSDM  TDD
Сопутствующие дисциплины
Конфигурационное управление  Управление проектами  Управление требованиями

Scrum в методология управления разработкой информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд обслуживания программного обеспечения (software maintenance teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.

Историческая справка

Подход впервые описали Хиротака Такеути и Икудзиро Нонака в статье The New Product Development Game (Гарвардский Деловой Обзор, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие, кросс-функциональные команды, обычно систематически производят лучшие результаты, и объяснили это как «подход регби». В 1991 году ДеГрейс и Шталь в книге «Злые проблемы, справедливые решения» ссылались на этот подход, как на Scrum (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведённый в статье Такеути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привел Scrum в его компанию. Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Сазерлендом и Швабером на OOPSLAв™96 (англ.) в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как Scrum. Швабер объединил усилия с Майком Бидлом в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM».

Определения

Скрам процессы

Скрам

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

Спринт

Спринт в итерация в скрам, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. На протяжении спринта никто не имеет права менять список требований к работе.

Резерв Проекта (Product backlog)

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

Резерв спринта (Sprint backlog)

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

Диаграмма сгорания задач (Burndown chart)

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

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

Существуют разные виды диаграммы:

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

Дополнительные определения

История спринта (Sprint Story)

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

Остановка спринта (Abnormal Termination)

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

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

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

Задачи истории спринта (Sprint Story Tasks)

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

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

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

Роли в скрам-процессе

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

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

«Свиньи»

«Свиньи» полностью включены в проект и в скрам-процесс. Основные роли в методологии скрам:

• Скрам-мастер (ScrumMaster) проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к хозяину проекта и не должен фигурировать в качестве скрам-мастера.
• Хозяин проекта (Product Owner) представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
• Скрам-команда (Scrum Team) кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

«Куры»

• Пользователи (Users)
• Клиенты, Продавцы (Stakeholders) лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
• Управляющие (Managers) люди, которые управляют персоналом.
• Эксперты-консультанты (Consulting Experts)

Артефакты

Обязательные поля

• ID в уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.
• Название (Name) в краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и хозяин проекта могли понять, о чем идёт речь и отличить одну историю от другой.
• Важность (Importance) в степень важности данной истории, по мнению хозяина проекта. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.
• Предварительная оценка (initial estimate) в начальная оценка объёма работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story pointв™ах. Приблизительно соответствует числу «идеальных человеко-часов».
• Как продемонстрировать (how to demo) в краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо-сдаточного испытания.

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

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

• Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля хозяин проекта может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.
• Компоненты (components) в указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkboxв™ов, которые отмечаются, если соответствующие компоненты требуют изменений.
• Инициатор запроса (requestor). хозяин продукта может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.
• ID в системе учёта дефектов (bug tracking ID) в если вы используете отдельную систему отслеживания ошибок, тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.

Встречи

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

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

• Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;
• На основе выбранных задач создается резерв спринт. Каждая задача оценивается в идеальных человеко-часах;
• Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
• Обсуждается и определяется, каким образом будет реализован этот объём работ;
• Продолжительность совещания ограничено сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
  • (первая часть совещания) Участвует хозяин проекта и скрам команда: выбирают задачи из резерва продукта;
  • (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют резерв спринта.

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

• начинается точно вовремя;
• все могут наблюдать, но только «свиньи» говорят;
• длится не более 15 минут;
• проводится в одном и том же месте в течение спринта.

В течение митинга каждый член команды отвечает на 3 вопроса.

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

Скрам над скрамом

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

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

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

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

• Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.
• Привлекается максимальное количество зрителей.
• Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
• Нельзя демонстрировать незавершенную функциональность.
• Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта.

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

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

• Члены команды высказывают своё мнение о прошедшем спринте.
• Отвечают на два основных вопроса:
  • Что было сделано хорошо в прошедшем спринте?
  • Что надо улучшить в следующем?
• Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
• Ограничена 1в3-мя часами.

Ссылки

• Белорусский портал о SCRUM  (рус.)
• Scrum - зачем заказчику знать такие непонятные слова?  (рус.)

Литература

• Майк Кон Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum. в М.: «Вильямс», 2011. в С. 576. в ISBN 978-5-8459-1731-7

• Хенрик Книберг Scrum и XP: заметки с передовой = Scrum and XP from the trenches. в C4Media], 2007. в С. 140. в ISBN 978-1-4303-2264-1