Документ описывает практику использования Scrum, включая основные понятия, принципы и роли, такие как Product Owner и Scrum Master. Он также сравнивает подходы Agile и Waterfall, подчеркивая важность эмпирического продвижения и самоорганизации команд. Приводятся ключевые митинги и документы, необходимые для успешного внедрения Scrum, а также некоторые примеры user stories и методы оценки производительности команды.

1. Scrum Framework
практика использования
Гельметдинов Сергей
1

2. Проблемы создания ПО
• Все что нам нужно:
• Сделать «правильную систему» нужным
способом
• Поставить программное обеспечение в срок
• Сделать организацию счастливее от того,
что сделали
• Кусок пирога, верно?
2

3. Понятия
 Основы SCRUM
 Люди Люди
 Продукт
+ Продукт
Действие
 Действие
 Плюс еще немного …
 Сделать «не хуже» чем было
 Нужно попытаться, первый шаг за Вами…
3

4. SCRUM
4

5. Как это было
• Agile Manifesto разработан и принят 11-13 февраля
2001
• Agile Manifesto cодержит 4 ценности, 12
принципов и не содержит практик
5
5

6. Как это было: Подход
Подход включает ценности, значимость которых
нивелирована:[3]
 личности и их взаимодействия важнее, чем процессы
и инструменты;
 работающее программное обеспечение важнее, чем
полная документация;
 сотрудничество с заказчиком важнее, чем
контрактные обязательства;
 реакция на изменения важнее, чем следование плану.
6
6

7. Как это было: Принципы
Принципы, которые разъясняет Agile Manifesto[4]:
 удовлетворение клиента за счѐт ранней и бесперебойной поставки ценного ПО;
 приветствие изменения требований, даже в конце разработки ( это может повысить
конкурентоспособность полученного продукта);
 частая поставка рабочего ПО (каждый месяц или неделю или ещѐ чаще);
 тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
 проектом занимаются мотивированные личности, которые обеспечены нужными
условиями работы, поддержкой и доверием;
 рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
 работающее ПО — лучший измеритель прогресса;
 спонсоры, разработчики и пользователи должны иметь возможность поддерживать
постоянный темп на неопределенный срок;
 постоянное внимание на улучшение технического мастерства и удобный дизайн;
 простота — искусство НЕ делать лишней работы;
 лучшие архитектура, требования и дизайн получаются у самоорганизованной команды;
 постоянная (частая) адаптация (улучшение эффективности работы) к изменяющимся
обстоятельствам.
7
7

8. Сравним “Agile vs. Waterfall”
8

9. Сравним
• SCRUM против «Итеративной разработки»
9

10. Сравним
Водопад
Итеративный водопад Agile

11. SCRUM это -
• Простой фреймворк, который может быть
изучен и внедрен за несколько дней
• Призван решать комплексные задачи
• Получение выгод от взаимодействия
разработчиков и заказчиков
• Инструмент (оболочка) для управления
инженерными практиками с выгодой
получения готовых продуктов с определенным
интервалом
11

12. SCRUM это не -
• Серебряная пуля
• Не новейшая технология
• SCRUM не имеет плана действий для
непредвиденных обстоятельств
―Scrum is not a methodology – it is a pathway‖
(Ken Schwaber)
12

13. Сравним “Agile vs. Waterfall”
Фиксируем это: Требования Стоимость Срок
AGILE
ВОДОПАД
Оцениваем это:
Срок Стоимость Требования
13

14. Два ключевых принципа в SCRUM
• Эмпирический продвижение – детализированное
предварительное планирование и
определенность в ходе работ заменяют
постоянные проверки и замкнутые циклы
• Детальная проработка заданий
• Исполнение всех артефактов процесса
• Максимально адаптировать процесс под себя и себя
под процесс
• Самоорганизация – команды являются
самоорганизованными и организуют себя для
достижения цели в заданных рамках
14

15. SCRUM Workflow
15

