?

Log in

No account? Create an account

Previous Entry | Next Entry

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

В свое время, когда я показывал табличку для адаптивной оценки итеративных проектов, меня спрашивали: «а нет ли у тебя такой же таблички, но только, чтобы по каждой отдельной задаче можно было бы задавать диапазон оценок? А то у нас все так сложно, и мы точно оценить каждую из задач не способны». Я отвечал, что такой таблички у меня нет, и так как точность оценки проекта устойчива по отношению к точности оценки отдельных задач (и чем больше задач, тем более устойчива), то такой таблички у меня и не будет, ибо нафик она никому не нужна.
Но я, видимо, был не убедителен в своем объяснении и поэтому решил все же сделать такую табличку, и на пальцах показать, что такое устойчивость.

Саму табличку можно взять здесь
Как читать эти графики рассказывается в этом видео.

С ее помощью я построил несколько оценок проекта (в котором уже прошло три итерации), состоящего из 80 задач, для различных разбросов оценок отдельных задач.

Устойчивость оценки

Посмотрите, чем отличается ситуация, когда каждая задача оценена точно в 5 (часов/лет/сторипоинтов/рублей) от ситуации, когда мы очень не уверены в каждой задаче, и говорим, что ее оценка «что-то в диапазоне от 2 до 8» (разброс в 4 раза – не хухры-мухры). Видите? Разница в оценке целого проекта примерно 10%. Если мы еще менее точны в своих оценках и говорим просто: «Оценка каждой задачи не больше 10», то точность оценки всего проекта как целого становится хуже всего на 20% по сравнению с ситуацией «Каждая задача – точно 5».

Соответственно, чем больше число задач в проекте, тем меньшую роль играет точность оценки отдельных задач (и ценность информации, получаемой при сравнении план/факт по каждой отдельной задаче)

Полезное знание?

Comments

( 18 comments — Leave a comment )
stabich
Nov. 5th, 2014 10:19 am (UTC)
На прошлой работе между стадиями
"разработчики разбили фичу на техзадачи"
и
"разработчики оценили объем работ по каждой техзадаче"
наш аналитик давал предварительный прогноз, сколько сторипоинтов у разрабов будет. Просто зная, сколько в среднем сторипоинтов на техзадачу приходилось раньше.

Ее прогноз ошибался процентов на 20.
cartmendum
Nov. 5th, 2014 11:31 am (UTC)
Интересно потом, кто по числу спринтов будет ближе к истине :)

Разрабы долго давали свою оценку?
stabich
Nov. 5th, 2014 02:11 pm (UTC)
А она такую оценку начинала давать через две-три итерации после начала проекта. И точность не менялась.
Я так думаю, мы, разрабы, с фиксированной долей задач ошибались, недооценивая их на этапе разбиения.

Сам процесс -- полчаса-час на одну двухнедельную итерацию.
Но с учетом переключения и с учетом того, что это не просто говорильня, а говорильня с элементами спора, это отнимало около половины рабочего дня, следующего за разбиением на технические подзадачи.
cartmendum
Nov. 5th, 2014 02:16 pm (UTC)
Ну, кстати, говорильня с элементами спора - это может быть как раз полезной вещью :) Как по ощущениям, спор конструктивен? Помогает прояснять мутные вещи и находить то, чего не знали раньше?
stabich
Nov. 10th, 2014 12:29 pm (UTC)
Да, конструктивен.
Другое дело, что время от времени такой процесс запускался из желания получить оценку объемов работ по нескольким конкурирующим за ресурсы проектам. Чтобы сравнить с хотелками клиентов и принять решение о том, какой именно запускать.
И тогда бывало, что недели две на обсуждения уходило 4-5 дней. И большая часть обсуждавшегося потом не получало никакого хода.

Да, помогал прояснять.
Совместное фичи на техзадачи типа "залезть в тот и тот код и написать то-то и то-то" и совместные оценки объема работы друг друга дополняют.
Появилось у разработчиков расхождение в оценках -- значит, нет общего понимания и в том, что стоит за формулировками в техзадачах, даже если с формулировками все согласны. И наоборот.

Edited at 2014-11-10 12:30 pm (UTC)
cartmendum
Nov. 10th, 2014 09:36 pm (UTC)
Конструктив - это хорошо.

И тогда бывало, что недели две на обсуждения уходило 4-5 дней. И большая часть обсуждавшегося потом не получало никакого хода.
Это нормально. Что бы не делай, всегда будут попадаться какие-то исключительные ситуации, в которых все не очень хорошо.
Алексей Лосев
Nov. 5th, 2014 11:56 am (UTC)
А то, конечно полезное. Основная проблема все равно возникает не из-за тех задачах которые в бэклоге, а из-за тех, которые в него не попали... Но при большом количестве задач и достаточном количестве итераций и эта проблема нивелируется, только если мы внедрение не отложим на последнюю итерацию.
cartmendum
Nov. 5th, 2014 12:05 pm (UTC)
Основная проблема все равно возникает не из-за тех задачах которые в бэклоге, а из-за тех, которые в него не попали...
Это верно, да...

