Книга Scrum Time

1

2

Оглавление Немного о главном ...................................................................................................................... 6

Для того, чтобы лучше понять функциональную составляющую Scrum Team,

необходимо ознакомиться с тремя частями: ............................................................................ 9

Scrum Master ...................................................................................................................................... 10

Самое основное вначале .............................................................................................................. 10

Взаимоотношения с другими ролями ....................................................................................... 11

Scrum Master в помощь Product Owner ..................................................................................... 11

Scrum Master и Организация ...................................................................................................... 11

Если душа просит подробностей: .............................................................................................. 12

Scrum Master – помощник, а не хозяин ..................................................................................... 12

Scrum Master играет в кёрлинг ................................................................................................... 12

Пример ............................................................................................................................................ 14

Разработка интернет-магазина глазами Scrum Master. ............................................................ 14

Product Owner .................................................................................................................................... 19

Жизнь Product Owner внутри Scrum Team ............................................................................. 19

Самое основное вначале .............................................................................................................. 21

Основные характеристики Development Team / Команда разработки Scrum ................. 22

Scrum Sprint ....................................................................................................................................... 24

Длительность Sprint ..................................................................................................................... 24

Цель Sprint ..................................................................................................................................... 24

Первая встреча в Scrum Sprint (планирование) ........................................................................ 25

Вторая встреча в Scrum Sprint (планирование) ........................................................................ 25

Ежедневный Scrum ...................................................................................................................... 26

Обзор Sprint .................................................................................................................................. 26

Sprint Planning Meeting ..................................................................................................................... 27

3

Длительность Sprint Planning Meeting ..................................................................................... 27

Формат проведения встречи ...................................................................................................... 27

Пример ............................................................................................................................................ 28

Daily Scrum Meeting / Ежедневный скрам ..................................................................................... 30

Кто участвует в Daily Meeting .................................................................................................... 31

Варианты проведения Daily Scrum Meeting ............................................................................ 32

Возможные проблемы на Daily Scrum Meeting ....................................................................... 32

Sprint Review Meeting ....................................................................................................................... 33

Время Sprint Review Meeting ...................................................................................................... 34

Пример Sprint Review Meeting ................................................................................................... 34

Sprint Review Meeting при разработке интернет магазина...................................................... 34

Sprint Retrospective Meeting – Ретроспектива в Scrum ................................................................ 36

Пример Sprint Retrospective Meeting в разработке интернет-магазина ............................ 37

Story Points ......................................................................................................................................... 40

Что же происходит на самом деле при Story Points? ............................................................. 41

Abnormal Termination / Остановка спринта ................................................................................. 43

Кто должен принимать решение на счет Abnormal Termination / Остановка спринта . 43

Definition of Done ............................................................................................................................... 45

Definition of Done на страже нашего спокойствия ................................................................. 46

Product Backlog .................................................................................................................................. 48

Подход №1 – один Product Owner и один Product Backlog ................................................... 52

Подход №2 – один Product Owner и несколько Product Backlog ......................................... 52

Подход №3 – несколько Product Owner и несколько Product Backlog .............................. 53

Sprint Backlog ..................................................................................................................................... 54

Изменение приоритетов для Sprint Backlog: .......................................................................... 55

Изменение объема работ для Sprint Backlog: .......................................................................... 57

4

Дробление задач для Sprint Backlog: ........................................................................................ 58

Planning Poker (Scrum Poker) .......................................................................................................... 61

Что собой представляют карты для Planning Poker / Scrum Poker .................................... 61

1 вид популярной колоды для Planning Poker: ......................................................................... 61

2 вид популярной колоды для Planning Poker: ......................................................................... 61

Как проходит Scrum Poker / Planning Poker ............................................................................ 62

Основные проблемы в использовании Planning Poker ......................................................... 62

Эффект привязки в Scrum Poker ................................................................................................ 62

Не выделяться из толпы.............................................................................................................. 63

Описание Scrum of Scrums .............................................................................................................. 64

Stakeholders Scrum / Заинтересованные стороны в Scrum ......................................................... 65

Основные обязанности Stakeholders: ....................................................................................... 65

Management Scrum / Менеджмент в Scrum ................................................................................... 66

Диаграмма сгорания задач / Burndown Chart .............................................................................. 68

Читаем Диаграмму сгорания задач / Burndown chart........................................................... 69

1. Burndown Chart: Слишком рано ............................................................................................. 69

2. Burndown Chart: Опоздали ..................................................................................................... 70

3. Burndown Chart: Без оценок ................................................................................................... 71

4. Burndown Chart: Конечная оценка ......................................................................................... 72

5. Burndown Chart: Zero .............................................................................................................. 73

6. Burndown Chart: Релаксирующая команда ........................................................................... 74

7. Burndown Chart: Совершенствование ................................................................................... 75

8. Burndown Chart: Опыт ............................................................................................................. 76

9. Burndown Chart: A++ ............................................................................................................... 77

Velocity Scrum .................................................................................................................................... 78

5

Доброго времени суток друзья!

Данная брошюра (книгой её назвать сложно) - это просто структурированный сборник наших

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

старта работы по системе Scrum.

6

Немного о главном

Не смотря на свою универсальность и поистине мощную составляющую, Scrum методология

является очень простым инструментом. Стоит один раз ознакомиться и понять, что к чему, и

жизнь действительно изменится. Вы удивитесь, на сколько эффективно можно организовать

свою работу или личные дела.

Мы составили описание наиболее важных элементов методологии и включили их в раздел

«Основы Scrum». Саму информацию мы старались подать не сухим текстом, а разбавляя

наглядными образами и примерами.

7

Для быстрого старта

Чтобы быстро начать работать по Scrum, нужно всего несколько вещей:

- убедить начальство (если оно имеется) попробовать данную систему управления проектами;

- изучить самые основные азы Scrum и роли;

