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


56

Хотя опытный разработчик относительно может оценить, сколько времени потребуется для реализации кода, когда шаблон и проблема, которую решает код, хорошо поняты, как вы можете сделать хорошую оценку, когда, хотя конечная цель хорошо понятна, реализация на 95% теоретическая / для решения проблем и имеет очень небольшие объемы реализации?

Моя работа часто состоит из задач для достижения четко определенных целей, однако я должен найти способ достичь этой цели, и пока я не пойму решение, неясно, какие могут быть дополнительные барьеры. В частности, я часто работаю над инструментами генерации кода или автоматизированного манипулирования кодом. Как только решение будет полностью решено и инструмент будет отработан, он сразу же выполнит 95% фактических изменений очень быстро. У меня, однако, нет никакого способа оценить, сколько дополнительных проблем, возможно, придется решить, чтобы инструмент генерации или анализа справился с непредвиденными крайними случаями.

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


Какие виды оценок вы даете? Если я спрашиваю вас: «Мне нужна функция, которая делает XYZ для клиентской ABC», какой тип ответа вы дадите? Обратите внимание, что любой ответ, который я даю, находится под сильным влиянием оценки программного обеспечения: демистификация черного искусства

Я специально пытаюсь оценить количество времени, которое потребуется для выполнения задачи. Так что это будет что-то вроде «Удалить весь какой-то определенный тип кода» или «Изменить весь код, который делает что-то вроде XYZ, вместо этого ведет себя как ABC».
А.Дж. Хендерсон

Хорошо ... поэтому, если я попрошу вас "Измените функциональность XYZ так, чтобы он выполнял ABC" ... какой тип ответа вы дадите? Вы говорите «Может быть, неделю» или «5 дней» или «от 1 дня до 10 дней, в зависимости от того, что я нахожу, когда копаюсь в нем?»

Обычно я стараюсь дать оценку от 4 дней до 8 дней (требуемая точность), хотя часто было бы более реалистично сказать что-то вроде 4 дней и 3 недель. Я пытаюсь найти способы сузить диапазон.
AJ Henderson

1
@gnat Спасибо за объяснение, однако я считаю, что мой вопрос уже ясен, так как другие ответы, кажется, понимают, о чем идет речь, и я, честно говоря, не понимаю, каким образом вопрос можно было бы сделать обманом отмеченного вопроса. Таким образом, я чувствую, что комментарий является достаточным, и дальнейшее изменение не принесет пользу этому вопросу.
AJ Henderson

Ответы:


41

Прежде чем я зайду слишком далеко, позвольте мне сказать, что « Оценка программного обеспечения: демистификация черного искусства» является отличным ресурсом для людей, которые смотрят и думают об оценках. Оба изображения, приведенные ниже, взяты из этой книги, так же как и основные идеи, представленные ниже

Как вы заметили, оценки являются важной частью способности точно прогнозировать и планировать работу. Отсутствие оценок делает бизнес слепым из-за того, как долго что-то займет. Для бизнеса нередко возникает совершенно ошибочное представление о том, сколько времени это займет - что, по их мнению, легко, занимает от шести до восьми недель, а то, что считается сложным, - это взлом в пятницу днем.

Прежде всего, дать оценку. Сама оценка - это не одно число - это обязательство. «Сколько времени займет ABC» -> «Около 5 дней» означает, что около 5 дней. Тем не менее, хорошая оценка - это диапазон, в котором вы на 90% уверены, что он будет в этом диапазоне. Если вы хотите сказать: «Я уверен на 90%, что это займет от 1 до 5 дней», то скажите это. Не работайте с «Я думаю, что это займет от 1 до 10 дней, так что 5 дней - это в среднем» - это не оценка, и вы будете ошибаться в 50% случаев.

Ну, в 50% или более раз программисты печально известны как недооценщики времени выполнения задач.

Рассмотрим конус неопределенности:

Изображение с http://www.construx.com - полная статья на http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Unterminty/

Поймите, что первая оценка в этом диапазоне - 16x. Это все равно что сказать: «Я думаю, это займет от полудня до двух недель», - но вы еще не знаете. Если вы немного продвинетесь в дизайне, диапазон сузится до 4х. Это не означает, что это займет одну неделю, это означает, что вместо этого вы бы сказали: «Если посмотреть на это немного, это займет от трех недель» - да, оценка увеличилась, но диапазон оценки также пошел вниз.

С каждой оценкой, которую вы даете, вы должны быть на 90% уверены, что оценка находится в этом диапазоне. Вы можете ошибаться - 10% времени он выпадет из этого диапазона.

Есть много способов оценить размер проектов. Сравнивая его с прошлыми проектами, используя прокси-сервер (я думаю, что это заняло бы 1000 строк кода, что потребовало бы столько времени для написания), используя функциональные точки (для преобразования в LOC ...), получая оценки от нескольких человек, а затем итеративная доработка ... некоторые работают для некоторых проектов, некоторые работают для других проектов.

Очень важная глава в этой книге , что я говорил на вершине # 23 , который имеет дело с политикой оценки и работа с менеджерами и руководителями.

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

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


Оценки требуют некоторого обдумывания - не выдавайте оценки за манжету. С ними часто связаны огромные ошибки по сравнению с тем, что требуется, когда вы немного об этом думаете.

От Как реагировать , когда вы просили оценки?

Что сказать, когда попросили оценить

Вы говорите: «Я вернусь к вам».

Вы почти всегда получаете лучшие результаты, если замедляете процесс и тратите некоторое время на выполнение шагов, описанных в этом разделе. Оценки, данные в кофемашине (как кофе) вернутся, чтобы преследовать вас.

