Что было выявлено по итогу присутствия на ретроспективе, у команды, которая уже около 3 месяцев работает по Scrum. Команда из 7 человек, причем ВП и СМ находятся в одной локации, а вся остальная команда в другой.

Что имеем из фактуры, над которой можно поработать:

1. Цель спринта состоит из 8 пунктов, в формате что надо сделать. (причина — задачи не связаны друг с другом, а раз так, то и разные цели)
2. Запланированный на спринт объем работы, команда не выполняет (команда хочет лучше оценивать задачи в человеко-часах и просит СМ дать им инструменты, чтобы трекать это Jira)
3. Команда не довольна оценкой результативности от ВП по результатам обзора, в прошлый раз было 4.5 из 10, в этот раз 3.5 из 10, команда не довольна и хочет лучше планировать
4. На ревью пользователи не приходят, так как им нечего показывать

Варианты, что можно улучшить Скрам-мастеру в его команде:

1. Сейчас ВП и команда по разные стороны баррикад, так как на обзоре никого кроме ВП и команды нету, то это походит на отчетную встречу. По этому команда спрашивает у ВП, как хорошо она поработала, на что получает низкую оценку, так как ВП смотрит на разницу между что планировали и что сделали. Поэтому команда хочет защититься от этого, хочет начать мерить свое время, чтобы узнать что она молодец, но реальная причина не в этом. Результат — демотивация команды. СМ нужно вернуть команду и ВП на одну сторону и направить их к единой цели. Еще раз сформировать общее видение того, что делает команда (см. цель спринта). Цель сформулировать по SMART.

2. Обратную связь получать от Пользователей, так она будет объективной и команда должна мочь сама оценить свою результативность без интерпретации ВП. Объективность можно достичь тем, что это будет какая-то измеримая цель: количество денег, пользователей и т. д.

3. Признаться, что ниодна задача не сделана до конца и поставить самим себе за результат 0. Еще раз вернуться к теме, что такое DoD и чем он отличается от AC. СМ нужно запустить активность с командой по генерации DoD и посмотреть на свой бэклог спринта с тем, что вся команда уверена, что сможет сделать все запланированное с учетом согласованного DoD

4. Команда формирует много целей спринта, так как видит элементы бэклога разными, но у нас же это команда и она делает общие цели. Для этого нужно посмотреть на нашу цель, на наших пользователей и постараться найти какую-то объединяющую метрику для всех элементов бэклога, так называемую единую линейку, по которой можно мерить все элементы. Если такой общей линейки найти не удается, то тут нужно остановиться и признать, что у нас это не команда и сделать перезапуск.

5. Еще раз с командой проговорить цикл, что когда мы берем задачу в спринт, то обсуждаем АС (критерии приемки), все задачи обязательно проходят DoD. АС — для каждой задачи свой, DoD общий и его можно менять на ретроспективе. Команда получает ОС от пользователей напрямую, и это являются экологичным источником положительных или отрицательных эмоций, где ВП может подбодрить команду и прийти на планирование с новым задором.

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

После такого разбора, за такой период, СМ сказал: «Ааа.... я все сломал, ничего не работает, я почти убил команду» :)

И здесь лежит ловушка в том, что Scrum всегда не работает — и в этом и была задумка. В этом и есть источник улучшений команды для СМ. Включайте режим Коломбо, экспериментируйте, сначала сделайте все события скрам, потом улучшайтесь.

Реально убить команду СМ может только специально и это тоже надо уметь. Нельзя все сразу предусмотреть, каждая команда идет своим путем, ему нужно только помогать.

Автор Роман Петров

В нашей работе очень важно помнить о том, что нам нужна прозрачность (transparency) того, что делает команда, для всех кто работает с этой командой: это могут быть другие команды, Заинтересованные лица (они заинтересованы в том, что делает эта команда, и будут как-то использовать тот результат, что она делает), а в особенности для Владельца продукта.

Так как же Команде разработчиков договориться с Владельцем продукта о том, что же такое сделано? И тут, на помощь нам приходит Критерии Готовности (DoD или Definition of Done) — это чек-лист работ, которые проходит каждая из задач команды, после чего она может на каждую из них свою печать «Готово». Этим команда заверяет, что продукт сделан правильно.