- зарегистрироваться в Scrum Time (http://scrum-time.com) для доступа к онлайн доске;

Начать следует именно с понимания, что такое команда в Scrum и как она вообще выглядит, и

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

обеспечения, так как в основном они быстро подхватили идею Scrum. Однако Scrum – это не

только программирование и более того, зарождение этих идей вообще не связано с этим.

http://scrum-time.com/

8

Основные роли Scrum необходимые для старта

Их немного, пожалуй, даже две, хотя в целом команду можно вынести как отдельную роль, ведь

она является отдельной рабочей единицей.

9

Scrum Team

Scrum Team – это собственно собирательный образ команды, состоящей из Development

Team, Scrum Master и Product Owner. Команда полностью самодостаточна и не зависит от

внешних специалистов или заказчиков. Хотя на самом деле понятия часто размыты. Порой

Development Team не фигурирует в процессе, особенно если проекты не касаются разработки

ПО.

Скрам команда поставляет заказчикам продукт после каждой итерации и подает его поэтапно,

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

версия. Благодаря этому постоянно происходит обратная связь, способная корректировать и

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

берет определённую часть работы (ту, которую точно выполнит за скажем 2 недели) и

выполняет её.

Для того, чтобы лучше понять функциональную составляющую Scrum Team,

необходимо ознакомиться с тремя частями:

Scrum Master – здесь описано как данный человек действует внутри Scrum Team, и

собственно станет понятно, как Scrum Team выглядит со стороны Scrum Master.

Product Owner – владелец продукта. На самом деле это не заказчик, а

полноправный член Scrum Team, который имеет большую ответственность, но и

большие ограничения. Ознакомившись с данной статьей, станет понятно, как Scrum

Team предстоит пред глазами владельца продукта.

Development Team – основная рабочая единица, которая и занимается

непосредственно разработкой продукта. О том, что происходит внутри Scrum

команды можно прочитать в данной статье.

10

Scrum Master

Давайте раз и навсегда разберемся и поймем, что же такое за понятие Scrum Master и кто тот

человек, который назначен на эту роль.

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

понимание об управленцах. Хотя с прямой уверенностью можно сказать, что его философия

единственно правильно отображает суть социальных взаимоотношений как в рабочих

коллективах в частности, так и во всём социуме в целом.

Самое основное вначале

Довольно смело можно сказать, что Scrum Master является одним из самых важных персон в

методологии Scrum. Необходимо понять – Scrum Master не дает заданий, а устраняет

проблемы, появляющиеся внутри (Scrum Team), далее "команды».

Все вопросы, которые возникают во время рабочего процесса неизбежно порождают

проблемы и цель Scrum Master их выявить и сделать открытыми.

Эта открытость напрямую ведет к доверию внутри команды. Данное доверие порождает

атмосферу, которая благоприятно влияет на скорость и качество работы. Scrum Master также

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

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

выполнения задач. Scrum Master следит за выполнением таких процессов.

Слежение за процессом и смена статусов задач в спринте также ложатся на плечи Scrum

Master.

Scrum Master каждый день руководит Daily Scrum Meeting.

Scrum Master должен грамотно организовывать митинги (meetings). На них он занимается

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

сконцентрироваться на правильных целях.

11

Scrum Master взаимодействует не только с командой, но и с Product Owner. Он может

помогать владельцу продукта создавать Backlog.

В качестве выжимки можно выделить основной функционал Scrum Master:

устранение проблем, образующихся внутри команды;

выявление скрытых вопросов;

создание дружественных отношений в команде;

слежение за процессами и их выполнением;

смена статусов задач в спринте;

проведение Daily Scrum Meeting;

организация встреч перед спринтами;

помощь Product Owner с Backlog.

Взаимоотношения с другими ролями

Scrum Master в помощь Product Owner

Контролирует то, что Product Owner понимает, как правильно вести Backlog для

достижения максимальной ценности продукта;

Старается найти более эффективные методы ведения Backlog;

Оказывает помощь Scrum Team в создании удобных и качественных элементах Backlog

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

требованию;

Использует гибкие методы в разработке и управлении;

Scrum Master и Организация

Взаимодействует с другими Scrum Master для более эффективного использования

методологии Scrum в Организации;

Проявляет инициативу в изменениях, которые должны приводить к большей

эффективности Scrum Team;

12

Занимается помощью тем сотрудникам, которые заинтересованы в методологии Scrum.

Помогает внедрять Scrum.

Занимается коучингом в организации для адаптации к Scrum;

Производит планирование этапов внедрения Scrum.

Если душа просит подробностей:

Scrum Master – помощник, а не хозяин

Если взять основное назначение такого понятия, как «чиновник», то оно приведет нас к

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

проблем в отведенной им области. Звучит утопично, не правда ли? Все мы прекрасно знаем,

что происходит, когда некий чиновник перестает быть слугой народа, а то и вовсе не

понимает главного смысла своего места и начинает чувствовать себя просто управленцем,

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

Ничего хорошего конечно из этого не получается.

Scrum Master играет в кёрлинг

В качестве известного примера scrum методологии является игра кёрлинг. Нас она сейчас

интересует со стороны Scrum Master.

Основные правила кёрлинга:

13

1. Игра ведется на специальной площадке, с дорожкой и "мишенью".

2. Один игрок производит бросок камня, который катится в сторону мишени.

3. Во время движения камня по льду происходит трение об лёд и по факту, камень может

либо перекатиться через мишень, либо наоборот не докатиться. В данном случае

вступают в игру игроки, которые занимаются так называемым "свипингом". Свипинг -

это процесс натирания льда, который обеспечивает более быстрое скольжение камня по

льду благодаря образующейся тонкой прослойки воды. Свипер (натирающий лёд) по

сути выполняет следующие функции:

o не прикасается к движущемуся камню;

o организует именно ту дорожку для камня, которая максимально точно приведет

камень к цели.

Можно ли сказать, что свипер двигает камень? Физически его толкает другой игрок и

физически свиперы не трогают камень. Однако именно благодаря свиперам камень движется

именно так как надо.

14

Как видно, свипер - это полный аналог Scrum Master. Scrum Master также не трогая работу

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

примере кёрлинга очень хорошо видно на сколько важна работа Scrum Master

Пример

Мы сделали один пример на нашу базу информации и постарались показать его из глаз

разных ролей. В данном случае мы будем смотреть на проект больше со стороны Scrum

Master. В примере мы приведем некоторые сложности, они по сути банальны и надуманы, но

они и созданы нами, чтобы дать понять основу того, как и что должен делать Scrum Master.

Разработка интернет-магазина глазами Scrum Master.

Для того, чтобы сделать хороший интернет-магазин, первым делом необходимо определить и

решить, а что все-таки нужно от этого магазина и как он будет выглядеть. Это является по

сути некоторым списком "хотелок".

Такой список составляет человек называемый Product Owner. Человек с данной ролью

представляет в голове тот конечный продукт, который задуман. Следует правда отметить, что

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

понимание, что, какая-то идея была не очень удачной, а какую-то идею следовало бы

включить. Рассматривать подробно функции и мысли Product Owner мы не будем, так как

речь всё же о Scrum Master.

Так или иначе, человек видящий хотя бы примерный конечный продукт (Product Owner).

Накидал список - описание того, что должно быть в интернет магазине.

15

Данный список называется Product Backlog, давайте на него посмотрим:

Тематика Название Описание Статус Оценка Релиз

Управление

каталогом

Добавление

продукта

Разработка формы создания продукта, которая

содержит фотографию, название, цену, скидку

или её отсутствие...

В

работе 2 Релиз 1


каталогом

Удаление

продукта

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

редактирования, так и списком

В


Заказ Оплата Использование платежных систем В


Заказ Вход Вход с помощью социальных сетей В

работе 1

Незапл

аниров

ано

... ... ... ... ... ...

Как мы помним из требований к Scrum Master - помощь Product Owner в ведении Product

Backlog, в его упорядочивании, эффективной настройке и так далее. Scrum Master первым

делом обязан посмотреть на данный список и помочь Product Owner.

Давайте посмотрим, чтобы мог сказать Scrum Master по данному бэклогу? Первым делом

надо разобраться с понятием "Платежные системы", по сути это общее понятие и цель не

такая точная. Сколько платежных систем должно быть подключено? Какие основные? Такой

же законный вопрос и по социальным сетям. Стоит подключать Facebook? Google+? Что

более важно и должно быть в первом релизе?

Неопределенность в Product Backlog является основной проблемой, которая вносит

неопределённость в работу Scrum Team. Как мы помним - одна из важнейших функций Scrum

Master это вынесение неясностей на поверхность и их устранение. Еще одним недочетом

можно считать отнесение работы над оплатой в Релиз 2. По сути, оплата в интернет-магазине

— это самый важный функционал. При новом бэклисте уже можно немного "дробить". Что-

то нужно оставить в Релиз 1, а что-то можно перенести в Релиз 2.

16

Давайте посмотрим, как мы сможем улучшить Product Backlog:



каталогом


продукта

Разработка формы создания продукта,

которая содержит фотографию, название,

цену, скидку или её отсутствие...

В



каталогом

Удаление

продукта



В


Заказ Оплата Наложенный платеж В


Заказ Оплата Оплата с помощью карт Visa и Mastercard В


Заказ Оплата Оплата с помощью системы Яндекс

Деньги

В


Заказ Вход Регистрация с помощью Facebook В

работе 1 Незапланировано

Заказ Вход Регистрация с помощью Google+ В

работе 1 Незапланировано

... ... ... ... ... ...

Теперь мы видим, что Product Backlog стал более конкретным. Конечено же, мы привели к

примеру, не идеальные бэклоги, а лишь те, которые в своей простой вариации могут показать

суть.

После того, как был сформирован бэклог начинаются Sprints (спринты). Scrum Master

принимает участие во всех жизненных циклах спринта. Участие в первом митинге. Scrum

Master участвует совместно с Product Owner, Scrum Team, пользователями и менеджерами. К

примеру, было решено, что целью первого спринта (Sprint Goal) стала реализация добавления

и удаления продукции и их вывод на экран в том виде, в котором они будут до конца. Это

17

позволит за первый Sprint сделать функционал способный дать возможность наполнять

каталог продукции, пока идут работы по следующим задачам. Такой подход ускорит вывод

готового продукта на рынок.

Второй митинг уже проводят Scrum Master и Scrum Team. На данном этапе в Sprint

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

Если происходит так, что во время спринта выясняется, что команда не может выполнить все

задачи, то Scrum Master должен встретиться с Product Owner и решить, какие задачи можно

исключить из sprint и при этом достигнуть цели. В нашем надуманном примере, можно

предположить, что Scrum Master решил исключить задачи по конечному оформлению

продуктов. Тогда основная цель спринта - организовать добавление и удаление продукции со

всеми нужными параметрами и взаимосвязями будет всё ровно достигнута.

Каждый день Scrum Master проводит Daily Scrum Meeting.

В данном примере Scrum Master по правилам задает всё те же вопросы:

1. Что было сделано вчера?

2. Что будет сделано сегодня?

3. С какими проблемами столкнулся?

Ответ Scrum Master, например, может услышать такой:

1. Таблицы продукции в базе данных;

2. Форма для добавления продукта в БД;

3. Не до конца сформированная схема о накопленных скидках.

После получения ответов Scrum Master составляет некий Action Items. В нем обычно

указывается: что, кто, когда решить.

Что сделать С кем обсудить Сроки

Решить вопрос со схемой скидок Алексей 24 часа

18

Завершающим этапом в Sprint является демонстрация продукта - Sprint Review Meeting.

Данное мероприятие проводит Scrum Master. Длительность такого мероприятия 4 часа. С

помощью Scrum Team на данное мероприятие составлен план действий (agenda) и Scrum

Master руководит, кто за кем и что рассказывает.

19

Product Owner

Product Owner является неким связующим звеном между заказчиком и командой разработки.

Окончательная инстанция по принятию решений в Scrum Team – это как раз и есть Product

Owner

Самая главная ответственность Product Owner – это создание и контроль Product Backlog

Основные обязанности и ответственность Product Owner при управлении Product

Backlog:

Определение элементов беклога продукта;

Правильное расположение элементов для оптимизации достижения цели;

Обеспечение понятности и прозрачности Product Backlog;

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

всей Scrum Team;

Общая оптимизация для достижения наибольшей ценности работы Development Team;

Ответственность за понимание беклога командой разработки.

Стоит отметить, что Product Owner может сам выполнять все вышеперечисленные

обязанности, а может отдать их на исполнение Development Team, однако всегда остается

ответственным.

Решения Product Owner по исполнению тех или иных задач должны исполняться. Все свои

решения, Владелец Продукта транслирует через тот Product Backlog, который получается.

Важно при этом помнить, что влиять на саму работу Development Team он не может и порой

даже не присутствует на планированиях, например, на Scrum Planning Meeting, однако он

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

оперативно решить.

Жизнь Product Owner внутри Scrum Team

Для Product Owner важно писать задачи не со стороны того же программирования, а со

стороны требований заказчика – «хотелок». Например, система выборки журнала работает

медленно, хотелось бы быстрее. Если Product Owner напишет – Произвести оптимизацию

20

базы данных, то это неправильный подход. Проблема ведь может быть и не в базе данных,

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

выдачу журнала. Для идей решения проблем, Product Owner (да и любой другой) есть поле

Примечание в Product Backlog.

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

нужно, ведь взаимодействие с командой ведет к более лучшей и эффективной работе.

Возвращаясь к тому же Planning Meeting, можно часто заметить, что как бы не старался

Product Owner в заполнении Product Backlog, всегда появляются спорные моменты. Самая

основная проблема – переоценка Story Points. Product Owner порой не может предусмотреть

всех технических аспектов того или иного действия (да и не должен), и давая задачу, он

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

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

задачи, а это может повлиять на выход общего количества Story Points за пределы

возможностей команды, оцененные по Velocity.

Подробнее о данной проблеме написано в статье про Sprint Backlog.

Product Owner нужен не только на

начальном этапе, как может показаться,

но и на протяжении всего Sprint.

Взаимосвязь с командой правда проходит

только односторонняя – команда по мере

возникновения вопросов вправе

привлекать Product Owner. Чаще

происходит так, что время необходимое

для привлечения Product Owner зависит от общего времени, проведенного с командой. Про

такое говорят: «Команда созревает для вопросов к Product Owner»

Также важной обязанностью Product Owner является остановка спринта. В статье Abnormal

Termination / Остановка спринта подробно описано это действие.

21

Development Team

В нашем привычном представлении, одной рабочей единицей является человек, если речь

идет о человеческих ресурсах, но в методологии Scrum это не так. Development Team

(Команда разработки) – это как раз и есть одна рабочая единица. Данная рабочая единица

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

организм, состоящий из отдельных элементов.

Самое основное вначале

Сама Scrum команда выполняет всю работу во время Sprint (спринта) и более того, она берет

на себя все обязательства по выполнению этой работы.

Scrum команда (Scrum Team) не является большой. Самый частый размер команды от 5 до 9

человек.

Если перечислить основный функции Scrum Team (Scrum команда) то они будут выглядеть

следующим образом:

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

Следит за собственной результативностью (совместно с Scrum Master);

Берет на себя решение по разработке и дизайну;

Оценивает элементы Product Backlog

Несет ответственность за результат перед Product Owner

Важно понять и отойти от привычного понимания должностей и, пожалуй, даже ролей.

Естественно, каждый член команды обладает каким-то уникальном функционалом, но

помимо этого он обладает и смежными знаниями. Это позволит команде быть одним целом.

В разработках есть такая практика – сажать работников в специальные «кубики» где каждый

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

В методологии Scrum это не практикуется. Чтобы эффективно выполнять ту или иную задачу,

необходимо, чтобы все члены Development Team могли свободно общаться друг с другом,

решая на ходу возникающие проблемы и советуясь.

22

Основные характеристики Development Team / Команда разработки Scrum

Команда полностью

самоорганизована. На её работу

никто не влияет, в том числе и

Scrum Master.

Для разработки текущего

продукта, команда полностью

обладает всеми навыками.

В Development Team есть

только понятие разработчик

продукта и исключены все

должности. Всё это, не смотря на то, чем

занимается конкретный человек.

Development не имеет

иерархии или подотделов. Всё

решается внутри команды.

Каждый член команды

разработки имеет

специализированные знания, но

ответственность всегда на всей команде в

целом.

23

Основные этапы исполнения проектов в Scrum

Ознакомившись с основными ролями в Scrum, самое время перейти к знакомству с рабочим

процессом и особенностями.

24

Scrum Sprint

Пожалуй, самый важный элемент методологии Scrum – это конечно же Sprint / Спринт.

Абсолютно всё вокруг крутится вокруг спринта, ибо именно во время него происходит

творение продукта.

Длительность Sprint

Вообще, длительность спринта обычно составляет 30 дней (1 месяц), но иногда его делают

равным двум неделям. Мнения по этим вопросам разделились, так как некоторые считают,

что подготовить и организовать спринт на 30 дней гораздо тяжелее чем на две недели, что и

логично.

Цель Sprint

В методологии Scrum, по завершении спринта должен обязательно получиться готовый

продукт, который можно передавать заказчикам. Стоит, однако понимать, что это естественно

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

бесконечно. Здесь нужно держаться ориентира – окончание спринта = рабочий продукт, на

котором можно что-то делать. Следующий спринт уже улучшает его, к примеру, и опять же в

конце спринта дает полностью рабочий продукт.

Как видно выше из рисунка, жизненный цикл методологии Scrum состоит из

подготовительных этапов для спринта и завершающих этапов. На каждом этом этапе

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

Scrum.

Жизнь Scrum Sprint – или как он устроен

25

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

Sprint начинается с планирования, только не обычного, а специального со своими законами и

порядками. На первых митингах встречаются Development Team, Scrum Master, Product

Owner, Managers, Stakeholders. Первая встреча называется Sprint Planning Meeting.

Первая встреча в Scrum Sprint (планирование)

Участники:

Development Team, Scrum Master, Product Owner, Managers, Stakeholders

Цель:

На данной встрече определяется и находится собственно сама цель Спринт, к чему он должен

привести, что мы должны получить на выходе. Такая находка имеет название Sprint Goal.

После определения Sprint Goal, необходимо определить Sprint Backlog – собственно то, что

нужно сделать во время Scrum Sprint для достижения цели спринта.

Артефакты:

Sprint Backlog

Вторая встреча в Scrum Sprint (планирование)

Участники:

Development Team, Scrum Master

Цель:

Внутренняя встреча Scrum Team. На ней обсуждаются вопросы по самой разработке. Важное

отличие методологии Scrum от простого управления проектами в том, что здесь никто извне

не вмешивается как будет работать команда.

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

или иной элемент проекта.

Происходит оценка продолжительности работы над той или иной задачей.

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

необходима еще одна встреча с участием Product Owner. На такой встрече будет решаться как

сократить Scope, не потеряв основного функционала.

Зачастую Product Owner находится где-то рядом во время второй встречи, но появляется в

26

комнате обсуждения только по требованию.

Ежедневный Scrum

В процессе Scrum Sprint каждый день происходят специальные встречи по 15 минут.

Название таких встреч Daily Scrum Meeting и призваны они, чтобы прозрачно видеть

проблемы, возникающие в процессе работы команды и вовремя их устранять. Да и в целом,

видно, как идет работа по проекту.

Обзор Sprint

Окончанием Scrum Sprint является демонстрация сделанного продукта. Ничто иное не может

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

Длительность такой встречи также регламентировано, порядок демонстрации и список

участников может меняться, но в основном присутствуют Product Owner, Development Team,

Scrum Master, Management, Stakeholders и разработчики из других проектов.

Вообще, Scrum Sprint состоит из многих элементов и как уже писалось выше – всё и завязано

вокруг спринта. Чтобы хорошо разбираться в структуре Sprint рекомендуем ознакомиться с

нашей информационной базой.

http://scrum-time.com/infobase/

27

Sprint Planning Meeting

Одно из самых важнейших мероприятий в методологии Scrum – это конечно же Sprint

Planning Meeting. В данном мероприятии принимают участие владелец продукта, Scrum

Master и вся команда разработки. Иногда происходит и участие внешних заинтересованных

сторон, однако это бывает редко.

Во время Sprint Planning Meeting Product Owner описывает наиболее приоритетные задачи

команды. Команда в это время задает достаточное количество вопросов, чтобы более точно

оценить и распределить задачи, которые будут решаться во время Sprint.

Владелец продукта не должен описывать каждый элемент Product Backlog. Для Product Owner

хорошим ориентиром будет приход на Sprint Planning Meeting и разговор о задачах, которые в

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

текущий Sprint, то разговор будет о топ-10 задачах из всего Backlog.

Два артефакта получаемые на Sprint Planning Meeting:

Sprint Goal;

Sprint Backlog.

Цель спринта – это сформулированные одно или два предложения, которые

описывают то, что команда планирует достичь вовремя Sprint. Sprint Goal

описывается командой и владельцем продукта (совместно).

Длительность Sprint Planning Meeting

Гибкость методологии Scrum проявлена везде, в том числе и в длительности Sprint Planning

Meeting. Эта самая длительность зависит от длительности будущего спринта. Формула тут

следующая – 1 неделя Sprint = 2 часа Sprint Planning Meeting. То есть при спринте

длительностью в 2 недели, Sprint Planning Meeting должен быть 4 часа.

Формат проведения встречи

Встреча условно делится на две части.

28

В первой части Product Owner проводит обзор элементов из Product Backlog, которые

необходимо представить и обсудить на данной встречи. Владелец продукта описывает

что он хочет видеть. Именно тут задаются вопросы и обсуждаются задачи в можно сказать

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

уточняющий вопрос. По сути целью таких уточнений является убирание любой

двусмысленности.

В конце первой части формируется та самая Цель спринта / Sprint Goal.

Во второй части команда уже формирует Sprint Backlog, задачи которого оцениваются

в часах. На данном этапе вмешательство Product Owner недопустимо. На самом деле

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

он не должен находиться в комнате где идет обсуждение. Иногда правда бывают случаи,

когда он присутствует, но тогда Scrum Master должен взять на себя ответственность за

создание спокойной атмосферы для работы команды. Product Owner не всегда может

понимать какие-то глубокие процессы и во время обсуждения где команда решает сделать так

или не так, Владелец продукта может развивать панику.

Пример

В качестве примера покажем как всегда задачи создания интернет-магазина.

Необходимо: реализовать основные функциональные возможности корзины покупок,

включая добавление, удаление и изменение.

Разработка процесса контроля: оплатить заказ, забрать груз, заказ подарочной упаковки и

т.д.

Вообще цель спринта служит некоторой точкой отчетности для «внешних участников».

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

работает команда, но которым нет необходимости (да и не разрешено) лезть в глубину работы

29

команды и оценивать каждую задачу, и тот или иной шаг, совершаемый Scrum Team. Sprint

Goal здесь как нельзя лучше подходит в качестве такого «мерило». Всё ведь очень просто,

достигнута цель или нет, а не какие элементы были сделаны или не сделаны.

Вторым артефактом является бэклог спринта, который уже является рабочим списком для

реализации в спринте.

Важно то, что команда должна всё же решить, сколько работы она сможет выполнить.

Недопустимо постановка задач таким образом: работы на 4 спринта, так что в первый спринт

команда должна выполнить 25% от всех задач.

30

Daily Scrum Meeting / Ежедневный скрам

Игра команды, да, именно игра команды. Всем, наверное, действительно надоело сравнение

Scrum с игрой команды, но, пожалуй, этот образ действительно максимально сильно дает нам

понять, как устроена методология Scrum. Во многих командных играх, перед выходом на

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

обсуждает самые важные моменты игры. Не стоит, однако путать эту встречу с планомерным

обсуждением тактики игры задолго до выхода, это будет скорее всего Planning meeting.

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

что-то в течении даже 5 минут. В условиях такого ограниченного времени вольно или

невольно игроки и тренер говорят только действительно о самом важном на ближайшее

время, и все при этом слушают крайне внимательно, затем они заряжаются боевым кличем и

устремляются на поле полные энергии и задора.

Разговор тренера может состоять при этом, например, из таких фраз: «главный нападающий

практически всегда бежит по данной траектории, ты находишь в этой позиции, тебе для

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

следующего таймаута», «я заметил, что тебе тяжело пройти вот эту дистанцию во время

нападения, в чем проблема?» и так далее. Daily Scrum Meeting выглядит примерно также,

31

хотя может и без такого напряжения. Так или иначе цель такого совещания скорректировать и

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

решения. Чтобы иметь структурированную систему в методологии Scrum разработаны три

простых вопроса, которые должны звучать на Daily Scrum Meeting.

Три главные фразы Daily Scrum Meeting

1. Что ты делал вчера?

2. Что ты будешь делать сегодня?

3. Какие проблемы есть у тебя на пути?

Данные вопросы безусловно задает Scrum Master. Все ответы он обязательно должен

фиксировать. Проблемы естественно могут быть абсолютно разными, приведем пример из

области офисной жизни и разработчиков, хотя, как известно методология Scrum может

применяться к чему угодно.

Мне нужна помощь в отладке программы;

Техническая поддержка офисного продукта не перезванивает уже второй день;

Заказанное программное обеспечение так еще и не пришло;

Мой стул сломался и мне приходится работать стоя!

Естественно, какие-то вопросы Scrum Master может решить сам, для каких-то он должен

искать решение, обратиться к кому-то или как-то еще. В любом случае, Scrum Master

ответственен за эти проблемы и за их решения.

Кто участвует в Daily Meeting

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

это все же будет неуместно и дело не в должностях, так как участие к примеру владельца

клуба, тоже тут неуместно. Ни один ни второй напрямую не могу повлиять на работу

команды в текущей отрезок времени. Данные лица могут помочь только в случае

необходимости, если в списке проблем появится что-то, по чему к ним смогут обратиться.

32

В Daily Scrum Meeting всё точно также. Участие в 15 минутной встречи обязательно для всей

Development Team, также участвуют Scrum Master и Product Owner. Иные лица, будь то

заказчики, маркетологи или кто-то еще, могут присутствовать, однако без права говорить.

Варианты проведения Daily Scrum Meeting

На самом деле вариантов проведения этого мероприятия достаточно много и разные команды

подстраиваются под свои условия.

1. Иногда Scrum Master спрашивает громко, чтобы слышали все. Спрашивает он по

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

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

отреагировать на проблему. Из минусов возможно тут сыграет некий психологический

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

как ему кажется вызвана другим членом команды.

2. Вторым вариантом можно считать ситуацию, при которой Scrum Master задает вопросы

каждому индивидуально в личной беседе, но в пределах одной комнаты. Тут

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

3. Третьим вариантом можно назвать использование иных средств отличных от беседы. В

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

пишет ответы на эти вопросы или современные технические средства, например, наш

сервис.

Возможные проблемы на Daily Scrum Meeting

Все проблемы в действительности человеческие. Самая основная – это обсуждение чего-то

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

хоккею или футболу (хотя и такое бывает), а скажем бюджет проекта. Также излишние

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

33

Sprint Review Meeting

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

продукта. Более того, это означает, что команда полностью написала код, провела

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

или целый продукт.

Sprint Review Meeting проводится в конце каждого спринта и носит обзорный характер. На

встрече команда оценивает то, что она сделала и чаще всего это выглядит в виде

демонстрации новых возможностей.

Не стоит относится к Sprint Review Meeting как к формальной четко поставленной встрече с

развернутыми докладами. Sprint Review Meeting это всё же просто логическое завершение

Sprint. На подготовку к этой встрече не позволительно готовиться более 2 часов и запрещено

использование слайдов типа PowerPoint.

В данной встрече обычно участвует Product Owner, Development Team, Scrum

Master, Management, заказчики и разработчики из других проектов.

В ходе Sprint Review Meeting, проект оценивается в отношении цели Спринта, которая была

определена во время планирования. В идеале команда выполнила все задачи из Product

Backlog помещенные в Sprint, но это не самое важное, а важно то, что была достигнута цель

Спринта.

Более подробно, на что смотрит заказчик на Sprint Review Meeting:

Команда передала законченный продукт;

Работа команды завершена;

Показатели проекта (завершенность кода и тд.);

Работоспособность выполненных задач;

Обзор приоритетов (для следующих итераций / спринтов).

34

Время Sprint Review Meeting

Время данного обзора строится по следующей формуле: за каждую неделю Sprint набегает 1

час обзора. То есть если Sprint был четырехнедельным, то Sprint Review Meeting будет длится

4 часа. Провидится эта встреча в последний день спринта.

Пример Sprint Review Meeting

Один созданный пример на всю базу знаний можно и упомянуть здесь. Разработка интернет

магазина описываемая в разных статьях нашей Info Base само собой разумеется имеет

Спринты, а Спринты имеют Sprint Review Meeting.

Sprint Review Meeting при разработке интернет магазина

Product Backlog



каталогом


продукта

Разработка формы создания

продукта, которая содержит

фотографию, название, цену, скидку

или её отсутствие...

В



каталогом

Удаление

продукта



В


Заказ Оплата Наложенный платеж В


Заказ Оплата Оплата с помощью карт Visa и

Mastercard

В


Заказ Оплата Оплата с помощью системы Яндекс

Деньги

В


35

Заказ Вход Регистрация с помощью Facebook В

работе 1

Незапланиров

ано

Заказ Вход Регистрация с помощью Google+ В

работе 1

Незапланиров

ано

... ... ... ... ... ...

Имея данный Product Backlog, в Sprint были добавлены задачи из первого релиза. А точнее мы

имеем задачи:

1. Добавление продукта.

2. Удаление продукта.

3. Оплата - Наложенный платеж.

4. Оплата - Оплата с помощью карт Visa и Mastercard.

На Sprint Review Meeting соответственно будут продемонстрированы возможности по

добавлению продуктов в базу интернет магазина и возможность их удалять. Также

продемонстрирована работа корзины с возможностью оплаты заказа по карте или выбором

наложенного платежа.

36

Sprint Retrospective Meeting – Ретроспектива в Scrum

Sprint Retrospective Meeting, наравне с Sprint Reviews Meeting, проводится в последний день

Спринта. Задачи в отличие от Sprint Reviews Meeting ставятся совершенно иные. Если

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

посмотреть на результат команды.

Не зависимо от того, на сколько хорошо работает Scrum Team, всегда есть возможность

улучшить показатели. Хорошая Scrum команда всегда ищет возможности своего улучшения и

для этого в методологии Scrum выделили специальное время, позволяющее остановиться и

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

Ретроспектива Scrum - очень полезное мероприятие и не стоит к нему относится

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

интервалом замены масла считается порядка 15 000 км., то есть через каждое это число

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

может ухудшаться или более того, это может привести к серьезной поломке и выходу из

строя. Scrum Team также нуждается в подобной замене «масла», чтобы работа всегда была в

наивысшей степени эффективной.

Большинство Scrum Team переходят к ретроспективе (Sprint Retrospective Meeting) сразу

после обзора (Sprint Review Meeting). Вся команда Development Team, а также Scrum

Master и Product Owner участвуют в этом процессе. Хотя стоит отметить, что участие Product

Owner не во всех видах Sprint Retrospective Meeting необходимо. У ретроспективы нет очень

сильных временных ограничений, но есть формула золотой середины: длина Sprint

Retrospective Meeting равна 75% часа (45 минут) умножить на количество недель в Sprint.

Если у вас четырехнедельный Спринт, то время на ретроспективу в Scrum следует выделить

равной 60 * 0.75 * 4 = 180 минут. То есть на ретроспективу следует потратить 180 минут, что

равняется трем часам. Иногда право некоторые команды не придерживаются этой формулы и

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

расширяется.

На самом деле способов проводить подобные встречи достаточно много и даже внутри

организации проведения мероприятий нет пределу совершенства. По этому поводу даже

37

написаны целые книги, например, Agile Retrospectives: Making Good Teams Great и Project

Retrospectives: A Handbook for Team Reviews.

Самым распространенным и простым способом (что не отменяет его эффективность),

является способ Start-Stop-Continue.

При этом способе каждого члена команды просят определить, какие конкретные вещи должна

делать команда, а какие нет, а какие продолжить. Он распределяет свои ответы по трем

возможным вариантам:

Начать делать;

Прекратить делать;

Продолжить делать.

Опять, здесь же, есть варианты исполнения. На самом деле, для ведения более эффективных

встреч и нужен Scrum Master, который к примеру, может попросить команду выкрикнуть

идеи во время схватки. Scrum Master может так и не делать, а вообще пойти по кругу и

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

начать делать, или прекратить, или продолжить.

После мозгового штурма Sprint Retrospective Meeting, может начаться голосование по

конкретным вопросам, которые будут учитываться в следующем спринте. В следующей

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

Пример Sprint Retrospective Meeting в разработке интернет-магазина

Созданный нами пример разработки интернет-магазина, кочующий из статьи в статью, не

прошел и мимо текущей.

38

После завершение Sprint и Проведения Sprint Reviews Meeting, команда Scrum собралась для

обсуждения эффективности её работы, которая была оценена каждым самостоятельно.

Scrum Master решает задать вопрос каждому лично и узнать ответы на все три вопроса.

Участник №1:

1. Я считаю, что команде следует начать использовать более развернутые листы

тестирования

2. ----

3. Я считаю, что команда должна продолжить использовать текущий вид Product Backlog,

он оптимально удобен

Участник №2

1. -----

2. Мне кажется, команде надо прекратить использовать оценку данную среду

разработки, её «неповоротливость» замедляет работу.

3. Команде однозначно следует продолжить использовать текущую систему контроля

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

концентрируемся на работе.

Как видно, высказывать идеи по улучшению можно совершенно разрознено, ведь этих точек

соприкосновений с рабочим процессом может быть огромное множество.

Scrum Master составляет список всех пожеланий и затем устраивает голосование. Во время

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

первую очередь и исправить в следующем спринте, а что оставить на потом.

39

Расширяем знания

После ознакомления с основными ролями и структурой Спринта – того, на чем строится

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

описаниям тех аспектов, которые так или иначе присутствуют практически в любом Scrum

процессе.

К такой информации относится:

Story Point как система оценок задачи;

Остановка спринта – исключительное состояние, когда нет иного выхода;

Definition of Done – определение точно того, что исполнено;

Product Backlog – общий список того, что необходимо;

Sprint Backlog – то, что выбрано на исполнение из Product backlog в текущую итерацию.

40

Story Points

Одна из самых важных сторон методологии Scrum – так называемые Story Points. Эта

сторона очень плотно интегрирована в Scrum совместно с технологией Planning Poker.

Самая частая проблема в работе Scrum Team – это неумение правильно оценивать сложность

работы и временные затраты на её выполнение. Из статьи про Burndown Chart можно увидеть,

как будет строится график сгорания, если неправильно оценить ту работу, за которую берется

команда.

Для многих действительно тяжело выработать правильную шкалу оценок и здесь нужен опыт

или хитрый подход. Для максимально эффективного и быстрого внедрения Story Points в

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

полный анализ. В данный анализ должны входить названия задач, которые выполнялись и их

продолжительность. Дальше всё проще простого, необходимо расположить эти задачи в

порядке возрастания, отсортировав по времени. Разделить на группы с одинаковыми

показателями или близкими и проставить оценки из вашей колоды карт Scrum Poker.

Рано или поздно, использование такого подхода сделает из вас классную и прогрессирующую

команду, что и есть единственно верное направление. Постоянно модернизирующаяся

команда, всегда будет разгонять свой Velocity и радовать своих заказчиков успехами.

41

Что же происходит на самом деле при Story Points?

Когда Scrum Team способна оценивать свою работу, ведет график Velocity, следит за

Диаграммой сгорания задач, рано или поздно (или с самого начала работы) абсолютно все

оценки будут вестись в Story Points.

Например, по графику Velocity можно увидеть, что динамика команды по среднему разгону

за каждый Sprint идет вверх и среднее значения за последние две итерации составили 23-30

Story Points (зависит от выбранной системы оценок). Глядя на эти показатели Product Owner

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

42

Правильная оценка и использование Story Points делает действительно чудеса, ведь она

связывает между собой работу всей команды: Development Team ощущает на что она

способна, Scrum Master видит есть ли проблемы у команды и что можно еще улучшить, а

у Product Owner не возникает вопросов сколько и какие задачи вкладывать в Backlog на

текущий Sprint.

43

Abnormal Termination / Остановка спринта

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

может прибегнуть к действию под названием Abnormal Termination или по-русски Остановка

спринта. Как видно из английского названия – это действие совершенно аномальное, но не

предусмотреть его и не оптимизировать было бы не в духе методологии Scrum.

Те, кто занимается разработкой программного обеспечения в любой области, знает, что

разбирать чужой код и чужую логику работы всегда тяжело. Если к Scrum команде поступает

задача на усовершенствование каких-либо процессов в работе web-сайта, то технические

специалисты оценивают уровень временных затрат относительно того, что уже сделано, а не

изготовления с нуля. После проведения Planning Poker и митингов, становится понятно, какой

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

которая длится уже какое-то время и выясняется, что в самых глубинах ядра текущего веб-

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

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

изменений и их временные рамки. На сам анализ также уходит ценное время, и

наша Диаграмма сгорания задач начинает принимать непривлекательный вид. Если команда

оценивает, что всё же успеет в заявленный срок переправить весь код, то она добавляет

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

есть совершить Abnormal Termination / Остановку спринта.

Кто должен принимать решение на счет Abnormal Termination / Остановка спринта

Вопрос этот не такой простой как кажется, и великие умы вселенной Scrum считают по-

разному. Кто-то точно скажет, что это должен быть Product Owner, а кто-то скажет, что Scrum

Master.

В целом, как мы знаем, за работой Development Team следит никто иной как Scrum Master, и

он в первую очередь решает, есть ли проблемы в работе команды или нет. Давайте

представим, что Scrum Master решает совершить остановку спринта, так как проблемы

команды выросли на столько, что ни к чему хорошему это не приведет. Scrum Master

останавливает спринт, и по всем правилам начинается планирование нового спринта. Как

44

известно, в планировании участвует Product Owner и на вопрос, что нам делать в новом

спринте? Product Owner ответит «То, что вы делали 10 минут назад, до того, как Scrum Master

прервал спринт». Для Product Owner, как для конечной инстанции, нет дела до работы

команды, ему есть дело до продукта и его качества. В данной ситуации решение об Abnormal

Termination логичней было бы исполнить Product Owner, тогда не было бы вопросов об

дальнейших действиях, и Product Owner пришлось бы пересматривать ход разработки, так как

он был бы в курсе того, что данный путь ведет в тупик. Product Owner так и так производит

остановку Sprint если назначенная цель исчезла.

Однако всё это перечеркивает тот факт, что в реальных Scrum командах, наверное, и не

бывает таких ситуаций, при которых кто-то решит оспаривать решение об Abnormal

Termination, ведь успех то нужен всем.

Стоит отметить, что также часто решение об остановки спринта принимает сама Development

team, ведь она как никто понимает сложившуюся ситуацию.

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

возникновения Abnormal Termination.

45

Definition of Done

Вы это уже сделали?

Что отвечать на такой вопрос рядовому сотруднику? Варианта два, но и два пути, которые

данному работнику могут и не понравиться. Если он отвечает «да», то это означает, что он

может взять еще работу на исполнение, а потом окажется, что ему нужно доделать старую.

Также если он отвечает «нет», то его могут посчитать медлительным и что он тормозит

процесс.

Такой вопрос обычно задается бесчисленное количество раз при разработке какого-либо

программного продукта, да и в целом во время рабочего процесса. В этих моментах, как и в

любых других, должна быть оптимизация способная минимизировать или исключить

полностью негативные стороны этого процесса. Вообще понимание выражения Definition of

Done в полной мере понятна людям знакомыми с философией Scrum. Определенно сделанная

задача – это та задача, которая не нуждается в доработках, но тут встает законный вопрос – а

как оценить, что задача действительно выполнена?

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

значит выполнена, не выполнена - значит не выполнена.

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

программы. Скажем, мы написали какой-то функционал и вроде как бы всё, однако мы

понимаем, что наш функционал может иметь баги (ошибки), которые, например, сейчас не

могут быть проверены, так как не готовы другие модули, позволяющие протестировать.

Получается ставя напротив этой задачи «Выполнено» мы немного лукавим, так как нам к ней

придется, так и так возвращаться. Даже если есть модули для тестирования, необходимо ли

тестировать? Может следует поставить «Выполнено» только после результатов code review?

Как мы видим у нас очень много вопросов, которые мешают нам правильно построить

работу. Из-за нашей неопределенности вытекают очень большие проблемы. Мало того, что

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

смогут разобраться. Как Вы уже, наверное, догадались Definition of Done и призвана

исправить это и не дать нам повода беспокоиться!

46

Definition of Done на страже нашего спокойствия

На самом деле на страже общего спокойствия. Мы действительно можем не понять до конца

о законченности нашей задачи, однако оповестить команду, что же мы все-таки сделали –

обязаны. Definition of Done – как и всё в Scrum должно быть лаконично, поэтому зачастую

отводится для этого одно предложение, однако это не единственный вариант.

Для примера приведем несколько выполненных задач с использованием Definition of

Done:

done=функционал оплаты реализован, проведено тестирование с тестировщиком

Алексеем

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

done=модуль авторизации разработан полностью, протестирован, продемонстрирован

на Sprint Review Meeting

done=модуль полностью реализован и выгружен для использования

Как видно, любое описание начинается с “done=”, что дает понять на что обращать внимание.

Вообще, принято в листе писать такие результаты, которые можно проверить. Нет смысла

описывать мысли, ведь скажем «done=придуман внешний вид интерфейса корзины» звучит

странно и никак это проверить нельзя.

47

Желательно изначально разработать список правил, которые будут описывать Definition of

Done, чтобы все в команде писали в одном стиле. Это приведет к более быстрому пониманию

того, что хотел передать коллега.

Еще одним из знаменитых способов записи Definition of Done — является простой список.

В заключении хочется сказать, что не стоит пренебрегать Definition of Done ведь это приводит

не только к осознанию того, что было сделано, но и к тому как это нужно сделать в будущем.

Благодаря использованию Definition of Done все будут стараться делать задачи более четкими

и конкретными, чтобы потом гордо сказать: «Точно сделано!». Помимо этого, набор рейтинга

в Velocity будет гораздо выше.

48

Product Backlog

Как-то в статье о Sprint мы писали, что это основа методологии Scrum и всё вокруг него

крутится. Сегодня самое время сказать:

«А сам Sprint то крутится вокруг Product Backlog и производной – Sprint

Backlog!».

На самом деле Product Backlog должен быть понятен абсолютно всем (за что и

отвечает Product Owner). Прозрачность Product Backlog помогает разобраться в нем как

команде, так и заказчику. Сделать его таким – сродни искусству. Порой заказчики и

специалисты говорят совершенно на разных языках и данный «языковой барьер» главным

образом мешает работе, а еще более того таит в себе опасности. Если где-то какое-то

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

то по прошествии спринта будет готовый продукт, который представьте себе сильно ушел в

сторону. Малейшее отклонение в ядре продукта может привести к его неисправимой

эволюции в другую сторону, так как весь остальной код может базироваться на ошибочном

изначальном.

Сам Product Backlog состоит из элементов беклога или как модно называть User Story. По

сути это список желаний, или на сленге разработчиков – «хотелок». Сами эти хотелки

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

выглядит:

I

D Название

Важност

ь

Начальная

оценка Демонстрация Релиз

Приме

чание

1 Создание корзины

покупок

50 13 Зайти на страницу товара, добавить товар в

корзину. Зайти в корзину, показать, что товар

добавлен. Перейти на другой товар, добавить

его, вернуться в корзину и

продемонстрировать, что добавлены два

товара, есть отображение цен продуктов,

общая сумма. Показать как оформить заказ

дойдя до стадии оплаты.

1

49

2 Подключить

электронную кассу

для оплаты товара

(название

подключаемой кассы)

45 21 Проделав демонстрацию работы корзины –

оплатить товар.

1

Расшифровка полей Product Backlog:

ID – всем разработчикам тут всё понятно. Уникальный номер задачи, который идет по

порядку.

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

всем.

Важность – В каком порядке выполнять задания, чтобы как можно скорее строился готовый

продукт, а потом только расширялся и улучшался. Каждая компания делает свои стандарты

по шкале оценок. Например, может быть от 10 до 150.

Изначальная оценка – Пока это просто примерное значение, которое накидал Product Owner,

но по сути, оно может конечно же меняться. Просто, когда команды работают достаточно

долго вместе над похожими продуктами, то Product Owner понимает сколько требуется

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

при помощи Planning (Scrum) Poker.

Демонстрация – Чтобы доказать законченность работы – надо продемонстрировать

результат. Что хочет видеть Product Owner и заказчик? Это и необходимо описать в данном

поле.

Релиз – по сути, это наглядная демонстрация что хотелось бы видеть после первого спринта.

По мере очков важности, бывает тяжело определить на чем остановиться если есть какие-то

пограничные состояния. Например, Product Owner по Velocity знает на что способна команда

и как идет её работа. Он рассчитывает по Story Points и по Важности сколько примерно

команда сможет выполнить за одну итерацию. Бывает так, что вроде следующий пункт уже

выходит за рамки возможностей команды согласно Velocity, или наоборот можно еще что-то

50

впихнуть, но стоит ли? Product Owner может оценить, что для логичной законченности

продукта на эту итерацию скажем не надо делать пункт, который еще можно включить и

ставит на нём Релиз 2.

Примечания - Всегда полезно иметь эту графу. Она может быть пустая, а может расширять

понимание задачи.

На самом деле в Product Backlog могут быть и другие поля, расширяющие понимание

задач и всего проекта:

Тематика – К какой теме или категории относится та или иная задача. Это необходимо для

разделения задач на тематические блоки. Иногда это помогает даже в групповой оценке.

Скажем стало решено, что оценка товара сейчас не нужна или точнее не важна, а в оценку

товара входят пара задач. Тогда можно по этой тематике изменить важность для всех задач

категории.

Компоненты – Разработка чего-либо так или иначе связано с какими-то компонентами

производства. В программировании это, например, могут быть: база данных, файловый

сервер, API и так далее, в других каких-то направлениях свои компоненты. Такое разделение

очень полезно если используются несколько команд. Таким образом команды могут поделить

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

книге Джеффа Сазерленда приводился пример, который отражает одну из основ методологии

Scrum. Данный пример заключается в написании последовательно цифр и букв.

1 I A

2 II B

3 III C

4 IV D

5 V E

51

Сначала необходимо попытаться написать это всё по строчкам: 1 I A, 2 II B, 3 III C, 4 IV D, 5

V E – и засечь сколько времени это займет. Можно представить, что арабские цифры – работа

с базой данных, римские – с файловым сервером, буквы – это API. То есть вам нужно сначала

сделать что-то по базе, потом по файлам, потом по API. Теперь по тесту нужно написать всё

тоже самое только по столбикам: 1 2 3 4 5, I II III IV V, A B C D E. Так конечно получится

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

другую, и он на автомате работает гораздо лучше в одной системе координат.

Привязываясь к данному примеру с компонентами, представьте, что у команды есть

возможность работы не с такими данными: 3 III C, 5 V E, а скажем с такими: 1 2 3 4, A B C.

Такая работа будет намного продуктивней.

Инициатор задачи – Как известно, ответственный за Product Backlog – Product Owner, однако

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

знать с кем по этому поводу общаться.

ID взаимосвязь – Связь с чем угодно. Бывает, что нужно завязать задачи беклога с какими-то

сторонними или внутренними сервисами, например, отдельный баг-трекер.

Возвращаясь к разделению на категории всегда возникает вопрос: а как поступать если

несколько команд разработки? Сделать для каждой своего Product Owner и свой Product

Backlog? Лучше может иметь один Product Backlog и одного Product Owner?

На само деле существуют разные подходы, используемые компаниями.

52

Подход №1 – один Product Owner и один Product Backlog

Такой подход похож на ситуацию, когда капитаны команд в

какой-либо игре отбирают себе игроков. Сначала один капитан

выбирает себе самого сильного игрока, потом второй самого

сильного из оставшихся и так далее. Здесь происходит похожая

ситуация. Product Owner располагает задачи из Product Backlog в

порядке важности и команды начинают разбирать себе задачи

также в порядке важности. Деление обычно происходит по

тематике (для этого удобно использовать соответствующую

графу в Product Backlog).

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

приоритеты.

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

есть своим Sprint Backlog.

Подход №2 – один Product Owner и несколько Product Backlog

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

Product Owner. Тут конечно сразу возникают резонные

замечание, одно из которых – «Зачем Владельцу продукта

распределять задачи по командам? Команды сами лучше решат

кто что сделает, ведь Product Owner может не знать тонкостей

реализации.» и это заслуженно. Однако, в некоторых случаях

рабочего процесса, это может вполне работать. Благодаря

такому подходу сама подготовка и формирование Sprint Backlog

происходит значительно быстрее. Если на каком-то производстве заранее известно какой

команде какой набор лучше дать – этот способ подойдет как нельзя лучше.

53

Подход №3 – несколько Product Owner и несколько Product Backlog

Существует даже такой подход и некоторые его используют.

Если быть честным, такой подход по большей степени пригоден

для каких-либо узких направлений, когда точно известно, как

распределяется разработка или она состоит из глобальных

модулей, которые между собой стыкуются в самый последний

момент.

54

Sprint Backlog

Sprint Backlog является соответственно набором задач, выбранных на исполнение в текущий

спринт. В статье Product Backlog мы писали про поле «Релиз», которое как раз призвано

отсекать список задач и переносить их в Sprint Backlog.

Изначально, вся эта информация по релизам (то, что должно попасть в какой Sprint Backlog)

выставляется Product Owner, однако решение по приему работы в Sprint останется

за Development Team.

Стоит, однако разобраться в том, как команда принимает решение о внесение той или иной

задачи в Sprint Backlog и как Product Owner может влиять на свои желания.

55

Производительность команды при создании Sprint Backlog

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

сюрприз, например, то что он планировал включить в первый релиз – завершить в первом

спринте, не входит по производительности.

Как видно из рисунка, одна задача из первого релиза не влезает. Что в этом случае может

сделать Product Owner?

Изменение приоритетов для Sprint Backlog:

Одним из вариантов является изменение приоритетов задач. То есть задача, которая не вошла

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

56

команда обязана будет её включить). Минусом такого подхода является то, что так и так одна

