Какие знаешь процессы в Scrum?

Процессы в Scrum

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

1. Sprint Planning

Цель: Спланировать работу на предстоящий sprint (обычно 1-2 недели)

Участники:

• Product Owner
• Scrum Master
• Development Team
• Business Analyst (я)

Процесс:

1. Product Owner представляет top-priority items из Product Backlog
2. Team обсуждает требования, уточняет детали
3. BA задаёт уточняющие вопросы: "Что именно означает готово?", "Есть ли исключительные случаи?"
4. Team оценивает сложность (story points, обычно 1-13)
5. Team выбирает items, которые реально завершить за sprint
6. Создаётся Sprint Goal — высокоуровневая цель спринта

Мой вклад как BA:

• Убеждаюсь, что требования достаточно ясны перед началом спринта
• Помогаю разбить большие items на меньшие (если нужно)
• Объясняю бизнес-контекст для каждого item

Результат: Sprint Backlog (список задач на спринт) и Sprint Goal

2. Daily Standup

Цель: Синхронизация команды каждый день

Продолжительность: 15 минут максимум

Процесс: Каждый член команды отвечает на 3 вопроса:

1. Что я завершил вчера?
2. Что я делаю сегодня?
3. Есть ли блокеры/препятствия?

Типичный пример:

Фронтенд разработчик: "Завершил форму для создания заказа. Сегодня буду интегрировать с API. Мне нужны уточнения по format ошибок в API — BA, ты поможешь?"
BA (я): "Давай обсудим после standup. У меня есть примеры ошибок из документации API."

Мой вклад:

• Слушаю, есть ли блокеры, связанные с требованиями
• Быстро отвечаю на вопросы об acceptance criteria
• Сообщаю о любых изменениях требований

3. Backlog Refinement

Цель: Подготовить items для будущих спринтов

Продолжительность: 1-2 часа, обычно за день-два до Sprint Planning

Процесс:

1. Product Owner показывает items, которые планирует добавить в следующий спринт
2. Team обсуждает техническую возможность реализации
3. BA уточняет требования:
   • Задаю вопросы
   • Разбираю исключительные случаи
   • Уточняю acceptance criteria
4. Team переоценивает сложность

Мой вклад:

• Помогаю подготовить demo
• Объясняю stakeholders, как использовать новую функцию
• Логирую feedback в Issues

4. Sprint Review

Цель: Показать завершённую работу заинтересованным сторонам

Продолжительность: 30-60 минут

Участники:

• Development Team
• Product Owner
• Scrum Master
• Stakeholders

Процесс:

1. Team демонстрирует каждый completed item
2. Stakeholders дают feedback
3. PO и Team обсуждают feedback
4. Feedback попадает в Product Backlog

Мой вклад как BA:

• Помогаю подготовить demo
• Объясняю stakeholders новую функцию
• Переводу техничные детали в бизнес-язык
• Логирую feedback

5. Sprint Retrospective

Цель: Улучшить процесс команды

Продолжительность: 45-60 минут

Процесс: Обычно используется формат "Что прошло хорошо / Что прошло плохо / Что улучшить":

1. Что прошло хорошо?

   • Отличная коммуникация с BA
   • Требования были ясные

2. Что прошло плохо?

   • Изменения требований в середине спринта
   • Не было ясного definition of done

3. Что улучшить?

   • Заморозить требования за день до спринта
   • Провести встречу по definition of done

Мой вклад:

• Слушаю feedback о моей работе
• Предлагаю улучшения в процессе
• Помогаю улучшить Definition of Done

6. Product Backlog Management

Что это: Управление списком всех требований

Процесс:

• PO prioritizes backlog
• BA помогает:
  • Разбить большие features на smaller items
  • Уточнить требования
  • Оценить влияние на систему

7. Definition of Done

Что это: Критерии, когда item считается готовым

Для BA:

• Требования документированы
• Acceptance criteria написаны
• Получен sign-off от PO
• Нет неясностей

Для Developer:

• Код написан и рецензирован
• Unit tests пройдены
• Функция работает по criteria
• No console errors
• Код документирован

Для Tester:

• Все criteria verified
• No critical bugs
• Tested на разных браузерах
• Performance acceptable

8. Sprint Metrics

Velocity — количество story points за спринт

Пример:

• Sprint 1: 25 points
• Sprint 2: 28 points
• Sprint 3: 26 points
• Average velocity: 26 points

Использование:

• Планировать будущие спринты
• Оценить timeline проекта
• Выявить проблемы

Burndown Chart — сколько work remaining в спринте

9. Управление изменениями требований

Change Request процесс в Scrum:

1. Заинтересованная сторона сообщает об изменении
2. PO и BA оценивают impact
3. Если в текущем спринте:
   • Обсуждаем с team
   • Что выведем из спринта?
4. Если в будущих спринтах:
   • Добавляем в Product Backlog
   • Prioritize относительно других items

Ключевые роли в Scrum

Product Owner:

• Управляет Product Backlog
• Prioritizes features
• Принимает решения

Scrum Master:

• Фасилитирует Scrum процессы
• Убирает блокеры
• Помогает улучшиться

Development Team:

• Разрабатывает product
• Self-organizing
• Оценивает сложность

Business Analyst:

• Уточняет требования
• Документирует функциональность
• Пишет acceptance criteria
• Помогает с communication

Лучшие практики для BA в Scrum

• Приходить на meetings подготовленным
• Быть доступным для team
• Уточнять требования на этапе Backlog Refinement
• Документировать acceptance criteria ясно
• Слушать feedback на Retro
• Не добавлять требования в спринт без Sprint Planning
• Участвовать во всех Scrum событиях

Scrum делает работу BA более динамичной и collaborative, так как нужно постоянно быть в контакте с team и быстро решать вопросы.