Dod scrum что это
Синхронизация команды со SCRUM
Как мне кажется, одна их самых больших проблем в скраме — это полный рассинхрон между людьми в команде. Мне пока не удавалось увидеть ни одного стабильного решения этой проблемы. Конечно, есть стандартные инструменты, но далеко не всегда они дают ответы на все вопросы и закрывают все дыры.
Предлагаю зайти к нам в гости и посмотреть как с проблемой синхронизации внутри себя борется команда “Онлайн-ипотеки” компании “Альфа-Банк”.
Статья была подготовлена членами нашей команды: Марина, Дима, Настя, Вероника, Толя.
Не так давно (чуть более полугода назад) в Альфа-Банке стартовал новый проект — «Онлайн-Ипотека». Команда под проект собиралась с нуля. Люди на проект пришли разные и с разных мест работы. Все было прямо по гайду: DevTeam (JS, Java, QA, Аналитик), скрам-мастер и Product Owner. Никто из девтим до этого никогда не работал по скрам-фреймворку.
Первая точка синхронизации: DOR
Итак, мы все собрались, познакомились и почти сразу приступили к делу. Впереди нас ждало множество неочевидных (на первый взгляд) идей. Большинство из них впоследствии стали обыденными и логичными. Но вот что мы долгое время не могли побороть — это мнимая понятность задач. Часто бывает так, что берешь задачу в спринт, а она оказывается не так проста (а иногда и сложна), как казалось на первый взгляд.
Рассинхрон для нас заключался в следующем:
Опыт оказался крайне успешен. Мы стали действовать более слаженно и более продуктивно. На грумингах мы держали DOR перед глазами и использовали как чек-лист при разборе задачи. PO почти всегда узнавал заранее, чего не хватает задаче, и старался как можно скорее уточнить информацию. Иначе такая задача просто не попадала в следующий спринт.
Нам приходилось брать спайки (исследования) из верхних задач в общем бэклоге (backlog) в спринт, но это приносило колоссальный результат. Неопределенность снижалась, и мы начали корректно оценивать трудоемкость задачи.
Тут стоит отметить, что DOR у каждой команды должен быть свой. Дело в том, что он не должен представлять собой набор четких указаний от работодателя. Это скорее требования команды к минимальному описанию задачи и проработке подводных камней, которые должны быть выполнены для удобства и ускорения работы.
Критерии готовности user story к взятию в работу
Вторая точка синхронизации: DOD
Очень хорошо, когда вся команда понимает, какие задачи мы можем помещать в спринт, а какие лучше не стоит. После выполнения условий DOR мы столкнулись со следующим: мы берем задачу (user story) в работу, но как мы можем понять, что она точно готова?
Конечно, мы можем посмотреть на все саб-таски (sub task) и оценить готовность задач по ним. Но что, если мы не завели саб-таску по документации, тестированию или настройке доступов? Есть ли необходимость каждый раз заводить подобные саб-таски?
Ну хорошо. Допустим, мы идеально заводим саб-таски и идеально вовремя их закрываем. Тогда логично было бы закрыть задачу сразу после мерджа в мастер. Но ведь задача еще не на бою! Пользователь не увидит пользы от нашей работы, и все было зря.
Первое время мы спорили о факте закрытой задачи. После чего мы приняли какие-то не совсем формальные правила. Это сильно упростило работу, но время от времени все же конфликты возникали. Тогда мы пришли к следующему стандартному шагу синхронизации.
DOD (Definition Of Done) позволяет решить проблему приемки и общего понимания готовой задачи. DOD очень похож на DOR. Это такой же набор критериев, но на этот раз для готовой задачи. Взглянув на него, мы всегда можем сказать: готова задача или нет.
В результате мы выработали общее понимание того, что надо сделать, чтобы считать задачу закрытой. Только после выполнения всех пунктов задача переходит в DONE.
Подводим итоги первых двух шагов синхронизации
Отлично! Работать стало гораздо удобнее. Мы больше не тратим время на ненужные формальности о разговорах, какая задача готова, а какую стоит еще доработать. С другой стороны, мы больше не боимся брать задачи в спринт. Но что происходит между этими событиями? Раздор, разруха и хаос.
Аналитик не всегда может изначально проверить все задачи в спринте. Один из разработчиков может сделать изменения (без возможности откатиться), которые коснутся другого разработчика. В конце концов, PO тоже люди, и задачи могут меняться в ходе спринта, даже если это сильно не приветствуется в скраме.
На самом деле есть целая масса случаев, которые могут привести к конфликтам и непродуктивной работе между этапами взятия в работу и завершения задачи (для краткости — DOR и DOD). В любой команде почти всегда можно видеть одну и ту же проблему. Кто-то что-то куда-то залил, и второй разработчик теперь страдает. Это провоцирует конфликты и негатив. И, конечно, эта проблема почти всегда возникает, когда одной задачей занимаются несколько разработчиков.
Вначале мы пытались найти что-то из уже существующего вроде DOR и DOD. К сожалению, ничего подобного и подходящего к нам мы не нашли (может быть, плохо искали). Пробовали 1 work in progress, но опыт не удался. Каждая задача состоит из разнородных частей. Наш опыт показал, что при таком подходе кто-то из разработчиков всегда скучает, а кто-то вынужден задерживаться на работе и доделывать свою “половинку”. Не так давно мы собрались и подумали над еще одним промежуточный этапом:
Третья точка синхронизации — наша собственная задумка: DOT
DOT (Definition Of Test) представляет собой набор критериев тестирования задачи и сборки ее в единое целое на тестовом стенде. Также мы устанавливаем правила о том, что девтим не может приступать к дальнейшим действиям (pull requests и тд), пока DOT не будет выполнен полностью.
Взглянем на рисунок и попробуем разобрать идею более подробно. Для начала представим, что у нас имеется только один разработчик на одну задачу:
Сразу отметим здесь ключевую особенность. У нас есть то, что должно быть сделано, и то, что делать нельзя до выхода из зоны тестирования. Сюда можно отнести прохождение pull request, мердж в мастер, выкатку и прочее.
Сразу стоит отметить отличие от DOR и DOD. Когда мы говорим про DOR, мы говорим о том, что нужно для решения задачи. При разговоре о DOD, мы говорим какую задачу можно считать сделанной. В DOT на нас влияют сразу несколько видов обстоятельств. С одной стороны, разработка задачи должна быть завершена. С другой, многие действия для доведения задачи в полностью готовый вид делать не стоит.
По-настоящему раскрывает себя идея в случае нескольких разработчиков с одной задачей. Посмотрим на такой случай. В нашем примере у нас будут фронт и бэк:
Схема очень примерная. Понятно, что у нас один специалист может помогать (или мешать) другому. Необходимость доработать задачу может всплыть раньше. А выкаткой на бой может заниматься другой человек. Главное тут другое. У нас есть некая область с четко оговоренными ДО и ПОСЛЕ. Более того, ПОСЛЕ не может наступить, пока не будут выполнены все условия DOT. И только после этого можно получить ОК от тестирования.
Что еще тут важно? Как видно из картинки, разработка может начинаться в разное время. Самое главное тут то, что в область тестирования входят несколько разработчиков в разное время, но выйти из нее они могут только вместе. Чем они будут заняты в это время — можно договориться.
После того как задача полностью протестирована, все разработчики получают волшебный ОК от тестирования, и теперь уже стартуют из одной точки. Интересно, что здесь крайне мала вероятность каких-то недочетов в синхронизации. Оставшиеся действия занимают примерно одинаковое время.
Потребностью DOT является необходимость жесткой синхронизации разработчиков между собой. В одну область входят несколько разработчиков в разное время, но выходят всегда в единой точке.
Минусом такого подхода является дополнительное время на продумывание организации задач на этапе формирования. Но на самом деле такие затраты легко окупаются. При этом, задачи становятся более структурированными и прогнозируемыми.
Критерии Готовности [Определение Готовности] (Definition of Done)
Критерии Готовности — это требования качества, предъявляемые к продукту и его Инкрементам — описание того, что нужно сделать, чтобы считать завершенной работу над будущими Инкрементами и реализованными в них Элементами Бэклога Продукта.
Критерии Готовности играют роль сommitment’а для Инкремента (в русской версии Scrum Guide термин сommitment переведен абстрактным словом «приверженность»). Commitment есть у каждого из трех артефактов Скрама и способствует понятности артефакта и лучшему соответствию между артефактом и конкретной работой Скрам-команды. В частности, Критерии Готовности помогают Скрам-команде оценивать, проверять и доводить работу над Элементами Бэклога до конца.
Определение Критериев Готовности звучит похоже на Критерии Приемки, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов и Инкрементов в целом.
Руководство по Scrum версии 2020 года следующим образом описывает назначение, содержание и применение Критериев Готовности (в этой версии термин Definition of Done впервые переведен как Определение Готовности, но мы пользуемся русским переводом, сложившимся за 10 предшествующих лет):
Критерии Приемки (Acceptance Criteria)
Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.
Цель Продукта описывает будущее состояние продукта, которое может выступать в качестве конечной цели, используемой Скрам-командой при планировании работы. Цель Продукта входит в состав Бэклога Продукта и играет в нем роль сommitment’а.
Цель, которая ставится на Спринт, и может быть достигнута через выполнение Элементов Бэклога Спринта. Она описывает то, для чего создаётся Инкремент Продукта.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Definition of Ready — то, о чем нам забыли рассказать
Введение
Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.
Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.
На Definition of Ready далее по тексту — DoR я наткнулся случайно, в профильном чате, который посвящен Agile. Попытавшись найти информацию, не нашёл ни одного упоминания в рунете на эту тему. Поэтому отправился читать и переводить англоязычные статьи. Теперь делюсь с вами результатом, надеюсь это поможет сделать вашу команду, еще круче и продуктивнее.
Что такое DoR
И так, что же такое DoR? Google переводчик подскажет, что это «определение готовности». Если DoD включает в себя критерии завершенности задачи, то DoR — критерии готовности задачи к взятию в работу. То есть, если задача, отвечает критериям из DoR, команда может взять её на планировании в работу. Вроде бы просто, вы уже наверняка начали придумывать как наконец то вместе с командой составите целый список требований для вашего PO, чтобы тот стал писать тонну документации, а остальные члены команды спокойно смогли сидеть за своим компьютером, и молча писать код. Это только начало, и DoR не то, чем кажется на первый взгляд.
Зачем нужен DoR
Сначала ответим на вопрос: зачем нужен этот артефакт? Какую пользу он принесет команде? DoR поможет команде:
Давайте взглянем на список проблем, которые косвенно, или напрямую вытекают из-за отсутствия DoR:
В конце концов, это приводит к выпуску продукта, который не рабочий, бесполезный, не решает первоочередной проблемы. А это в пустую потраченное время, которое каждый желает тратить на важные вещи. В одной из статей, я встретил отличное высказывание: «Мусор вошёл, мусор вышел».
Где применять DoR
DoR используют на Product Backlog Refinement далее по тексту PBR или более привычное название артефакта: Grooming. Во время этой активности, User Story становятся готовыми — Ready. Это означает что результатом мероприятия, в Бэклоге продукта, будут Ready US. DoR нужен чтобы описать состояние, при котором US, можно обсуждать на планировании. Это называется Takin in — принятые US.
Чтобы пойти дальше, обращаю внимание, как Джефф Сазерленд, один из основателей Scrum и Agile манифеста, рассказывает о DoR и DoD в своих видео. Сазерленд вводит понятия Done-Done, и Ready-Ready. Когда член команды говорит что задача готова или выполнена, подразумевается, что она соответствует тем критериям, которые команда определила в DoD и DoR соответственно. Это важный аспект, каждый член команды должен понимать его, и не забывать. Иначе возникают смешные ситуации, когда на Daily Петя будет рассказывать что задача уже выполнена, а потом выяснится, что там ещё тесты дописать надо, и было бы неплохо выполнить рефакторинг кода, да и Code Review ещё не проходили.
Таким образом, пока US не достигнет состояния Ready-Ready, она не существует, и не обсуждается на планировании. Верхняя часть бэклога должна состоять только из US, с состоянием Ready-Ready. Лучший способ добиться этого, прорабатывать US вместе с командой. Это позволит взглянуть на задачу с разных сторон, вовлечь в процесс каждого члена команды, и впоследствии развить коллективную ответственность за выпускаемый функционал. Разработчики буду сами отвечать за результат и качество, если осознают, что это плод «их» совместной работы.
Когда применять DoR
Когда команда понимает во время PBR, что задача не соответствует DoR, и несет с собой слишком много неопределенности, составляйте список вопросов, выбирайте исследователя, и откладывайте задачу до следующего PBR. В моей команде, это называлось Research, но впоследствии мы перешли на Spike из XP, так как посчитали что это приносит больше результата и ясности по итогу исследования. Обязательно ограничивайте исследование по времени, и обозначьте результат, который хотите получить по итогу. Во время Spike исследователь может привлечь любую помощь со стороны, например участников других команд, методологов, PO, архитекторов… в общем любого, кого посчитает нужным. Результат — ответы на вопросы, новые данные, прототип. Если таких User Story много, в каждый спринт можно брать по 1-2 Spike, на следующие итерации, таким образом обеспечите постоянный поток Ready задач.
Как уже упоминалось выше, DoR — набор критериев. Команда может попробовать сама составить эти критерии. Проработайте те “сигналы”, которые прослеживаются в итерациях. Обсудите на ретроспективах эти моменты, найдите глубинную причину. Если нет желания тратить следующую ретроспективу на это, воспользуйтесь готовыми решениями.
Во многих статьях описывается модель INVEST, которая похожа на SMART, но более подходит для User Story. Помимо статей, данную модель так же рекомендуют и в Agile литературе. Например Роман Пихлер в книге “Управление продуктом в Scrum” или Майк Кон — “Пользовательские истории. Гибкая разработка программного обеспечения”.
INVEST модель
Заключение
В заключение: используя DoR, вы не избавитесь от пробелов, которые будут просачиваться в спринт. Так же это не означает, что во время спринта отпадает необходимость постоянного контакта PO с разработчиками. Постоянно фиксируйте результаты обсуждений в виде приемочных тестов, так никто из команды, не потеряет понимание статуса задачи. Проанализируйте и обсудите с командой текущие проблемы, возможно они связаны с отсутствием DoR.
DoR — артефакт, который позволит команде лучше продумывать US, что в конечном итоге снизит риски, и позволит побудить каждого члена команды к постоянному обсуждению задач. Много развернутой информации о INVEST, и User Story, вы найдете в книге «Пользовательские истории». Рекомендую дать прочитать эту книгу каждому члену команды, или хотя бы прочитайте сами и поделитесь с ними информацией.
Напишите в комментариях какие DoD и DoR используются у вас в команде.
Словарик айтишника или Что? Где? Куда? Часть 2
Scrum-терминология
От англ. Definition of Done (дословно — критерии готовности) — список требований, по которым можно считать, что цель выполнена. Например, набор задач, которые должны быть завершены к определенной дате.
Майлстоун
От англ. milestone (дословно — веха) — запланированная дата окончания работ по выборочным задачам. Проставление таких «дат» позволяет не сбиваться с графика и отслеживать процесс работы и понимания выполнения целей.
Сторя
От англ. story (дословно — история) — корневая задача с описанием требований для разработки, она содержит в себе подзадачи, назначенные на разработчиков разных должностей. Это точка входа при разработке какого-либо функционала.
Фасилитатор
От англ. facilitator (дословно — координатор) — человек, берущий на себя обязанности ведущего. Он обеспечивает успешную коммуникацию внутри команды, пытается упростить общение и создает понимание между всеми участниками команды. Термин может использоваться и как существительное, и как прилагательное, и как глагол.
Разработка
Ассайнить
От англ. assign (дословно — поручать) — назначать задачу на человека в качестве исполнителя.
От англ. bug (дословно — жук) — ошибка в коде, проблема, недоработка. Слово уже давно в лексиконе разработчиков, но интересно то, как меняется форма термина. Калька «баг» превратилось в слово женского рода — «бага». В такой форме согласование в предложениях проще. А если ошибка или проблема совсем маленькая, то это багуля.
Грумить
От англ. groom (дословно — чистить) — приводить в порядок. Относится к коду, бэклогу, организации работы. В том же значении используется и русский аналог — «причесать».
Деплой
От англ. deploy (дословно — разворачивать) — процесс интеграции кода из разработческих веток в продуктовую (мастер) ветку. Термин также употребляется и как существительное, и как глагол, и как прилагательное.
Компилить
От англ. compile (дословно — составлять) — собирать написанный код воедино, конвертировать его из одного формата в другой, преобразовывать в требуемый вид для работы в браузере.
Костыль
Временная «подпорка» в коде, которая приводит к нужному результату, но само решение является идеологически неверным.
Лагать
От англ. lag (дословно — отставание) — плохая производительность, притормаживание, работа с ошибками.
Легаси
От англ. legacy (дословно — наследие) — код, написанный определенное время назад и считающийся морально устаревшим. Он всё ещё работает, но вызывает неприятие у разработчиков.
Мерджить
От англ. merge (дословно — слияние) — соединять свою часть работы с частями работы других разработчиков в рамках одной ветки. Сливать всё воедино.
Нативный
От англ. native (дословно — родной) — первоначально заложенное поведение или внешний вид элемента или кода.
Стоимость задачи
Пришедшее из скрама выражение, означающее суммарное количество затрат разработчика на задачу. Вопрос про стоимость задачи буквально означает оценку времени и усилий на неё. Соответственно дорого — долго и сложно, дешево — быстро и легко.
Фейлить
От англ. fail (дословно — неудача) — терпеть поражение, проваливать планы, заваливать что-либо. Чаще используется в разговорной, не технической речи.
От англ. fix (дословно — чинить) — решение проблемы, устранение бага. Термин употребляется и как существительное, и как глагол, и как прилагательное.
Должности
От англ. junior (дословно — новичок) — специалист любой должности, которая предусматривает градацию по уровню знаний. Джун находится на первой (нижней) ступеньке. Человек, знаний, которого хватает для выполнения рабочих обязанностей и разработки в целом, но не обладающий глубиной и широтой знаний.
От англ. lead, сокращенно от TeamLead (дословно — глава команды) — специалист высшей градации, обладающий широтой и глубиной знаний, является лидером команды. Он руководит процессами и помогает решать спорные технические вопросы.
Секопс
От англ. SecOps, сокращенно от Security Operations (дословно — интеграция безопасности) — специалист, занимающийся обеспечением безопасности при имплементации новых решений и безопасностью в целом.
Организационное
Апрув
От англ. approve (дословно — одобрять) — еще одна вариация для одобрения, утверждения или подтверждения чего-либо.
Валидный
От англ. valid (дословно — правильный) — в разговорной речи вариации слова означают согласие с оппонентом, одобрение его результата. Означает правильность решения. Часто заменяет слово «идет» в значении «подходит».
Инпут
От англ. input (дословно — вклад) — в разговорной речи используется в значении внимание, отклик.
Капиай
От англ. KPI, сокращенно от Key Performance Indicator (дословно — ключевой показатель результативности) — единица измерения, которая требуется для того, чтобы понять эффективность какой-либо деятельности.
Пинговать
От англ. ping (дословно — ударяться со стуком) — напоминать кому-либо о чем-либо, давать знать.
Эскалировать
От англ. escalate (дословно — обострять) — поднимать вопрос или проблему на обсуждение, привлекать внешние ресурсы, принимать меры.
И напоследок.
Райкер
От англ. wrike-er — человек, который работает в Wrike и является частью команды компании.
Как считаете, проще ли бы было новичкам, если при выходе на работу им давали расшифровку незнакомых терминов, которые обрушиваются уже в первый день работы? Дают ли ясность подобные расшифровки или только больше запутывают? Поделитесь своим мнением в комментариях.
Мини-справочник и руководство по Scrum
Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Мини-справочник Scrum
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Руководство Scrum
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?