scrum framework

1

Scrum Framework практика использования

Гельметдинов Сергей

Проблемы создания ПО

2

• Все что нам нужно:• Сделать «правильную систему» нужным

способом• Поставить программное обеспечение в срок• Сделать организацию счастливее от того,

что сделали

• Кусок пирога, верно?

Понятия

3

Основы SCRUM Люди Продукт Действие

Плюс еще немного … Сделать «не хуже» чем было Нужно попытаться, первый шаг за Вами…

Люди+

ДействиеПродукт

SCRUM

4

5

Как это было• Agile Manifesto разработан и принят 11-13

февраля 2001• Agile Manifesto cодержит 4 ценности, 12

принципов и не содержит практик

5

6

Как это было: ПодходПодход включает ценности, значимость которых

нивелирована:[3]

личности и их взаимодействия важнее, чем процессы и инструменты;

работающее программное обеспечение важнее, чем полная документация;

сотрудничество с заказчиком важнее, чем контрактные обязательства;

реакция на изменения важнее, чем следование плану.

6

7

Как это было: ПринципыПринципы, которые разъясняет Agile Manifesto[4]:

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО; приветствие изменения требований, даже в конце разработки ( это может повысить

конкурентоспособность полученного продукта); частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще); тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; проектом занимаются мотивированные личности, которые обеспечены нужными

условиями работы, поддержкой и доверием; рекомендуемый метод передачи информации — личный разговор (лицом к лицу); работающее ПО — лучший измеритель прогресса; спонсоры, разработчики и пользователи должны иметь возможность поддерживать

постоянный темп на неопределенный срок; постоянное внимание на улучшение технического мастерства и удобный дизайн; простота — искусство НЕ делать лишней работы; лучшие архитектура, требования и дизайн получаются у самоорганизованной команды; постоянная (частая) адаптация (улучшение эффективности работы) к изменяющимся

обстоятельствам.

7

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

8

Сравним

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

9

Сравним

Водопад

Итеративный водопад Agile

SCRUM это -

• Простой фреймворк, который может быть изучен и внедрен за несколько дней

• Призван решать комплексные задачи• Получение выгод от взаимодействия

разработчиков и заказчиков• Инструмент (оболочка) для управления

инженерными практиками с выгодой получения готовых продуктов с определенным интервалом

11

SCRUM это не -

• Серебряная пуля• Не новейшая технология• SCRUM не имеет плана действий для

непредвиденных обстоятельств

“Scrum is not a methodology – it is a pathway” (Ken Schwaber)

12

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

13

ВОДОПАД

Требования

СтоимостьСрок

AGILE

СрокСтоимость

Требования

Фиксируем это:

Оцениваем это:

Два ключевых принципа в SCRUM

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

процесс

• Самоорганизация – команды являются самоорганизованными и организуют себя для достижения цели в заданных рамках

14

SCRUM Workflow

15

Роли

Product owner (владелец продукта) – олицетворение пожеланий заказчика

Scrum Master – …

Команда – самоорганизующаяся группа, в состав которой входят разработчики, дизайнеры, тестировщики, документаторы

16

ЗаказчикВладелец бизнеса

SME (ЭСО)

SME (ЭСО)SME (ЭСО)

SME (ЭСО)

17

Больше о ролях

Термины

User Story – описание требований

Размер

Стоимость

Соглашение

Task – декомпозированная задача

Icebox – Список требований без приоритетов

Backlog – Сформированный список требованийProduct Backlog – сформированный список требований на

несколько итераций

Sprint Backlog – сформированный, приоритеризированный список требований на одну итерацию разработки

Sprint – Итерация разработки

Результат (продукт) – работающий, проверенный и интегрированный код, документация

18

Еще немного терминов

Daily (Stand-Up) Meeting - Ежедневная «летучка»

Sprint Review (Demo)

Ретроспектива

Story Point

Burn-down Chart

19

ProductOwner (Владелец продукта)Определение

Владелец Продукта ответственный за то, что разрабатывает команда и оптимизацию стоимостной составляющей (“The enterprise and SCRUM”, 2008)

Product Owner – is the “single, wringable, neck”

Принимает решения и учитывает риски:Требования заказчиков

Что войдет в продукт (Стратегически и Тактическая)

Будет ли прибавка функциональности дорогой с точки зрения экономических и временных показателей

20

Обязанности Product OwnerСоздавать User Stories