Из главы 4 «Оценка программного обеспечения»:

Рис. 4-8. Средняя ошибка, полученная за пределами оценки

Обратите внимание, что при этом оценки после небольшого обзора систематически менее дикие и подвержены ошибкам, чем оценки, снятые с манжеты. Не делайте из манжетных оценок. Сядьте и подумайте о задаче и оцените ее, немного подумав.


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

@Ptolemy в любом случае - будь то реализация или концепция, это оценка. Я могу оценить, сколько времени это займет, так что я на 90% уверен, что диапазон охватывает конечный результат. Это может быть очень широкий диапазон, но это тоже оценка - слишком многие люди дают оценки «6-8 недель», а затем пропускают эту оценку, потому что она была слишком узкой - они давали 30% -ную, а не 90% -ную уверенность. Это относится к навыкам оценки, итеративным уточнениям и распространенным ошибкам при оценке любой задачи, поскольку это первые навыки, необходимые для решения проблемы.

15

Босс : AJ, у нас есть 3 собаки, 2 кролика, катапульта и монахиня. Нам нужно найти способ пройти все 7 (да, катапульту тоже) через 20-футовую стену и в озеро на другой стороне без собак, которые едят кроликов, и без утопления монахини. Сколько времени вам понадобится, чтобы найти решение?

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

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

Мораль этой истории в том, что если у вас недостаточно информации для обоснованной оценки, то не делайте этого . Еще нет. Получите больше информации. Исследуй больше. Как правило, вполне нормально сказать: «Я вернусь к вам через 2 дня с более надежными цифрами».

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


9
В этом случае, тем не менее, дизайн, кажется, составляет 90% работы. А высказывание «Я дам вам оценку после того, как я выполнил 90% работы», редко делает кого-либо счастливым.
Móż

1
Как насчет "Дизайн - это 90% работы, и я не буду знать, сколько времени это займет, пока дизайн не будет завершен. Может дать вам приблизительный диапазон сейчас, запустите дизайн и держите вас в курсе изменений в смете как я узнаю больше о решении?
Роб Бэйли

Говоря «это сложная проблема, мы работаем над несколькими идеями, чтобы решить ее. Как команда, мы рассмотрим эти идеи на следующей неделе, и в рамках этого обзора будут определены сроки для различных решений. Хотели бы вы быть на этом техническом совещании?
Майкл Шоу,

4

Я хотел бы предложить вам попробовать что - то на полпути между ответами tylerl и MichaelT со следующим:

  • разделите работу на 3 или 4 фазы. Этапы должны быть:
    1. Анализ проблем
    2. Решение прототипа
    3. Решение в реальном мире
    4. Оценка выхода (тест)
  • Предоставьте оценку своему руководству только для фазы 1 (анализ) на основе своего опыта или фаз 1 + 2 (анализ + прототип). Затем предоставьте им оценку для фаз 3 + 4, когда проблемные фазы 1 и 2 выполнены (или, по крайней мере, достаточно продвинуты, чтобы вы могли быть уверены в своей оценке).

Основанием для этого является то, что вы по опыту знаете, что вам нужно X дней для анализа заданной кодовой базы (возможно, в зависимости от ее размера) и выполнения набора основных инструментов или сценариев (и, возможно, сбоя). Затем количество ошибок должно предоставить вам некоторую информацию о реальной сложности поставленной задачи.

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


+1 Возможно, вы еще не знаете, сколько времени это займет, но вы можете сказать: «Дайте моему Х время, чтобы подумать об этом, и я вернусь к вам» - час, день, неделю, что угодно.
Рори Хантер

1

Поскольку этот вопрос в первую очередь касается исследовательских видов работ, вопрос о том, чтобы разрабатывать программное обеспечение - смелый подход, является общим показателем того, что разработчику программного обеспечения требуется вдвое больше времени, чем его оценка, вероятно, является хорошим разработчиком. Тем не менее, задачи исследования (и проектирования архитектуры) в значительной степени являются частью программирования и часто пропускаются / сводятся к минимуму. Их также часто сложно оценить.

Первый вопрос, который я хотел бы задать себе, это проблема, которую можно решить? Это не проблема интеллекта или умственных способностей, а проблема практической реальности. Если вы не находитесь в мире лунных снимков Google, где отказ является ожидаемым результатом, тяжелая реальность такова , что я буду ожидать , чтобы доставить это , что бы это оказывается. Похоже на грубое практическое правило: мы уже знаем, каким должно быть 90% решения?

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

Третий вопрос: кто лучше всего подходит в команде для такого рода проблем? Кто бы ни получил это задание, украсит результат своим собственным стилем. Предоставление такого рода проблемы программисту, который имеет 10 миллионов вопросов в начале задачи, а затем уходит и поставляет что-то в первый раз (хотя и медленно), может быть лучшим выбором, чем предоставление программисту, который быстро отбрасывает реализацию , но когда есть проблема, она обнаруживается только в конце процесса.

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

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


1

Что касается исследовательских вопросов, где неясно, есть ли вообще ответ, не говоря уже о четком представлении о том, что нужно сделать, я обычно предлагаю потратить на это как можно больше времени.

«Я понятия не имею, возможно ли это вообще, но я мог бы потратить два дня на его изучение. Это, вероятно, не даст нам решения, но, возможно, я смогу исключить некоторые вещи и, возможно, у меня будет идея какими могут быть конкретные последующие шаги и какие временные вложения они будут означать. Тогда мы сможем решить, имеет ли смысл сделать еще один шаг ».

Так что поставьте неопределенность в другом направлении - оценка очень точная (я потрачу два дня), просто очень не определено, что будет достигнуто к тому времени.

Timeboxing, в основном.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.