Лайфхак: в любой непонятной ситуации умножай на три

[andrey_hse]

Я слышал версию, что
реальные_сроки == предварительные_сроки * Math.PI

[alhimik45]

Вот она — вездесущность числа Пи!

[veitmen]

Как мне кажется, когда говорят «срок будет равен планируемые сроки умножить на пи», не имеют ввиду число ПИ, а именно имеют ввиду пи…

[nooze]

— да, да срок верный, только надо еще умножить на пи здесь

[FrimInc]

Если разработчики нинцзя, то
Math.exp(1)

[azproduction]

e, pi — слишком палевно… Нужно использовать честное распределение!

function realRerm(preTerm) {
    return preTerm * (Math.E + Math.random() * (Math.PI - Math.E)); // fair estimation
}

[mynameco]

Мы следовали правилу, либо лиды умножает на 4 либо пм умножает на 4. И всегда успевали, и работать приятнее, никакой дипресси.

[valyard]

Статья была написана три года назад но так и пылилась в черновиках.

А здесь тоже умножено на 3?

[kirushik]

Дичайше рекомендую автору и сочувствующим «Критическую цепь» Голдратта.
Или, если душа к формальным хэндбукам лежит — «Вовремя и в рамках бюджета» Лоуренса Лича.

[murich]

> Однако как занизить срок, который разработчик сам себе выбрал? Я перенес это занижение в коэффициенты, на которые в последствии умножаю общую сумму часов.
Можно здесь подробнее?
Если разработчик с вами договорился о конкретном сроке на задачу — какое ему дело до того, что вы, называя эстимейты заказчику умножаете на занижающие коэффициенты?

[kuzmuk]

Разработчику — никакого дела. А вот мне нужно было следить что бы мы не выходили за пределы бюджета.

Проблема в том что наблюдалась тенденция растягивать задачу на все выделенное время и не оставлять время для доделок которые обычно бывают т.к. что-то где-то сделано не так или не красиво или глючит в каком-то из браузеров.

Пример 1. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 8 часов. Этот же разработчик берет ее и через 8 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 9-10 часов.

Пример 2. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 6 часов. Этот же разработчик берет ее и через 6 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 7-8 часов.

Понятно, что не всегда так. Где-то больше, где-то меньше. Но общая статистическая картина была именно такой.

Поэтому разработчику нужно видеть не все время, выделенное на задачу, а только его часть. Тогда он не будет стремиться «растягивать удовольствие» на все выделенное время. Точнее, он будет его растягивать на меньшее время. И по итогу сделает все в срок если не возникнет чего-то экстраординарного. Но для этого есть запас на непредвиденные обстоятельства.

[semyonchetvertnyh]

Пример 2. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 6 часов.

А разработчик не обратит внимание, что изначально оцененная им в 8 часов задача в трекере значится, как 6-тичасовая? Как вы оправдываете занижение часов перед ним?

[NikMelnikov]

Присоединяюсь к вопросу.

[kuzmuk]

В последствии к каждой задаче я стал добавлять 10-25% времени на доделки сверху оценки девелопером. Этот запас я не включал в выделенное на задачу время в трекере. Т.е. девелопер его не видел и не рассчитывал на него. Но когда этот запас расходовался (а он почти всегда расходовался) то это не сказывалось на бюджете в плохую сторону.

[vittore]

После первой картинки как-то сразу вспомнил вот этого товарища.

[xanep]

Почему когда вы говорите об оценке сроков, учитываете только непосредственную реализацию (имплементацию) разработчиками? Но ведь разработка еще состоит из сбора требований, архитектуры и дизайна, тестирования, в конце концов. Если у вас нет перед началом разработки software requirements specification (SRS), то это лишь означает, что вам самим придется выяснять требования в том или ином виде, что занимает ничуть не меньше времени, чем написание SRS. В целом имплементация занимает примерно треть времени разработки проекта. Так что совершенно не удивителен ваш вывод «умножай на 3».

[boolivar]

И Закон Хофштадтера не забудьте!