Описать условия приема истории

Оценить ценность истории

Ответственный за риски вложений (ROI) – знает нужды бизнеса и нужды заказчиков

Приоритезировать список разработки согласно требованиям заказчиков с учетом стоимости разработки

Абсолютный арбитраж в описании требований

Аналитики команды работают на Product Owner

Определять условия готовности и рекомендации с учетом мнения команды

Принимает решение о необходимости разработки

Может изменять требования и приоритеты каждую итерацию

21

Scrum MasterСледит за исполнением разработки

Управляет внутренней динамикой внутри команды

Следит за исполнением «правил» SCRUM

Следит за вовлечением всех участников во все митинги

Делает все процессы видимыми

Использовать лучшие практики (технические, а также опыт SCRUM)

Защищает команду от внешнего воздействия

Способствовать разрешению проблем (без возможности руководить)

22

Product Owner и Scrum MasterPO – это человек, который ответственен за то, что

команда делает, а также за оптимизацию расходов на разработку

SM – ответственен за исполнение процессов SCRUM, его правильное внедрение и максимизацию преимуществ

По сути, Scrum Master – это человек, который учит Product Owner как максимально эффективно сделать задачу посредством SCRUM силами команды

PO vs. SM точно также вместе как:

Ром и кока-кола (Д. Дибров)

Жиглов и Шарапов ()

Дед мороз и снегурочка (Снежинка)

23

Команда

Многофункциональная, небольшая (7±2 чел.) – одна команда может содержать разработчиков, тестировщиков, дизайнеров, документаторов

Имеют представление о том, что делать, знают о рамках выполняемой задачи, характеристиках проекта для выполнения своих обязанностей

В рамках представленных задач могут выбрать чем заниматься

Самоорганизованная

Располагаются в одном помещении (в идеале)

24

Команда

25

Ключевые митингиSpring Planning – PO и команда разработчиков

декомпозируют User Stories, определяют время реализации. Результатом является сформированный Sprint Backlog.

Sprint Review – Обзор текущей итерации. Демонстрация функциональных новинок. Открытый для заинтересованных лиц

Daily Meeting – ежедневное собрание для того, чтобы обсудить текущее состояние выполнения задач

Ретроспектива – собрание на котором участники команды могут скорректировать процессы внутри SCRUM

26

Что сделать чтобы начать?

Набрать 3-9 человек в команду

Команда должна иметь опыт в различных областях

Заставить комнату работать

Выбрать продукт

Выбрать Product Owner

Выбрать Scrum Master

ВПЕРЕД!

27

Не так сразу …

Получить упорядоченный Backlog

Представить видение развития настолько насколько возможно

Научиться писать правильные User Story

28

И даже место имеет значение

Не просто комната, а приспособленное местоSCRUM room как артефактНеобходимость в постоянном общении и постоянного

взаимодействияКоммуникативные каналы• Прямое общение• Видеоконференция• Аудио-конференция• Instance Messenger (jabber, icq, и тд)• Электронная почта• Статичные документы

29

Если не существует Product Backlog – ничего не существует

Backlog – это список требований для команды SCRUM, который будет реализован как действительная ценность продукта

Все известные и потенциальные ошибкиo Часто встречаемые ошибкиo Вновь открытые ошибкиo Необходимость в аналитической работеo Необходимость рефакторинга кода

А что же не включать в беклог?

30

Пример User Story

31

Архитектура и дизайн

32 часа

Функциональные тесты

12 часа

Определить unit-test

12 часов

Задачи

Пример User Story

32

Пример User Story

33

Пример User Story

34

Пример User Story

35

Планирование Sprint’a

36

1. Product Owner (с помощью команды) приоритезирует истории в Backlog

2. Команда вместе с Product Owner – добавляет секции «Соглашения» в Истории с максимальным приоритетом

3. Команда без Product Owner – делит истории на задачи

4. Команда без Product Owner – решает, если она сможет ли реализовать историю в текущем спринте (путем голосования)

• Если не сможет, останавливается, рисуем полоску в Sprint Backlog над историей, которая была декомпозирована, но не команда не согласна, что успеет ее сделать в срок

* можно с согласованием PO передвинуть наверх более короткую историю и вернутся к шагу 2

• Если да, то спрашиваем команду полная ли История• Если да – останавливаемся• Если нет, начинаем со шага 2 новую Историю

