Комментарии 24
Задачи занимают больше времени, потому что много случайных и неизвестных факторов, влияющих на конечный результат. Оценивать сколь-нибудь точно можно только «типовые» задачи. Плюс ещё необходимо определиться, что мы понимаем под выполнением задачи, это тоже крайне размытое понятие, от непокрытого тестами лапшекода до продуманного архитектурно решения. Сроки отличаются в разы, зачастую под выбранный заранее срок решение можно подогнать, но далеко не с 100% качеством.
Думал все программисты руководствуются правилом: оцени время, умножь на Пи.
Вообще-то: оцени время, подели на два и умножь на пи.
У ва опасная формула, моя безопаснее
Ну вот теперь я знаю откуда в моей голове взялся коэффициент 1.6 который я обычно использую при оценке длительности задачи.
Но откуда само правило?
Представьте, что программист видит решение задачи как прямую (сверху вниз), обозначим D.
Но в реальности будут вопросы, уточнения, недопонимание и все такое, т.е. реально время на решение задачи пойдет по окружности, диаметр который мы уже обозначили D.
Т.е. это будет пол окружности. Длина половины окружности будет: 2 * pi * R / 2
Т.к. R — это наше время D/2, то выходит, что наше время задачи, в реальности, выльется:
(2 * pi * D / 2) / 2 = pi * D / 2
Как-то так ))
Но в реальности будут вопросы, уточнения, недопонимание и все такое, т.е. реально время на решение задачи пойдет по окружности, диаметр который мы уже обозначили D.
Т.е. это будет пол окружности. Длина половины окружности будет: 2 * pi * R / 2
Т.к. R — это наше время D/2, то выходит, что наше время задачи, в реальности, выльется:
(2 * pi * D / 2) / 2 = pi * D / 2
Как-то так ))
Метод Бобука-Бацека: www.youtube.com/watch?v=XUqiMEh2PMc
Иногда решение задачи надо обойти со всех сторон (вдруг она не симметричная) — pi * D…
Опять же нужно еще и сам радиус добавить — pi * D + D / 2…
А еще можно сделать несколько обходов (чтобы лучше разглядеть и полюбоваться видами). А на налюбовавшись понять, что может и не стоит ее решать… :))
Опять же нужно еще и сам радиус добавить — pi * D + D / 2…
А еще можно сделать несколько обходов (чтобы лучше разглядеть и полюбоваться видами). А на налюбовавшись понять, что может и не стоит ее решать… :))
1) Оцени время
2) Умножь на пи и прибавь неделю
3) Позови скрам-мастера
4) Декомпозируй
5) Повтори с п2 для каждой подзадачи
2) Умножь на пи и прибавь неделю
3) Позови скрам-мастера
4) Декомпозируй
5) Повтори с п2 для каждой подзадачи
и ешё плюс две недели же
Есть целая книга на эту тему, Time Predictions. Ее можно бесплатно почитать через Google Play.
В книге много букв, но, по-моему, она довольно интересна. Там подробно все разбирают и показывают, в том числе распределения и формулы оценки времени.
В книге много букв, но, по-моему, она довольно интересна. Там подробно все разбирают и показывают, в том числе распределения и формулы оценки времени.
Оценка сроков — это не самоцель, а просто инструмент, который стимулирует участников декомпозировать задачи и начинать обсуждение деталей еще на ранней стадии, а также придает процессу ощущение конечности/коммитности, убрает эффект рассусоливания. Вот и все. Не так важно, какая именно оценка получается, там плюс-минус километр всегда.
Неточная оценка сроков в любом случае гораздо лучше, чем вообще отсутствие оценки.
Спасибо! Теперь когда руководство меня спросит о сроках выпоонения задачи, будет много встречных вопросов :)
- для какого перцентиля оцениваем срок;
- зачем перцентили, когда вам нужно среднее;
- согласны ли вы, что среднее вовсе не означает 100% вероятности выполнения в указанный срок; и даже 75% вероятности, скорее всего тоже
:)
Для оценки использую PERT. В результате вы сразу же получаете роадмапу, майлстоуны, критические места, 4 оценки времени на каждую подзадачу, и распаралеленые задачи для команды. Даже если несколько задач профакапятся, то это не повлияет на сроки.
Необоснованная оценка времени из головы — это чушь. Она годиться лишь для предварительной оценки. Чтобы оценить сроки сложной задачи — ее нужно декомпозировать на мелкие задачи, сроки которых известны. Для сложных для которых опыта не хватает — нужно делать ресерч и прототипирование, чтобы дать оценку. Ни разу еще не профакапился по срокам
Необоснованная оценка времени из головы — это чушь. Она годиться лишь для предварительной оценки. Чтобы оценить сроки сложной задачи — ее нужно декомпозировать на мелкие задачи, сроки которых известны. Для сложных для которых опыта не хватает — нужно делать ресерч и прототипирование, чтобы дать оценку. Ни разу еще не профакапился по срокам
Менеджеру интересен, как правило, ответ на вопрос:
— за какой срок задача Х будет завершена?
Программист же отвечает на вопрос:
— сколько требует времени решение задачи Х.
Зачастую, решение задачи Х прерывается решением других задач, как учитываемых в графике (прерваться на устранение критической ошибки ...), так и нет (помочь коллеге ...)
Менеджер, конечно, всё понимает… но вот задача Х оказывается не решенной к сроку, зачастую при том, что оценка была корректна.
— за какой срок задача Х будет завершена?
Программист же отвечает на вопрос:
— сколько требует времени решение задачи Х.
Зачастую, решение задачи Х прерывается решением других задач, как учитываемых в графике (прерваться на устранение критической ошибки ...), так и нет (помочь коллеге ...)
Менеджер, конечно, всё понимает… но вот задача Х оказывается не решенной к сроку, зачастую при том, что оценка была корректна.
Часто бывает что задание не детализировано, привет кстати Аджайлу.
Так что чепуховая задача, выливается в огромный срок. Типичный кейс это внедрение локализации после начала работы над приложением. Или в мобильных приложениях добавление бэджика непрочитанных сообщений.
Так что чепуховая задача, выливается в огромный срок. Типичный кейс это внедрение локализации после начала работы над приложением. Или в мобильных приложениях добавление бэджика непрочитанных сообщений.
На самом деле логика бизнеса диктует указывать минимальный срок(если всё пойдёт гладко) + некоторый коэффициент запаса. Допустим человек 2 раза подряд укажит срок n, но в принципе всё пошло гладко и проект решён за n/2 времени. Естественно начальник скажет, что ты дурак не умеешь правильно оценивать время на проекты. И будет сам тебе сроки ставить. И наоборот, если сказал n/2 то может редко случитсья, что по факту выполнил за n. В этом случае либо удаётся сослаться на объективные обстоятельства либо от начальника получаешь минус в карму. Т.к. срывы сроков по такой причине редки, то человек может 5 лет и больше проработать. Потом программист А увольняется вместо него нанимается программист Б, который на соседнем предприятии имел такой срыв сроков и тоже имеет некий минус в карме. Итог — система работает, сроки периодически срываются. А иногда и не срываются — т.к. программиста застравляют работать сверурочно за минимальную доплату. Кто постоянно работает сверхурочно и не срывает сроки идёт на повышение(иногда).
Как-то автор не сделал главный вывод — на проектах с высокой неопределенностью нужно управлять сигмами.
Уже на начальном этапе становится понятно, что у части задач неопределенность выше, чем у большинства остальных. Если ничего не предпринимать, то высокая неопределенность никуда не денется, и при наличии опоздания (допустим) на 50% исполнитель будет всё так же не в состоянии сделать достоверную оценку времени, требующегося для завершения.
На таких задачах требуется вложить время и силы не в работу по существу задачи, а в понимание, что этот исполнитель (или исполнители) не учитывают или не понимают. В терминах статьи — разобраться в том, почему сигма такая большая.
Дальше возможны варианты — либо после разбора становится ясно, как сигму уменьшить до средних по проекту величин, либо прикинуть ту самую сигму и дальше ее закладывать в оценки сроков.
Уже на начальном этапе становится понятно, что у части задач неопределенность выше, чем у большинства остальных. Если ничего не предпринимать, то высокая неопределенность никуда не денется, и при наличии опоздания (допустим) на 50% исполнитель будет всё так же не в состоянии сделать достоверную оценку времени, требующегося для завершения.
На таких задачах требуется вложить время и силы не в работу по существу задачи, а в понимание, что этот исполнитель (или исполнители) не учитывают или не понимают. В терминах статьи — разобраться в том, почему сигма такая большая.
Дальше возможны варианты — либо после разбора становится ясно, как сигму уменьшить до средних по проекту величин, либо прикинуть ту самую сигму и дальше ее закладывать в оценки сроков.
Редкостный пример, когда автор открыл для себя инструмент (элементарную теорию вероятности), но совершенно не понимает как им пользоваться и, в рез-те, притянул его за уши к совершенно не подходящей задаче. Начнём с того, что процесс разработки — ни разу не стационарный и, уже, тем более — не эргодический процесс. Тогда уж, автор, давай жги до конца, подтаскивай теорию нестационарных случайных процессов! А если серъёзно, то, как правильно абсолютно выше написали, реальная разработка — это процесс, к-рый зависит от уймы слабопредсказуемых пар-ров. Вы можете сложный кусок сделать на удивление быстро, а на простом месте забуксовать на недели. А что-то и не сделать никогда. С этим нужно просто смириться, увы.
Проблема в том, что любое непредвиденное обстоятельство, т.е. в данном контексте «случайность», в 99% случаев приводит не к сокращению времени, а к его увеличению. Т.е. распределение резко ассиметрично.
Умножение на 3 — довольно распространенное правило. На моей практике оно почти всегда дает достаточноый запас чтобы выполнить всё в хорошем качестве и выпустить в продакшн.
Умножение на 3 — довольно распространенное правило. На моей практике оно почти всегда дает достаточноый запас чтобы выполнить всё в хорошем качестве и выпустить в продакшн.
Еще в 1975 году про неточность сроков обратили внимание:
«Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering), автор Фредерик Брукс.
«Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering), автор Фредерик Брукс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему программные задачи всегда занимают больше времени, чем вы думаете