Scrum для ИТ-проектов: роли, события, артефакты
«Мы работаем по Scrum. У нас есть спринты и стендапы»
Команда работает по Scrum уже полгода, проводит спринты, стендапы, демо, но проект буксует. Почему? Потому что Scrum — это не про спринты и стендапы, а про роли, события и артефакты. Если хотя бы один элемент выпадает — всё разваливается.
Три роли — и каждая критична
Владелец продукта (Product Owner). Отвечает за максимизацию ценности, управляет бэклогом, приоритизирует требования, является единственным источником требований для команды. Это не «секретарь», записывающий пожелания, а человек, который говорит «нет» заказчику, когда фича не в приоритете.
Scrum-мастер. Обеспечивает соблюдение процессов, помогает устранять препятствия, фасилитирует встречи, обучает команду Scrum. Это не «лишний менеджер», который только мешает, а щит команды, который убирает блокеры и защищает от внешнего вмешательства.
Команда разработки. Самоорганизующаяся кросс-функциональная группа, 3–9 человек, которая отвечает за результат. Это не «исполнители», которые ждут указаний сверху, а команда, которая самостоятельно распределяет задачи внутри спринта.
Пять событий — ритм Scrum
Спринт. Итерация фиксированной длины (обычно 2 недели), контейнер для всех остальных событий.
Планирование спринта. В начале спринта команда выбирает задачи из бэклога и формулирует цель спринта.
Ежедневный Scrum (стендап). Каждый день, 15 минут, синхронизация: что сделал, что планирую, какие блокеры. Это не отчётность перед начальником, а инструмент для команды.
Обзор спринта (демо). В конце спринта демонстрация инкремента заказчику. Подробнее о том, чем демо отличается от ретроспективы — в статье Демонстрация продукта vs ретроспектива.
Ретроспектива. После обзора — анализ процесса: что хорошо, что плохо, что улучшить.
Три артефакта
Бэклог продукта. Приоритизированный список всего, что может потребоваться. Элементы — пользовательские истории с оценкой (story points). Управляет им Владелец продукта.
Бэклог спринта. Набор элементов, выбранных для текущего спринта. Менять его может только команда.
Инкремент продукта. Сумма всех выполненных элементов, которая должна быть работоспособной — готовой к релизу.
Определение готовности (Definition of Done)
Без DoD нет понимания, когда задача завершена. Пример DoD для ИТ-команды: код написан и соответствует стандартам, код прошёл ревью коллеги, написаны модульные тесты (покрытие ≥ 80%), интеграционные тесты пройдены, задача протестирована в тестовой среде, документация обновлена, готово к деплою.
Что в понедельник утром
Проверьте, есть ли настоящий Владелец продукта (не «секретарь»), есть ли Scrum-мастер, который защищает команду, а не контролирует, проходит ли ретроспектива и заканчивается ли улучшениями, видит ли заказчик бэклог и может ли влиять на приоритеты, есть ли Definition of Done у вашей команды.
Заключение
Scrum — это не про спринты и стендапы, а про три роли, пять событий и три артефакта. Без любого из них Scrum разваливается.
На воркшопах курса «Мастер управления IT-проектами» вы работаете в реальном инструменте: создаёте бэклог, планируете спринт, ведёте доску задач. Подробнее о курсе →