Пример User Story

37

BacklogПриоритезированный список функциональных,

технологических или аналитических «историй»

Должен быть выстроен согласно приоритетам

Не бывает двух одинаково важных «историй»

Все приоритезированно, измерено по времени и стомости разработки

Технически понятные и полные описания

Каждый может согласованно расширить описание/требование

Владелец продукта ответственный за приоритеты

38

Backlog

39

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

Все «истории» мы берем из списка Icebox

Backlog

40

Backlog

41

42

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

43

Доска задач

44

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

45

Daily meeting (дневной митинг)Назначение: Для команды понять в каком статусе находятся задачи,

для своевременного реагирования на проблемы

Три вопроса: Что было сделано с прошлого митинга? Что будет сделано до следующего? Какие трудности предполагаются при выполнении?

А также: Нужно собрать метрики для графика «сгорания»

burndown chart Нужно ответить на вопросы, которые возникают по

ходу процесса

46

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

47

Sprint Review MeetingМитинг для подведения итогов итерации

Команда вместе с Владельцем Продукта просматривают, что же было сделано за итерацию

ПО СУТИ – это митинг Владельца Продукта Рассчитывается продуктивность команды (velocity) Рассчитываются экономические показатели (при необходимости)

Делаются три вещи: Демонстрирует заказчикам продукт, который сделала команда, и показывает,

что все идет правильно Демонстрирует заказчикам нужды команды, чтобы понимать что они

собираются делать и делать это правильно Согласовываются детали и цели следующего Спринта

Добавляются новые истории в Backlog, если это необходимо

«Де-монстрация» – изгонение монстров из софта?

48

Определение продуктивности команды и экономических показателей

Магическое SPs & FP

Мы действительно хотим знать сколько может сделать наша команда (сколько SPs, сможет сделать за один спринт)

Мы не знаем этого … и мы считаем – сколько StoryPoints мы сделали за спринт

Сколько мы сделали за прошлый спринт Посчитать среднюю оценку Поверить в результат или иметь причины не верить

Итак, какова продуктивность команды?

49

Определение продуктивности команды и экономических показателей

Магическое SPs & FP

Мы действительно хотим знать сколько может сделать наша команда (сколько SPs, сможет сделать за один спринт)

Мы не знаем этого … и мы считаем – сколько StoryPoints мы сделали за спринт

Сколько мы сделали за прошлый спринт Посчитать среднюю оценку Поверить в результат или иметь причины не верить

Итак, какова продуктивность команды?

50

Ретроспектива Команда берет на себя проведения такого митинга

Что было хорошо и что не нужно менять Что может быть улучшено и как?

• ScrumMaster ведет такого рода митинг

Охватываемые проблемы: Постоянно команда решает какие-то сложности ScrumMaster вместе с Владельцем продукта выбирает время для

разрешения таких проблем Список задач команды ScrumMaster – «ScrumMaster’s Community»

ScrumMaster работает на преодоление любых проблем вне команды Сделать жизнь лучше со SCRUM Проработать с руководством по поводу поставки лимонада для улучшения

работы, экспериментом над продуктом

51

Что такое StoryPoints? Не бывает одинаковых по уровню разработки

историй Это относительная оценка каждой истории

степень двойки для оценки( 2, 4, 8...) ряд Фибоначчи (1, 2, 3, 5, 8...)

Самая легкая и самая тяжелая истории Возможно применение Planning Poker Не нужно оценивать весь список событий, а

только на несколько итераций

А почему не часах или днях?

52

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

53

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

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

55

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

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

56

Agile Водопад

Разработчики Кросс функциональная команда,

Жесткое разделение на узкоспециализированных специалистов

Процесс Немедленная реакция на события (например тестировщик - разработчик)

Требуется прошествие большого количества времени для опеределение неисправностей

Качество Контроль с технической составляющей, возможность просматривать код и писать автоматические тесты

Тестирование происходит по принципу черного ящика, в основном заканчивается проверкой GUI

Заказчики Возможность взаимодействия в проекте и влиять на разработку

Клиенты никак не взаимодействуют в процессе разработки, а только заинтересованы в конечном продукте

Стиль управления Управляющие функции Контролирующие функции

Проект Сфокусирован на своевременность реагирования на потребности заказчиков

Сфокусирован на сроках сдачи проекта и принятых контрактах

57

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

58

Вопросы?