задача выйдет за рамки.

57

Изменение объема работ для Sprint Backlog:

Если у Product Owner нет желания исключать какую-либо задачу методом перестановки, то у

него есть еще вариант изменения объема работ. Многие задачи имеют различные дополнения

и улучшения уже из коробки и Product Owner обычно их сразу и вносит, так как работа над

одной задачей даже, более расширенной пройдет быстрее, чем постоянное переключение

между различными задачами и возвращение к старым. Если задачи из первого релиза не

влезают, то можно постараться ужать объем работ по каким-либо задачам.

58

Дробление задач для Sprint Backlog:

Если Владелец продукта не желает ужимать объемы работ, то ему остается только разбить

какую-либо задачу на две и вторую часть задачи оставить на второй релиз. Это конечно же

может быть и не та, что не влезает. Обычно разбивают ту задачу, которая легко поддается

такому действию.

59

на данной встрече.

60

Еще немного вглубь методологии

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

эффективность работы по Scrum. Проблемой обычно является корректная оценка сложности

задачи и для этого, например, существует Planning Poker (Scrum Poker). Для

взаимодействия нескольких команд Scrum - Scrum-of-Scrums. Также существуют и другие

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

так, например, Stakeholders Scrum / Заинтересованные стороны в Scrum и Management

Scrum / Менеджмент в Scrum.