16. Роли
Product owner (владелец продукта) –
олицетворение пожеланий заказчика
Scrum Master – …
Команда – самоорганизующаяся группа, в
состав которой входят разработчики,
дизайнеры, тестировщики, документаторы
16

17. Больше о ролях
Владелец Заказчик
бизнеса
SME (ЭСО) SME (ЭСО)
SME (ЭСО)
SME (ЭСО)
17

18. Термины
User Story – описание требований
Размер
Стоимость
Соглашение
Task – декомпозированная задача
Icebox – Список требований без приоритетов
Backlog – Сформированный список требований
Product Backlog – сформированный список требований на
несколько итераций
Sprint Backlog – сформированный, приоритеризированный
список требований на одну итерацию разработки
Sprint – Итерация разработки
Результат (продукт) – работающий, проверенный и
интегрированный код, документация
18

19. Еще немного терминов
Daily (Stand-Up) Meeting - Ежедневная
«летучка»
Sprint Review (Demo)
Ретроспектива
Story Point
Burn-down Chart
19

20. ProductOwner (Владелец продукта)
Определение
Владелец Продукта ответственный за то, что
разрабатывает команда и оптимизацию
стоимостной составляющей (―The enterprise and
SCRUM‖, 2008)
Product Owner – is the ―single, wringable, neck‖
Принимает решения и учитывает риски:
Требования заказчиков
Что войдет в продукт (Стратегически и Тактическая)
Будет ли прибавка функциональности дорогой с точки
зрения экономических и временных показателей
20

21. Обязанности Product Owner
Создавать User Stories
Описать условия приема истории
Оценить ценность истории
Ответственный за риски вложений (ROI) – знает нужды
бизнеса и нужды заказчиков
Приоритезировать список разработки согласно требованиям
заказчиков с учетом стоимости разработки
Абсолютный арбитраж в описании требований
Аналитики команды работают на Product Owner
Определять условия готовности и рекомендации с учетом
мнения команды
Принимает решение о необходимости разработки
Может изменять требования и приоритеты каждую итерацию
21

22. Scrum Master
Следит за исполнением разработки
Управляет внутренней динамикой внутри команды
Следит за исполнением «правил» SCRUM
Следит за вовлечением всех участников во все
митинги
Делает все процессы видимыми
Использовать лучшие практики (технические, а
также опыт SCRUM)
Защищает команду от внешнего воздействия
Способствовать разрешению проблем (без
возможности руководить)
22

23. Product Owner и Scrum Master
PO – это человек, который ответственен за то, что
команда делает, а также за оптимизацию расходов на
разработку
SM – ответственен за исполнение процессов SCRUM,
его правильное внедрение и максимизацию
преимуществ
По сути, Scrum Master – это человек, который учит
Product Owner как максимально эффективно сделать
задачу посредством SCRUM силами команды
PO vs. SM точно также вместе как:
Ром и кока-кола (Д. Дибров)
Жиглов и Шарапов ()
Дед мороз и снегурочка (Снежинка)
23

24. Команда
Многофункциональная, небольшая (7 2 чел.) –
одна команда может содержать разработчиков,
тестировщиков, дизайнеров, документаторов
Имеют представление о том, что делать, знают о
рамках выполняемой задачи, характеристиках
проекта для выполнения своих обязанностей
В рамках представленных задач могут выбрать чем
заниматься
Самоорганизованная
Располагаются в одном помещении (в идеале)
24

25. Команда
25

26. Ключевые митинги
Spring Planning – PO и команда разработчиков
декомпозируют User Stories, определяют время
реализации. Результатом является сформированный
Sprint Backlog.
Sprint Review – Обзор текущей итерации. Демонстрация
функциональных новинок. Открытый для
заинтересованных лиц
Daily Meeting – ежедневное собрание для того, чтобы
обсудить текущее состояние выполнения задач
Ретроспектива – собрание на котором участники
команды могут скорректировать процессы внутри
SCRUM
26

