Об устойчивости оценки проекта по отношению к точности оценки отдельных задач
В математике устойчивостью называют такую ситуацию, при которой небольшие отклонения входных параметров приводят к небольшим отклонениям результата
( Read more... )
Comments 18
"разработчики разбили фичу на техзадачи"
и
"разработчики оценили объем работ по каждой техзадаче"
наш аналитик давал предварительный прогноз, сколько сторипоинтов у разрабов будет. Просто зная, сколько в среднем сторипоинтов на техзадачу приходилось раньше.
Ее прогноз ошибался процентов на 20.
Reply
Разрабы долго давали свою оценку?
Reply
Я так думаю, мы, разрабы, с фиксированной долей задач ошибались, недооценивая их на этапе разбиения.
Сам процесс -- полчаса-час на одну двухнедельную итерацию.
Но с учетом переключения и с учетом того, что это не просто говорильня, а говорильня с элементами спора, это отнимало около половины рабочего дня, следующего за разбиением на технические подзадачи.
Reply
Reply
Reply
Это верно, да...
Но при большом количестве задач и достаточном количестве итераций и эта проблема нивелируется, только если мы внедрение не отложим на последнюю итерацию.
Нивелируются только мелкие риски из-за характеристик системы, как ты понимаешь.
Reply
Могу ошибаться, но и крупные могут нивелироваться, если они именно системные. Абстрактный пример, если у нас ведущий разработчик меняется каждые 2 итерации, то риск системный и в долгосрочной перспективе будет учтен. Хотя эффект будет оказывать вполне себе. А вот черные лебеди, или системные риски которые на большей части проекта не проявляются, могут оказать разрушительное воздействие даже если и не риск, а так, пшик. Ну подумаешь человек от заказчика у которого единственный ключ от серверной уехал на две недели в командировку и ключ увез... А у нас срок сдачи проекта за два дня до его возвращения.
Reply
Обобщая, можно сказать, что нивелируется то, что уже часто случалось и скорее всего продолжит случаться примерно с той же частотой и последствиями.
Reply
Извини Макс, но это давняя тема. Еще в Новософте в 2000 году народ оценивал проекты по фиксам на юзкейс. Реально удобно. Правда без рисков эта цифра могла быть пальцем в цебо.
Reply
Reply
Reply
Reply
Reply
>> Допущение первое: задачи независимы.
Не совсем... ЦПТ говорит про независимые случайные величины, то есть, ОЦЕНКА одной задачи не должна зависеть от ОЦЕНКИ другой задачи. Но согласен, это допущение, да.
>> Я это дело моделировал на очень щадящей (совершенно нереалистичной)
>> вириабельности трудоемкостей атомарных задач и получил рост в
>> полтора раза срока завершения проекта для зависимых задач по
>> сравнению с независимыми.
А как моделировал? Мне было бы любопытно взглянуть хоть одним глазком.
>> Допущение второе. Нет попытки компенсации белого шума. На
>> практике сам факт наличия оценки трудоемкости атомарных задач
>> ухудшает производственные показатели в полтора-два раза.
О, да! Вот это действительно очень важное допущение. Совершенно согласен. Да, такое встречается очень часто на практике и что такое зарегулированная система это еще Деминг описывал.
Reply
Не. Я моделировал паралельное и последовательное выполнение. Зависимости FS, SF и т.д. Разберем параллельное. Пусть вехой окончания чего то там считается момент, когда закончена последняя из пяти задач, выполняемых параллельно пятью разными людьми. Распределение длительности возьмем пуассоновское и 5 дней будет 50/50
Рассмотрим следующие варианты:
А) Разброса у задач нет. Проект гарантированно завершится через 5 дней.
Б) Для каждой задачи точка нулевой вероятности 3 дня, точка 100% вероятности 10 дней. Пусть нас интересует дата в которую проект завершается с вероятностью 80%. Неожиданно эта точка соответствует точке 96% для атомарной задачи. Это примерно 9 дней. Но самое неожиданное, что вероятность завершения проекта через 5 дней всего 3%. Этот факт необычайно удивляет менеджеров.
> А как моделировал? Мне было бы любопытно взглянуть хоть одним глазком.
Так я вроде предлагал...
Reply
Reply
Leave a comment