Как научиться делать более точные оценки? [закрыто]

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

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

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

Я думаю, больше всего на свете это опыт.

Закон Мерфи Тайм - менеджмент: Для того, чтобы выяснить , как долго что - то будет брать, выяснить , как долго она должна принять и удвоить его.

Затем перейдите к следующей более высокой единице времени. Таким образом, мы выделяем две недели на однодневный проект.

Вы можете учиться, делая их коллективно .

Я использую Planning Poker . Это основанный на консенсусе метод оценки.

Ваша оценка должна отслеживаться и сравниваться с тем, что вы фактически сделали. Вы получите скорость .

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

Оценка программного обеспечения Стивом Макконнеллом (MS Press) - хорошее чтение.

Главное с оценкой программного обеспечения сводится к следующему

Без исторической информации ваши оценки бесполезны.

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

Несколько других моментов, которые следует иметь в виду:

1. Это будет только медленнее . Применение правила 80/20 означает, что тяжелая работа придет позже, если ваше руководство проектом не будет очень дисциплинированным.
2. Оценка! = Планирование. Оценка - это процесс определения усилий, необходимых для выполнения чего-либо. Планирование - это процесс вписывания его в график.
3. Эффективность 60% - это все, на что вы можете надеяться. 70% это утопия. Если вы оцениваете в днях, встраивайте это. Если вы оцениваете в часах, не забудьте применить его позже.
4. Запомни длинный хвост . Оценки представляют собой приблизительное предположение о том, сколько времени это «вероятно» займет с учетом некоторого уровня риска и неизвестных факторов. Длинный хвост вступает в игру, потому что фактический объем требуемой работы никогда не будет меньше 0. ОТО, максимальное количество времени, которое потребуется, ограничено только тем, сколько времени вы готовы потратить на это, прежде чем сдаться. Как сказал мой бывший начальник, «все оценки +/- x%, и это никогда не минус».

Я удивлен, что никто не упомянул технику оценки в стиле PERT, которая описана в книге Роберта Мартина « Чистый кодер» . В этом методе вы оцениваете, сколько времени потребуется для 3 сценариев: optimistic ( O), nominal ( N) и pessimistic ( P). Тогда ожидаемая продолжительность = (O+4N+P)/6и вы получите стандартное отклонение (P-O)/6.

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

Как прокомментировали другие, я также сделал оценки, изучив исторические данные («Сколько времени потребовалось, чтобы сделать эту похожую вещь?»).

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

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

Если мне нужно делать часовые оценки, я стараюсь делать их только для небольших задач в течение итерации. Я измеряю все в полудневных оценках (4, 8, 12 часов), если я не знаю, что это может быть меньше. Но я редко оцениваю что-либо менее чем за 1 час.

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

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

В-третьих, отслеживать время (усилия). Вы должны по крайней мере дифференцировать:

• Анализ
• дизайн
• Код
• Модульное тестирование (включая исправление дефектов)
• Интеграционное тестирование (включая исправление дефектов)

• Приемочные испытания, с пользователем (включая исправление дефектов)

  Было бы замечательно, если бы вы измерили усилия по устранению дефектов для каждого типа тестирования, но это добавляет сложности, так что вы можете сделать это позже.

В-четвертых, определить основные базовые элементы для оценки. Например:

• Количество процессов, которые будут автоматизированы (Анализ)
• Количество объектов модели домена (Дизайн)
• Количество форм и отчетов (Код)

В-пятых, соотнесите базовые предметы и усилия. Например:

• Анализ усилий = X человеко-часов / процесс, который будет автоматизирован
• Проектное усилие = Y человеко-часов / сущность модели домена
• Усилие кода = Z человеко-часов / форма (или отчет); количество форм = A * сущности модели домена
• Модульное тестирование = M% * Кодовое усилие
• Интеграционное тестирование = N% * Кодовое усилие
• Приемочное тестирование = P% * Кодовое усилие

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

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

Посмотрите на http://en.wikipedia.org/wiki/Personal_Software_Process , это действительно работает.

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

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

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

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

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

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

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

