{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Kanban.club: posts tagged DoD", "_rss_description": "Кратко и по делу о Kanban, Scrum, LeSS, SAFe и все, что может пригодиться в работе менеджеру", "_rss_language": "en", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/kanban.club\/?go=tags\/dod\/", "feed_url": "https:\/\/kanban.club\/?go=tags%2Fdod%2Fjson%2F", "icon": false, "authors": [ { "name": "Роман Петров", "url": "https:\/\/kanban.club\/", "avatar": false } ], "items": [ { "id": "84", "url": "https:\/\/kanban.club\/?go=all\/keys-scrum-posle-3-mesyacev-raboty\/", "title": "Кейс. Scrum после 3 месяцев работы", "content_html": "

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

Что имеем из фактуры, над которой можно поработать:<\/b><\/p>\n

\n
Цель спринта состоит из 8 пунктов, в формате что надо сделать. (причина – задачи не связаны друг с другом, а раз так, то и разные цели)<\/li>\n
Запланированный на спринт объем работы, команда не выполняет (команда хочет лучше оценивать задачи в человеко-часах и просит СМ дать им инструменты, чтобы трекать это Jira)<\/li>\n
Команда не довольна оценкой результативности от ВП по результатам обзора, в прошлый раз было 4.5 из 10, в этот раз 3.5 из 10, команда не довольна и хочет лучше планировать<\/li>\n
На ревью пользователи не приходят, так как им нечего показывать<\/li>\n<\/ol>\n
\n $\"\"$ \n<\/div>\n
Варианты, что можно улучшить Скрам-мастеру в его команде:<\/b><\/p>\n
\n
Сейчас ВП и команда по разные стороны баррикад, так как на обзоре никого кроме ВП и команды нету, то это походит на отчетную встречу. По этому команда спрашивает у ВП, как хорошо она поработала, на что получает низкую оценку, так как ВП смотрит на разницу между что планировали и что сделали. Поэтому команда хочет защититься от этого, хочет начать мерить свое время, чтобы узнать что она молодец, но реальная причина не в этом. Результат – демотивация команды. СМ нужно вернуть команду и ВП на одну сторону и направить их к единой цели. Еще раз сформировать общее видение того, что делает команда (см. цель спринта). Цель сформулировать по SMART.<\/li>\n<\/ol>\n
\n
Обратную связь получать от Пользователей, так она будет объективной и команда должна мочь сама оценить свою результативность без интерпретации ВП. Объективность можно достичь тем, что это будет какая-то измеримая цель: количество денег, пользователей и т.д.<\/li>\n<\/ol>\n
\n
Признаться, что ниодна задача не сделана до конца и поставить самим себе за результат 0. Еще раз вернуться к теме, что такое DoD и чем он отличается от AC. СМ нужно запустить активность с командой по генерации DoD и посмотреть на свой бэклог спринта с тем, что вся команда уверена, что сможет сделать все запланированное с учетом согласованного DoD<\/li>\n<\/ol>\n
\n
Команда формирует много целей спринта, так как видит элементы бэклога разными, но у нас же это команда и она делает общие цели. Для этого нужно посмотреть на нашу цель, на наших пользователей и постараться найти какую-то объединяющую метрику для всех элементов бэклога, так называемую единую линейку, по которой можно мерить все элементы. Если такой общей линейки найти не удается, то тут нужно остановиться и признать, что у нас это не команда и сделать перезапуск.<\/li>\n<\/ol>\n
\n
Еще раз с командой проговорить цикл, что когда мы берем задачу в спринт, то обсуждаем АС (критерии приемки), все задачи обязательно проходят DoD. АС – для каждой задачи свой, DoD общий и его можно менять на ретроспективе. Команда получает ОС от пользователей напрямую, и это являются экологичным источником положительных или отрицательных эмоций, где ВП может подбодрить команду и прийти на планирование с новым задором.<\/li>\n<\/ol>\n
Обязательно не забывать об экологичной обратной связи между всеми участниками процесса, чтобы не получить проблему на пустом месте.<\/i><\/p>\n
После такого разбора, за такой период, СМ сказал: “Ааа.... я все сломал, ничего не работает, я почти убил команду” :)<\/p>\n
И здесь лежит ловушка в том, что Scrum всегда не работает – и в этом и была задумка. В этом и есть источник улучшений команды для СМ. Включайте режим Коломбо, экспериментируйте, сначала сделайте все события скрам, потом улучшайтесь.<\/p>\n
Реально убить команду СМ может только специально и это тоже надо уметь. Нельзя все сразу предусмотреть, каждая команда идет своим путем, ему нужно только помогать.<\/p>\n
Автор Роман Петров<\/p>\n", "date_published": "2019-06-28T19:10:23+03:00", "date_modified": "2019-06-28T19:10:09+03:00", "tags": [ "DoD", "scrum", "scrum-case" ], "image": "https:\/\/kanban.club\/pictures\/Scrum-case-1.jpg", "_date_published_rfc2822": "Fri, 28 Jun 2019 19:10:23 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "84", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/kanban.club\/pictures\/Scrum-case-1.jpg" ] } }, { "id": "78", "url": "https:\/\/kanban.club\/?go=all\/otlichiya-definition-of-done-ot-acceptance-criteria\/", "title": "Отличия Definition of Done от Acceptance Criteria (CoS)", "content_html": "
В нашей работе очень важно помнить о том, что нам нужна прозрачность (transparency<\/i>) того, что делает команда, для всех кто работает с этой командой: это могут быть другие команды, Заинтересованные лица<\/b> (они заинтересованы в том, что делает эта команда, и будут как-то использовать тот результат, что она делает), а в особенности для Владельца продукта<\/b>.<\/p>\n
\n $\"\"$ \n<\/div>\n
Так как же Команде разработчиков договориться с Владельцем продукта о том, что же такое сделано? И тут, на помощь нам приходит Критерии Готовности (DoD или Definition of Done)<\/b> – это чек-лист работ, которые проходит каждая из задач команды, после чего она может на каждую из них свою печать “Готово”. Этим команда заверяет, что продукт сделан правильно<\/b>.<\/p>\n
Владелец продукта, принимая задачу от команды, уже знает, что все очевидное и ожидаемое, по умолчанию от команды, сделано. А чтобы, это действительно было так, то стоит, этот список действий, записать в явном виде и согласовать с двух сторон. Цель в том, чтобы не было разночтений, все четкой ИЛИ работа СДЕЛАНА, ИЛИ НЕ СДЕЛАНА, только в этом случае, будет доверие к команде от Владельца Продукта и Заинтересованных лиц.<\/p>\n
Кто составляет этот список?<\/h2>\n
Команда. Это именно команда, говорит, что для нее значит, что задача сделана, это общий список без привязки к контексту. Это может быть для ИТ проекта: “Прошли автотесты, Сделан регресс, Написана пользовательская документация, и т.д.”, для доставки: “заказ собран в коробку, упакован в пакет, зарегистрирован в систему, наклеен штрих-код, положен на полку на складе”.<\/p>\n
Достаточно ли это для Владельца продукта?<\/h2>\n
Очевидно, нет! То, что код прошел все технические процедуры, а коробка лежит в красивом виде на правильной полке, не говорит ничего о содержимом. Для содержимого, есть дополнительный критерий, называемый Критерий Приемки (Acceptance Criteria). Он уже составляется Владельцем продукта, для того чтобы понимать, что сделали вещь правильную<\/b>.<\/p>\n
Соединение DoD и AC, дает нам прозрачность в том, что была сделана правильная вещь правильным способом<\/b>.<\/h2>\n
Давайте посмотрим на это, на примере метафоры нашего любимого аэропорта.<\/h2>\n
Мы приходим в аэропорт и сдаем багаж. Каждый багаж проходит необходимые проверки: по размеру, весу и содержимому. Если в самолет загрузили багаж, то команда самолета уверена, что все, что загружено правильной формы, безопасно и т.д. Эти все процедуры – это критерии готовности (DoD), в которых вам можно, что сдав свой багаж, вы получите его целым по прилету. И тут-то содержимое чемоданов – это критерий приемки (AC), он то и важен для вас, в соответствии с ним, вы смотрите, что все что вы положили в чемодан, прилетело в целости и сохранности.<\/p>\n
Т.е. у вас с перевозчиком есть договоренность, что значит доставленный груз, но ценность – это то, что внутри. Принимаете работы вы уже смотря на то, что внутри.<\/p>\n
В пиццерии<\/h2>\n
DoD: пицца приготовлена, пожарена, нарезана, упакована в коробку \/ подана на стол и нигде в процессе не испорчена<\/p>\n
Acceptance Criteria: пицца именно того размера и вида (состав ингредиентов), какого заказал клиент.<\/p>\n
Говоря математическим языком: DoD – это необходимое условие, а AC – это достаточное условие. Они всегда идут рука об руку, но путать их не надо.<\/h2>\n
Еще, для больших команд, применяется критерий готовности Релиза (Definition of Done for a Release).<\/p>\n
Если вам не нравится слово Критерий приемки, то можете взять вариант Хенрика Книберга «Как продемонстрировать» (How to demo)<\/b> или Майка Кона «Условия удовлетворения ожиданий» (Conditions of Satisfaction)<\/b>. Эти варианты больше подходят для задач без ИТ, например, в высокоуровневых бизнес-целях.<\/p>\n
Что такое идеальный DoD?<\/h2>\n
\n $\"\"$ \n<\/div>\n
DoD – это те работы, которые мы делаем с каждым элементом бэклога, каждый спринт.<\/b> И в идеале, у вас в результате есть то, что сразу можно поставить \\ отдать пользователю. Но что делать, если для этого нужно сделать что-то еще? Например, провести сборку, сделать нагрузочное тестирование, подготовить документацию, получить согласования от юристов, бухгалтерии, безопасников и т.д. Быть честным!<\/p>\n
Нужно подсветить всю эту работу, которая НЕ будет готова в конце спринта. Она будет накапливаться и с ней нужно что-то делать. Задача Scrum команды, честно признавать что еще нужно делать и находить решения<\/b>, чтобы с каждым новым спринтом, таких работ становилось все меньше.<\/p>\n
Список Критериев может создаваться как самим Владельцем продукта, а может и командой разработки. Команда, на планировании или PBR, может задавать вопросы относительно этого списка в целях прояснения понимания, что нужно сделать, а так же предлагать от себя дополнительные критерии. Здесь важный нюанс, что ответственность за то, как будет проверяться каждый элемент бэклога, лежит на Владельце продукта<\/b>.<\/p>\n
Сокращенно, AC – называть не удобно и можно путать с Agile Coach, Автоматизированная Система и т.д. Поэтому, давайте пользоваться термином CoS (Conditions of Satisfaction) Условия удовлетворения ожиданий<\/b><\/p>\n
Автор: Роман Петров<\/p>\n", "date_published": "2019-04-06T16:01:08+03:00", "date_modified": "2019-04-08T14:04:55+03:00", "tags": [ "Acceptance Criteria", "Conditions of Satisfaction", "Definition of Done", "DoD", "How to demo", "UnDone", "Роман Петров" ], "image": "https:\/\/kanban.club\/pictures\/dod_ac_correct.jpg", "_date_published_rfc2822": "Sat, 06 Apr 2019 16:01:08 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "78", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/kanban.club\/pictures\/dod_ac_correct.jpg", "https:\/\/kanban.club\/pictures\/Done_UnDone.jpg" ] } } ], "_e2_version": 4134, "_e2_ua_string": "Aegea 11.3 (v4134)" }