61

Planning Poker (Scrum Poker)

Planning Poker или Scrum Poker пожалуй одно из важнейших мероприятий в методологии

Scrum или любой гибкой технологии разработки. Практически всегда перед командой встает

вопрос:

Как оценить эту задачу?

Оценка трудозатрат будет влиять на целую цепочку зависимостей. От сложности работы

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

которые должен будет заплатить заказчик. Пожалуй, каждый из членов Scrum Team может

оценить ту или иную задачу лучше других, особенно если она лежит в области его

профессиональной деятельности. Сама методология Scrum, в выполнении той или иной

работы, уводит нас из области личной ответственности в область коллективной. Логично при

этом считать, что и оценивать ту или иную задачу, за которую несет ответственность вся

команда, должна вся Scrum Team. Более того, такой подход поможет более точно определить

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

причинам.

Что собой представляют карты для Planning Poker / Scrum Poker

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

например, означающие количество дней на разработку.

Есть несколько вариантов карт, которые пользуются большой популярностью.

1 вид популярной колоды для Planning Poker:

Карточки представляют собой последовательность чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34,

55, 89.

2 вид популярной колоды для Planning Poker:

Данный вид имеет следующие значения: 0, ?, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?», «Чашка кофе».

Знак вопроса означает, что «игрок» не понял до конца смысл обсуждаемого или не обладает

