Что обсуждает команда на sprint retrospective митинге
Ретроспектива спринта. Как сделать её интересной и продуктивной?
Для чего проводится ретроспектива в команде? Какова её цель? Прежде всего ретроспектива нужна для инспекции прошедшего спринта применительно к людям, отношениям, процессам и инструментам, а также для адаптации рабочего процесса или продукта.
В процессе проведения ретроспективы команда должна выявить и понять, что в спринте прошло хорошо, а что не очень и по результатам общения попробовать выработать план по улучшению продуктивности и сплочённости.
Каждая команда проводит ретроспективу по-разному и по разным причинам: кто-то для поддержания командного духа, а кто-то для определения недовольства или выявления причин провального спринта. Важно, чтобы ретроспектива, прежде всего, была живым мероприятием. Проведение ретро по стандартным шаблонам, скорее всего, приведет это мероприятие в разряд формальных и, со временем, команда потеряет к ней интерес. Члены команды будут с неохотой участвовать или вообще стараться под различными предлогами избегать ретро.
Для поддержания командного духа и привлечения интереса к данному мероприятию часто приходится придумывать различные форматы, вносить новые идеи и делать ретроспективу интересней и необычней. В этой статье хочу рассказать о тех инструментах, которые я использую и, возможно, вы сможете использовать их у себя в командах. Итак, приступим.
Классическая структура ретроспективы состоит из 5 шагов:
Важно отметить, что проценты могут варьироваться исходя из специфики вашей команды. Рекомендованная длительность проведение ретроспективы — не более 3 часов. Как правило, для двухнедельного спринта команды из 9–12 человек ретроспектива проводится за 1–2 часа.
Перед проведением ретроспективы очень важно подготовить команду к этому мероприятию. Постарайтесь немного отвлечь команду от текущих работ – проведите небольшую разминку. Поверьте, это поможет каждому члену команды “переключиться”, выйти из своего кокона и быть более открытым для общения.
Можно использовать огромное количество разминок. В интернете их довольно много. Но я бы хотел рассказать о тех, которые мне нравятся больше всего.
Необходимо взять стакан / кружку и поместить туда m&m’s или skittles. По очереди каждый член команды вытягивает из стакана по 1 конфете и отвечает на вопрос:
Цвет конфет и вопросы могут быть совершенно любыми.
Если команда собирается в чате / конференции, вместо конфет можно использовать рандомайзер (генератор чисел). Например, вы можете включить демонстрацию экрана в приложении, например: discord, zoom. Называете члена команды и на сайте генерируете случайное число (от 1 до N, где N – максимальное число вопросов). Задаёте вопрос исходя из полученного номера.
Отличная разминка, позволяющая членам команды выражать признательность друг другу. Большинство из нас настолько заняты работой, что забывают благодарить членов команд за помощь или поддержку. Каждому члену команды очень важно чувствовать, что его ценят.
Если вы проводите встречу вживую, то рекомендую заранее распечатать карточки. Если нет времени – можно написать на стикерах какой цвет отвечает за ту или иную карточку.
Шаблоны cudo cards можно скачать тут.
Раздайте каждому члену команды стикеры / карточки. Дайте несколько минут на заполнение. После чего каждый член команды рассказывает что он написал и клеит свои карточки на доску благодарности. Оставьте доску висеть в помещении на некоторое время. Пусть она радует коллег!
Это мероприятие прекрасно подходит как для спринтов, где все прошло хорошо, так и тех, в которых все пошло наперекосяк. В первом случае разминка послужит отличным стимулом для мотивации команды, во втором – напомнит всем, что даже в трудные времена члены команды ценят друг друга.
Хотите провести разминку удалённо? Не вопрос. Можете сделать это, например, в Miro.
Сверху укажите карточки определённого цвета с формулировкой. Дайте команде 10 – 15 минут на заполнение карточек. После чего попросите перенести карточки на доску.
Многие члены команды могут умалчивать о некоторых проблемах во время проведения ретро. Сбор обратной связи (анонимной) поможет разобраться в проблемах, которые видно со стороны, но не “подсвечиваются” при обсуждении.
В качестве сбора обратной связи можно использовать различные опросы или тесты, например:
Быстрый способ собрать обратную связь по спринту.
Запишите полученные результаты в таблицу:
Используйте данные, полученные по результатам опроса, для ретроспективы. Постарайтесь направить команду на обсуждение проблемных зон, а также не забывайте подчёркивать успехи команды.
Тест позволяет оценить взаимоотношения в коллективе, заинтересованность сотрудников в получении результатов и их мотивацию.
Принцип тестирования не сложен. Каждый член команды независимо от должности заполняет вопросник в который входит 84 утверждения. Затем по специальной таблице выполняется подсчет результатов и их анализ.
В данном тесте вопросы могут быть совершенно любые. Постарайтесь вспомнить те моменты, которые не понравились команде на предыдущих planning. Тест позволит понять смогли ли вы решить часть проблем, которые обсуждала команда.
Собирайте статистику для понимания проблем, сильных и слабых сторон команды. Через некоторое время запустите этот же опросник и сравните результаты.
(Начать / Прекращать / Продолжать)
Это метод систематизации мнений позволит команде понять текущие проблемы и предложить варианты их решений.
Каждый член команды должен за отведенное время ответить на следующие вопросы:
(Расстроило / Разозлило / Порадовало)
Это метод хорош тем, что позволяет каждому члену команды выпустить пар и рассказать о наболевшем. Быть выслушанным уже само по себе немаловажно. Но не забывайте, что конструктивный негатив должен быть уравновешен позитивом. Не допускайте “токсичности” в команде.
Базовый ретроспективный метод, который фокусируется на сильных и слабых сторонах вашей команды.
Этот метод хорошо подходит для ретроспективы, когда команда уже давно работает над одним проектом / продуктом.
Простой и понятный метод, которых отлично подойдет, если вам необходимо выделить как положительные, так и отрицательные моменты.
Как вы могли уже заметить, способы сбора данных примерно одинаковы. Разница лишь в задаваемых вопросах. Если вашей команде наскучило проведение классических ретро, попробуйте придумать свои вопросы. Например, вашей команде выделили бюджет на обучение, можно выяснить, какое из направлений обучения интересует каждого члена команды. Создайте 2 колонки с вопросами: «Что я хочу изучить для повышения компетенции?», «Что я хочу изучить для личностного роста?»
После получения ответов на вопросы, каждый член команды должен выбрать до 3 вопросов (стикеров), которые, по его мнению, он считает важными. Если встретились вживую, можно провести голосование точками, отлично подойдут маркеры разного цвета. Каждому члену команды можно оставить по 1 точке на стикер (Заранее решите командой лимит голосов). После того, как вся команда проголосует, необходимо выделить от 3 тем, за которые отдали большинство голосов. Обсудите их с командой, попробуйте найти способы решения, если это проблема или поговорите о том, как улучшить то, что уже имеется. В случае, если команда нашла вариант способа решения проблемы, зафиксируйте ваши решения как «Action point» и назначьте по одному ответственному на каждый стикер. Можно составить «Action Plan» (Who, What, When), если это необходимо.
В начале следующей ретроспективы обязательно пройдитесь по предыдущим Action points. Узнайте у ответственных, получилось ли решить проблему.
P.S. Очень часто бывают action points на проблемах, которые невозможно решить на уровне команды. Просто запишите эту проблему — пусть она хранится в вашей wiki системе.
Цель закрытия – подвести итоги, высказать коллегам благодарность за терпение и похвалить за продуктивную работу. Попробуйте получить обратную связь:
Или просто расскажите анекдот, поздравьте коллегу с прошедшим днём рождения.
В общем, завершите ретроспективу на позитиве!
One to one – это мероприятие, позволяющее узнать членов команды получше. Узнайте, что движет человеком, что его мотивирует, какие у него интересы, чем человек занимается в свободное время и какое направление он хочет развивать. Узнайте мнение собеседника об атмосфере в команде, получите обратную связь.
Кто должен проводить? Желательно, teamlead, но можно и PO/PM/SM.
Как проводить? Желательно проводить one to one вместо ретроспективы в формате конфиденциального дружеского разговора, а не начальника и подчинённого. В течение спринта teamlead (PO/PM/SM) назначает встречу с каждым членом команды на 30 минут.
Очень важно, чтобы организатор грамотно подходил к собеседнику и находил к каждому индивидуальный подход. Некоторые члены команды могут быть скептически настроены, поэтому перед началом разговора объясните коллеге цель встречи.
Можно использовать множество различных инструментов. Перечисляю те, которыми пользуюсь сам:
1. Google forms – для тестов и опросов;
2. Retrium – проведение классических ретроспектив + Team radar;
3. EasyRetro – проведение классических ретроспектив;
4. Miro – для разминок и не только. При должном желании и подходе можно проводить ретроспективы.
Ретроспектива по шагам. Рецепт
Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, «обучающих» материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.
Кто присутствует
Очень желательно на первых двух-трёх ретро присутствие профессионального скрам-мастера. Причём не сертифицированного, а именно профессионального, который не просто прошёл сертификацию и обучение, а применял свои навыки проведения ретроспектив на практике хотя бы год. При кажущейся простоте мероприятие очень просто сваливается в «не туда», и по его итогам даже не понятно, а почему и как это исправить.
В будущем проведение (фасилитацию) ретро можно передать члену команды, а через некоторое время выбирать нового фасилитатора для каждого нового ретро.
Когда
Ретроспектива должна проводиться регулярно. Вообще всё в Scrum должно делаться регулярно. И планирование, и обзор, и ретро. «Сила» методологии именно в том, чтобы превратить непредсказуемый творческий процесс разработки в предсказуемый и планируемый.
Ретро должно проводиться после обзора спринта. Чтобы на ретро команда могла обсудить в том числе и то, как результаты команды были представлены (успешно или нет) заказчикам. Ретро должно проводиться до планирования следующего спринта. Во-первых потому, что планирование следующего спринта, это уже следующий спринт, а во-вторых, потому что в числе результатов могут быть какие-то задачи, которые команда поставит самой себе. И они должны будут войти в следующий спринт.
Что нужно для ретро?
Если ретро проводится в «реальном мире», потребуются стикеры/листочки (по 6-10 штук на человека), ручки и доска с маркером.
В «виртуальном» мире достаточно обойтись расшаренным экраном с двумя/тремя блокнотами, либо одним экраном Confluence / MS Word с тремя полями. Условно их пока можно назвать «плюсы», «минусы» и «действия».
Для целей геймификации можно использовать онлайн-инструменты типа fun retro / easy retro, но пока что ни один из этих инструментов не вписался в тот рецепт, который будет описан ниже.
Начало ретро
(+) Не менее N таких вещей, которые им понравились в текущем спринте, и которые они не хотели бы терять в процессе предлагаемых в рамках ретро изменений.
(-) Не более N таких вещей, которые не нравятся, и хотелось бы поменять.
Другое важное назначение «+»-пунктов, это возможность позже, когда будут предлагаться действия по решению проблем (action point’ы), выбирать те из них, которые минимальным образом будут влиять на то, что команда не хочет потерять.
Важно, чтобы плюсы и минусы записывались на листочках независимо друг от друга. Тем самым мы избавляемся от «проблемы +1», когда люди вместо раздумывания над проблемой просто присоединяются к чужому ответу (аналогичная ситуация происходит, например, при планировании, от чёго защищает «слепое» покер-планирование).
Минусы. В идеале нужно, чтобы участники сразу записали что им не нравится. Не action point, не то, что они предлагают сделать, а то, что им непосредственно мешает в работе. Но в принципе на первые 4-6 ретроспектив достаточно, чтобы участники хоть что-нибудь записали. А далее ведущий уже вытянет из них всю правду (*дьявольский смех за кадром*).
Вполне можно и допустимо сюда писать что-то, что на первый взгляд кажется «внешним» по отношению к команде. Потому что потом на детальном разборе может оказаться, что при внешней причине мы можем что-то поправить в процессе внутри команды.
Анализ
Минусы. Самый сложный этап. Игра в доктора «наоборот».
Берём каждый стикер (присланный нам в персональные предложения пункт) и. не записываем его. А проверяем, что данный пункт описывает симптом, а не болезнь. Почему? Потому что потом мы должны будем предложить такое решение, которое будет наиболее эффективным способом избавиться от симптома. И «лечение» самой болезни может быть одним из, но не самым эффективным (с точки зрения усилий и времени) способом. Кроме того, данный симптом может быть вызван несколькими причинами, и возможно только одну из них нужно будет убрать, и это вовсе не та, которую изначально назвал член команды.
Ещё раз. Каждый пункт надо записать в виде симптома, а не болезни (и точно не в виде action point’а). Например. Член команды записывает на стикере «у нас неоптимальный CI-скрипт«. Если оставить как есть, единственным возможными способом решения данной проблемы будет, очевидно, переписать CI-скрипт. Но нужно ли?
Уточняем у члена команды, «[Олег], на что в твоей работе влияет то, что CI-скрипт не оптимален»? Внезапно оказывается, что:
скрипт медленно работает
медленная работа приводит к медленному прохождению pull request’ов
невозможность распарраллелить работу приводит к простою
это приводит к медленной работе члена команды
скрипт работает недетерминированно, иногда проваливаясь из-за фазы луны и положения Сатурна в созвездии козерога
это приводит к необходимости ручного перезапуска CI
это приводит к медленной работе члена команды
Но зато для каждого следующего более общего уровня можно предложить самые разные варианты решения проблем:
поставить больше CI-агентов для сборки и распараллелить его работу / сборку / разрешить параллельную работу нескольких сборок одновременно
поставить посильнее машину для CI
выкинуть часть действий из CI-скрипта, не переписывая его кардинально
полностью переписать CI-скрипт
научить пользователя переключаться между ветками в git, позволив ему распараллелить работу и не ждать CI
сделать простой скрипт для перезапуска failed-сценариев 2-3 раза
Но пока что возможный список даже не озвучиваем. Но мы должны (из своего опыта) как-то понять, что именно та формулировка, которая будет записана, может, хотя бы в теории, быть решена несколькими разными способами. И вот именно эту формулировку и надо записать в «минусы».
Очень важно при попытке вытащить из члена команды более общую проблему не задавить его авторитетом и не подложить свою проблему вместо его. Все мы люди, все мы субъективны, и можем увидеть в чужой проблеме вовсе не то, что беспокоит члена команды, а что беспокоит нас самих. Уметь оставлять свои проблемы в стороне и слушать (и слышать) другого человека, наверное, самое важное для того, кто собирается в IT работать с людьми. Но это очень и очень сложно. Ничего страшного, если Вас по началу будут поправлять и говорить, «нет, это вовсе не то, что меня беспокоит, меня беспокоит другое». Замечательно, если Вам будут это говорить. Гораздо хуже, если с Вами молча согласятся, чтобы не спорить и побыстрее закончить.
Голосование
Изначально считаем, что за каждый пункт подано столько голосов, сколько изначальных «минусов» было сгруппировано в него. Далее я предлагаю членам команды проголосовать дополнительно за 1 или 2 пункта (из сгруппированных 7-10), Но только за те, в которых нет пунктов, которые они формулировали сами (или в которые были переформулированы их «минусы»).
В результате формируется отсортированный «по голосам» список проблем.
Блиц-этап
60 секунд это скорее ориентир. На то, что не нужно тратить много времени на блиц-проблемы, которые не являются самыми больными местами в процессе.
Перерыв на кофе
Перед перерывом на кофе окончательно формулируем top3 проблем, которые нужно обсудить, и предлагаем членам команды пойти покурить/попить/выпить/отойти проверить почту.
Обсуждение. Action Points
Во-первых, не надо отбрасывать решения, которые не решают проблему целиком. Нас вполне устроят решения, которые решают проблему хотя бы частично. Хоть на 20%, но облегчают жизнь команды. Кто знает, может именно этих 20% хватит, чтобы в следующий раз проблему не включили в top3?
Во-вторых, решения должны проходить валидацию у тех, чьи проблемы были изначально сгруппированы в единый «пункт симптомов болезни». Хотя бы один из них должен подтвердить, что предложенное решение действительно сделает его жизнь проще.
В-третьих, формулировка. Формулировка должна быть такой, чтобы у команды был минимальный шанс не выполнить пункт.
Плохой вариант
Вариант получше
Нужно устроить встречу и обсудить розовых единорогов
[Олег] устраивает встречу во-вторник в 15 часов по обсуждению проблемы питания розовых единорогов
Ответственно подходить к ревью pull request’ов
— (или) при отклонении pull request’а оставлять комментарий
— (или) настроить бота, назначающего PR на ревью на членов команды
— (или) добавить в CI-скрипт автоматический линтер, а все проблемы в оформлении, которые им не покрываются не считать проблемами
заранее формулировать тикеты в jira до планирования
[Олег] заведёт в outlook еженедельный backlog grooming до планирования с участием владельца backlog’а, представителя аналитиков и solution-архитекторов смежных систем
Полученные шаги записываются в action point’ы.
Почему ретро может не помочь
Может так случиться, что сделали всё по рецепту, а огонёк в глазах команды всё тусклее и тусклее, а производительность команды падает. Потому что автор этого текста ни хрена не знает. Ретроспектива в этом случае позволяет найти часть этих причин, и задуматься, почему эти причины до сих пор не исправлены.
Признаками проблем являются:
Ретроспектива проводится за полчаса. Это не ретроспектива, это отчёт-доклад команды «как у нас всё хорошо, как здорово и дружно мы живём, дорогой дедушка Ленин«. Явный признак того, что мероприятие проводится для галочки, без той пользы, которую могло бы принести полноценное ретро.
Повторяющиеся в две-три ретроспективы похожие описания проблем. Команда предполагает, что теоретически эти проблемы можно было бы попытаться решить какими-то действиями внутри команды. Может быть даже предлагает action point’ы.Но в какой-то момент эти проблемы просто исчезают из анализа, потому что команда уже привыкла к тому, что высказывать их бесполезно. Но сами проблемы-то никуда не делись!
Если таких проблем много, то в какой-то момент появляются фразы «слишком много времени тратится на ретроспективы». Это прямо-таки прямой сигнал о том, что с ретроспективой всё плохо. И да, без изменения формата ретро далее проводить бессмысленно.
Невыполненные action point’ы (при том, что проблема не ушла). Возможно они были очень неудачно сформулированы. А возможно тот, кто должен был их выполнить, забыл/забил/не захотел их делать.
Мини-справочник и руководство по 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-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?