Привет! Спасибо за такой разбор моей статьи. С удовольствием прочитал.
Считаю, такие разборы очень ценными. И словил себя на мысли, что очень хочу с тобой пообщаться в живую. Может быть даже сможем?! Мне давольно часто приходится искать способы изложения в очень простой форме опуская какие-либо детали и порой приводить доводы на том языке который будет понятен более широкой аудитории. И это может приводить к определенным "аффектам". И мне очень приятно, что ты обратился к такому разбору и с тобой можно провести диалог на более инженерном языке.
Отмечу пару моментов:
"Хвост толщиной 5.6", "широкий разброс", исходя из соображения про сумму распределений, кажутся мне какой-то совсем наугад взятой величиной, но, наверное, она подбиралась для каких-то суперконкретных ситуаций, ограничения на которые в прочитанных мной статьях я не понял.
По поводу значения "5.6", значение взято из отношения 98% к 50% из свойств распределения Вэйбула. Для упрощенной методики менеджмента, которая будет понятна большему количеству людей в материалах по менеджменту (от Kanban Univercty) даже не упоминают откуда это взято, но приводят как готовое решение: "Смотрите вот так, и вот это правильно, а вот так не правильно". В массе это помогает зародить дисскуссию к действию которая позже приводит к положительным решениям. Но, в деталях, конечно, оставляет конфуз. Основа есть, но, в разборе требует деталей.
По поводу использования весов для оценки. Практика показывает, что такая система (по сути над система) требует отдельного процесса по ее корреляции с весами при изменениях в процессах связанными как с ростом продукта, или в общем каких-то изменений в системе управления. Таким образом это требует дополнительных ресурсов на поддержание актуализации весовых функций, это достаточно затратно. И с моей точки зрения излишне.
В твоей статье очень много определенных деталей которые явно имеют основу для дискуссии. Именно по этому было бы и интересно пообщаться в живую (в силу ограниченности времени, и возможности разобрать больше интересных деталей).
Demo режим сейчас у нас в работе, скоро предоставим. Войти в него можно будет без всего вот этого. Правде в Demo-режиме не будут доступна возможность посмотреть кабинет, только рисовашка.
А сейчас можно как пример попросить кого-то у кого есть аккаунт поделится доской по ссылке со входом на доску без регистрации
Добре! Ретро бывает разным. Недавно Оксана Кречко, профессиональный фасилитатор с многолетним стажем, рассказывала в своей статье о своём опыте проведения таких мероприятий. Статью можно прочитать тут.
— Есть ли подобные шаблоны?
— Да, есть, и мы постепенно расширяем их набор. Например, сегодня мы выпустили новый шаблон для "Event Storming".
— Возможность скрывать карточки? — Можно сделать карточки полностью прозрачными или накрывать их другими карточками?
— И как насчёт раундов для голосования и т.д.?
— Вероятно, вы имеете в виду модуль "голосований". Пока мы его не добавляли.
Для рисования BPMN-схем мы работаем над тем, чтобы добавить ортогональные стрелки и готовый набор шейпов. Это не то же самое, что шаблон — это быстрые, отдельно готовые блоки, которые можно сразу добавлять на доску. Плюс будет возможность создавать новые элементы от уже существующих с быстрой связью с помощью стрелок.
В мобильной версии мы временно отключили редактирование до тех пор, пока не протестируем разные способы использования с новым дизайном, который мы готовим к выпуску.
Да, например, у Unidraw с использованием sboard лучше производительность при большом количестве элементов или одновременном редактировании нескольких пользователей.
geoma.space — это платный сервис, что сразу бросается в глаза, но по функционалу его еще нужно сравнивать.
Спасибо за вопросы. Очень схожие вопросы я задавался и сам.
По поводу вопроса "а)" вы правы, но так же, если глубже капнуть можно найти разные связи (частный не частный). Тут на хабре даже есть по этому поводу интересная статья https://habr.com/ru/articles/331060/
По поводу вопроса "б)". Лично я склонялся так же больше к истории с распределением Пуассона, но в свое время не смог найти хороших аргументов против мнения Алексея Жеглова. Возможно и вашими стараниями и еще большим углублением в изучении статистики смогу найти эти аргументы.
По этому при написании статьи воспользовался работами Алексея и использовать наработанные материалы от коллег из KU. Как минимум уже упомянутого Алексей Жеглова, и как пример его статья "The Weibull Training Wheels".
И так, если я верно вас понял, то вы говорите о том, что
Дорожная карта — это набор вех которые изначально не связаны со временем.
План — это приземление дорожной карты на время, когда веха привязывается к какой-то дате, а значит сразу дает информацию "а когда это надо", исходя из анализа и определения рисков, вехи на дорожной краты возможно может уточнятся по сроку, формируя план.
Получается, так что анализ и моделирование сроков для достижения вех по дорожной карте создают план.
Тогда ответ на вопрос
И ещё такой вопрос как этот подход помогает оценивать вехи на дорожной карте?
Будет помогать косвенно. Скорее подход помогает лучше ориентироваться в построении плана.
Если для вас дорожная карта уже связана со сроками, тогда ответ на вопрос будет таким:
Будет помогать напрямую в моделировании сроков. Так как мы находим риски, а с учетом выстроенного стабильного процесса позволяет определять и сроки выполнения работ с определенной точностью, которую, кстати, можно так же измерить и отслеживать за счет наблюдения за инквартильным размахом или отслеживанием тонких и толстых хвостов на "Lead Time".
Конечно, важно в построении процессов учесть ньюансы своего контекста и лучше разобраться где у вас Time To Market, где фактический Lead Time.
Если вы считает Time To Market — это все таки не то же самое, что Lead Time.
И все техники тюнинга и upstream и downstream и вынос рисков на ранний этап и прочее это про сокращение lead time и про устранение потерь.
Кстати не обязательно про сокращение Lead Time, может быть это про уменьшение дисперсного разброса, зависит от необходимой задачи, и повышения предсказуемости.
MMF, техника полезная и контекстная, и это про Time To Market.
И ещё такой вопрос как этот подход помогает оценивать вехи на дорожной карте?
Тут бы понять, что вы конкретно вкладываете в словосочетание "оценивать вехи", как вы представляете это действие, чтобы попробовать ответить на ваш вопрос.
Да, вы правы в том, что Lead Time может начинаться для разных задач с разного этапа. И в этом тоже есть проблема для анализа метрик и процессов.
И, как вы уточнили, есть процессы где Анализ входит в Lead Time, есть где не входит. Хотя чаще всего бывает так, что для разных задач и с разным приоритетом Lead Time может начинаться как и до анализа, так и после, да и в общем с разного этапа. И это одна из проблем при в построении процессов разработки.
И самое не удобное в том, что почти во всех трекерах это не учтено. И сложность сбора метрики Lead Time привод к том, что приходится тюнить процесс в трекере под то, чтобы это получалось.
В нашем внутреннем инструменте, анализа метрик, учитываются эти моменты, чтобы была возможность гибкой настройки и сборы более актуальных данных для анализа.
В статье подсвечена эта проблема на картинках "Методика упрощения", заключающееся в том, что в работу задачи могут быть взяты как полностью подготовленные "Simple", так и не готовые "Complecated". Вы жизни они могут быть взяты в работу по требованию с позиции "сделайте чтобы было хорошо, время пошло". Тогда вы этом случае постановщик задачи перекладывает риски связанные с этой задачей на команду реализающую ее. А команда должна уметь работать с такими рисками, и закладывать в систему управления работой такие особенности.
В частности возникает вопрос: "А как нам ограничивать работу тогда, ведь по количеству задач это не тоже самое, что по количеству рисков задачах?"
Я постараюсь раскрыть более подробно с примером в следующих статьях, где хочу привести примеры как это можно сделать.
Собственно, улучшение процессов будет приводить к тому, что на этапах ближе к релизу, нужно уменьшать количество рисков в пользу более ранних этапов. О чем намекает эта статья.
Об этом много есть информации и методик, та же "Shift Left Testing" концепция тоже про перенос рисков на более ранние этапы.
А так как очень многие не прорабатывают свои Upstream-процессы перекладывая проблемы на Downstream часто приводят к проблемам в реализации.
Я надеюсь, что статья побудит читателей обратить на это внимание, и начать работать над своим Upstream.
Надеюсь, что те кто управляет "бэклогами" Upstream процессами смогут взять себе это на заметку и посмотреть например доклады от Patrick Steyaert про Discovery Kanban https://www.youtube.com/watch?v=iMzw2p68oh8 А так же работы Dimitar Bakardzhiev, например https://www.youtube.com/watch?v=sn0vKLVj9mM, и другие его работы, например как можно уменьшить количество рисков через технику Capacity Allocation.
Простите, не уверен что понял, что находится по осям последнего графика. X - количество единиц времени, затраченных на "In-Progress/Review/Testing"; Y - количество таких задач? Если да, то лучше все таки изобразить их на разных графиках по оценках как в статье. Но, если лепестки распределения достаточно точно Вами отмечены, то я скорее склонен увидеть довольно хорошую точность/качество оценки.
Я уверен, что точность оценки, особенно предиктивной, не подходит для того, чтобы правило аддитивности работало для SP.
Да и в общем если понимаем, что мы пробуем складывать в итоге вероятностные значения, при этом забывая про функцию ошибки которая сильно увеличивается при таких сложениях, к тому же часто не учитываем характер зависимых и не зависимых событий завершения задач, то можно однозначно прейти к выводу, что баловаться сложениями SP простыми арефметическими способами приведет к ошибкам.
Либо начнете подгонять всю систему под то, чтобы ваша оценка работала (подгонка) вместо того чтобы генерировала максимум пользы, либо просто расстанетесь с идеей оценивать в SP.
мне кажется "не честным" использование Lead Time, когда мы пытаемся определить надежность самой оценки. Т.к., в моем понимании (и уверен 99% работников), при оценке в sp мы рассматриваем задачу как "коня в вакууме" (конечно, это не правильно) и не знаем когда конкретно и кем она будет выполняться, но мы оцениваем именно ее (In-progress - ... - Done) сложность/ресурсы и не учитываем Reaction Time.
Так а кому вообще интересна оценка, которая не связана с Lead Time?
Если оценка не отражает в себе Lead Time, то ее влияние на время ожидания не имеет значения. А значит в этом смысле такая оценка лишь приносит дисбаланс в работу.
Предсказание (с какой-то ошибкой) ресурсов требуемых на реализацию задачи;
А почему просто не использовать пропускную способность для этого и WIP-лимиты?
Простой WIP-лимит по количеству задач, без сложной системы с оценкой в SP. И правила простые — заканчивай что начал, работай максимум над двумя задачами одновременно. И все ресурсы легко считаються. По персональным WIP-лимитам - можем ограничить количество задач на человека, CONWIP-лимитом, количество задач на всю команду, с учетом фактической пропускной способности. SP будет не нужен.
Если же задаетесь вопросом, а что делать людям которые останутся без работы, чем им заняться, то на эту тему очень много уже создано контента даже в российском интернете, например от Алексея Пименова или от Максима Дорофеева и многих других.
В приведенных ссылках есть хорошее видео про WIP-лимиты. А так же про Capacity Allocation
Возможность относительного сравнения задач между собой (часто для определения их приоритетов);
Тип работ определяется через работы которые необходимо воспроизвести и вероятными проблемами с которыми можете столкнуться.
Вы можете обозначить тип работ и числом, конечно. Но тогда будете соблазняться на то, чтобы начать производить арифметические опперации с ними, хотя так нельзя.
Привет! Спасибо за такой разбор моей статьи. С удовольствием прочитал.
Считаю, такие разборы очень ценными. И словил себя на мысли, что очень хочу с тобой пообщаться в живую. Может быть даже сможем?!
Мне давольно часто приходится искать способы изложения в очень простой форме опуская какие-либо детали и порой приводить доводы на том языке который будет понятен более широкой аудитории. И это может приводить к определенным "аффектам".
И мне очень приятно, что ты обратился к такому разбору и с тобой можно провести диалог на более инженерном языке.
Отмечу пару моментов:
По поводу значения "5.6", значение взято из отношения 98% к 50% из свойств распределения Вэйбула. Для упрощенной методики менеджмента, которая будет понятна большему количеству людей в материалах по менеджменту (от Kanban Univercty) даже не упоминают откуда это взято, но приводят как готовое решение: "Смотрите вот так, и вот это правильно, а вот так не правильно". В массе это помогает зародить дисскуссию к действию которая позже приводит к положительным решениям. Но, в деталях, конечно, оставляет конфуз. Основа есть, но, в разборе требует деталей.
Кстати, спасибо Василию Савунову, который чуть больше закапывается в материал по источникам в своих статьях на vc.ru и приводил пример откуда это взялось https://vc.ru/u/2611688-vasilii-savunov/1711878-taina-zhirnogo-hvosta
По поводу использования весов для оценки.
Практика показывает, что такая система (по сути над система) требует отдельного процесса по ее корреляции с весами при изменениях в процессах связанными как с ростом продукта, или в общем каких-то изменений в системе управления. Таким образом это требует дополнительных ресурсов на поддержание актуализации весовых функций, это достаточно затратно. И с моей точки зрения излишне.
В твоей статье очень много определенных деталей которые явно имеют основу для дискуссии. Именно по этому было бы и интересно пообщаться в живую (в силу ограниченности времени, и возможности разобрать больше интересных деталей).
На доску с Канбан-Метриками, я открою доступ без регистрации, когда подготовлю свою статью с описанием этой работы.
Сейчас для зарегистрированных пользователей она открыта.
Demo режим сейчас у нас в работе, скоро предоставим. Войти в него можно будет без всего вот этого. Правде в Demo-режиме не будут доступна возможность посмотреть кабинет, только рисовашка.
А сейчас можно как пример попросить кого-то у кого есть аккаунт поделится доской по ссылке со входом на доску без регистрации
Добре! Ретро бывает разным. Недавно Оксана Кречко, профессиональный фасилитатор с многолетним стажем, рассказывала в своей статье о своём опыте проведения таких мероприятий. Статью можно прочитать тут.
— Есть ли подобные шаблоны?
— Да, есть, и мы постепенно расширяем их набор. Например, сегодня мы выпустили новый шаблон для "Event Storming".
— Возможность скрывать карточки?
— Можно сделать карточки полностью прозрачными или накрывать их другими карточками?
— И как насчёт раундов для голосования и т.д.?
— Вероятно, вы имеете в виду модуль "голосований". Пока мы его не добавляли.
Добре!
Для рисования BPMN-схем мы работаем над тем, чтобы добавить ортогональные стрелки и готовый набор шейпов. Это не то же самое, что шаблон — это быстрые, отдельно готовые блоки, которые можно сразу добавлять на доску. Плюс будет возможность создавать новые элементы от уже существующих с быстрой связью с помощью стрелок.
В мобильной версии мы временно отключили редактирование до тех пор, пока не протестируем разные способы использования с новым дизайном, который мы готовим к выпуску.
Да, например, у Unidraw с использованием sboard лучше производительность при большом количестве элементов или одновременном редактировании нескольких пользователей.
geoma.space — это платный сервис, что сразу бросается в глаза, но по функционалу его еще нужно сравнивать.
Собственно о чем вся эта статья, которая похоже сходится с вашими тезисами.
Приятно осознать, что мнения совпадают
Добро!
Уже с интересом жду вашу статью
По поводу вопроса "в)"
Соответственно, правильно будет указать не "Логарифмическое семейсвто", а скорее "Гамма-распределение".
Спасибо за вопросы. Очень схожие вопросы я задавался и сам.
По поводу вопроса "а)" вы правы, но так же, если глубже капнуть можно найти разные связи (частный не частный). Тут на хабре даже есть по этому поводу интересная статья https://habr.com/ru/articles/331060/
По поводу вопроса "б)". Лично я склонялся так же больше к истории с распределением Пуассона, но в свое время не смог найти хороших аргументов против мнения Алексея Жеглова. Возможно и вашими стараниями и еще большим углублением в изучении статистики смогу найти эти аргументы.
По этому при написании статьи воспользовался работами Алексея и использовать наработанные материалы от коллег из KU. Как минимум уже упомянутого Алексей Жеглова, и как пример его статья "The Weibull Training Wheels".
Спасибо исправил на https://deliverymanager.ru/docs/profession/about
И так, если я верно вас понял, то вы говорите о том, что
Дорожная карта — это набор вех которые изначально не связаны со временем.
План — это приземление дорожной карты на время, когда веха привязывается к какой-то дате, а значит сразу дает информацию "а когда это надо", исходя из анализа и определения рисков, вехи на дорожной краты возможно может уточнятся по сроку, формируя план.
Получается, так что анализ и моделирование сроков для достижения вех по дорожной карте создают план.
Тогда ответ на вопрос
Будет помогать косвенно. Скорее подход помогает лучше ориентироваться в построении плана.
Если для вас дорожная карта уже связана со сроками, тогда ответ на вопрос будет таким:
Будет помогать напрямую в моделировании сроков. Так как мы находим риски, а с учетом выстроенного стабильного процесса позволяет определять и сроки выполнения работ с определенной точностью, которую, кстати, можно так же измерить и отслеживать за счет наблюдения за инквартильным размахом или отслеживанием тонких и толстых хвостов на "Lead Time".
Конечно, важно в построении процессов учесть ньюансы своего контекста и лучше разобраться где у вас Time To Market, где фактический Lead Time.
Если вы считает Time To Market — это все таки не то же самое, что Lead Time.
Кстати не обязательно про сокращение Lead Time, может быть это про уменьшение дисперсного разброса, зависит от необходимой задачи, и повышения предсказуемости.
MMF, техника полезная и контекстная, и это про Time To Market.
Тут бы понять, что вы конкретно вкладываете в словосочетание "оценивать вехи", как вы представляете это действие, чтобы попробовать ответить на ваш вопрос.
почему-то первый комментарий так и не отобразился
Да, вы правы в том, что Lead Time может начинаться для разных задач с разного этапа. И в этом тоже есть проблема для анализа метрик и процессов.
И, как вы уточнили, есть процессы где Анализ входит в Lead Time, есть где не входит. Хотя чаще всего бывает так, что для разных задач и с разным приоритетом Lead Time может начинаться как и до анализа, так и после, да и в общем с разного этапа. И это одна из проблем при в построении процессов разработки.
И самое не удобное в том, что почти во всех трекерах это не учтено. И сложность сбора метрики Lead Time привод к том, что приходится тюнить процесс в трекере под то, чтобы это получалось.
В нашем внутреннем инструменте, анализа метрик, учитываются эти моменты, чтобы была возможность гибкой настройки и сборы более актуальных данных для анализа.
В статье подсвечена эта проблема на картинках "Методика упрощения", заключающееся в том, что в работу задачи могут быть взяты как полностью подготовленные "Simple", так и не готовые "Complecated". Вы жизни они могут быть взяты в работу по требованию с позиции "сделайте чтобы было хорошо, время пошло". Тогда вы этом случае постановщик задачи перекладывает риски связанные с этой задачей на команду реализающую ее. А команда должна уметь работать с такими рисками, и закладывать в систему управления работой такие особенности.
В частности возникает вопрос: "А как нам ограничивать работу тогда, ведь по количеству задач это не тоже самое, что по количеству рисков задачах?"
Я постараюсь раскрыть более подробно с примером в следующих статьях, где хочу привести примеры как это можно сделать.
Собственно, улучшение процессов будет приводить к тому, что на этапах ближе к релизу, нужно уменьшать количество рисков в пользу более ранних этапов. О чем намекает эта статья.
Об этом много есть информации и методик, та же "Shift Left Testing" концепция тоже про перенос рисков на более ранние этапы.
А так как очень многие не прорабатывают свои Upstream-процессы перекладывая проблемы на Downstream часто приводят к проблемам в реализации.
Я надеюсь, что статья побудит читателей обратить на это внимание, и начать работать над своим Upstream.
Надеюсь, что те кто управляет
"бэклогами"Upstream процессами смогут взять себе это на заметку и посмотреть например доклады от Patrick Steyaert про Discovery Kanban https://www.youtube.com/watch?v=iMzw2p68oh8А так же работы Dimitar Bakardzhiev, например https://www.youtube.com/watch?v=sn0vKLVj9mM, и другие его работы, например как можно уменьшить количество рисков через технику Capacity Allocation.
И поработать в эту сторону лучше свои процессы.
Посмотрел алгоритм https://pulsemanagement.org/rules-create-plan/
Очень даже хорош!
Значит вы работаете с людьми которые не используют Lead Time.
Мой не скромный опыт как раз показывает другое.
Я уверен, что точность оценки, особенно предиктивной, не подходит для того, чтобы правило аддитивности работало для SP.
Да и в общем если понимаем, что мы пробуем складывать в итоге вероятностные значения, при этом забывая про функцию ошибки которая сильно увеличивается при таких сложениях, к тому же часто не учитываем характер зависимых и не зависимых событий завершения задач, то можно однозначно прейти к выводу, что баловаться сложениями SP простыми арефметическими способами приведет к ошибкам.
Либо начнете подгонять всю систему под то, чтобы ваша оценка работала (подгонка) вместо того чтобы генерировала максимум пользы, либо просто расстанетесь с идеей оценивать в SP.
Так а кому вообще интересна оценка, которая не связана с Lead Time?
Если оценка не отражает в себе Lead Time, то ее влияние на время ожидания не имеет значения. А значит в этом смысле такая оценка лишь приносит дисбаланс в работу.
А почему просто не использовать пропускную способность для этого и WIP-лимиты?
Простой WIP-лимит по количеству задач, без сложной системы с оценкой в SP. И правила простые — заканчивай что начал, работай максимум над двумя задачами одновременно. И все ресурсы легко считаються. По персональным WIP-лимитам - можем ограничить количество задач на человека, CONWIP-лимитом, количество задач на всю команду, с учетом фактической пропускной способности. SP будет не нужен.
Если же задаетесь вопросом, а что делать людям которые останутся без работы, чем им заняться, то на эту тему очень много уже создано контента даже в российском интернете, например от Алексея Пименова или от Максима Дорофеева и многих других.
В приведенных ссылках есть хорошее видео про WIP-лимиты. А так же про Capacity Allocation
Тип работ определяется через работы которые необходимо воспроизвести и вероятными проблемами с которыми можете столкнуться.
Вы можете обозначить тип работ и числом, конечно. Но тогда будете соблазняться на то, чтобы начать производить арифметические опперации с ними, хотя так нельзя.