62

достаточно информацией, чтобы оценить её. Чашка кофе в свою очередь означает «Я устал,

давайте передохнем».

Как проходит Scrum Poker / Planning Poker

1 человек является ведущим, и он не учувствует в «игре». На обсуждение выносятся

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

провести обзор без оценочных данных. После этого каждый член команды выбирает карточку

и кладет её рубашкой вверх. После того, как все положили карты – они вскрываются.

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

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

наибольшие значения. Людям, выбросившим такие карточки, дают слово, и они высказывают

свое мнение, почему оценка была именно такой. Это позволяет больше информации получить

всей остальной команде и задуматься, услышав доводы, либо объяснить выбросившим

высокие или низкие позиции свою точку зрения.

После этого карты выбрасываются снова и обычно разрыв уже сокращается, однако если

этого не произошло, то цикл повторяется. В данном случае рекомендуется ввести таймер на

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

показатели примерно одинаковые. Если имеются небольшие расхождения, то приоритетней

показатель человека, который непосредственно будет в разработке этой задачи.

Основные проблемы в использовании Planning Poker

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

так и Planning Poker имеет четкие предписания, которые не позволяют делать ошибки и

сводить на нет внедрение этого усовершенствования рабочего процесса.

Эффект привязки в Scrum Poker

Главной проблемой всегда был эффект привязки, который может проявлять себя по-разному.

