Комментарии 57
Прокрутите это в голове и сравните два вопроса: «Когда вы выполните эту задачу?» и «Сможем ли мы решить задачу к такому-то сроку?» На какой вам будет проще ответить?
На мой взгляд, ответ на второй вопрос (от человека, разбирающегося в планировании), никогда не будет "Да" или "Нет", а будет что-то вроде "Да, с вероятностью 0.01". То есть, скорее всего нет, но может быть что и да.
И ничего при этом на практике от смены постановки вопроса не поменяется, потому что знать эту вероятность вы все равно будете очень приблизительно. По крайней мере для задач, которые вы никогда раньше не делали, и не имеете четкого представления об их сложности. То есть, вместо нечеткого ответа на вопрос "когда" вы получите такой же нечеткий ответ на вопрос, с какой вероятностью мы получим результат, разве нет?
>По крайней мере для задач, которые вы никогда раньше не делали, и не имеете четкого представления об их сложности.
Для задач о которых мы мало что знаем, вероятность будет низкая, действительно.
Однако если имеем ответ когда это надо, нам будет проще искать инфомрацию для ответа на этот вопрос.
Все еще не улавливаю, почему проще-то? Ведь по сути, чтобы понять, сумеем ли мы выполнить задачи к такому-то, нам все равно нужно:
получить список задач, определиться с зависимостями между ними, построить критический путь
для каждой задачи прикинуть распределение времени выполнения
получить распределение времени выполнения всех задач на критическом пути
Ответ "Да, мы успеваем" эквивалентен тому, что дата старта + время выполнения задач с критического пути с определенной вероятностью меньше требуемой даты завершения.
Единственное что меняется, если мы фиксируем дату завершения - это наверное объем работ. И его можно сократить, если мы понимаем, что не успеваем. Но чтобы понять - все равно надо проделать вот этот весь анализ. Про который вы сами написали, что он сложный :)
Ну т.е. если совсем просто - информация-то для анализа все равно нужна та же самая, разве нет? Мне кажется, эта простота - чисто психологическая. Нам удобнее иметь дело с задачей в такой постановке.
Да, все верно, нам все равно нужно собрать информацию которая позволит ответить на вопрос.
Считаю, что изменение формы вопроса, позволяет начать сбор это информации проще. Как отметил в статье, при закрытом вопросе легче воспринимается и логика рассуждения и поиска дополнительной информации. Это полезно тогда когда еще очень мало информации, в самом начале.
Однако, если у вас уже есть наработанный аппарат по прогнозированию, например вы собрали модель своего процесса и используя Монте-Карло определяете сроки, то вам уже не так важно будет как поставлен вопрос о сроках.
Хороший и детальный рецепт прогнозирования, спасибо.
Вам спасибо за обратную связь
Хочу добавить, что контрольные карты Шухарта работают только для статистически управляемых процессов. То есть для таких величин, вариации в которых обусловлены исключительно трушным рандомом, а любая вариация обусловленная не природой рандома уже рассматривается как "специальная причина".
В айтишечке процессы в основном "статистически неуправляемые". Нет однотипных задач, вариации (в т.ч. в длительности выполнения задач) обусловлены не фактором случайности, и т.д.
JIRA рисует не контрольную карту Шухарта, конечно же. Это какая-то другая контрольная карта. Либо не контрольная карта вовсе, и её не следует называть контрольной картой.
Ради интереса посчитал свою статистику :)
Для большого количества задач фактическое время совпадает с оценкой с точностью до дня. В целом я обычно завышаю оценку на 1-2 дня:
Хотя я делаю это осознанно, интересно какое было бы распределение в противном случае. Возможно не получается нормальное распределение из-за того, что люди склонны перестраховываться или давать другим людям запас времени на задачу.
В сумме у меня получилась перестраховка на 42% - я реально посчитал, а не взял это число из Автостопом по галактике :). Правда это по мелким задачам. Возможна ситуация, что задачу завершили раньше, но завели по ней ещё несколько багов, которые тоже исправили раньше. Но если посмотреть в сумме за год, то эта перестраховка в итоге выходит примерно в ноль.
Кстати, что интересно я от разных людей слышал про коэффициент риска равный квадратному корню из двух - sqrt(2) = 1.41, что удивительно близко к моей интуитивной перестраховке.
42% - Это почти стандартный размер буфера критической цепи. Там размер буфера - 50% длительности цепи.
>Возможно не получается нормальное распределение из-за того, что люди склонны перестраховываться или давать другим людям запас времени на задачу.
Нормальное распределение не получается потому, что это время. Оно не умеет ходить назад. И если задаться анализом временных рядов, то работать будете всегда с логарифмическими распределениями в положительную сторону.
А вот распределение пропускной способности, вполне может подчиняться нормальному распределению.
Отмечу что, когда мы говорим про Lead Time, хорошо все таки рассматривать в качестве исследуемых элементов работы элементы уровня "Customer Work Item". Если вы приводите метрики для задач которые являются результатом декомпозиции CWI, и измерение Lead Time по ним, действительно начинается от согласования с заказчиками на их реализацию, то ваша картина очень похожа больше на сервис поддержки, или выборку по багам. Там возможны такие показатели.
А посчитайте коэффициент корреляции между оценкой и фактом. Визуально на втором графике корреляция в лучшем случае очень слабая.
И по мелким задачам мы умеем давать прогноз неплохо обычно. Проблемы начинаются когда начинаем прогнозировать проекты или большие фичи :)
Итак, мы получаем рецепт, как правильно прогнозировать выполнения задач
Поделюсь бесплатным рецептом. Допустим, вы "спрогнозировали" и обозначили дедлайн команде к 1 января. Постарайтесь либо с вашей стороны, либо со стороны клиента создать буфер, на всякий случай. Пусть это будет неделя/месяц за который в нормальной ситуации клиент платить не будет, а если наступит плохой случай, у команды разработки будет время спокойно все доделать.
Очень не хватает примера. Чтобы прочувствовать и понять.
А то (на первый взгляд) кажется, что вся эта непредсказуемость проистекает из-за отсутствия должной декомпозиции до элементарных операций, длительность выполнения которых надёжно определяется.
А ещё есть такой момент. Когда берутся за какой-то проект, то не имеют заранее всех нужных библиотек. Их делают по ходу реализации проекта. Было бы любопытно посмотреть на ситуацию, когда контора получает лицензию на производство определённого ПО только при наличии заранее созданного набора инструментов. Ведь, если эти инструменты есть, то и создание каждого ПО можно будет заранее предсказывать.
В последнее время я замечаю что вся непредсказуемость возникает из-за.... "Да ну нафиг оценивать в днях, давай в майках, или вообще не будем оценивать.". А потом начинаются попытки применить "процессы поддержки" где SLA есть и атомарность для основной разработки. И в итоге "статистика что-то не очень".
>Было бы любопытно посмотреть на ситуацию, когда контора получает лицензию на производство определённого ПО только при наличии заранее созданного набора инструментов.
Это называется "Сертификация компании по уровню CMMI", правда Мотороле это не очень помогло, но модель хорошая и понятная.
>А ещё есть такой момент. Когда берутся за какой-то проект, то не имеют заранее всех нужных библиотек
Эта проблема может быть решена правильным алгоритмом планирования "от конца" , простой вариант алгоритма тут: https://pulsemanagement.org/rules-create-plan/ , полный в вариант в книге Детмера , называется "мыслительный процесс дерево перехода". Но... "это сложно". Хотя если нужно выполнить проект в срок то есть два пути: или планировать как выше указал или стандартизировать все операции и считать по функциональным точкам.
Отсутствие библиотек (или понимания того, как нужно выполнить задачу) - это вполне стандартная ситуация для разработки. Основная проблема состоит в том, что большинство команд не рассматривают планирование, как процесс, на который тоже тратится время. В случае отсутствия библиотеки, мы приходим к ситуации, когда основная задача не может быть выполнена ни к какому сроку. И нам требуется время, чтобы решить: будем ли мы писать свою библиотеку, или закажем еë на аутсорсинге, или нам вообще можно обойтись без неë? Вот тут и вступают в игру мыслительные процессы и деревья принятия решений. Их цель - оценить промежуточный этап. Например, реализацию недостающей библиотеки. После этого, будет ещë один этап оценки, где предстоит определить: достаточно ли принятых мер для решения задачи? Но, опять же, на это нужно время.
Основная проблема разработки - это достаточность времени на планирование. Как-правило, заказчика смущает необходимость оплачивать планирование и промежуточные этапы. Плюс, для мелких проектов планирование нужно сокращать, а для крупных, наоборот, увеличивать. Но, бывает так, что мелкий проект разрастается, и команда с заказчиком не могут определить это время, когда необходимо закладывать больше часов на планирование. При этом, от вида работ зависит: стоит их оценивать в часах, или в майках? Также, это зависит от конкретной реализации. Чем лучше архитектура проекта, тем больше возможность оценить работу в часах. Также, на это влияет и инфраструктура. Например, если от меня требуется только написать код и сделать МР, при том, что дальнейшая доставка кода пройдëт автоматически и быстро, то мне будет проще оценить работу в часах. Если же мне придëтся решать конфликты слияния, ошибки в тестах, несовместимость с другими компонентами, то мне легче использовать стори-поинты (легко, средне, тяжело, очень тяжело). При этом, забавно, что если адекватно планировать проект на ранних этапах разработки, уделяя этому процессу чуть больше времени, то ситуации, когда архитектура или инфраструктура затрудняют оценку, происходят реже.
Полагаю, что тема зависимости единиц измерения оценки от параметров проекта, нуждается в более качественном описании и осмыслении. Однако, совершенно понятно, что для работы часы являются более приемлемой единицей измерения, чем стори-поинты. И переход оценки на стори-поинты следует оценивать, как сигнал к тому, что необходимо пересмотреть архитектуру проекта или другие блокеры, побуждающие уходить от точной оценки - к субъективной, примерной оценке.
Все верно! Только...
Час - это слишком точно для слишком неточной оценки
https://bipulse.ru/blog/index.php?post/2019/08/03/Как-оценивать-задачи
Посмотрел алгоритм https://pulsemanagement.org/rules-create-plan/
Очень даже хорош!
должной декомпозиции до элементарных операций
Во-первых, это далеко не бесплатно, т.е. это работа (и она еще занимает время), и во-вторых, далеко не всегда вы вообще понимаете, на какие операции нужно декомпозировать. И пока всю систему не спроектируете - не узнаете. Ну т.е. я бы сказал, что тут компромисс между точностью прогноза, и моментом, когда вы можете его дать. Чем позже - тем у вас как правило в наличии более точная декомпозиция задач, и более точный прогноз. Но магически получить прогноз раньше на год с той же точностью вы не сможете.
Спасибо за обратную связь.
Пример с разбором я планирую сделать в следующей статье, или в статье через одну.
Наконец то нормальный подход к оценки времени.
Хорошо бы чтобы эта статья выросла в курс для менеджеров по управлению проектом. 😀
@mad_nazgulесть уже курсы связанные с этим, правда не все публичные.
Это как вы хорошо завернули! Непонятные задачи сделайте понятными, и тогда они будут прогнозируемы и оцениваемы. Все верно :)
А где время на упрощение и ресерч? Зачастую в задачах с большой неопределенностью это отнимает бОльшую часть времени.
@anzв общем вы верно уловили конву. Только добавлю, что в статье говорится и о проблеме того, что в работу не всегда берутся задачи которые хорошо проработаны, а значит определенный риск переноситься на команду разработки — что собственно вы и подсветили во втором абзаце вашего сообщения.
И чем больше набранных рисков уходит на Downstream тем больше шансов того, что какие-то из них сработают.
Собственно и весь процесс Upstream нужно тюнить под то, чтобы как можно меньше рисков уходило в Downstream.
Я думаю подробнее расписать свой опыт настройки процесса в следующей статье, где хочется раскрыть более подробнее проблему с рисками и процессом Upstream
Мне кажется вы жульничаете. Для конечного заказчика лид тайм - от попросил до сделали.
И то, что вы анализ не включаете в разработку, а начинаете считать лид тайм с последнего участка, на котором уже почти все задачи симпл конечно дает вам возможность сказать про прогнозируемость лид тайма команды разработки... Но это искусственный лид тайм, и разработка тоже искусственная.
Ну примерно как за время строительства нетипового дома только работу каменщиков и штукатуров брать. А геологов, архитекторов и проектный институт оставлять за скобками.
почему-то первый комментарий так и не отобразился
Да, вы правы в том, что 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.
И поработать в эту сторону лучше свои процессы.
По мне так у всех задач lead time начинается с upstream. И все техники тюнинга и upstream и downstream и вынос рисков на ранний этап и прочее это про сокращение lead time и про устранение потерь.
А вот предсказуемость наверно может дать техника MMF (minimum marketable feature) тогда все фичи становятся примерно одинаковые.
И ещё такой вопрос как этот подход помогает оценивать вехи на дорожной карте?
Если вы считает Time To Market — это все таки не то же самое, что Lead Time.
И все техники тюнинга и upstream и downstream и вынос рисков на ранний этап и прочее это про сокращение lead time и про устранение потерь.
Кстати не обязательно про сокращение Lead Time, может быть это про уменьшение дисперсного разброса, зависит от необходимой задачи, и повышения предсказуемости.
MMF, техника полезная и контекстная, и это про Time To Market.
И ещё такой вопрос как этот подход помогает оценивать вехи на дорожной карте?
Тут бы понять, что вы конкретно вкладываете в словосочетание "оценивать вехи", как вы представляете это действие, чтобы попробовать ответить на ваш вопрос.
Тут бы понять, что вы конкретно вкладываете в словосочетание "оценивать вехи", как вы представляете это действие, чтобы попробовать ответить на ваш вопрос.
Ну есть дорожная карта, есть плановый (ну или прогнозируемый) срок выпуска релиза. И в этот горизонт планирования входят не только карточки из downstream-а, и даже не только из upstream-а, но даже и с этапа синтеза...
И так, если я верно вас понял, то вы говорите о том, что
Дорожная карта — это набор вех которые изначально не связаны со временем.
План — это приземление дорожной карты на время, когда веха привязывается к какой-то дате, а значит сразу дает информацию "а когда это надо", исходя из анализа и определения рисков, вехи на дорожной краты возможно может уточнятся по сроку, формируя план.
Получается, так что анализ и моделирование сроков для достижения вех по дорожной карте создают план.
Тогда ответ на вопрос
И ещё такой вопрос как этот подход помогает оценивать вехи на дорожной карте?
Будет помогать косвенно. Скорее подход помогает лучше ориентироваться в построении плана.
Если для вас дорожная карта уже связана со сроками, тогда ответ на вопрос будет таким:
Будет помогать напрямую в моделировании сроков. Так как мы находим риски, а с учетом выстроенного стабильного процесса позволяет определять и сроки выполнения работ с определенной точностью, которую, кстати, можно так же измерить и отслеживать за счет наблюдения за инквартильным размахом или отслеживанием тонких и толстых хвостов на "Lead Time".
Конечно, важно в построении процессов учесть ньюансы своего контекста и лучше разобраться где у вас Time To Market, где фактический Lead Time.
Доброго времени суток.
Спасибо за материал.
Возник вопрос по поводу расчета Lead Time и использование его как показателя качества оценки задач.
Разве при оценке задач мы учитываем промежуток времени с момента как задача перешла в ToDo до момента как она перешла в Developing? В моем понимании, когда мы ставим оценку, мы сознательно отбрасываем этот промежуток и он определяется в основном важностью/приоритетом задачи, а не ее сложностью.
Ведь, если мы работаем по спринтам, то это логичино, что таска на 1sp висит до последнего дня спринта, а потом выполняется за пару часов. При этом ее Lead Time = весь спринт. Тоже самое валидно и при работе без спринтов, если есть буферное время между ToDo и Developing.
Интересно было бы посмотреть на Ваши графики после вычитания (ToDo - Developing)-периода из Lead Time.
Возник вопрос по поводу расчета Lead Time и использование его как показателя качества оценки задач.
Предполагаю, что вы говорите о корреляции.
Разве при оценке задач мы учитываем промежуток времени с момента как задача перешла в ToDo до момента как она перешла в Developing?
Нет, Lead Time рассчитывается от момента принятия решения о том, что задачу берем в работу, до момента ее поставки клиенту или заказчику.
Если у вас настроен процесс так, что с момента попадания задачи в "To Do" и заказчик и команда разработки считают, что эта задача взята в работу — то именно тут и проходит линия Commitment (принятия обязательства). Не всегда это так настроено.
В Scrum обязательство на выполнение наступает с момента старта спринта, например.
В моем понимании, когда мы ставим оценку, мы сознательно отбрасываем этот промежуток и он определяется в основном важностью/приоритетом задачи, а не ее сложностью.
Честно сказать, я не понял сути этого изложения и не понимаю связи в этом предложении между важностью/приоритетом и сложностью. В статье про приоритеты ничего не было.
Если вы имели ввиду, что время от момента того как задача попадает в "To Do" до момента начала непосредственно работ "Developing"/"In Progress", у нас это время называется "Reaction Time". И "Reaction Time" входит в "Lead Time".
Кроме этого в "Lead Time" входит все время ожиданий в буферных состояниях от начала работ до завершения, например такие как "Ready to Review", "Ready to Test", "Ready to Deploy", как и Action состояния "Developing", "Review", "Testing", ...
Это, действительно все нужно учесть в Lead Time, потому что Lead Time — это именно время ожидания исполнения обязательства, которое на себя взяла команда по решению задачи.
С этим может быть связана еще и проблема "отложенного" ожидания. Когда заказчик задачи поставив ее, думает, о том, что команда уже над ней работает, а команда даже и не думала начинать. Такие ситуации приводят к конфликтам.
Пример Явного обязательства, который не приведет к таким проблемам
И вот пример не явного обязательства, в этой ситуации конфликтов не избежать
Ведь, если мы работаем по спринтам, то это логичино, что таска на 1sp висит до последнего дня спринта, а потом выполняется за пару часов. При этом ее Lead Time = весь спринт. Тоже самое валидно и при работе без спринтов, если есть буферное время между ToDo и Developing.
Если вы работаете по спринтам, "Lead Time" может сильно отличатся от спринта. Допустим, во время спринта вы поняли что можете поставить быстрее функционал — это раз.
Допустим, вы не успели за спринт задачу и переносите ее на другой — это два
Только в случае если у вас всегда спринты завершаются поставкой инкримента и по завершению спринта вы отдаете результат клиенту или заказчику, то "Lead Time" будет равен спринту. Что довольно редкое явление к сожалению.
Интересно было бы посмотреть на Ваши графики после вычитания (ToDo - Developing)-периода из Lead Time.
Для команд у которых "Reaction Time" не большой разница будет не сильной. Актуально кстати, для коротких циклов планирования или для ситуаций с настроенным процессом без планирования.
А какой смысл смотреть на "Lead Time", который раскрывает проблему ожидания клиентом своей задачи считать без "Reaction Time"? Ведь именно от "Lead Time" он будет расчитывать все свои планы и договоренности с вами. И время без учета "Reaction Time" нужно только команде разработки, чтобы потешить себя. С точки зрения построения процесса в общем, это бессмысленно.
А какой смысл смотреть на «Lead Time», который раскрывает проблему ожидания клиентом своей задачи считать без «Reaction Time»? Ведь именно от «Lead Time» он будет расчитывать все свои планы и договоренности с вами.
-------------------------
Не обязательно. Это все должно явно решаться и проговариваться, все остальное только допущения.
Конкретно я вижу лишь ошибочность использования Lead Time как показателя качества оценки задач, так как при таком подходе становятся бессмысленными понятия продуктивности/пропускной способности отдельного человека/команды: стори-поинты теряют свои аддитивные свойства, т.к. при наличии нескольких задач в ToDo и их последовательном выполнении Lead Time предпоследней = Reaction Time последней.
Конкретно я вижу лишь ошибочность использования Lead Time как показателя качества оценки задач
А в чем вы видите смысл оценки задач? Для какой цели вы используете?
так как при таком подходе становятся бессмысленными понятия продуктивности/пропускной способности отдельного человека
Вот до момента "отдельного человека" я с вами соглашусь.
И отмечу, что продуктивность отдельного человека вам нужна только в случае если решили вы его уволить, и надо хоть что-то вам на него накопать.
В остальных случаях продуктивность отдельного человека не так важна с точки зрения общего end-to-end процесса команды, а так же отдельная продуктивность команды не так важна если она является сервисной и не в узком звене end-to-end процесса, как продуктивность всей системы в целом (что будет эквивалентно продуктивности узкого звена)
стори-поинты теряют свои аддитивные свойства, т.к. при наличии нескольких задач в ToDo и их последовательном выполнении Lead Time предпоследней = Reaction Time последней.
Story Points в общем-то и не обладают хорошими аддитивными свойствами, если
Они описывают свою зависимость от времени — время связано с распределениями логарифмического вида, тут нет нормальных распределений, чтобы сводить к аддитивности
Они имеют широкие распределения и в рамках своих границ вносят имеют большой разброс в шкале
Так что в итоге вы правы в том, что SP нельзя складывать!
И в общем в них особо смысла нет, если они не используются как названия категорий групп для анализа статистики.
А в чем вы видите смысл оценки задач? Для какой цели вы используете?
Предсказание (с какой-то ошибкой) ресурсов требуемых на реализацию задачи;
Возможность относительного сравнения задач между собой (часто для определения их приоритетов);
Я не спорю с Вами в плане необходимости оценки, sp, их ценности и надежности, а только в доказательном аппарате: мне кажется "не честным" использование Lead Time, когда мы пытаемся определить надежность самой оценки. Т.к., в моем понимании (и уверен 99% работников), при оценке в sp мы рассматриваем задачу как "коня в вакууме" (конечно, это не правильно) и не знаем когда конкретно и кем она будет выполняться, но мы оцениваем именно ее (In-progress - ... - Done) сложность/ресурсы и не учитываем Reaction Time.
Простите, не уверен что понял, что находится по осям последнего графика.
X - количество единиц времени, затраченных на "In-Progress/Review/Testing"; Y - количество таких задач? Если да, то лучше все таки изобразить их на разных графиках по оценках как в статье. Но, если лепестки распределения достаточно точно Вами отмечены, то я скорее склонен увидеть довольно хорошую точность/качество оценки.
мне кажется "не честным" использование Lead Time, когда мы пытаемся определить надежность самой оценки. Т.к., в моем понимании (и уверен 99% работников), при оценке в sp мы рассматриваем задачу как "коня в вакууме" (конечно, это не правильно) и не знаем когда конкретно и кем она будет выполняться, но мы оцениваем именно ее (In-progress - ... - Done) сложность/ресурсы и не учитываем Reaction Time.
Так а кому вообще интересна оценка, которая не связана с Lead Time?
Если оценка не отражает в себе Lead Time, то ее влияние на время ожидания не имеет значения. А значит в этом смысле такая оценка лишь приносит дисбаланс в работу.
Предсказание (с какой-то ошибкой) ресурсов требуемых на реализацию задачи;
А почему просто не использовать пропускную способность для этого и WIP-лимиты?
Простой WIP-лимит по количеству задач, без сложной системы с оценкой в SP. И правила простые — заканчивай что начал, работай максимум над двумя задачами одновременно. И все ресурсы легко считаються. По персональным WIP-лимитам - можем ограничить количество задач на человека, CONWIP-лимитом, количество задач на всю команду, с учетом фактической пропускной способности. SP будет не нужен.
Если же задаетесь вопросом, а что делать людям которые останутся без работы, чем им заняться, то на эту тему очень много уже создано контента даже в российском интернете, например от Алексея Пименова или от Максима Дорофеева и многих других.
В приведенных ссылках есть хорошее видео про WIP-лимиты. А так же про Capacity Allocation
Возможность относительного сравнения задач между собой (часто для определения их приоритетов);
Тип работ определяется через работы которые необходимо воспроизвести и вероятными проблемами с которыми можете столкнуться.
Вы можете обозначить тип работ и числом, конечно. Но тогда будете соблазняться на то, чтобы начать производить арифметические опперации с ними, хотя так нельзя.
Простите, не уверен что понял, что находится по осям последнего графика.
X - количество единиц времени, затраченных на "In-Progress/Review/Testing"; Y - количество таких задач? Если да, то лучше все таки изобразить их на разных графиках по оценках как в статье. Но, если лепестки распределения достаточно точно Вами отмечены, то я скорее склонен увидеть довольно хорошую точность/качество оценки.
Я уверен, что точность оценки, особенно предиктивной, не подходит для того, чтобы правило аддитивности работало для SP.
Да и в общем если понимаем, что мы пробуем складывать в итоге вероятностные значения, при этом забывая про функцию ошибки которая сильно увеличивается при таких сложениях, к тому же часто не учитываем характер зависимых и не зависимых событий завершения задач, то можно однозначно прейти к выводу, что баловаться сложениями SP простыми арефметическими способами приведет к ошибкам.
Либо начнете подгонять всю систему под то, чтобы ваша оценка работала (подгонка) вместо того чтобы генерировала максимум пользы, либо просто расстанетесь с идеей оценивать в SP.
Ведь, если мы работаем по спринтам, то это логичино, что таска на 1sp висит до последнего дня спринта, а потом выполняется за пару часов. При этом ее Lead Time = весь спринт. Тоже самое валидно и при работе без спринтов, если есть буферное время между ToDo и Developing.
И да, я все же настаиваю, что для спринтов не нужны SP. У спринтов есть цель. А цель это по сути и есть CWI, иначе говоря задача вокруг которой собирается вся команда и решает ее.
Если же у вас много разных задач которые вы набираете в спринт, и чтобы не перебрать используете для этого SP, то у вас точно не спринты, а итерации. И, конечно, больше шансов к дистабилизации чем в настоящем Scrum.
Ссылка на «Менеджмент изменений» возвращает 404, видимо, внутренний ресурс?
Спасибо исправил на https://deliverymanager.ru/docs/profession/about
Не могу не задать вопросы, касающиеся распределений.
а) Как можно интерпретировать "распределения Вейбула является логарифмическим"? Семейство Вейбула является частным случаем гамма-распределения (в определенном смысле, с точностью до замены). Логарифмическое распределение - это принципиально другой вид распределения.
б) Почему представленное распределение является именно Вейбулом? Вейбул - это непрерывное распределение, а количество задач строго дискретно.
Почему не дискретное распределение Пуассона (которое как раз описывает количество событий, происходящих с заданной интенсивностью, за единицу времени)?
Для определения типа распределения аргументации "похож график" недостаточно, потому что похожесть можно увидеть любую. Требуется использование критерия.
в) Подбор распределения для величин, зависимых друг от друга (чем, предположительно, являются выполняемые задачи) - задача, которую надо решать очень аккуратно.
Спасибо за вопросы. Очень схожие вопросы я задавался и сам.
По поводу вопроса "а)" вы правы, но так же, если глубже капнуть можно найти разные связи (частный не частный). Тут на хабре даже есть по этому поводу интересная статья https://habr.com/ru/articles/331060/
По поводу вопроса "б)". Лично я склонялся так же больше к истории с распределением Пуассона, но в свое время не смог найти хороших аргументов против мнения Алексея Жеглова. Возможно и вашими стараниями и еще большим углублением в изучении статистики смогу найти эти аргументы.
По этому при написании статьи воспользовался работами Алексея и использовать наработанные материалы от коллег из KU. Как минимум уже упомянутого Алексей Жеглова, и как пример его статья "The Weibull Training Wheels".
Кстати, статью Жеглова прочитал, и в целом вижу, что он так же, как и я, склоняется ныне (в 2019 году :) ) к мнению, что Вейбул - это вещь, которую можно притянуть к ситуации к задачами в неких идеализациях, типа описанной мной ниже, но предсказательной силы от этого знания мало.
А надо идти глубже, в процесс :) По удивительному совпадению - мои тезисы сходны с его.
Соответственно, правильно будет указать не "Логарифмическое семейсвто", а скорее "Гамма-распределение".
Да, семейство распределений, обобщаемых через гамма-распределение. Сюда могут (в зависимости от того, какой смысл мы вкладываем в параметры и какую ситуацию рассматриваем) подходить и экспоненциальное, и Эрланг, и Вейбул.
Отвечая сразу на следующий комментарий - Вейбул параметрически подойдёт, если мы моделируем некую итерацию, где принимаем среднюю интенсивность задач изменяющейся в окрестностях константы в меньшую сторону, и рассматриваем распределение времени выполнения в смысле "от начала итерации до завершения задачи". Это имеет смысл, т.к. в начале задачи завершаются реже, а под конец - быстрее. К сожалению, предсказательная сила применения такого распределения мне кажется сомнительной.
Экспоненциальное - это реальная трудоёмкость задач одинаковой сложности, Эрланг - распределение трудоёмкости многоэтапных задач (поделённых между разными исполнителями).
У меня есть ряд дополнительных соображений, в том числе и с некоторой критикой, которую я собираюсь оформить в отдельную статью. Так что по выходу приглашаю к полемике :) .
По поводу вопроса "в)"
Как прогнозировать время выполнения задач