{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Блоги: заметки с тегом очереди",
    "_rss_description": "Автоматически собираемая лента заметок, написанных в блогах на Эгее",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": false,
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/www.blogengine.ru\/blogs\/tags\/ocheredi\/",
    "feed_url": "https:\/\/www.blogengine.ru\/blogs\/tags\/ocheredi\/json\/",
    "icon": false,
    "authors": [
        {
            "name": "Илья Бирман",
            "url": "https:\/\/www.blogengine.ru\/blogs\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "127937",
            "url": "https:\/\/artemushanov.ru\/?go=all\/chto-takoe-ocheredi\/",
            "title": "The Principles of Product Development Flow, пост 4 — что такое «очереди»",
            "content_html": "<p class=\"foot\">🔬 Это пост с разбором очередной части книги Дона Рейнертсена <i>The Principles of Product Development Flow<\/i>. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">pdflow<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-3.png\" width=\"338\" height=\"500\" alt=\"\" \/>\n<\/div>\n<p>В предыдущей части про <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/\">экономический фреймворк<\/a> стало понятно, что время цикла — важная метрика с точки зрения экономики разработки продукта.<\/p>\n<p class=\"loud\">Дешевые способы уменьшить время цикла разработки увеличивают прибыль на жизненном цикле продукта.<\/p>\n<p>Один из таких способов — устранение периодов неактивности, когда над РП никто не работает и он висит в ожидании. Такие периоды называются очередями, и сегодня мы разберемся, что они такое.<\/p>\n<p><img src=\"https:\/\/artemushanov.ru\/pictures\/chto-takoe-ocheredi-1.png\" width=75% height=75%><\/p>\n<p class=\"foot\">© Страдающее Средневековье<\/p>\n<h3>Зачем рассматривать очереди<\/h3>\n<p>Рейнертсен считает, что очереди — одна из главных причин задержек в продуктовой разработке, а работать с ними мало кто умеет.<\/p>\n<p>Вот перечень проблем, которые вызывают очереди:<\/p>\n<ul>\n<li>Увеличение цикла разработки: чем длиннее очередь — тем дольше рабочий продукт будет ждать, пока за него возьмутся. Если мы знаем про очереди, мы можем придумать, как спрогнозировать и посчитать потери от ожидания.<\/li>\n<li>Рост рисков: этапы обработки рабочих продуктов разделены длительным временем ожидания, поэтому растут риски. Чем дольше мы ждем — тем выше вероятность, что могут произойти нежелательные изменения на рынке, у конкурентов или в используемых технологиях.<\/li>\n<li>Увеличение вариабельности: когда мы сильно нагружаем наши мощности по разработке, сильно растет вариабельность. Подробнее — в следующих постах.<\/li>\n<li>Увеличение накладных расходов: чем больше РП сидит в очередях — тем длиннее очереди, больше встреч и отчетов.<\/li>\n<li>Снижение качества: из-за очередей мы получаем фидбек о сделанной работе позже. Если программист начал писать код исходя из неверных предпосылок и получил фидбек на следующий день — можно быстро откатиться и исправить. Если фидбек придет только через неделю, то придется выкинуть результаты работы за неделю.<\/li>\n<li>Снижение мотивации: нет необходимости торопиться и пилить дизайны для приложения за день или два, если продакт сможет посмотреть их только через неделю.<\/li>\n<\/ul>\n<p>Просто понимание того, что очереди — есть, и их можно обнаружить, уже дает возможность находить и устранять очевидные заторы в работе какими-то интуитивно понятными методами.<\/p>\n<p>Коротко я вопроса очередей касался в <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#queuesblindness\">первом<\/a> посте про книгу. Там была такая иллюстрация:<\/p>\n<div style=\"border-radius: 25px; border:1px solid #DCDCDC;padding:20px;margin:20px;\"><p class=\"foot\">🟢 — работа над РП<\/p>\n<p class=\"foot\">🔴 — ожидание в очереди<\/p>\n<p>Ситуация у нас такая:<br \/>\n🟢🟢🔴🔴🔴🔴🔴🔴🟢🟢🔴🔴🔴🔴🔴🔴🔴🟢🟢<\/p>\n<p>То есть над РП работают два дня, потом он шесть дней ждет, потом еще два дня в работе, еще семь дней ждет, и наконец финальные два дня в работе перед выпуском. Итого цикл 19 дней, чистое время работы над РП 6 дней.<\/p>\n<\/div><p>Для ускорения разработки нужно уменьшить время цикла, т. е. завершить работы над рабочим продуктом быстрее, чем за 19 дней. Как это сделать? Ответ: сокращать «красные» этапы ожидания, когда РП висит в очереди на обработку; сокращение «зеленых» этапов сложнее и даст меньший эффект.<\/p>\n<p>Чтобы сократить этапы ожидания, нужно их для начала обнаружить, а для этого нужна правильная «оптика» и понимание, куда смотреть. Подходящий инструментарий может предложить раздел тервера под названием «теория очередей».<\/p>\n<h3>Теория очередей<\/h3>\n<p>Теория появилась в начале 20 века как практический метод решить задачу Копенгагенской телефонной компании: требовалось понять, сколько телефонных линий требуется для обслуживания какого-то количества абонентов. Задача на тот момент была нетривиальной: звонки поступали в случайном порядке и спрогнозировать их было невозможно, как и длительность каждого конкретного разговора.<\/p>\n<p>Датский инженер по фамилии Эрланг разработал матмодели для формализации этих проблем, что помогло лучше прогнозировать трафик, оптимизировать количество операторов, снизить время ожидания на коммутацию — в общем, оптимизировать затраты, добившись при этом достаточного уровня сервиса.<\/p>\n<h3>Основные понятия<\/h3>\n<p class=\"note\">Термины и проч. по теории очередей — <a href=\"https:\/\/staff.um.edu.mt\/jskl1\/simweb\/intro.htm\">https:\/\/staff.um.edu.mt\/jskl1\/simweb\/intro.htm<\/a><\/p>\n<p><i>Процесс прибытия<\/i> (Arrival Process): паттерн, по которому в очередь попадают новые объекты. Он описывает, как объекты (например, телефонные звонки) поступают в систему. Может быть случайным или детерминированным.<br \/>\n<i>Механизм обслуживания<\/i> (Service Mechanism): описывает, как обслуживаются объекты. Это может зависеть от таких факторов, как количество серверов (операторов), способ определения приоритетности задач и время, необходимое для обслуживания задачи (длительность звонка).<br \/>\n<i>Сервер<\/i> (Server): ресурс, который осуществляет работу над объектами из очереди; в нашем случае — оператор, который коммутирует звонки<br \/>\n<i>Дисциплина очереди<\/i> (Queue Discipline): означает порядок, в котором обслуживаются объекты. Распространены такие дисциплины, как «первым пришел — первым ушел» (FIFO), «последним пришел — первым ушел» (LIFO) и обслуживание на основе приоритетов.<br \/>\n<i>Емкость<\/i> (Capacity): количество объектов (например, абонентов), которые система может обслуживать одновременно.<br \/>\n<i>Длина очереди<\/i> (Queue Length): количество объектов, ожидающих в очереди.<\/p>\n<p>Два важнейших показателя для очередей — <b>заполняемость<\/b> и <b>время цикла<\/b>. Зная их, можно измерять:<\/p>\n<ul>\n<li>количество РП в очереди, количество РП в сервисе, общее количество в системе;<\/li>\n<li>время, проведенное РП в очереди, в сервисе, в системе в целом.<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/Mm1_queue.png\" width=\"292\" height=\"119\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Лямбда — это процесс прибытия, Мю — механизм обслуживания<\/div>\n<\/div>\n<p>На иллюстрации — тип очереди <tt>M\/M\/1\/∞<\/tt> в <a href=\"https:\/\/en.wikipedia.org\/wiki\/Kendall%27s_notation\">нотации Кендалла<\/a>, именно с него Рейнертсен предлагает начать. В нотации элементы означают, в порядке очереди: «М» — тип процесса прибытия, «М» — тип механизма обслуживания, «1» — количество серверов, «∞» — максимальный размер очереди. «М» — значит «<a href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%9C%D0%B0%D1%80%D0%BA%D0%BE%D0%B2%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81\">Марковский процесс<\/a>», и он в нашем примере относится и к прибытию, и к сервису. Это означает, что в прибытии время между поступлениями распределено экспоненциально (меньший интервал между поступлениями более вероятен, чем больший), при этом следующий интервал прибытия не зависит от любых предыдущих. Для сервиса\/обслуживания то же самое: длительность сервиса разная для каждого РП, на временном ряду длительности распределяются экспоненицально, длительность каждого следующего сервиса не зависит от предыдущих.<br \/>\nЕсли по простому описать этот тип очереди, получится примерно следующее: люди приходят на оформление визы независимо друг от друга и со случайными интервалами, встают в очередь в единственное окно, обслуживание каждого человека занимает примерно 15 минут, но иногда может и 30, а может и 5.<\/p>\n<h3>На практике<\/h3>\n<p>Если заземлять все вышеописанное на реалии продуктовой софтверной разработки, то элементами очереди могут быть любые промежуточные рабочие продукты: дизайн-макеты, требования, юзер-стори (или другие элементы бэклога), реализованные фичи, документация.<\/p>\n<p>Серверами могут быть: арт-директор, обозревающий дизайн-макеты; тимлид, анализирующий требования или юзер-стори; продакт, превращающий инсайты в спеки. Процесс прибытия у нас зависит от предыдущего звена: когда дизайнер нарисует макет, или инженер по требованиям разработает требования, или ПМ напишет юзер-стори.<br \/>\nПолучается несколько последовательных очередей, выход из одной становится входом в другую — про это тоже будет в книге.<\/p>\n<p>Дисциплина очереди в разработке обычно задается приоритетом, а механизм обслуживания зависит от типа задачи и команды.<\/p>\n<p>Принципы начнем рассматривать в следующих постах.<\/p>\n",
            "date_published": "2024-05-14T18:22:21+05:00",
            "date_modified": "2024-07-10T05:53:46+05:00",
            "tags": [
                "pdflow",
                "post",
                "Дон Рейнертсен",
                "менеджмент",
                "очереди"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Tue, 14 May 2024 18:22:21 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "127937",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        }
    ],
    "_e2_version": 4079,
    "_e2_ua_string": "Aegea 11.0 (v4079e)"
}