Главной ошибкой, вызывающей этот эффект, является открытое обсуждение оценок. Если

тот, кто начинает обсуждение говорит примерно следующее: «Я считаю, что данное задание

63

займет 18 часов разработки», то так или иначе все будут акцентированы на сроке в 18 часов, и

тот, кто считал, что задача будет решена за 2 дня, может подумать, что на самом деле и 18

часов будет достаточно, а тот, кто думал про 5 часов, может подумать, что недооценил. С

одной стороны, консенсус достигается быстрее, но с другой стороны он не будет

эффективным, а эффективность – это то, для чего мы всё это делаем. В такой ситуации

больше в результат войдет мнение одного человека, а не команды.

Не выделяться из толпы

Второй знаменитой проблемой бывает ситуация, когда оценки выставляются не

одновременно. В такой ситуации кто-то конечно выскажет свое мнение, но с другой, человек

сомневающийся решит бросить карту, которая ближе к тем что есть. К примеру, опять, кто-то

решил, что задача займет 18 часов, а до него двое выкинули по 5 часов, и логично

предположить, что данный человек быстро среагирует что оценил не так и так выделяться не

стоит и бросит не то, что хотел изначально.

64

Описание Scrum of Scrums

Понятие Scrum-of-Scrums актуально для компаний, в которой находятся несколько команд

