Scrum

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

Процесс разработки ПО
Шаги процесса
Анализ | Проектирование | Реализация | Тестирование | Внедрение | Сопровождение
Модели / Методы
Agile | Cleanroom | Итеративная | RAD | Scrum | RUP | OpenUP | MSF | Спиральная | Водопад | XP
Сопутствующие дисциплины
Конфигурационное управление | Документирование | Управление проектами

Scrum — методология управления проектами для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

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

Определение

Файл:Scrum process.svg

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

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

На протяжении каждого спринта, 15-30 дневного периода (длительность определяется командой), создается функциональный рост программного обеспечения.

Набор возможностей, которые реализуются в каждом спринте, приходят из этапа, который называется product backlog (документация запросов на выполнение работ), который имеет наивысший приоритет по уровню требований к работе, которая должна быть выполнена. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта. Во время спринта команда выполняет определенный фиксированный список заданий (т.з. backlog items). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.

Роли в scrum-процессе

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

Свинья идёт по дороге. Цыплёнок смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на цыплёнка и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Цыплёнок думает и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечен только частично.»

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

«Свиньи»

Свиньи полностью включены в проект, в Скрам процесс, они как бы едины со «своей сущностью» на производственной линии.

• Владелец Продукта (Product Owner)
• Руководитель (ScrumMaster)
• Команда (Scrum Team)

«Цыплята»

• Пользователи (Users)
• Клиенты, Продавцы (Stakeholders)
• Эксперты-консультанты (Consulting Experts)

Артефакты

Product backlog

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

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

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

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

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

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

Встречи

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

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

• Выбирается объём работ, обязательства по выполнению которой за спринт принимает на себя команда
• Обсуждается и определяется, каким образом будет реализован этот объём работ
• Каждая запись PBL принятая к реализации разбивается на подзадачи, которые оцениваются в идеальных человеко-часах
• Ограничен 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.

Митинг (Daily Scrum)

Происходит каждый день в течение спринта. Является «пульсом» хода спринта. Митингу присущи следующие ограничения.

• Начинается точно вовремя
• Все могут наблюдать, но только «свиньи» говорят
• Ограничен во времени 15-ю минутами
• Проводится в одном и том же месте в течение спринта

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

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

Демонстрация (Demo Meeting)

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

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

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

Ссылки

• Украинский портал о SCRUM (рус.)