{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Kanban.club: posts tagged Conditions of Satisfaction",
    "_rss_description": "Кратко и по делу о Kanban, Scrum, LeSS, SAFe и все, что может пригодиться в работе менеджеру",
    "_rss_language": "en",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/www.kanban.club\/?go=tags\/conditions-of-satisfaction\/",
    "feed_url": "https:\/\/www.kanban.club\/?go=tags%2Fconditions-of-satisfaction%2Fjson%2F",
    "icon": false,
    "authors": [
        {
            "name": "Роман Петров",
            "url": "https:\/\/www.kanban.club\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "78",
            "url": "https:\/\/www.kanban.club\/?go=all\/otlichiya-definition-of-done-ot-acceptance-criteria\/",
            "title": "Отличия Definition of Done от Acceptance Criteria (CoS)",
            "content_html": "<p>В нашей работе очень важно помнить о том, что нам нужна прозрачность (<i>transparency<\/i>) того, что делает команда, для всех кто работает с этой командой: это могут быть другие команды, <b>Заинтересованные лица<\/b> (они заинтересованы в том, что делает эта команда, и будут как-то использовать тот результат, что она делает), а в особенности для <b>Владельца продукта<\/b>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.kanban.club\/pictures\/dod_ac_correct.jpg\" width=\"800\" height=\"600\" alt=\"\" \/>\n<\/div>\n<p>Так как же Команде разработчиков договориться с Владельцем продукта о том, что же такое сделано? И тут, на помощь нам приходит <b>Критерии Готовности (DoD или Definition of Done)<\/b> – это чек-лист работ, которые проходит каждая из задач команды, после чего она может на каждую из них свою печать “Готово”. Этим команда заверяет, что <b>продукт сделан правильно<\/b>.<\/p>\n<p>Владелец продукта, принимая задачу от команды, уже знает, что все очевидное и ожидаемое, по умолчанию от команды, сделано. А чтобы, это действительно было так, то стоит, этот список действий, записать в явном виде и согласовать с двух сторон. Цель в том, чтобы не было разночтений, все четкой ИЛИ работа СДЕЛАНА, ИЛИ НЕ СДЕЛАНА, только в этом случае, будет доверие к команде от Владельца Продукта и Заинтересованных лиц.<\/p>\n<h2>Кто составляет этот список?<\/h2>\n<p>Команда. Это именно команда, говорит, что для нее значит, что задача сделана, это общий список без привязки к контексту. Это может быть для ИТ проекта: “Прошли автотесты, Сделан регресс, Написана пользовательская документация, и т.д.”, для доставки: “заказ собран в коробку, упакован в пакет, зарегистрирован в систему, наклеен штрих-код, положен на полку на складе”.<\/p>\n<h2>Достаточно ли это для Владельца продукта?<\/h2>\n<p>Очевидно, нет! То, что код прошел все технические процедуры, а коробка лежит в красивом виде на правильной полке, не говорит ничего о содержимом. Для содержимого, есть дополнительный критерий, называемый Критерий Приемки (Acceptance Criteria). Он уже составляется Владельцем продукта, для того чтобы понимать, что <b>сделали вещь правильную<\/b>.<\/p>\n<h2>Соединение DoD и AC, дает нам прозрачность в том, что была сделана <b>правильная вещь правильным способом<\/b>.<\/h2>\n<h2>Давайте посмотрим на это, на примере метафоры нашего любимого аэропорта.<\/h2>\n<p>Мы приходим в аэропорт и сдаем багаж. Каждый багаж проходит необходимые проверки: по размеру, весу и содержимому. Если в самолет загрузили багаж, то команда самолета уверена, что все, что загружено правильной формы, безопасно и т.д. Эти все процедуры – это критерии готовности (DoD), в которых вам можно, что сдав свой багаж, вы получите его целым по прилету.  И тут-то содержимое чемоданов – это критерий приемки (AC), он то и важен для вас, в соответствии с ним, вы смотрите, что все что вы положили в чемодан, прилетело в целости и сохранности.<\/p>\n<p>Т.е. у вас с перевозчиком есть договоренность, что значит доставленный груз, но ценность – это то, что внутри. Принимаете работы вы уже смотря на то, что внутри.<\/p>\n<h2>В пиццерии<\/h2>\n<p>DoD: пицца приготовлена, пожарена, нарезана, упакована в коробку \/ подана на стол и нигде в процессе не испорчена<\/p>\n<p>Acceptance Criteria: пицца именно того размера и вида (состав ингредиентов), какого заказал клиент.<\/p>\n<h2>Говоря математическим языком: DoD – это необходимое условие, а AC – это достаточное условие. Они всегда идут рука об руку, но путать их не надо.<\/h2>\n<p>Еще, для больших команд, применяется критерий готовности Релиза (Definition of Done for a Release).<\/p>\n<p>Если вам не нравится слово Критерий приемки, то можете взять вариант Хенрика Книберга <b>«Как продемонстрировать» (How to demo)<\/b> или Майка Кона <b>«Условия удовлетворения ожиданий» (Conditions of Satisfaction)<\/b>. Эти варианты больше подходят для задач без ИТ, например, в высокоуровневых бизнес-целях.<\/p>\n<h2>Что такое идеальный DoD?<\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.kanban.club\/pictures\/Done_UnDone.jpg\" width=\"800\" height=\"573\" alt=\"\" \/>\n<\/div>\n<p><b>DoD – это те работы, которые мы делаем с каждым элементом бэклога, каждый спринт.<\/b> И в идеале, у вас в результате есть то, что сразу можно поставить \\ отдать пользователю. Но что делать, если для этого нужно сделать что-то еще? Например, провести сборку, сделать нагрузочное тестирование, подготовить документацию, получить согласования от юристов, бухгалтерии, безопасников и т.д. Быть честным!<\/p>\n<p>Нужно подсветить всю эту работу, которая НЕ будет готова в конце спринта. Она будет накапливаться и с ней нужно что-то делать. <b>Задача Scrum команды, честно признавать что еще нужно делать и находить решения<\/b>, чтобы с каждым новым спринтом, таких работ становилось все меньше.<\/p>\n<p>Список Критериев может создаваться как самим Владельцем продукта, а может и командой разработки. Команда, на планировании или PBR, может задавать вопросы относительно этого списка в целях прояснения понимания, что нужно сделать, а так же предлагать от себя дополнительные критерии. Здесь важный нюанс, что <b>ответственность за то, как будет проверяться каждый элемент бэклога, лежит на Владельце продукта<\/b>.<\/p>\n<p>Сокращенно, AC – называть не удобно и можно путать с Agile Coach, Автоматизированная Система и т.д.  Поэтому, <b>давайте пользоваться термином CoS (Conditions of Satisfaction) Условия удовлетворения ожиданий<\/b><\/p>\n<p>Автор: Роман Петров<\/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:\/\/www.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:\/\/www.kanban.club\/pictures\/dod_ac_correct.jpg",
                    "https:\/\/www.kanban.club\/pictures\/Done_UnDone.jpg"
                ]
            }
        }
    ],
    "_e2_version": 4134,
    "_e2_ua_string": "Aegea 11.3 (v4134)"
}