разработки, и они работают над одним проектом. В статье про Sprint Backlog есть описание

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

чтобы не было никаких проблем с выполнением несет Scrum Master, а сама Development

Team в свою очередь несет ответственность перед Product Owner, чтобы все задачи

выполнялись.

Ведя свою команду к цели спринта можно её успешно довести, но при этом упустить что

происходит на уровне продукта, а порой это бывает так, что из-за этого нарушается

целостность всей разработки.

Представьте, что вы едете на автомобиле в сторону цели, параллельно едет еще одна команда,

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

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

команды, довезли его в сохранности.

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

проделанной работе и ближайших планах. Одним из важных плюсов таких встреч – со

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

65

Stakeholders Scrum / Заинтересованные стороны в Scrum

Если прочитать статью про Sprint Planning Meeting, то в самом начале можно встретить фразу

про некие заинтересованные стороны:

Одно из самых важнейших мероприятий в методологии Scrum – это конечно же

Sprint Planning Meeting. В данном мероприятии принимают участие владелец

продукта, Scrum Master и вся команда разработки. Иногда происходит и участие

внешних заинтересованных сторон, однако это бывает редко.

Если сказать грубо, то название Stakeholders обозначает всех тех, кто имеет интерес или долю

в проекте. Это могут быть непосредственные руководители или, например, лица,