Владелец продукта, принимая задачу от команды, уже знает, что все очевидное и ожидаемое, по умолчанию от команды, сделано. А чтобы, это действительно было так, то стоит, этот список действий, записать в явном виде и согласовать с двух сторон. Цель в том, чтобы не было разночтений, все четкой ИЛИ работа СДЕЛАНА, ИЛИ НЕ СДЕЛАНА, только в этом случае, будет доверие к команде от Владельца Продукта и Заинтересованных лиц.

Кто составляет этот список?

Команда. Это именно команда, говорит, что для нее значит, что задача сделана, это общий список без привязки к контексту. Это может быть для ИТ проекта: «Прошли автотесты, Сделан регресс, Написана пользовательская документация, и т. д.», для доставки: «заказ собран в коробку, упакован в пакет, зарегистрирован в систему, наклеен штрих-код, положен на полку на складе».

Достаточно ли это для Владельца продукта?

Очевидно, нет! То, что код прошел все технические процедуры, а коробка лежит в красивом виде на правильной полке, не говорит ничего о содержимом. Для содержимого, есть дополнительный критерий, называемый Критерий Приемки (Acceptance Criteria). Он уже составляется Владельцем продукта, для того чтобы понимать, что сделали вещь правильную.

Соединение DoD и AC, дает нам прозрачность в том, что была сделана правильная вещь правильным способом.

Давайте посмотрим на это, на примере метафоры нашего любимого аэропорта.

Мы приходим в аэропорт и сдаем багаж. Каждый багаж проходит необходимые проверки: по размеру, весу и содержимому. Если в самолет загрузили багаж, то команда самолета уверена, что все, что загружено правильной формы, безопасно и т. д. Эти все процедуры — это критерии готовности (DoD), в которых вам можно, что сдав свой багаж, вы получите его целым по прилету. И тут-то содержимое чемоданов — это критерий приемки (AC), он то и важен для вас, в соответствии с ним, вы смотрите, что все что вы положили в чемодан, прилетело в целости и сохранности.

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

В пиццерии

DoD: пицца приготовлена, пожарена, нарезана, упакована в коробку / подана на стол и нигде в процессе не испорчена

Acceptance Criteria: пицца именно того размера и вида (состав ингредиентов), какого заказал клиент.

Говоря математическим языком: DoD — это необходимое условие, а AC — это достаточное условие. Они всегда идут рука об руку, но путать их не надо.

Еще, для больших команд, применяется критерий готовности Релиза (Definition of Done for a Release).

Если вам не нравится слово Критерий приемки, то можете взять вариант Хенрика Книберга «Как продемонстрировать» (How to demo) или Майка Кона «Условия удовлетворения ожиданий» (Conditions of Satisfaction). Эти варианты больше подходят для задач без ИТ, например, в высокоуровневых бизнес-целях.

Что такое идеальный DoD?

DoD — это те работы, которые мы делаем с каждым элементом бэклога, каждый спринт. И в идеале, у вас в результате есть то, что сразу можно поставить \ отдать пользователю. Но что делать, если для этого нужно сделать что-то еще? Например, провести сборку, сделать нагрузочное тестирование, подготовить документацию, получить согласования от юристов, бухгалтерии, безопасников и т. д. Быть честным!

Нужно подсветить всю эту работу, которая НЕ будет готова в конце спринта. Она будет накапливаться и с ней нужно что-то делать. Задача Scrum команды, честно признавать что еще нужно делать и находить решения, чтобы с каждым новым спринтом, таких работ становилось все меньше.

Список Критериев может создаваться как самим Владельцем продукта, а может и командой разработки. Команда, на планировании или PBR, может задавать вопросы относительно этого списка в целях прояснения понимания, что нужно сделать, а так же предлагать от себя дополнительные критерии. Здесь важный нюанс, что ответственность за то, как будет проверяться каждый элемент бэклога, лежит на Владельце продукта.

Сокращенно, AC — называть не удобно и можно путать с Agile Coach, Автоматизированная Система и т. д. Поэтому, давайте пользоваться термином CoS (Conditions of Satisfaction) Условия удовлетворения ожиданий

Автор: Роман Петров