🤡 Всем, привет!

Давайте попробуем решить новую задачу. На этот раз сложность выше и приз будет по интереснее. Приз достанется одному. Но, по новому правилу. Приз получит случайно выбранный программой из верно ответивших. При этом за ответ будут поставлены балы которые будут повышать вероятность получения приза. Балы ставится за правильный ответ, так же за пояснение, на сколько хорошо разъяснено, и скорость ответа.
Ответы принимаются до 11:00 утра субботы по MSK.

Дано:
На основе прошлых релизов и подготовки релизов выяснили, что команда допускает ошибки для 15% фич.
При этом, вы как ответственный заказчик всегда сами проверяете результат работы на тестовом стенде. Наблюдая за своим опытом вы обнаружили, что в 20% случаев результат вашего тестирования оказывается некорректным — вы находите ошибку когда ее нет и останавливаете релиз, или не обнаруживаете ошибок даёте добро на релиз, но после выпуска ошибки обнаруживают пользователи.

Найти:
С какой вероятность произойдет событие того, что на прод попадет фича с ошибками?

А, так же, с какой вероятностью вы зря остановите релиз, потому что нашли ошибку, которой на самом деле нет?

Дополнительно дайте пояснение:
Что стоит улучшить в процессах, чтобы улучшить экономический эффект и лишний раз не останавливать релизы?

#задачки

🧐В рамках моего долклада в Инополисе (Кзань), на этих выходных,
Я рассказал о двух способах моделирования выбора количества задач в бэклог использования метода Монте-Карло:

1. Более традиционный на основе пропускной способности
2. Это моделирование на основе Lead Time

Для первого способа я написал простой скрипт, это дейстивтельно простой метод, и в большенстве случаев будет достаточным. Но у него есть свои ограниыения - минимальная итерация которая имеет смысл в моделировании это неделя.

Вот пример скрипта на github, это на JS можно завпустить в консоли браузера

В этом случае сложно учесть будущие выходные и отпуска.
По этому придется учитывать как-то в рисках.

И если хочется этот способ попробовать можно воспользвоаться форомой от Rodrigo Rosario, хотя эта форма для прогнозирования проекта, но все же можно использовать и для итераций.

А вот для второго случая - моделирвоания на основе Lead Time, я написал вот такую програмку на JS (можно запускать в консоли браузера)

Этот вариант интеересен тем, что он считает по дням и учитывает lead time задач, по этому можно золожить и праздники и отпуска которые у вас подразумеваются - количеством работников которые будут роботать в этот день.

С учтом правила, что один работник работает над одной задачей пока ее не завршит.

При этом Lead Time учитывает время блокирвоки, и частоту этой блокировки на задачи.

Что достаточно интересно может показать результаты.

Результат этого кода выводится в двух табличных формах в консоль
Первая таблица — это наиболее частотный вариант кагорты типов для вероятного бэклога
А вторая таблица — это вариант сборки бэклога на основе полученных расчетов.

Скрипт позволят помоделировать разную стратегию приоретизации бэклога. Я сделал две
1. Shaffle - каждая итерация совершенно случайная сборка бкэлога
2. По приоритизации учтенной в бэклоге

Можно заметить, что приоретизация дает более надежный статистический результат.

🥸Попробуйте на основе этого кода помоделировать свои бэклоги.

А в этом примере используются настоящие данные одной из команд, где суммарно 3 человек в команде.
И 2-е из них в начале квартала уходят в отпуск.
Набор задач в бэклоге случайный.

А тут код тот же самый, но из Lead Time я вычел время блокировок задач.

Запустив два этих варианта можно получить результат и обсудить их с командой, как на результат модуляции влияют вероятные блокировки.

🥂 Буду верить, вам эти примеры понравятся, вы их попробуете у себя и найдете себе новых инсайтов для вашей работы.

#доклад