Comments 17
Я слышал версию, что
реальные_сроки == предварительные_сроки * Math.PI 
Вот она — вездесущность числа Пи!
Как мне кажется, когда говорят «срок будет равен планируемые сроки умножить на пи», не имеют ввиду число ПИ, а именно имеют ввиду пи…
Если разработчики нинцзя, то
Math.exp(1)
Мы следовали правилу, либо лиды умножает на 4 либо пм умножает на 4. И всегда успевали, и работать приятнее, никакой дипресси.
Статья была написана три года назад но так и пылилась в черновиках.
А здесь тоже умножено на 3?
Дичайше рекомендую автору и сочувствующим «Критическую цепь» Голдратта.
Или, если душа к формальным хэндбукам лежит — «Вовремя и в рамках бюджета» Лоуренса Лича.
Или, если душа к формальным хэндбукам лежит — «Вовремя и в рамках бюджета» Лоуренса Лича.
> Однако как занизить срок, который разработчик сам себе выбрал? Я перенес это занижение в коэффициенты, на которые в последствии умножаю общую сумму часов.
Можно здесь подробнее?
Если разработчик с вами договорился о конкретном сроке на задачу — какое ему дело до того, что вы, называя эстимейты заказчику умножаете на занижающие коэффициенты?
Можно здесь подробнее?
Если разработчик с вами договорился о конкретном сроке на задачу — какое ему дело до того, что вы, называя эстимейты заказчику умножаете на занижающие коэффициенты?
Разработчику — никакого дела. А вот мне нужно было следить что бы мы не выходили за пределы бюджета.
Проблема в том что наблюдалась тенденция растягивать задачу на все выделенное время и не оставлять время для доделок которые обычно бывают т.к. что-то где-то сделано не так или не красиво или глючит в каком-то из браузеров.
Пример 1. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 8 часов. Этот же разработчик берет ее и через 8 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 9-10 часов.
Пример 2. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 6 часов. Этот же разработчик берет ее и через 6 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 7-8 часов.
Понятно, что не всегда так. Где-то больше, где-то меньше. Но общая статистическая картина была именно такой.
Поэтому разработчику нужно видеть не все время, выделенное на задачу, а только его часть. Тогда он не будет стремиться «растягивать удовольствие» на все выделенное время. Точнее, он будет его растягивать на меньшее время. И по итогу сделает все в срок если не возникнет чего-то экстраординарного. Но для этого есть запас на непредвиденные обстоятельства.
Проблема в том что наблюдалась тенденция растягивать задачу на все выделенное время и не оставлять время для доделок которые обычно бывают т.к. что-то где-то сделано не так или не красиво или глючит в каком-то из браузеров.
Пример 1. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 8 часов. Этот же разработчик берет ее и через 8 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 9-10 часов.
Пример 2. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 6 часов. Этот же разработчик берет ее и через 6 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 7-8 часов.
Понятно, что не всегда так. Где-то больше, где-то меньше. Но общая статистическая картина была именно такой.
Поэтому разработчику нужно видеть не все время, выделенное на задачу, а только его часть. Тогда он не будет стремиться «растягивать удовольствие» на все выделенное время. Точнее, он будет его растягивать на меньшее время. И по итогу сделает все в срок если не возникнет чего-то экстраординарного. Но для этого есть запас на непредвиденные обстоятельства.
Пример 2. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 6 часов.
А разработчик не обратит внимание, что изначально оцененная им в 8 часов задача в трекере значится, как 6-тичасовая? Как вы оправдываете занижение часов перед ним?
Присоединяюсь к вопросу.
В последствии к каждой задаче я стал добавлять 10-25% времени на доделки сверху оценки девелопером. Этот запас я не включал в выделенное на задачу время в трекере. Т.е. девелопер его не видел и не рассчитывал на него. Но когда этот запас расходовался (а он почти всегда расходовался) то это не сказывалось на бюджете в плохую сторону.
После первой картинки как-то сразу вспомнил вот этого товарища.
Почему когда вы говорите об оценке сроков, учитываете только непосредственную реализацию (имплементацию) разработчиками? Но ведь разработка еще состоит из сбора требований, архитектуры и дизайна, тестирования, в конце концов. Если у вас нет перед началом разработки software requirements specification (SRS), то это лишь означает, что вам самим придется выяснять требования в том или ином виде, что занимает ничуть не меньше времени, чем написание SRS. В целом имплементация занимает примерно треть времени разработки проекта. Так что совершенно не удивителен ваш вывод «умножай на 3».
И Закон Хофштадтера не забудьте!
Sign up to leave a comment.
Лайфхак: в любой непонятной ситуации умножай на три