Один с способов вести разработку программного обеспечения, в то числе разработка веб-сайтов.
SCRUM (по русски читается СКРАМ) — методология управления процессом для гибкой разработки программного обеспечения.
Для лучшего понимания методологии пройдем последовательно по этапам создания программного продукта согласно методологии SCRUM.
Давайте подробнее рассмотрим как работает методология SCRUM.
На встрече с клиентом определяется концепция и список требований к функциональности продукта. При этом все требования описаны на понятном для заказчика языке. На основании этого Product Owner — человек, который представляет интересы заказчика, составляет Product Backlog — список требований к функциональности, упорядоченный по степени важности так, чтобы в первую очередь были реализованы наиболее ценные для бизнеса заказчика возможности. Product Backlog должен быть ориентирован на бизнес, т.е. на то «что надо», а не на то «как сделать».
Затем список обсуждается с командой (Scrum Team) для оценки объема работ.
В результате у каждого элемента Backlog'а должны быть заполнены следующие поля:
- ID – уникальный идентификатор – порядковый номер.
- Название – краткое описание. Должно быть однозначным, чтобы разработчики и product owner могли примерно понять, о чем идет речь, и отличить один элемент Backlog'а от другого. Обычно от 2 до 10 слов.
- Важность (Importance) – степень важности, по мнению product owner'а. Например, 10. Или 150. Чем больше значение, тем выше важность.
- Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации элемента Backlog'а. Приблизительно соответствует числу «идеальных человеко-дней».
- Как продемонстрировать (how to demo) – краткое пояснение того, как завершённый элемент Backlog'а будет продемонстрирована в конце спринта. По сути, это простой тестовый сценарий типа «Сделайте это, сделайте то – должно получиться то-то».
- Примечания – любая другая информация: пояснения, ссылки на дополнительные источники информации, и т.д.
Официально документ принадлежит product owner’у, однако другим членам команды разрешается его редактировать.
У каждого продукта должен быть только один product backlog и только один product owner.
Все наиболее важные элементы Backlog'а должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать.
Product owner должен понимать каждый элемент Backlog'а.
Примечание: Хотя заинтересованные лица могут добавлять требования в product backlog, они не имеют права присваивать им уровень важности. Это прерогатива product owner’а. Они также не могут добавлять оценки трудозатрат, поскольку это прерогатива команды.
Весь процесс разработки продукта в SCRUM разбит на итерации, называемые СПРИНТами. Продолжительность итерации 1 — 4 недели.
Перед каждой итерацией производится планирование спринта.
Задачи планирования спринта – это определение цели спринта, выбор требований из Product Backlog'а для перемещения их в Sprint backlog, определение даты демонстрации (или длины спринта), определение команды, реализующей спринт. По окончании спринта на выходе должна быть работающая программа, которую владелец продукта может попробовать своими руками.
Цель спринта должна отвечать на главный вопрос “Зачем команда работает над этим спринтом»?
Sprint backlog – это список верхних элементов элементов из Product Backlog'а, которые команда обязалась выполнить в течение спринта.
Дата демо — дата окончания спринта, дата демонстрации работающего функционала.
Важно, чтобы и product owner, и команда совместными усилиями определили критерий готовности элемента Backlog'а.
Каждый элемент Sprint backlog'а может быть разбит на задачи. Разница между “задачами” и “элементами Backlog'а” в том, что элементы Backlog'а это нечто, что можно продемонстрировать, что представляет ценность для product owner’а, а задачи либо нельзя продемонстрировать, либо они не представляют ценности для product owner’a.
Также во время планирования спринта определяются время и место проведения ежедневных Scrum-митингов.
Scrum-митинг — ежедневная короткая встреча команды, где каждый участник разработки отчитывается, что он сделал вчера, что должен сделать сегодня, какие проблемы у него возникли. В ходе общей встречи ищутся способы разрешения этих проблем. Задача Scrum Master’a (лидера команды) — состоит в том, чтобы предоставить команде все возможности для реализации выбранных задач, но не диктовать, что должен делать каждый участник разработки.
Scrum Master контролирует продвижение работ.
Эффективный инструмент для этого — доска задач. Доска задач состоит из трех колонок: «В планах», «В процессе», «Готово».
Для иллюстрации мы взяли картинки из книги Хенрика Книберга «SCRUM и XP: заметки с передовой» (скачать книгу).
При старте спринта все задачи находятся в колонке «В планах». После первого ежедневного Scrum'a доска задач может выглядеть примерно так:
Через пару дней доска задач может выглядеть примерно так:
Кроме доски задач Scrum Master создает burndown-диаграмму (ее видно на рисунках справа).
Burndown-диаграмма создается следующим образом:
- по оси Y отмечается прогнозируемый объем работ в story-point'ах.
- по оси Х даты до дня демонстрации. Выходные дни при этом лучше пропустить.
После окончания каждого Scrum-митинга Scrum Master отмечает на burndown-диаграмме точку, в которой находится команда.
Таким образом взглянув на диаграмму, всегда можно сказать где находится команда.
При обнаружении отклонений Scrum Master принимает меры.
По завершению спринта проводится демонстрация продукта Product owner'у.
По окончанию скрипта рекомендуется проводить собрание по ретроспективе разработки, с целью закрепления лучших практик и устранения препятствий.
Далее производится планирование следующего спринта и процесс повторяется.
На определенном этапе оказывается, что все необходимые заказчику возможности реализованы, что является сигналом к окончанию проекта.