Какие знаешь роли scrum?

Роли в Scrum

Scrum — это фреймворк для управления проектами, особенно в разработке ПО. Scrum определяет три основные роли, каждая из которых имеет свою ответственность и цели.

1. Product Owner (Владелец продукта)

Отвественен за видение продукта и приоритизацию работы.

Основные ответственности:

• Создание и управление Product Backlog (список требований)
• Приоритизация элементов backlog'а на основе бизнес-ценности
• Определение критериев приёмки (acceptance criteria)
• Взаимодействие со stakeholders (заказчик, бизнес)
• Ответ на вопросы команды разработки о требованиях
• Принятие завершённой работы

Дневные задачи:

• Встреча с бизнесом для понимания требований
• Написание или уточнение user stories
• Обсуждение prioritization с командой
• Review готового функционала с заказчиком

Примеры:

• E-commerce: PO создаёт backlog (добавить фильтр по цене, улучшить поиск, интеграция с платёжной системой)
• SaaS: PO приоритизирует: сначала критичные баги, потом новые функции

2. Scrum Master (Скрам-мастер)

Отвественен за процесс Scrum и удаление препятствий для команды.

Основные ответственности:

• Фасилитирование Scrum церемоний (Daily, Planning, Review, Retrospective)
• Защита команды от внешних помех
• Помощь в решении блокирующих проблем
• Обучение команды Scrum принципам
• Мониторинг здоровья процесса
• Работа с командой над улучшением скорости (velocity)

Дневные задачи:

• Провести Daily Standup
• Отследить блокирующие задачи
• Помочь в разрешении конфликтов
• Заказать ресурсы если нужны
• Отследить burndown chart

Примеры:

• Scrum Master видит что разработчик ждёт ответ от дизайнера → помогает получить ответ
• Видит что команда перегружена → помогает перепланировать sprint
• Видит что процесс неэффективен → предлагает улучшения на Retrospective

3. Development Team (Команда разработки)

Отвественна за создание качественного продукта.

Основные ответственности:

• Оценка сложности задач
• Планирование sprint'а (что успеем)
• Разработка и тестирование функционала
• Демонстрация готового кода на Sprint Review
• Обеспечение качества (code review, testing)
• Самоорганизация и распределение задач

Дневные задачи:

• Attend Daily Standup
• Разработка функционала
• Code review коллег
• Тестирование
• Интеграция с другими компонентами

Размер команды: обычно 5-9 человек (три пальца в каждой руке :)

Типичный состав:

• Backend разработчики
• Frontend разработчики
• QA инженеры
• Дизайнеры (если в команде)
• DevOps (если в команде)

Взаимодействие ролей

Пример на протяжении Sprint'а (2 недели):

Понедельник — Sprint Planning:

• Product Owner: "Вот приоритизированный backlog"
• Team: "Мы возьмем эти задачи, это ~40 story points"
• Scrum Master: "Вопросов нет? Ок, начинаем"

Вторник-Четверг — Development:

• Team: Разрабатывает, тестирует
• Scrum Master: Следит что нет блокирующих проблем
• Product Owner: Уточняет требования если нужно

Пятница — Sprint Review & Retrospective:

• Team: "Мы сделали 35 story points из 40"
• Product Owner: "Спасибо, это отлично. Вот feedback от заказчика"
• Scrum Master: "Видим что общались друг с другом лучше, но нужна лучше документация"

Scrum Artifacts (Артефакты)

Основные документы/списки:

1. Product Backlog

• Приоритизированный список всех требований
• Владеет Product Owner
• Постоянно эволюционирует

Пример:

1. (High) Реализовать двухфакторную аутентификацию (13 points)
2. (High) Интеграция с Stripe (21 points)
3. (Medium) Улучшить поиск (8 points)
4. (Low) Добавить тёмную тему (5 points)
5. (Low) Улучшить документацию (3 points)

1. Sprint Backlog

• Элементы, которые команда берёт на текущий sprint
• Выбираются на Sprint Planning
• Может меняться во время sprint'а

1. Increment (Инкремент)

• Готовый, потенциально продаваемый продукт
• Результат Sprint'а
• Должен быть полностью готов к production

Scrum Ceremonies (Церемонии)

1. Sprint Planning (4 часа на 2-недельный sprint)

• Team смотрит backlog
• PO объясняет требования
• Team оценивает сложность
• Team выбирает что делать

1. Daily Standup (15 минут)

• Каждый говорит: что сделал, что делает, есть ли блокеры
• Не решаем проблемы, только идентифицируем

1. Sprint Review (2 часа)

• Team показывает готовый функционал
• PO принимает или требует доделок
• Gathering feedback

1. Sprint Retrospective (1.5 часа)

• Team обсуждает: что хорошо, что плохо, как улучшить
• Выбирают 1-2 улучшения на следующий sprint
• Scrum Master фасилитирует

Роль System Analyst в Scrum

System Analyst обычно входит в Team (разработка) или работает совместно:

• Анализ требований → помогает PO уточнить backlog
• Technical design → создаёт архитектурные документы
• Estimation → помогает team оценить complexity
• Quality assurance → проверяет требования соответствуют коду

Некоторые компании имеют отдельную роль System Analyst, другие распределяют эту работу между team members.

Частые ошибки в Scrum

• PO не приоритизирует → team не знает что делать
• Scrum Master слишком много вмешивается → team теряет самостоятельность
• Team слишком амбициозен → не успевает → падает мотивация
• Нет Daily Standup → проблемы всплывают только на Review
• Sprint commitment не соблюдается → velocity непредсказуема

Заключение

Три роли Scrum создают баланс:

• PO → видение и приоритизация (ЧТО делать)
• Scrum Master → процесс и удаление блокеров (КАК делать)
• Team → исполнение и качество (ДЕЛАЕМ)

Каждая роль критична для успеха проекта. System Analyst, понимая эти роли, лучше интегрируется в команду и вносит больше ценности.