Документ описывает методологию Scrum, акцентируя внимание на ключевых ролях, таких как Product Owner, Scrum Master и команда разработчиков. Представлены основные практики, такие как планирование спринтов, ежедневные встречи и ретроспективы, а также преимущества и проблемы, связанные с этой методологией. Рассматриваются инструменты для управления проектами и способы улучшения коммуникации в командах.

1. Scrum
Scrum! Lovely scrum! Lovely scrum!
Eduard (@index01d) Antsupov, 2012

2. Команда
● Зовут x01d
● Появились в августе 2010 г.
● 8 человек в штате
● 3 ключевых программиста
● 3-5 проектов в работе одновременно
● Еда обходится в полтора раза дороже аренды офиса!
● Друзей много
● Но нам мало
● Фриланс (http://lookubra.x01d.com/)
● Сбор и анализ данных в сети интернет (мы много
знаем про OAuth-протокол v1-2, DOM, открытые API и
методы сбора и анализа данных из социальных сетей,
обнаружение групп, деревья решений, фильтрацию
документов...)
● Интеграция социальных сетей в сайты и веб-сервисы

3. Начало. Нет методологии.
Nokia 6120
18 кв. м

4. Постановка задачи. ТЗ. Водопад.

5. Постановка задачи. ТЗ. Водопад.
Потом всё поменяли
Можно было не вырабатывать
Страшно
ошибиться
Делали долго...
Получилось не то
Не успели :
(
ПАНИКА и УЖАС!

6. Scrum! - The New Product Development Game

7. Методология гибкой
разработки

9. Набор инструментов
управления
разработкой

10. Фреймворк для
разработки сложных
продуктов и систем

11. Роли
● Product Owner
● Scrum Master
● Scrum Team
● ...
● Users

12. Product Owner
Владелец продукта. Представляет
интересы заказчика.

13. Product Owner
Владелец продукта. Представляет
интересы заказчика.

14. Product Owner
● Определяет набор функционала ПО
● Устанавливает приоритеты
● Устанавливает дату релиза
● Даёт обратную связь
● Обеспечивает связь заказчиков и
исполнителей
● Принимает результат

15. Команда
3-9 человек, самоорганизуется,
кроссфункциональна

16. Команда
3-9 человек, самоорганизуется,
кроссфункциональна

17. Команда
● Декомпозирует пользовательские истории
на задачи
● Оценивает сложность
● Разрабатывает продукт
● Контролирует качество
● Улучшает процесс разработки
● Демонстрирует работу Product Owner'у

18. Scrum Master
Лидер команды. Защитник Scrum.
Защитник команды. Решает проблемы.

19. Scrum Master
Лидер команды. Защитник Scrum.
Защитник команды. Решает проблемы.

20. Scrum Master
● Устраняет препятствия
● Предотвращает перерывы в разработке
● Помогает команде
● Следит за процессом

21. Мы делаем продукт.

22. Продукт представляет
собой список функций,
который называется
backlog

23. Backlog'ом владеет
Product Owner

24. Продукт описывается в
терминах
пользовательских
историй

25. Product owner
расставляет задачам
приоритеты по степени
важности

26. Команда оценивает
сложность задач

27. Результат: Список
оцененных и
отсортированных по
важности задач

29. Спринт
● Обычно короткий (от 2-х до 4-х недель)
● Жёстко ограничен по времени
● Начинается с планирования (Planning
Meeting)
● Заканчивается ретроспективой
● Сопровождается ежедневными
совещаниями (daily meeting)

30. Планирование спринта (Planning
meeting)
● Участвуют все
● Длится 4-8 часов
● Выбираются первые n задач из Backlog'a
● Определяется цель спринта
● Обсуждаются способы достижения цели
● Команда формирует Sprint Backlog
● Истории из Backlog'a разбиваются на
подзадачи
● Формируется расписание спринта

31. Sprint Backlog не
изменяется в процессе
спринта!

33. Planning Poker

34. Доска (task board)

35. Доска (task board)

36. Митинг (Daily Scrum)
● Участвует команда
● Длится 15-20 минут
● Что сделано?
● Что мешает продвижению спринта?
● Что будет сделано?

37. Демонстрация
● Участвуют все
● Озвучивается цель
● Демонстрируется инкремент функционала
● Бизнес-ориентация (что сделано, вместо
как сделано!)
● Обмен отзывами
● Демонстрируйте недемонстрируемое!
● How-to-demo

38. Ретроспектива
● Главное - проводить :)
● Длится 1-3 часа
● Участвуют все
● Неформальная встреча
● Каждый высказывается
● Никто не перебивает
● Что хорошего?
● Что можно улучшить?
● Анализ производительности
● Подведение итогов

39. Производительность и
прогнозирование
● График успеваемости (BurnDown-
диаграмма)
● Фокус-фактор

40. BurnDown-диаграмма (график
успеваемости)

41. Фокус-фактор

42. Фокус-фактор

44. 3 кита Scrum
● Эффективные коммуникации
● Жёсткий TimeBoxing
● Самоорганизующаяся команда

45. Позитив
● Прототип в процессе разработки
превращается в продукт
● Оперативная реакция на обратную связь
● Предсказуемая производительность
● Возможность определить процент
готовности проекта
● Простые метрики
● => меньше риски
● Разгружает менеджмент
● Повышает настроение и мотивацию в
команде :)

46. Проблемы
● Коммуникация удаленных членов
команды
● Бизнес-процессы заказчика
● Кроссфункциональность и постоянство
состава команды
● Небольшие команды
● Слабая документированность продукта

47. Nokia-тест: итеративность
● Итерации фиксированы?
● Длина итерации не превышает 6 недель?
● В конце итерации вы имеете работающее
ПО?
● Вам не нужна детальная спецификация,
чтобы начать итерацию?
● Вы проводите тестирование во время
разработки? (важно иметь работающее
ПО)

48. Nokia-тест: Scrum
● У вас есть Product Owner?
● Если у вас есть P.O., ведет ли он Backlog
(cписок фич, которые нужно
запрограммировать)? Приоритеты?
Оценка сложности?
● Строите ли вы burndown-диаграмму?
● Команда работает по принципу
самоорганизации?

49. Must read.
● Wiki читать не нужно.
● Там много воды
● И мало дела
● И бесполезно

50. Must read.
● Практика внедрения Scrum: трудности и пути их
преодоления // Бибичев Андрей, 15 апреля 2008 г.

51. Must read.
● Scrum и XP: заметки с передовой // Хенрик Книберг,
InfoQ

52. Must read.
● Succeeding with Agile // Addison-Wesley, Mike Cohn,
2010

53. Здесь должны быть
ваши вопросы
Да, это точная информация.
100%

54. О чём я забыл
● Планирование релиза
● Связь с XP и TDD
● Масштабирование Scrum
● Организация тестирования