Прежде чем я зайду слишком далеко, позвольте мне сказать, что « Оценка программного обеспечения: демистификация черного искусства» является отличным ресурсом для людей, которые смотрят и думают об оценках. Оба изображения, приведенные ниже, взяты из этой книги, так же как и основные идеи, представленные ниже
Как вы заметили, оценки являются важной частью способности точно прогнозировать и планировать работу. Отсутствие оценок делает бизнес слепым из-за того, как долго что-то займет. Для бизнеса нередко возникает совершенно ошибочное представление о том, сколько времени это займет - что, по их мнению, легко, занимает от шести до восьми недель, а то, что считается сложным, - это взлом в пятницу днем.
Прежде всего, дать оценку. Сама оценка - это не одно число - это обязательство. «Сколько времени займет 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 «Оценка программного обеспечения»:
Обратите внимание, что при этом оценки после небольшого обзора систематически менее дикие и подвержены ошибкам, чем оценки, снятые с манжеты. Не делайте из манжетных оценок. Сядьте и подумайте о задаче и оцените ее, немного подумав.