27. Что сделать чтобы начать?
Набрать 3-9 человек в команду
Команда должна иметь опыт в различных
областях
Заставить комнату работать
Выбрать продукт
Выбрать Product Owner
Выбрать Scrum Master
ВПЕРЕД!
27

28. Не так сразу …
Получить упорядоченный Backlog
Представить видение развития настолько
насколько возможно
Научиться писать правильные User Story
28

29. И даже место имеет значение
Не просто комната, а приспособленное место
SCRUM room как артефакт
Необходимость в постоянном общении и
постоянного взаимодействия
Коммуникативные каналы
• Прямое общение
• Видеоконференция
• Аудио-конференция
• Instance Messenger (jabber, icq, и тд)
• Электронная почта
• Статичные документы
29

30. Если не существует Product Backlog – ничего
не существует
Backlog – это список требований для команды
SCRUM, который будет реализован как
действительная ценность продукта
Все известные и потенциальные ошибки
o Часто встречаемые ошибки
o Вновь открытые ошибки
o Необходимость в аналитической работе
o Необходимость рефакторинга кода
А что же не включать в беклог?
30

31. Пример User Story
Задачи
Архитектура
и дизайн
32 часа Определить
unit-test
12 часов
Функциональ
ные тесты
12 часа
31

32. Пример User Story
32

33. Пример User Story
33

34. Пример User Story
34

35. Пример User Story
35

36. Планирование Sprint’a
1. Product Owner (с помощью команды) приоритезирует истории в
Backlog
2. Команда вместе с Product Owner – добавляет секции
«Соглашения» в Истории с максимальным приоритетом
3. Команда без Product Owner – делит истории на задачи
4. Команда без Product Owner – решает, если она сможет ли
реализовать историю в текущем спринте (путем голосования)
• Если не сможет, останавливается, рисуем полоску в Sprint
Backlog над историей, которая была декомпозирована, но не
команда не согласна, что успеет ее сделать в срок
* можно с согласованием PO передвинуть наверх более
короткую историю и вернутся к шагу 2
• Если да, то спрашиваем команду полная ли История
• Если да – останавливаемся
• Если нет, начинаем со шага 2 новую Историю
36

37. Пример User Story
37

38. Backlog
Приоритезированный список функциональных,
технологических или аналитических «историй»
Должен быть выстроен согласно приоритетам
Не бывает двух одинаково важных «историй»
Все приоритезированно, измерено по времени и
стомости разработки
Технически понятные и полные описания
Каждый может согласованно расширить
описание/требование
Владелец продукта ответственный за приоритеты
38

39. Backlog
«Истории» правильного размера
– мелкие и понятные
Большие истории (Epic) –
большие, составные или
рискованные
Все «истории» мы берем из
списка Icebox
39

40. Backlog
40

41. Backlog
41

42. Визуализация – доска задач
42

43. Доска задач
43

44. Доска задач (программное средство)
44

45. Daily meeting (дневной митинг)
Назначение:
 Для команды понять в каком статусе находятся
задачи, для своевременного реагирования на
проблемы
Три вопроса:
 Что было сделано с прошлого митинга?
 Что будет сделано до следующего?
 Какие трудности предполагаются при выполнении?
А также:
 Нужно собрать метрики для графика «сгорания»
burndown chart
 Нужно ответить на вопросы, которые возникают по
ходу процесса
45

46. Опять доска?
А используется ли доска в процессе?
46

47. Sprint Review Meeting
Митинг для подведения итогов итерации
Команда вместе с Владельцем Продукта просматривают, что же было
сделано за итерацию
 ПО СУТИ – это митинг Владельца Продукта
 Рассчитывается продуктивность команды (velocity)
 Рассчитываются экономические показатели (при необходимости)
Делаются три вещи:
 Демонстрирует заказчикам продукт, который сделала команда, и
показывает, что все идет правильно
 Демонстрирует заказчикам нужды команды, чтобы понимать что они
собираются делать и делать это правильно
 Согласовываются детали и цели следующего Спринта