Но при большом количестве задач и достаточном количестве итераций и эта проблема нивелируется, только если мы внедрение не отложим на последнюю итерацию.
Нивелируются только мелкие риски из-за характеристик системы, как ты понимаешь.
Алексей Лосев
Nov. 5th, 2014 12:16 pm (UTC)
Нивелируются только мелкие риски из-за характеристик системы, как ты понимаешь.
Могу ошибаться, но и крупные могут нивелироваться, если они именно системные. Абстрактный пример, если у нас ведущий разработчик меняется каждые 2 итерации, то риск системный и в долгосрочной перспективе будет учтен. Хотя эффект будет оказывать вполне себе. А вот черные лебеди, или системные риски которые на большей части проекта не проявляются, могут оказать разрушительное воздействие даже если и не риск, а так, пшик. Ну подумаешь человек от заказчика у которого единственный ключ от серверной уехал на две недели в командировку и ключ увез... А у нас срок сдачи проекта за два дня до его возвращения.
cartmendum
Nov. 5th, 2014 01:34 pm (UTC)
Ага, все верно :)

Обобщая, можно сказать, что нивелируется то, что уже часто случалось и скорее всего продолжит случаться примерно с той же частотой и последствиями.
lalibu
Nov. 5th, 2014 04:29 pm (UTC)
молодые ученые академгородка открыли для себя новый способ клонирования человека. Ну способ конечно не новый, дедовский. Но для молодых ученых ...

Извини Макс, но это давняя тема. Еще в Новософте в 2000 году народ оценивал проекты по фиксам на юзкейс. Реально удобно. Правда без рисков эта цифра могла быть пальцем в цебо.
cartmendum
Nov. 5th, 2014 04:34 pm (UTC)
Прекрасно понимаю, что этой теме лет очень много :) Я ищу не новое, а простые способы объяснять старое :)
sdtsdt
Nov. 5th, 2014 08:32 pm (UTC)
остается нюанс - количество задач + неизвестные генерируемые внешними контрагентами
cartmendum
Nov. 6th, 2014 06:59 am (UTC)
Есть такое
(Anonymous)
Nov. 10th, 2014 12:24 pm (UTC)
Эта картинка работает только при куче допущений.

Допущение первое: задачи независимы. Как только они становятся зависимыми картинка радикально меняется. Я это дело моделировал на очень щадящей (совершенно нереалистичной) вириабельности трудоемкостей атомарных задач и получил рост в полтора раза срока завершения проекта для зависимых задач по сравнению с независимыми. Если бы разброс соответствовал реальности, то время разница была бы еще больше. И распределение там не слишком соответствует ЦПТ.

Допущение второе. Нет попытки компенсации белого шума. На практике сам факт наличия оценки трудоемкости атомарных задач ухудшает производственные показатели в полтора-два раза. Этот факт подтвердило экспериментальное исследование, ЕМНИП Путмена, и ему лет двадцать. Трудоемкость атомарной задачи это вариабельная величина. И умение оценивать совершенно не причем. Это белый шум, с очень, очень большим разбросом. На практике в более чем 95% случаев эту вариабельность пытаются компенсировать. И всегда с одним и тем же результатом. Ухудшение производительности в 1.5 - 2 раза.

Правило 34. Никаких исключений.
cartmendum
Nov. 10th, 2014 09:29 pm (UTC)
Спасибо за очень дельный комментарий. Пройдусь по пунктам

>> Допущение первое: задачи независимы.
Не совсем... ЦПТ говорит про независимые случайные величины, то есть, ОЦЕНКА одной задачи не должна зависеть от ОЦЕНКИ другой задачи. Но согласен, это допущение, да.

>> Я это дело моделировал на очень щадящей (совершенно нереалистичной)
>> вириабельности трудоемкостей атомарных задач и получил рост в
>> полтора раза срока завершения проекта для зависимых задач по
>> сравнению с независимыми.
А как моделировал? Мне было бы любопытно взглянуть хоть одним глазком.

>> Допущение второе. Нет попытки компенсации белого шума. На
>> практике сам факт наличия оценки трудоемкости атомарных задач
>> ухудшает производственные показатели в полтора-два раза.
О, да! Вот это действительно очень важное допущение. Совершенно согласен. Да, такое встречается очень часто на практике и что такое зарегулированная система это еще Деминг описывал.
Sergey Martynenko
Nov. 11th, 2014 03:05 pm (UTC)
> Не совсем... ЦПТ говорит про независимые случайные величины, то есть, ОЦЕНКА одной задачи не должна зависеть от ОЦЕНКИ другой задачи.
Не. Я моделировал паралельное и последовательное выполнение. Зависимости FS, SF и т.д. Разберем параллельное. Пусть вехой окончания чего то там считается момент, когда закончена последняя из пяти задач, выполняемых параллельно пятью разными людьми. Распределение длительности возьмем пуассоновское и 5 дней будет 50/50

Рассмотрим следующие варианты:
А) Разброса у задач нет. Проект гарантированно завершится через 5 дней.
Б) Для каждой задачи точка нулевой вероятности 3 дня, точка 100% вероятности 10 дней. Пусть нас интересует дата в которую проект завершается с вероятностью 80%. Неожиданно эта точка соответствует точке 96% для атомарной задачи. Это примерно 9 дней. Но самое неожиданное, что вероятность завершения проекта через 5 дней всего 3%. Этот факт необычайно удивляет менеджеров.

> А как моделировал? Мне было бы любопытно взглянуть хоть одним глазком.
Так я вроде предлагал...
cartmendum
Nov. 12th, 2014 06:06 pm (UTC)
Серега, я мог бы догадаться, что это ты :)
( 18 comments — Leave a comment )