{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Kanban.club: posts tagged потери",
    "_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\/poteri\/",
    "feed_url": "https:\/\/kanban.club\/?go=tags%2Fpoteri%2Fjson%2F",
    "icon": false,
    "authors": [
        {
            "name": "Роман Петров",
            "url": "https:\/\/kanban.club\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "52",
            "url": "https:\/\/kanban.club\/?go=all\/otlichie-ocenki-ot-analiza\/",
            "title": "Отличие оценки от анализа",
            "content_html": "<p>Давайте разберемся, какие оценки бывают: абсолютные и относительные.<\/p>\n<p>Для чего мы их делаем? Чтобы сделать прогноз на поставку, какой-то ценности. Так? Но, сама эта работа, для точной оценки интеллектуальной работы, требует больших усилий в том, чтобы её подсчитать, а потом и управлять ей.<\/p>\n<p>Очевидно, что такая работа не приносит ценности нашим заказчикам и является потерями, от которых надо избавляться.<\/p>\n<h2>Почему не надо делать оценок?<\/h2>\n<p>Давайте рассмотрим случай, когда разработка у нас не самое узкое место в нашей системе, тогда нам нет смысла оценивать, потому что все что попадает на вход – будет сделано.<\/p>\n<p>Другой вариант, что разработка узкое место, тогда нагружая его работой по оценке, мы только еще больше уменьшаем его производительность, что негативно сказывается на всей системе в целом.<\/p>\n<h2>А как же анализ?<\/h2>\n<p>А вот анализ задачи участвует в цепочке создания ценности. Это помогает нам сделать декомпозицию задачи и сделать стратегию по интеграции декомпозированных компонентов в один ценностный рабочий элемент на выходе.<\/p>\n<p>При этом, если нам нужно дать прогноз на поставку, то здесь нам помогут относительные оценки. Эту оценку можно называть как угодно, лишь бы не часы, минуты, дни и т.д. Обычно это стори-поинты, но могут быть хоть попугаи.<\/p>\n<p>> Напомним, что прижились несколько видов числовых ряды для оценок:<br \/>\n> На основе мутировавшегося ряда Фибоначчи: 1, 2, 3, 5, 8, 13, 20, 40, 100<br \/>\n> Так и степень двойки: 1, 2, 4, 8, 16, 32, 64, 128<\/p>\n<p>Относительные оценки, служат для выработки договоренности внутри команды о размере того или иного рабочего элемента (как частный случай, это может быть user story). Причем, размерность дана таким образом, что разница между  числами от 50 до 100%, и основной фокус обсуждения идет не о том, что это 7 или 8 стори-поинтов, а о том, что мы сравниваем задачи относительно друг друга (новую с набором уже сделанных задач нашей командой) и много говорим, для того чтобы совместно выявить максимум рисков и сделать прогноз, когда мы можем это сделать.<\/p>\n",
            "date_published": "2018-08-08T00:37:20+03:00",
            "date_modified": "2018-08-08T11:27:04+03:00",
            "tags": [
                "noestimate",
                "storypoint",
                "анализ",
                "оценка",
                "потери",
                "ценность"
            ],
            "_date_published_rfc2822": "Wed, 08 Aug 2018 00:37:20 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "52",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4134,
    "_e2_ua_string": "Aegea 11.3 (v4134)"
}