Добавляются новые истории в Backlog, если это необходимо
«Де-монстрация» – изгонение монстров из софта?
47

48. Определение продуктивности команды и
экономических показателей
Магическое SPs & FP
Мы действительно хотим знать сколько может
сделать наша команда (сколько SPs, сможет
сделать за один спринт)
Мы не знаем этого … и мы считаем – сколько
StoryPoints мы сделали за спринт
 Сколько мы сделали за прошлый спринт
 Посчитать среднюю оценку
 Поверить в результат или иметь причины не
верить
Итак, какова продуктивность команды?
48

49. Определение продуктивности команды и
экономических показателей
Магическое SPs & FP
Мы действительно хотим знать сколько может
сделать наша команда (сколько SPs, сможет
сделать за один спринт)
Мы не знаем этого … и мы считаем – сколько
StoryPoints мы сделали за спринт
 Сколько мы сделали за прошлый спринт
 Посчитать среднюю оценку
 Поверить в результат или иметь причины не
верить
Итак, какова продуктивность команды?
49

50. Ретроспектива
 Команда берет на себя проведения такого митинга
 Что было хорошо и что не нужно менять
 Что может быть улучшено и как?
 • ScrumMaster ведет такого рода митинг
Охватываемые проблемы:
 Постоянно команда решает какие-то сложности
 ScrumMaster вместе с Владельцем продукта выбирает время
для разрешения таких проблем
 Список задач команды ScrumMaster – «ScrumMaster’s
Community»
 ScrumMaster работает на преодоление любых проблем вне команды
 Сделать жизнь лучше со SCRUM
 Проработать с руководством по поводу поставки лимонада для
улучшения работы, экспериментом над продуктом
50

51. Что такое StoryPoints?
 Не бывает одинаковых по уровню разработки
историй
 Это относительная оценка каждой истории
 степень двойки для оценки( 2, 4, 8...)
 ряд Фибоначчи (1, 2, 3, 5, 8...)
 Самая легкая и самая тяжелая истории
 Возможно применение Planning Poker
 Не нужно оценивать весь список событий, а
только на несколько итераций
 А почему не часах или днях?
51

52. Показатели исполнения
52

53. Показатели исполнения: Release Burndown
Chart
53

54. Расчет производительности
 Посчитать количество завершенных SPs в каждом спринте
 SP1, SP2, SP3…SPn
 Среднее арифметический расчет
 Veln = (SP1+SP2+SP3+…+SPn)/n
 Транзакционный расчет (несколько последних)
 Veln = (Veln-1+SPn)/2, or
 Veln = (Veln-2+Veln-1+SPn)/3
54

55. Показатели исполнения
Оценка скорости разработки на основе имеющихся данных за
несколько итераций.
Для текущих данных – количество ошибок при оценке
Средняя погрешность 19%; последние 3 – 17%; последние 2 –
13%
55

56. Agile Водопад
Разработчики Кросс функциональная Жесткое разделение на
команда, узкоспециализированных
специалистов
Процесс Немедленная реакция на Требуется прошествие
события (например большого количества времени
тестировщик - разработчик) для опеределение
неисправностей
Качество Контроль с технической Тестирование происходит по
составляющей, возможность принципу черного ящика, в
просматривать код и писать основном заканчивается
автоматические тесты проверкой GUI
Заказчики Возможность взаимодействия Клиенты никак не
в проекте и влиять на взаимодействуют в процессе
разработку разработки, а только
заинтересованы в конечном
продукте
Стиль управления Управляющие функции Контролирующие функции
Проект Сфокусирован на Сфокусирован на сроках
своевременность сдачи проекта и принятых
реагирования на потребности контрактах
заказчиков
56

57. Компании практикующие SCRUM/Agile в
производстве
 Adobe
 Amazone
 Google
 Hewlett Packard
 Intel
 Microsoft
 Motorolla
 Oracle
 Yahoo
 БАРС Груп
57

58. Вопросы?
58