Scrum методология разработки

Понятие scrum пришло в мир IT из спорта, а точнее из регби. На данный момент это одна из более гибких и эффективных методологий в разработке ПО и его поддержке. Методология Scrum,которая построена на принципах тайм-менеджмента, делает акцент на качественном контроле процесса разработки.

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

Роли в Scrum команде: кто за что отвечает

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

Давайте рассмотрим структуру методологии подробнее.

Итак, основная составляющая здесь это Scrum-команда (обычно состоит из 3-9 человек, оптимально 5-7). Это группа специалистов разного профиля, например, java-программисты, тестировщики, аналитики и т.д. Команда полностью вовлечена в разработку продукта и отвечает за результат как единое целое.

Практический пример: В проекте разработки мобильного приложения для банка команда может включать 2 Java-разработчиков, 1 Android-разработчика, 1 тестировщика, 1 UI/UX дизайнера и 1 DevOps-инженера.

Есть product owner (владелец продукта) – заказчик или его представитель, который заинтересован в качественном конечном продукте. Этот человек знает как должен выглядеть и работать продукт, поэтому он расставляет перед командой приоритеты для задач. Главное отличие владельца продукта в том, что он работает не в команде, а с ней.

Product Owner также отвечает за создание и поддержание Product Backlog - приоритизированного списка функций и требований к продукту. Он пишет User Stories (пользовательские истории) в формате: "Как [тип пользователя], я хочу [функцию], чтобы [получить результат]".

Пример User Story: "Как клиент банка, я хочу переводить деньги через мобильное приложение, чтобы не тратить время на посещение отделения".

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

Инструменты Scrum-мастера:

Jira или Azure DevOps для управления задачами
Confluence для документации
Miro или Mural для ретроспектив
Burndown charts для отслеживания прогресса

Реальный пример: Если разработчик застрял с интеграцией API, Scrum-мастер не решает техническую проблему сам, а помогает найти нужного эксперта или организует pair programming с более опытным коллегой.

Как работает Scrum: спринты и события

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

Sprint Planning: планирование на результат

Sprint Planning состоит из двух частей:

Что делать? - Product Owner презентует приоритетные User Stories из Product Backlog
Как делать? - команда разбивает User Stories на технические задачи и оценивает их

Практический пример планирования:

User Story: "Авторизация через Google"
Технические задачи:
- Настроить OAuth 2.0 (5 story points)
- Создать UI для кнопки входа (3 story points)
- Написать тесты (3 story points)
- Добавить обработку ошибок (2 story points)

Команда формирует Sprint Backlog - список задач на текущий спринт.

Каждый рабочий день начинается со скрама (совещания). Каждый член команды отвечает на 3 вопроса: «Что я уже сделал?», «Что я сделаю сегодня?», «Что может помешать выполнению задачи?». С помощью данных собраний участники оценивают прогресс и своевременно решают возникающие трудности.

Daily Scrum: ежедневная синхронизация

Пример Daily Scrum в Java-команде:

Андрей (Backend): "Вчера закончил API для регистрации пользователей. Сегодня начну интеграцию с базой данных. Блокеров нет."

Мария (Frontend): "Вчера сверстала форму логина. Сегодня подключу к API Андрея. Нужна помощь с валидацией email на фронтенде."

Игорь (QA): "Вчера написал тест-кейсы для регистрации. Сегодня протестирую готовый API. Жду окончания задачи Андрея."

Daily Scrum не должен превышать 15 минут и проводится в одно и то же время каждый день.

Также проводится завершающее совещание в конце спринта, где каждый участник докладывает своих успехах или о том, что помешало выполнить некоторые задачи. В основном отвечают на 2 вопроса: «Что было сделано хорошо в прошедшем спринте?», «Что надо улучшить в следующем?».

Sprint Review и Sprint Retrospective: анализ и улучшение

Важно: в конце спринта проводятся ДВА разных события:

Sprint Review (Обзор спринта)

Цель: демонстрация готового функционала заказчику и stakeholders
Участники: вся Scrum-команда + заказчик + пользователи
Длительность: до 4 часов для месячного спринта
Результат: обратная связь по продукту, корректировка Product Backlog

Пример Sprint Review:

Команда демонстрирует новую функцию авторизации через Google. Заказчик тестирует, предлагает добавить возможность входа через Facebook. Product Owner добавляет эту задачу в Product Backlog.

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

Цель: улучшение процесса работы команды
Участники: только Scrum-команда (без заказчика)
Длительность: до 3 часов для месячного спринта
Формат: "Start-Stop-Continue" или "What went well - What could be improved - Action items"

Пример ретроспективы:

Start: использовать pair programming для сложных задач
Stop: откладывать code review на конец дня
Continue: ежедневные демо готового функционала

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

FunRetro.io
Retrium
MetroRetro
Miro templates

Плюсы и минусы методологии Scrum в IT-разработке

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

Реальные примеры успешного применения Scrum

Spotify: использует модифицированный Scrum с "племенами" и "гильдиями" для координации 100+ команд разработки.

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

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

Еще один плюс Scrum'a это самостоятельность и самоорганизованность каждого участника проекта. Можно сэкономить на руководителе и разделить деньги между членами команды. Но в таком случае достаточно много внимания уделяется отбору персонала.

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

Когда Scrum может не подойти

Примеры проектов, где Scrum менее эффективен:

Compliance-проекты: строгие требования и фиксированные дедлайны (например, внедрение GDPR)
Embedded разработка: длительные циклы тестирования оборудования
Исследовательские проекты: неопределенность результата и методов

Альтернативы Scrum:

Kanban - для команд поддержки с постоянным потоком задач
Waterfall - для проектов с четкими требованиями и фиксированным scope
SAFe - для крупных enterprise-проектов с множеством команд

Самоорганизованность и гибкость java-программиста в scrum'e это, конечно, хорошо, но куда без знаний и практических навыков? Чувствуешь, что тебе этого не хватает? Тогда быстрей решай задачи на JavaRush