финансирующие проект. С этой стороны их даже можно назвать менеджерами проекта, что

конечно для методологии Scrum звучит странно, однако это так. Традиционное управление

подвластное менеджерам проектов здесь конечно отсечено, однако есть то, чем команда

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

закупками, плана обеспечения качества и так далее, собственно всё то, что необходимо для

нормального функционирования компании. Stakeholders можно представить, как некую

склейку между инновационной системой Scrum (со своими нюансами управления проектами)

с функционированием компании в целом.

Основные обязанности Stakeholders:

взаимодействие с Product Owner по вопросам развития и поддержки Product Backlog;

посещение Sprint Planning Meeting по необходимости для обеспечения обратной связи;

осуществление обратной связи c командой на Sprint Review Meeting;

удаление препятствий в работе команды, владельца продукта и скрам мастера;

обеспечивает спокойную работу команды (оберегает от отвлечения) во время Sprint, а

если быть точнее – сразу после того, как команда начинает готовиться к Sprint.

66

Management Scrum / Менеджмент в Scrum

Понятие менеджмента для непосредственно Scrum Team более размыто и не так важно, как

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

выполняет Product Owner. Можно сказать, и так, но от части. Обычно в традиционном

понимании у менеджера проекта нет таких обязанностей как у Product Owner.

Так как понятий менеджера или вообще менеджмента очень обширное, то и в Scrum оно

носит некий образ оболочки, которая обволакивает весь процесс работы Development Team,

но никак на него не влияет. Development Team вообще не контактирует с Management, а для

контактов могут выступать Scrum Master, Product Owner, Stake Holders и другие. К примеру,

для решений каких-то проблем, мешающих работе команды, Scrum Master может обратиться

к финансистам. С одной стороны – финансисты не являются менеджерами в прямом смысле,

однако сейчас они выступают в качестве обслуживания работы Development Team.

Чтобы понять подобную структуру, взгляните на рисунок

67

Оценки эффективности

В самом конце, пожалуй самое важное – определение эффективности работы. Как бы хорошо

не шла работа во время спринта, мы не знаем на сколько. Контроль эффективности просто

необходим, так как усовершенствование работы команды лежит в основе Scrum. Во время

спринта нам активно помогает Диаграмма сгорания задач, а отследить эффективность

между спринтами – Velocity.

68

Диаграмма сгорания задач / Burndown Chart

В большинстве своем мы привыкли к графикам идущими вверх, что означает положительную

динамику, однако они могут идти и вниз, и также показывать положительную динамику.

Одним из таких ярких примеров является Диаграмма сгорания задач (Burndown chart). Само

сочетание Burn Down дословно переводится как «гореть вниз» и действительно это так.

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

спринте или во всем проекте. Хотя по сути он может использоваться как угодно, но мы его

рассматриваем внутри методологии Scrum.

Пример Диаграммы сгорания задач:

Синим на диаграмме сгорания отмечена идеальная линия выполнения задач, на которую и

следует опираться.

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

69

По шкале Y отмечают количество запланированных баллов (в данном случае), идеальные

часы, количество задач и так далее.

По шкале X отмечают количество дней до окончания Sprint.

Как может показаться на первый взгляд – данная Диаграмма сгорания задач / Burndown chart

служит всего лишь для самоконтроля и самоотчета, однако ее использование может

рассказать об очень многом.

Читаем Диаграмму сгорания задач / Burndown chart

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

команды и закончим более качественными.

1. Burndown Chart: Слишком рано

70

По Диаграмме сгорания задач / Burndown chart отчетливо видно, что команда все задачи

выполнила раньше срока. Такая ситуация тоже не является позитивной, так как это означает

ряд совершенных проблем:

Команда сделала неправильную оценку предстоящей работы;

В случае быстрого выполнения задач, разработчики не добавляли задачи из следующего

спринта;

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

В случае такой проблемы, чаще всего Scrum Master спрашивает команду о возможности

добавления дополнительных задач из Product Backlog.

2. Burndown Chart: Опоздали

Также один из видов негативных диаграмм сгорания задач.

71

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

спринта, что увеличило нагрузку.

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

Такие задачи, как выразился Джефф Сазерленд – являются хламом.

В такой ситуации, на Daily Scrum Meeting обязательно нужно говорить о проблемах,

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

надо решать проблему – это также один из постулатов методологии Scrum.

3. Burndown Chart: Без оценок

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

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

эффективной работе. Команда не может контролировать себя, не может совершенствоваться и

так далее.

72

4. Burndown Chart: Конечная оценка

Собственно, ситуация равна предыдущей. Не смотря на законченный Sprint, все итоговые

оценки были внесены в диаграмму сгорания в самый последний день после завершения

работы. Это равносильно тому, когда вообще законченные задачи не вносятся. По данному

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

можно предположить, что команда не стремится к развитию.

73

5. Burndown Chart: Zero

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

не производилась, ведь она могла быть просто не оценена. Как и в предыдущих пунктах,

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

совершенствоваться.

74

6. Burndown Chart: Релаксирующая команда

Этот пример диаграммы сгорания задач уже значительно лучше нежели другие, ведь в нем

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

в пункте «Слишком рано», но Scrum Team решили не заканчивать Sprint раньше, а более

расслаблено продолжить работу, что также является ошибкой.

75

7. Burndown Chart: Совершенствование

Scrum Team на текущих показателях выглядит достаточно хорошо. По линиям видно, что в

самом начале были трудности, но вовремя Daily Scrum Meeting все вопросы вскрывались

и Scrum Master исправлял работу ведя команду к цели.

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

Еще одной причиной, к примеру, может быть то, что команда брала дополнительные задачи.

76

8. Burndown Chart: Опыт

На лицо опытная группа, которая после начала работы, сразу исправляет все возникающие

трудности и совершенствуется так, что резко переходит к активному сжиганию.

77

9. Burndown Chart: A++

Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как строится

идеальный график =).

78

Velocity Scrum

Если представить себе движение автомобиля, то скорость в нем оценивается по спидометру и

тогда всё предельно ясно. Однако в жизни в целом и в каком-то конкретном деле нет

спидометра и как оценить скорость объективно уже вопрос. Если представить, что на

автомобиле сломался спидометр, то скорость может быть оценена постфактум, то есть когда

человек будет ехать 60 минут и проедет, например, 100 км, затем опять пройдет 60 минут, но

проедет 120 км, то он будет видеть с какой скоростью он двигался – около 110 км/ч. При

этом, если во время следующих 60 минут он остановится и потратит на заправку 12 минут, на

обед 15 минут и проедет 55 км, то средняя скорость за весь путь составит – 98 км/ч.

79

Как и в движении на автомобиле, скорость можно измерять и в Scrum, и называется это

Velocity (скорость). Расчет Scrum Velocity очень простой и также состоит из поставленных

отметок, как через каждые 60 минут было какое-то количество километров.

Для примера предоставим график Velocity отображающий по горизонтальной оси количество

Sprints, а по вертикальной Story Points.

В таком графике по сути изображено Story Points и на основе этих показателей

выстраивается среднее значение скорости. Однако график Velocity может быть и иной, с

простым отображением Story Points, на основе которых визуально видна тенденция.

80

Если быть кратким в сравнении с движением по дороги, то список ассоциаций, влияющих на

скорость может быть такой:

Дорога - она же препятствия

Топливо - мотивация, что движет нами

Опыт водителя - знание / опыт / компетенция разработчик

Условия для автомобилей - DEV среда

Видимость - прозрачность проекта

Направление - цели проекта

Трафик / правила вождения - процессы

Пункт назначения – продукт

Хочется, однако отметить, что по поводу метрики Velocity в Scrum ходят споры, и кто-то

считает данные графики не очень полезными и сложными в определении возможных

81

проблем, да и самого разгона. В целом все сходятся во мнении, что Velocity должен

использоваться специалистом, как дополнительное наглядное отображение эффективности,

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

аналитическую работу Scrum Master.

82

Date post:	16-Apr-2017
Category:	Leadership & Management
Upload:	scrum-time
View:	394 times
Download:	0 times

Книга Scrum Time

Leadership & Management