Вы можете попытаться составить отчет о том, какова была оценка и что было актуально для различных задач, чтобы создать достаточно записи, чтобы затем узнать, какой множитель будет иметь для определенных вещей, которые повторяются в вашем списке. Конечно, это пробное и ошибочное упражнение, но, похоже, оно мне подходит. Существует также что-то, что можно сказать о многих испытаниях, прежде чем, вероятно, появится модель. Это, вероятно, похоже на множество других ответов, в которых можно было бы сказать: «Просто сделай это!» как это действительно, как большинство из нас развили навык. Это большая боль, чтобы увидеть, насколько неправильно можно делать оценки? Да, но если оценки улучшатся, тогда все могут быть счастливы в конце концов.

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

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

• Разбейте свое назначение на более мелкие составляющие задачи. Оцените каждую задачу как можно лучше.

• Добавьте задачу для планирования и проектирования (которая включает в себя то, что вы делаете сейчас). Оцените ее.

• Если у вас его еще нет, добавьте задачу для «объединения задач». Поначалу эта задача может показаться бесполезной. Тем не менее, когда вы используете этот «оценочный» метод оценки, всегда есть много времени, чтобы выполнить «падение между задачами» и «объединить задачи». Это может быть сложно оценить. Старайся изо всех сил.

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

• Сложите оценки задачи, чтобы получить общую оценку.

• Продолжайте и умножьте эту общую оценку на два ††. Это даст вам время для:

  1. Завершите то, что вы упустили из исходного списка задач
  2. Завершите вещи, о которых вы не могли знать, пока не начали
  3. Включать отзывы других людей и вносить изменения
  4. Быть прерванным другими вещами, происходящими вокруг вас, такими как встречи
  5. Финишируйте с опережением оценки чаще, чем за ней

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

†† По мере того, как вы получаете все больше и больше опыта, этот «фактор выдумки» можно настроить в соответствии с вашим личным стилем и рабочей средой.

Формула, которая работает при работе на себя:

1. сделать разбивку задач до 1 - 4 часа детализации. Я нахожу, что я обычно точен с этими

2. «фактор неизвестных»: умножить на коэффициент 2, повышенный до количества неизвестных. Т.е., если вы хотите разработать приложение couchdb, но теперь знаете что-нибудь о javascript и http .. добавьте 2 ^ 2 в качестве множителя.

3. коэффициент переключения контекста: умножьте на 1,5, если вы будете работать в идеальной обстановке (дома в учебном уголке и т. д.), или на 2,5, если вы будете работать в несовершенной обстановке (офис / людное место и т. д.)

Я считаю, что это в пределах +/- 20% от фактического времени!

Изучите свой собственный уклон. Если ваша последняя оценка была слишком низкой в ​​два раза, в следующий раз удвойте первоначальную оценку. (Конечно, закон Хофштадтера затрудняет это право ...)

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

Для новичков прочитайте «Экономика разработки программного обеспечения» Барри Бома и «Управление программными проектами» Тома Демарко. После того, как вы прочитали и усвоили эти два, прочитайте «Оценка стоимости программного обеспечения с COCOMO 2», Барри Бём.

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

Нет оценки идеально. Есть некоторая вероятность приехать рано, и некоторая вероятность приехать поздно. Первоначальная подробная модель COCOMO Бома давала прогнозы, которые оказались в пределах 30% от фактического результата, лучше, чем в 60% случаев. Это было намного лучше, чем то, что было обычным, когда он написал и опубликовал книгу.

Когда вы берете свое лучшее предположение (и это все оценки), вы включаете эти вероятности. Если вы даете оценку, вы увеличиваете вероятность того, что вы опоздаете. Если вы увеличиваете оценку, вы увеличиваете вероятность того, что вы придете рано или закончите вовремя. То, как много вы вытаскиваете или отпускаете, определяет, как изменяется вероятность, и должно обязательно зависеть от штрафов за раннее или позднее. (Вставьте ужасные истории здесь - и за эти годы их было МНОГО!)

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