Всем привет! Я Анастасия Жадринская, деливери-менеджер в Тинькофф. Да, эта статья опять про оценки и сроки выполнения задач. Сроки без вуду, астрологии, гаданий и привлечения экспертов. В статье рассмотрю метод Монте-Карло — элегантный и простой в применении математический подход для прогнозирования сроков завершения проектов или объема выпуска задач.
Подробнее про метод
Метод Монте-Карло — математический метод, который прогнозирует возможные исходы неопределенного события. Суть метода заключается в том, что процесс описывается математической моделью с использованием генератора случайных величин, модель многократно обсчитывается, на основе полученных данных вычисляются вероятностные характеристики рассматриваемого процесса
Модель Монте-Карло берет реальные показатели объема выпуска задач за некоторый промежуток времени. Обсчитывает эти данные с помощью модели, повторяя вычисления тысячи раз. В результате расчетов у нас получаются тысячи результатов прогноза. Модель берет их и рассчитывает, с какой вероятностью произойдет тот или иной исход. На выходе мы получаем диаграмму распределения вероятности прогноза. В статье мы рассмотрим инструмент Троя Маггениса, автора книги Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation, который помогает использовать модель для расчета прогнозов в ИТ.
Монте-Карло на примере
Допустим, есть данные по объему завершенных Feature за последний год. Мы хотим спрогнозировать, к какой дате и с какой вероятностью мы завершим 80 Feature.
Берем данные о выпуске и загружаем их в симулятор, вписываем количество задач, по которым хотим получить прогноз. На основе этих данных симулятор формирует ряд случайных моделей и выдает итоговое распределение прогнозируемых дат выполнения 80 задач с разной степенью вероятности.
Пример прогноза:
со 100%-й вероятностью мы закроем 80 Feature за 18 месяцев, дата завершения — 16.02.2025;
-
с 85%-й вероятностью мы закроем 80 Feature за 14 месяцев, дата завершения — 27.10.2024.
Что повлияет на точность прогноза? Стабильность системы. Она определяется повторяемостью результатов вашей команды. Чем меньше разброс выпуска задач между месяцами, тем система предсказуемее. Как сделать систему более стабильной? Ограничивайте количество незавершенной работы.
Как построить такой прогноз для задач:
Скачать файл Throughput Forecaster.xlsx.
Заполнить исторические данные. Для этого переходим на вкладку Historical Samples и в графе заполняем Enter Samples Below исторические значения по выпуску вашей команды. Порядок внесения данных не имеет значения. Если вы пользуетесь Jira, данные по команде можно найти в отчете Throughput в плагине JFC. Можно взять период 1, 2, 3 или 4 недели. Минимальное количество периодов для расчета прогноза — 7. Максимальное количество периодов неограниченно, но лучше использовать периоды в рамках года: так на ваш прогноз не будут влиять данные, которые уже не актуальны, ведь скорость изменений в ИТ крайне высока.
Для корректности прогноза стоит учитывать консистентные данные. Например:
загружаем данные по закрытым Feature + Bug, прогноз строится для Feature + Bug;
загружаем данные по закрытым Feature, прогноз строится только для Feature.
Также мы рекомендуем рассчитывать прогноз по задачам, несущим дискретную ценность для клиента, например по Feature. Но и прогноз по более низкому уровню декомпозиции может быть полезен. Главное — не смешивать разные уровни декомпозиции, например Feature и Sub-task.
Настроить прогноз. Для этого переходим на вкладку Forecast и начинаем заполнять поля по условиям нашего прогноза:
Start Date – дата с которой будет рассчитываться прогноз.
How many stories are remaining to be completed? Для какого количества задач мы хотим рассчитать результаты прогноза, интервал или точное количество. Scope complexity — коэффициент для оценки сложности объема работ. Чем точнее вы понимаете декомпозицию и требования к общему скоупу работ, тем ниже этот коэффициент. Если вы работаете с большой степенью неизвестности, коэффициент повышается. Значения корректирующего коэффициента можно настроить на вкладке Settings.
Stories are often split before and whilst being worked on. Estimate the split rate low and high bounds. Здесь мы указываем степень уверенности в декомпозиции текущего бэклога. 2 значения указаны для того, чтобы мы могли оценить разброс значений декомпозиции. 1 означает, что мы на 100% уверены в том, что прогнозируемые задачи не будут декомпозироваться на более мелкие элементы. Например, мы предполагаем, что каждая из задач в прогнозе декомпозируется еще на 2—5 подзадач, указываем low — 2, high — 5.
Throughput. How many completed stories per week or sprint do you estimate low and high bounds? Указывает заданный интервал по выпуску задач в Historical Samples. Например, в каждой ячейке указан выпуск за 4 недели, указывайте его тут.
Use historical throughput/velocity data OR enter a low and high estimate below. Выбираем Data, так ваш прогноз будет основываться на исторических данных.
Прочие поля остаются без изменений.
Получить результаты — это таблица с распределением вероятности длительности завершения наших задач.
Пример:
со 100%-й вероятностью мы закроем 80 задач за 18 месяцев, дата завершения — 19.05.2024;
с 85%-й вероятностью мы закроем 80 задач за 14 месяцев, дата завершения — 28.01.2024.
Красные значения: не стоит рассчитывать на эти сроки ни при каких обстоятельствах. Желтое: тоже довольно безответственно, вероятность 50% равна броску моменты: может быть, успеете, а может быть, и нет. Зеленое: то, на что стоит опираться, понимая, что даже 85% означает, что есть один шанс из восьми (немало, да?) в этот срок не уложиться. Приемлемый это для вас риск? Если да, вперед, если нет, лучше брать более вероятный прогноз
Продвинутая настройка учитывает возможное отвлечение команды на другие задачи по сравнению с нашими использованными историческими данными. Для этого нужно выбрать подходящий уровень фокусировки на запланированной работе.
Вопрос — ответ
Чем такие прогнозы отличаются от экспертных прогнозов аналитиков? Они учитывают всю неопределенность, с которой встречалась команда, — живой человек так не сможет.
Экспертные прогнозы учитывают только фактическое время работы над задачей, а это в нашей индустрии бесполезно, так как гораздо больше времени занимают разные ожидания, блокировки и тому подобное.
Прогнозы методом Монте-Карло практически не требуют затрат и считаются стандартом прогнозирования в смежных индустриях вроде промышленности, химии, экономики.
Как понять, можно ли доверять моему прогнозу? Убедитесь, что вы ввели верные исторические данные. Результаты расчета напрямую зависят от их точности.
Если с данными все в порядке, можно оценить степень достоверности по выбранной вероятности. Вероятность наступления прогноза от 85 до 100% считается высокой. 50% говорит о том, что прогноз может сбыться и не сбыться с одинаковой вероятностью — подбросьте монету. Наступление событий с прогнозом ниже 50% можно считать маловероятными, лучше не использовать такой прогноз.
Что делать, если нет исторических данных? Можно попробовать взять исторические данные с похожей команды или просто придумать их. Но правдоподобность прогноза в таком случае будет стремительно ухудшаться.
Лучше поработать до закрытия 7—11 задач новой командой и перестроить прогноз уже реальной командой.
Как сделать прогнозы точнее? Делайте процесс более предсказуемым. Вот простейшие шаги к улучшению качества прогнозов.
Что делать? |
Зачем делать? |
Визуализируйте всю работу |
Так у вас будут точные исторические данные и средство контроля незавершенки |
Ограничивайте количество незавершенной работы |
Так вы нормализуете сроки и объем выпуска |
Завершайте начатую работу, не откладывайте ее в блок |
Так вы решите проблему скачущих объемов выпуска |
Декомпозируйте работу |
Так ваш ритм выпуска станет более управляемым и предсказуемым |
Можно ли попроще, без вот этих excel-файлов? Да, можно. Скачивайте Chrome-расширение Jira Flow Companion, нажимайте Analyze около названия вашей доски. На крайней правой вкладке расширения будет тот же самый Монте Карло, построенный на основании данных вашей доски.
Не забудьте отфильтровать данные быстрыми фильтрами Jira! Но excel-файл дает возможность сделать более тонкие настройки.
Как мне получить данные по выпуску команды? Данные о производительности команды можно посмотреть через расширение Chrome для Jira — Jira flow companion. После установки на доске команды появится кнопка Analyze Flow, нажмите на нее и перейдите в отчет Throughput. Если команда использует спринты, можно взять данные по спринтам из отчетов Jira.
В команде менялись типы задач в течение года. Какие указывать? Указывайте максимально схожие типы задач. Например, первые полгода команда работала с одним типом, затем вы разделили их на два. Для общего прогноза указывайте один тип в первые 6 месяцев и сумму по двум новым в следующие 6 месяцев. Так вы построите прогноз для двух типов задач.
Как построить прогноз по проекту, в котором участвует больше одной команды? Если команды выполняют работы в некоторой логической последовательности: рассчитываем прогноз по критической цепи. Для каждого из этапов проекта используем прогноз сроков работы только основной команды, работающей на этом этапе, остальные команды игнорируем. Потом выстраиваем полученные в разрезе этапов прогнозы в логическую последовательность — так получаем общий прогноз по проекту.
Такое прогнозирование используют регулярно — с каждой неделей появляются новые данные по производительности и изменению скоупа. Было бы расточительно не строить новые прогнозы на постоянной основе, ведь они с каждым разом будут все точнее.
Комментарии (25)
Batalmv
10.10.2023 08:37+6Блин, я фигею, дорогая редакция :)
Ну честно, все команды уникальны, проекты уникальны - что вы в таких условиях хотите мерять? Ну да, статистически можно подсчитать любую математическую ересь типа "ПМ завшает сроки сдачи проекта в среднем на 11%, если срок проекта не больше года, и на 23,5% - если больше". Серьезно?
Ну давайте трезво, что у вас есть?
Скоуп в виде backlog либо иного списка, в зависимости от методологии. Точность оценки длительности выполнения каждой задачи? Я думаю, будет плюс минус половина срока, и то - хорошо если так. Понято, есть опция, когда вы много лет пилите один и тот же продукт, и тогда оценки будут лучше. Но извините, в таком случае вы вообще практически в тепличных условиях, по сравнению с разработкой решения с нуля, особенно если оно в принципе новое для организации.
Да и зачем все это. Вы же либо четко знаете дедлайн и требования, если живете в fixed price/fixed scope (на самоми деле нет, но в любом случае, есть контракт и дополнения к нему, и если что - все пойдут его читать). Если же вы относительно гибки, то вопрос в том, не как мерять, а в том, как управлять процессом прихода в продукту, имеющую ценность. Но и в этом случае есть какой-то контракт со сроками и условиями.
Даже если вы внутри организации, и над вами не нависают документы, имеющие прямую юридическую силу - есть практически аналогичные обязательства по внутренним процедурам.
Намного проще и правильнее не "добавлять", а "отнимать". К примеру, вам надо выйти на рынок в день Х. Вы считаете назад. У вас есть пилот на выбранных пользователях, фиксы после него. Условного заложили 3 недели. Тут сложно ошибиться, так как если вы ошиблись, значит имел место быть эпический косяк. Итого имеем день Х - 21 день. Дальше финальные тесты пользователями с фиксами. Условно 4 недели. Отлично, имеет день Х - 49 дней. Вот после этой точки мы, к примеру, не берем новые требования. Значит до того закладываем условно 2 недели, на финализацию того, что есть, полировку и т.д.. Даты и milestones условны, так как зависят от целей проекта, размеров поставки, методологии и кучи всего. Но так намного безопаснее, когда вы от главного milestone отняли длительность обязательных шагов + буффера. И все
У вас есть точка заверщения разработки.
Идете по "гибкой" методологии. Да пожалуйста, все тоже самое, просто надо четче пояснить продакту, что "бантики" пора сворачивать и за пару спринтов трезво посмотреть, что успеваем допилить до дня Х, а что лучше не начинать, так как не успеем.
Но это реально какой-то ... я даже не знаю. Если вы не успеваете, это и так понятно. Вы расставили себе milestones по ходу проекта. Если вы начинаете их проваливать - все, вы не успеваете, и надо чего-то делать. Добавлять людей, чего-то менять внутри, с кем-то прощаться. Для этого есть план при waterfall либо разумный взгляд на backlog.
----------------
Как по мне, скорее "горе от ума". Подмена project execution какими-то ненужными теложвижениями
StepEv
10.10.2023 08:37Для применения метода Монте-Карло не нужны оценки длительности отдельных задач.
Конечно, применять его лучше для той же команды, для которой у нас есть данные.
Всё, что вы описали, расчёт назад от "когда надо", расстановка и контроль промежуточных точек, имеет место, конечно. Но разве это отменяет другие методы?
В чём посыл вашего комментария? Метод не рабочий? Это не так.
Метод не надо применять? Не применяйте. Для нас он работает и результат лучше, чем экспертные оценки "да, вот это мы сделаем тогда-то". Что их не отменяет, но методом они прекрасно проверяются на адекватность.Batalmv
10.10.2023 08:37Просто трата времени. Либо просто презентация руководству некой "супер-пупер" техники :)
Он ничего не дает, если управлять проектов. А если не управлять - не дает тем более :)
zhadrinskaya Автор
10.10.2023 08:37+1Инструмент решает вполне конкретные задачи и не пытается заменить управление проектами. Всё зависит от того, какой вопрос вы ставите.
Предлагается в качестве альтернативы или в дополнение к экспертным оценкам, чтобы не "закладывать", "добавлять", "отнимать".
Batalmv
10.10.2023 08:37-1Ну, такое.
К примеру: тим лид оценил в 8 попугаев, метод - в 5. Вы заложили 5. А итоге сделали за 8. Дальше вам светит короткая лекция на тему важности не поддавать сомнению экспертное мнение, и хорошо, если без сильных выражений. В любом случае, вам менеджерить, а людям делать. Они "подписываются", явно или нет, на свои оценки. Это вопрос психологии на проекте.
Вы ж в проекте не фишки двигаете, а управляете людьми и их взаимоотношениями. Базовая основа планирование - исполнитель оценивает.
Если вам надо оценить некий объем задач для больших планов - тогда вы попадаете в ловушку неточных данных. Это ж тоже математика. Если вам нравится туда идти, то представьте, какая погрешность будет у расчетов, где изначальные данных даны з погрешностью 50%? Это почти тоже самое, что просто кидать монету, так как итоговая погрешность будет плюс минус бесконечность.
----------------
Тем более, ну смотрите. Вам надо чего-то оценить. Собираем лидов, чай, кофе, плюшки. И оцениваем задачи по сложности, 3-5 категорий. Потом попарно сверим некоторые, чтобы понять адекватность оценок и после пары кругов получаем результат. Плюсы:
вы провели время с командой, а не с компом. Это безценно
вы получили оценки, за которыми подписались лиды, и теперь они же будут подсознательно стараться им соответствовать
вы услышали команду и смогли узнать о куче потенциальных проблем
люди, посидели, обдумали фронт работ и тоже придумали кучу интересных идей/возможных проблем
вы дали всем понять, что их мнение важно и даже необходимо
Итого позитив, как ни посмотри.
Если эти данные прокрутить через любой "движок", вы все это потеряете. Именно поэтому он useless. Даже не потому, что он что-то там насчитает. А потому что применив его, вы рискуете весь позитив от такого упражнения помножить на ноль
А все потому, что люди и отношения во стократ важнее, и такого рода вопросы лучше решать в виде совместной работы
Конечно, потом это все надо прокрутить, наложить риски и прочее - вы ведь ПМ. Но базовые оценки, данные командой, важно оставить как есть, иначе ... ну вроде как понятно
-----
Единственное мы можете использовать технику "якоря", использовав движок как некую начальную оценку. Да, это может сработать. Но вопрос в том, что правильный "якорь" имеет цель и именно поэтому он вводится. А тут полагаться на не пойми что
zhadrinskaya Автор
10.10.2023 08:37Если у вас есть расхождение в 3 попугая — это повод обсудить, почему тим-лид оценивает на 8, а математика на 5. Есть какие-то риски? Блокеры? Что важно учесть в проекте?
Точность и полезность экспертных оценок тема отдельной статьи.
Batalmv
10.10.2023 08:37Ну можно.
Но тогда возвращаемся к вопросу, для чего изначальная "5". Если как "якорь" - стремно все таки. Не проще ли классически опросить всех? Либо довериться лиду
Все равно ему за свои оценки отвечать, а не за ваши
Там выходит. тим лид дам 8 и сделал за 8. Все пучком.
А с движком сплошная "каша из топора". Лишние обсуждения, вопросы. А в конце риск нарваться на лекцию о важности экспертного мнения :)
Mausglov
10.10.2023 08:37+1То есть Вам в любом случае нужен эксперт с его оценкой, который подтвердит, что Вы намеряли не среднюю температуру по больнице, а действительно учли все риски, блокеры и тонкие моменты.
Я понимаю, что очень хочется взять данные, которые есть, скормить умной машине, а уж она разберётся. Но реальность - она другая. Если у Вас однообразные задачи, то оценку Вы дадите и без метода Монте-Карло. А если разнообразные, то погрешность сравнится с оценкой и сделает оценку бесполезной. "Вероятность встретить слона на улице 50% - или встретите, или нет"
StepEv
10.10.2023 08:37Вы что-то путаете. Метод Монте-Карло не даёт никаких оценок ни в каких попугаях. Он отвечает на один из двух вопросов:
а) с какой вероятностью к какой дате будут сделаны вот эти N задач?б) Сколько и с какой вероятность задач мы сделаем за период?
Ни в одном из этих случаев попугаи не фигурируют. Тратить время на попытки экспертно предсказать будущее тоже не нужно.
Если у вас эксперты хорошо умеют давать такие предсказания и трудозатраты на этот процесс вас устраивает, вам не нужен Монте-Карло, смело проходите мимо. Но почему-то в подавляющем большинстве случаев оценки попугаев, да хоть трудозатрат в человеко-часах, не имеют никакой корреляции с длительностью работы и, соответственно, на вопрос "Когда?" ответить не помогают. Хотите проверим на ваших данных? :)
Batalmv
10.10.2023 08:37Вы что-то путаете. Метод Монте-Карло не даёт никаких оценок ни в каких попугаях. Он отвечает на один из двух вопросов:
а) с какой вероятностью к какой дате будут сделаны вот эти N задач?б) Сколько и с какой вероятность задач мы сделаем за период?
На этот вопрос может дать ответ только оракул, так как методу на вход надо давать некоторые числовые значения, которые как-то характеризуют разимер и сложность задачи :)
Некоторые сейчас используют ChatGPT :)
Но почему-то в подавляющем большинстве случаев оценки попугаев, да хоть трудозатрат в человеко-часах, не имеют никакой корреляции с длительностью работы и, соответственно, на вопрос "Когда?" ответить не помогают. Хотите проверим на ваших данных? :)
Как раз имеют, причем связь обычно близка к линейной :) У вас есть оценка в трудоднях, есть размер команды, далее несложные арифметические действия :)
В случае, если команда бежит спринтами, вообще все сводится чуть ли не к тупой формуле , в которую входят:
производительности команды за спринт
обьем бэклога
длина спринта
К итогу добавляем коэфициент неопределенности и "говнистости" заказчика и в общем-то все
Если большим проектом и "водопадом", то чуть сложнее, так как заказчик обычно просит план, который надо чуть ли не включить как дополнение к конктракту. Но на расчет общего срока это не сильно влияет :)
P.S. Но у именя есть стойкое ощущение, что после "оценки попугаев, да хоть трудозатрат в человеко-часах, не имеют никакой корреляции с длительностью работы" разговор надо сворачивать :)
chilicoder
10.10.2023 08:37Вы расставили себе milestones по ходу проекта.
Вот для этого авторы и предполагают использовать Монте-Карло. При условии стабильности среды, когда на всех ваших уникальных командах и проектах начинает хоть как то работать закон больших чисел, why not?
Batalmv
10.10.2023 08:37А как вы видите тут Закон больших чисел?
Во-первых: команды различны, проекты тоже, среда все время меняется. Ничего похожего там нет, обычно. Поэтому у вас получится очень большой разброс и маленькая выборка. А это прям скажем, не лучшие стартовые данные для применения метода :)
Во-вторых: закон больших числе не зря про большие числа :) К примеру, у вас есть сценарий, вероятность которого 0.01%. Фигня, скажете вы. Но если у вас 1000000 транзакций в день, то этот случай скорее рутина, чем что-то редкое. Перенося в практическую плоскость, это значит что такой случай должен быть учтен во время разработки, тестирования и вообще. Ну или на масштабе страны, условно 100 миллионов человек == почти любое отклонение будет иметь место быть. Просто такое большое число автоматом делает реальным события, для отдельно взятого человека практически нереальными. Это на пальцах, но для понимания масштабов. Теперь возьмите даже большую организацию. Ну сколько там будет проектов? 1-2 самых важных, 5-10 больших, 20 мелких и куча мелкого, что всем на них по фиг (можете поделиться своим опытом). Так где вы тут примените этот закон?
В-третьих, среда меняется, все время. За условные 10 лет работы на одном месте вы почти точно словите один экономический кризис, к примеру. А это резкое срезание бюджетов, смена стратегии. А за ним отмена проектов, урезание скоупов, битва за ресурсы. Это колосально влияет на проекты, какой уж тут Монте-карло? А есть локальные перетрубации, смена собственника, новый директор - тут тоже похуже революции. Может быть, вы бежали прямо за много денег, пришла новая метла и за много денег вас развернула в другую сторону.
------------
Практически ... у вас уже есть куда более сильные "milestone" в виде ожиданий. Все ж условно происходит не так. У бизнеса есть идея, либо набор идей. Не важно, это что-то с нуля или продолжение. Есть бюджет, на год например. Есть продукт, или целое подразделение, которое расписало стратегию, как потратив Х, они заработают Y. При этом к дате Z надо чтобы продукт был на рынке. Эта концепция прошла защиту на некотором "бюджетно-ресурсном" процессе и дали денег и ресурсы. Все. Просто так вам денег не дадут, не важно, у вас выделенная команда либо ситуативная на реализацию конкретной идеи (вариант, когда вы "жена цезаря" и вам дали освоить много денег просто так мы не рассматриваем). Вот в процессе "защиты" идеи и можно сесть и прикинуть CBA, где за букву "C" как раз отвечают ПМ, лиды, архитектор, ну и вообще, находится наша задача. Но тогда важно получить оценки ОТ ЛЮДЕЙ, так как потом вам это ДЕЛАТЬ. И если оценки даны людьми, они будут с вами, так как дав их - они подписались что в итоге выдадут продукт на рынок, и бизнес заработает Y денег (либо не заработает, но тут уже не наша проблема).
А вы дали, потом не вложились, и ... вы тогда лох, потому что исполнители вам скажут, что сам дурак, мы же предупреждали, и заказчик вам это Монте Карло может засунуть куда-то туда, куда природа не предполагало, но неожиданно стало возможно. Оно вам надо?
kogemrka
10.10.2023 08:37Ух, было бы очень интересно прочитать рассказ про то, как же метод монте-карло тут используется. В смысле, применяемого мат-аппарата и допущений, что берём, что и как считаем, вот это всё.
Статья, по сути, говорит, "есть эксель табличка, которая считает". Хорошо, что есть какой-то готовый инструмент.
Но было бы интересно почитать, что происходит внутри этого инструмента.
zhadrinskaya Автор
10.10.2023 08:37+2Вот тут можно познакомиться с подробностями самого расчёта как раз на примере ИТ проекта: https://tinkoff.github.io/dm-knowledgebase/docs/roadmap/management/job/tasks/planning/monte-carlo-method
romas1982
10.10.2023 08:37Казалось бы, и методы не новые совсем, и попытки прикрутить их к оценке проектов я еще в середине 200х видел в исполнении того же Дорофеева, но как-то результатов положительных достигнуто так и не было.
Интересно, почему….
reinmaker1990
10.10.2023 08:37+2Не одна мат.модель насколько бы она сложной не была, не может быть рассмотрена как целевое решение такой проблемы как сроки, у которой есть десятки параметров влияющих на них.
К тебе приходит сейлз, приносит контракт и плевал он на твой анализ и данные, когда у него тендер в огне, это как один из примеров, таких можно найти сотни которые будут ломать о колено все эту "красоту"
StepEv
10.10.2023 08:37Вы делаете утверждение, можете его подкрепить чем-то?
Когда к вам приходит сейлз с уже сгоревшими сроками, ему вообще оценки нужны? Если ему эксперт скажет "не успеем", что скажет ему в ответ сейлз?
StepEv
10.10.2023 08:37+1А где вы смотрели результаты? Они таки есть. И у Дорофеева и у других.
Во-первых, Дорофеев описывал не Монте-Карло, а более простой способ расчёта, тоже на исторических данных, но без учёта распределения. И даже он даёт достаточно неплохие результаты.
Во-вторых, сравнение результатов прогнозов его методом и методом Монте-Карло, на реальных данных и проектах, он как раз проводил https://youtu.be/xt27W5WhMrs?list=PLm6zCN_KJCrXXiDWoIczR7B9n73wPX2wnЦеликом плейлист тут https://www.youtube.com/playlist?list=PLm6zCN_KJCrXXiDWoIczR7B9n73wPX2wn
И не он один, конечно, сверял результаты прогноза МК с реальностью. Так же как и результаты прогноза экспертов :)
chilicoder
10.10.2023 08:37+3Как человек, когда то давно применявший Монте-Карло при разработке торговых систем, давайте сразу перейду к сути критики этого метода.
Основная проблема в том, что вероятностные распределения компонентов процесса IT-разработки неизвестны и процесс нестационарен. В этих условиях метод Монте-Карло порождает явление ложной регрессии. Более подробно можно почитать, например, в этой статье
"Кирилюк, Сенько. Исследования соотношений между нестационарными временными рядами на примере производственных функций" )В вашем посте содержится хороший рецепт приведения системы в состояние, пригодное для анализа методом Монте-Карло.
Что повлияет на точность прогноза? Стабильность системы.
Именно. Метод будет давать хоть что-то полезное только при условии стабильности наблюдаемого процесса.
Однако, в IT-организациях часто возникают ситуации, в которых невозможно заранее предсказать будущую продуктивность. Вот у вас новая команда. Одному Богу известно, сможет ли она сыграться и выйти на некое плато продуктивности в рамках вверенного ей функционала. Или у вас стабильная команда, но ей передали в ответственность новые подсистемы, после того как на этом участке не справились другие команды. Или команда стабильная, и функционал ее, но внезапно изменилась внешняя среда, невозможно больше пользоваться Jira, Miro, Idea и AWS. В этих ситуациях Монте-Карло не поможет, скорее навредит, создав ложные ожидания.
И такие ситуации возникают в большой IT-организации постоянно. Они влияют на общую стабильность и с ними необходимо работать. В этом суть менеджмента, приводить систему к стабильности каждый день, неделю и месяц. Иначе никакого менеджмента не будет.
Поэтому давайте не впадать в иллюзии и писать такие утверждения:
Чем такие прогнозы отличаются от экспертных прогнозов аналитиков? Они учитывают всю неопределенность, с которой встречалась команда,
Конечно же Монте-Карло не учитывает всей неопределенности. Более того, он не учитывает главной составляющей этой неопределенности, именно той, которую при планировании больших задач мы хотим избежать. Поэтому решить за нас проблемы оценки сложных проектов он не сможет. Хотя инструмент красивый.
zhadrinskaya Автор
10.10.2023 08:37+2Спасибо за комментарий. Конечно, чем выше стабильность системы тем точнее прогноз. И прогноз не только по Монте-Карло, но и экспертная оценка будет лучше работать в стабильной среде.
Монте-Карло учитывает предыдующую неопределенность, выбросы, которые у команды встречалась и повторяет её в прогнозе. Но понятно, что будущую неопределенность он не может предсказать достоверно. Как и эксперт не сможет предсказать черного лебедя.
StepEv
10.10.2023 08:37Спасибо за конструктивный комментарий!
На практике, даже с учётом нестабильности, метод зачастую оказывается не хуже, чем экспертные прогнозы. При этом на порядки дешевле по трудозатратам.
В худшем случае, он даёт оценку снизу, "раньше чем Ч не сделаем точно", что уже очень ценный результат, позволяющий запустить полезные дискуссии о скоупе работ, ресурсах и, таки, сроках.
Alban44
Опробуем)