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

1. Обзор методологии Scrum

2. Agile Manifesto
www.agilemanifesto.org

Люди и общение, а не процессы и
инструменты

Работающее приложение, а не сложная
документация

Сотрудничество с клиентом, а не
составление контрактов

Реакция на изменения, а не следование
плану

3. Scrum – не панацея

Проблемы, которые мы решаем, не связаны
с процессами, они в людях

Scrum и Agile основаны на теории, что для
разработки програмного обеспечения не
существует мета-решения. Только framework
(тут - scrum), который мы изучаем и
адаптируем

Разочаровывающе для тех, кто ищет
процедуры и окончательные ответы

4. Преимущества Scrum

Прозрачность для бизнеса

Заказчик всегда вносит изменения

Проблемы быстро идентифицируются

Команда вовлечена в процесс

Потяри не превышают длинну спринта

Менеджмент видит прогресс

Прогресс определяется наличием
работающего продукта

5. Scrum за 2 минуты

Scrum – это гибкая методология, которая
фокусируется на business value

Scrum members – это Product Owner, Scrum Master,
Team

Scrum events – это Sprint planing, Daily Scrum, Sprint
demo, Retrospective

Scrum artefacts – это Product backlog, Sprint
Backlog, User Stories, Burn-down charts

6. Scrum Framework
•Product owner
•ScrumMaster
•Team
Members
•Sprint planning
•Daily meetings
•Sprint review/demo
•Sprint retrospective
Events
•Product backlog
•Sprint backlog
•User stories
•Burndown charts
Artefacts

7. Характеристики

Самоопределяющаяся команда (нельзя
диктовать команде что и как нужно делать)

Продукт разрабатывается в процессе серии
итераций (sprints)

Типичная продолжительность спринта - 1-4
недели

Требования записываются в “product
backlog”

8. Feel the differences

9. Изменения во время спринта
• Планируйте длительность спринта исходя
из соображения о том, как долго вы можете
работать, не внося изменения в план работ
Изменение

10. Product Owner

Один человек

Определяет требования (vision)

Ответственен за доходность проекта (ROI)

Приоритизирует требования, исходя
из их рыночной ценности

Корректирует приоритеты на каждой
итерации, если необходимо

Постоянно общается с всей командой

Принимает работу

11. Product Owner

Эксперт в бизнесе, готовый потратить 30
минут в день на общение с командой

Product Owner заинтересован в проекте

Полдня на планировании спринта

15-30 минут в день

2 часа на спринт-ревью

Несколько дней на начальную
идентификацию User Stories

Желательна доступность в режиме онлайн

skype, icq, messenger

12. Scrum Master
• Ответственен за внедрение практик
• Устраняет препятствия
• Ответственен за эффективность работы
команды
• Защищает команду от внешних
воздействий
• Не раздает задания
• Обеспечивает видимость и прозрачность

13. Scrum Master

Лидер и помощник

Ответственен за

удаление препятствий

обучение клиента

упрощение жизни команды

улучшение производительности команды

улучшение применяемых инженерных практик

14. Team

Обычно 5-9 человек

Кросфункциональные члены команды:
программисты, тестеры, дизайнеры...

Полный рабочий день

Самоопределяющаяся (отвечает на вопрос -
как делать?)

Отвечает за результат перед Product Owner

15. Product backlog

Список желательной функциональности

Управляет Product owner

Приоритизируется Product owner

Реприоритизируется в начале спринта

В идеале написан так, что каждый элемент
описывает Use case конечного пользователя

16. Когда Scrum не работает?

Гос. проект

Тонущий проект, который отдали в офшор

Фиксированный бюджет проекта

Во всех остальных случаях, когда не
работают другие методологии

текучка

недостаточная квалификация участников

17. Sprint planning

Скорость работы команды задает объем
работ на спринт

Суммарный объем задач на спринте не
должен превышать возможности команды

Увеличение объема работ неизбежно
приводит к падению качества

Из product backlog выбирабются задачи
согласно приоритетам для формирования
sprint backlog

Каждая взятая user story - переоценивается
исполнителем

18. Управление sprint backlog
• Работа выбирается самостоятельно,
назначений нет
• Постоянная переоценка сложности задач
• Любой член команды имеет доступ
к бэклогу спринта
• Изменения во время sprint крайне
нежелательны

если нужно “очень срочно” - перенести
часть задач обратно в product backlog

19. Daily Scrum Meeting
• Характеристики

Ежедневно, в одно время

До 15 минут

Обмен информацией
• Не для решения проблем
• Приглашены все
• Только участники команды могут говорить
(product owner – часть команды)
• Ведет ScrumMaster

20. Daily Scrum Meeting
Что ты сделал вчера?Что ты сделал вчера?
1
Что будешь делать сегодня?Что будешь делать сегодня?
2
Что тебе мешает?Что тебе мешает?
3

21. Sprint burn-down chart

22. Sprint review/demo

Команда проводит демонстрацию (не
презентацию!) реализованной
функциональности

Фокус на результат, а не процесс

Длиться до 4-х часов (при максимальной
длинне спринта в 4 недели)

Вся команда участвует

Приглашены все

23. Retrospective

Пересмотр эффективности процесса

До 4-х часов (при максимальной длинне
спринта в 4 недели)

В конце спринта, после demo

Вся команда участвует

Возможно, приглашены клиенты

24. Сопутствующие практики

Unit testing

Test Driven Development

Continuous integration

Refactoring

Code review

25. Вариант определения
приоритета User Story

Определение важности User Story

Effort – затраты на реализацию

Benefit – преимущество от включения

Penalty – урон при отсутствии

Business weight = benefit + penalty

Release business value (RBV) = BW/SUM(BW)

ROI = (RBV/Effort) %

26. User Story

Высокоуровневое описание
функциональности с точки зрения конечного
пользователя

Помогает разработчикам оценивать проект
не с технической точки зрения

Помогает избавиться от “как сделано” в
пользу “что сделано”

Могут разбиваться на более мелкие в
процессе работы

27. A Good User Story

INVEST

Independent

Negotiable

Valuable

Estimatable

Sized Appropriately

Testable

28. Estimation Game

Основана на Expert Estimations

Вся команда принимает участие

Оценки даются независимо, результаты
сверяются и обсуждаются

Раунды оценок

29. Изменения в Scrum

Принципы Scrum — не безусловные истины

Tailoring допустим и приветствуется

Вносите новшества в команду постепенно

30. Возможные проблемы

Большие команды

Scrum of Scrums

Привычки