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

652

Нас, программистов, постоянно спрашивают: «Сколько времени это займет?»

И вы знаете, ситуация почти всегда так:

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

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

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

Каков ваш личный процесс для принятия решения и оценки? Какие техники вы нашли полезными?

Серхио Акоста
источник
4
Если требования не так ясны, вы можете оценить с погрешностью 50% (более широкий диапазон). Если требования ясны, вы можете оценить с погрешностью 20%. Еще одна хорошая стратегия, которая сработала для меня, - это разбить проект на этапы. Этот способ легче оценить, и вам нужно оценить только первый этап. Когда вы собираетесь оценить следующий этап, вы гораздо лучше понимаете проект. Кроме того, доверие между вами и вашим подрядчиком должно быть лучше. Я также всегда пишу свои предположения и предпосылки. Никогда не пишите "это будет работать на IE8 или выше", конкретно.
Франциско Гольдштейн
Серхио: «В результате я всегда заканчиваю давать оценки, которые позже осознаю, что не могу выполнить. Это происходило бесчисленное количество раз, и я всегда обещаю, что это больше не повторится. Но так и есть». Насколько вы чувствуете себя лучше сегодня?
Ремигиюс Панкявичюс
4
@ r.pankevicius Честно говоря, я просто перестал давать оценки: rclayton.silvrback.com/software-esvaluation-is-a-losing-game
Серхио Акоста,
2
Я думаю, что также важно видеть нюанс между «оценками» и «сроками». Оценка не является обязательством, поэтому небольшая ошибка не должна быть слишком проблематичной. Я написал длинное сообщение в блоге об этом здесь на случай, если кому-то будет интересно: marcgg.com/blog/2015/08/27/deadlines-estimates-software-startup
marcgg

Ответы:

390

От прагматичного программиста: от подмастерья до мастера :

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

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

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

В разделе авторы рекомендуют следующий процесс:

  • Определите, какая точность вам нужна. На основании продолжительности вы можете процитировать оценку с различной точностью. Сказать «от 5 до 6 месяцев» - это не то же самое, что сказать «150 дней». Если вы немного проскользнете в 7-й месяц, вы все еще довольно точны. Но если проскочить в 180-й или 210-й день, не так уж и много.
  • Убедитесь, что вы понимаете, о чем спрашивают. Определите масштабы проблемы.
  • Смоделируйте систему. Модель может быть ментальной моделью, диаграммами или существующими записями данных. Разложите эту модель и составьте оценки из компонентов. Присвойте значения и диапазоны ошибок (+/-) каждому значению.
  • Рассчитайте оценку на основе вашей модели.
  • Отслеживайте свои оценки. Запишите информацию о проблеме, которую вы оцениваете, вашу оценку и фактические значения.
  • Другие вещи, которые необходимо включить в оценку, - это разработка и документирование требований или изменений в спецификациях требований, создание или обновление проектной документации и спецификаций, тестирование (единица, интеграция и принятие), создание или обновление руководств пользователя или README с изменениями. Если 2 или более человека работают вместе, это накладные расходы на общение (телефонные звонки, электронные письма, встречи) и слияние исходного кода. Если это длинная задача, при выборе даты доставки учитывайте такие вещи, как другая работа, свободное время (праздники, отпуск, больничное время), встречи и другие служебные задачи.
Томас Оуэнс
источник
32
Это также большая часть «Черного искусства оценки программного обеспечения» Макконнелса. Никогда не обманывайте это.
Пол Натан
12
Я очень рекомендую книгу Макконнелла. Если возможно, попросите любого, кто нуждается в оценке от вас, принять участие в его оценочной викторине: codinghorror.com/blog/2006/06/… Вы можете представить его как игру, но это часто помогает донести сообщение.
Paddyslacker
130
Вы всегда можете сказать: «Я вернусь к вам». Если кто-то скажет: «Ну, мне нужен ответ», скажите: «Если я дам вам ответ сейчас, это будет ложь. У меня сейчас недостаточно информации. Это было бы плохой услугой для нас обоих, чтобы я что-то сделал на месте ".
Энди Лестер
15
@AndyLester - возникает множество ситуаций, когда если ВЫ не дадите ответ сейчас, кто-то другой ответит, или либо возьмет с собой проект и деньги, либо все равно возьмет на себя вину вину за то, что вы пропустили оценку, у которой ничего не было делать с. Это отстой, и это неправильно, но, к сожалению, это реальность.
Йорис Тиммерманс
3
@ThomasOwens Я бы никогда не использовал оценку для стрельбы из контракта, но я использую эти оценки до стадии контракта. Я должен дать какой-то порядок величины, прежде чем клиент посвятит свое драгоценное время детальному изучению мелких деталей - если то, что они думают заплатить, на несколько порядков меньше, чем мое оптимистичное настроение, то нет смысла даже Начало.
Йорис Тиммерманс
170

Оценка программного обеспечения является наиболее сложной единственной задачей в программной инженерии, а второе - определение требований.

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

  1. Внимательно посмотрите на ваши требования.
  2. Сделайте предположения, чтобы заполнить пробелы, основанные на ваших лучших предположениях о том, что они хотят
  3. Запишите все свои предположения
  4. Заставьте их сесть, прочитайте и согласитесь с вашими предположениями (или, если вам повезет, заставьте их сдаться и дать вам реальные требования).
  5. Теперь у вас есть подробные требования, которые вы можете оценить.

Как будто моя мать в детстве угрожала мне: «Поторопись и выбери одежду, или я выберу ее для тебя!»

Fishtoaster
источник
Я задал дополнительный вопрос относительно вашего третьего пункта. programmers.stackexchange.com/questions/132970/…
k0pernikus
Сколько времени нужно, чтобы написать хорошие требования?
Mmehl
142

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

  • Я выставил счет за все время, потраченное на оценку. Это составило около 20-25% от того, что я выставил.
  • Я сделал очень подробный анализ заданий. Нет стрельбы из бедра. Я пошел в код, выяснил, какие строки нужно изменить, на какие другие части программы это повлияет, сколько тестов мне нужно сделать, чтобы убедиться, что все работает. Я бы оценил каждый кусок в единицах по 0,1 часа (6 минут).
  • Я отправил ему свою оценку для каждой задачи вместе с этим подробным описанием.

20-25% биллинга звучит как много.

Но он попросил меня внести изменения XYZ, думая, что это займет около 2 часов. За 1 час детальной оценки я бы определил, что это займет 8,5 часов. Поэтому он решит, стоит ли это 8,5 часов оплаты. Если нет, то он сэкономил 7,5 часов сверх того, что стоило бы ему, если бы я сделал это без оценки.

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

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

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

Kyralessa
источник
12
Это звучит как очень адекватная техника. Фактически, когда вы делаете оценку для своей компании, расчетное время оплачивается как часть вашей зарплаты. Однако я боюсь, что проблема в том, что большинству организаций нужны оценки гораздо больших задач, чем те, которые могут быть выражены в .1 часах. Спасибо за Ваш ответ. (Вы тот же самый Киралесса из Джоэла по программным платам?)
Серхио Акоста,
1
Да, тот самый.
Kyralessa
@ SergioAcosta в том, что вы используете время анализа / оценки, чтобы разбить задачу на более мелкие куски. Это лучший ответ, имхо.
НимЧимпски
7
Так что, если это 5-месячный проект, вы должны оценивать его на месяц или более. Вероятно, менеджеры не примут это :)
Darius.V
@ Darius.V, вы делаете хорошее замечание. В этом случае решения клиента были «да» или «нет» для определенных функций, а не «да» или «нет» для всего проекта. Этот метод, безусловно, более сложный, если выполнение всего проекта зависит от общей оценки. С другой стороны, если вы составляете бюджет на шесть месяцев для проекта, но проект может фактически занять год, вы бы предпочли выяснить это через шесть месяцев или через два или три?
Kyralessa
64

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

Они почти всегда получают смысл.

Вальтер
источник
7
Когда они говорят, что это слишком много, я делаю вид, что думаю на минуту, а потом говорю: «Ты прав! Это 18 месяцев и 2 миллиона».
CyberFonic
55

Это зависит от того, для чего оценка.

Для начальной, высокоуровневой оценки для бизнес-кейса ключевыми являются следующие вещи:

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

Я нахожу лучшую технику, чтобы выбрать сопоставимый проект, который "чувствует" то же самое «Чувство» является полностью субъективным, но с такой оценкой мой опыт подсказывает, что вы не найдете объективных измерений. Тогда предоставьте широкий ассортимент. Я читал некоторые книги, в которых говорится, что диапазон от -50% до + 100% - это хорошо, но это зависит от многих факторов.

Для подробной оценки низкого уровня:

  1. Вам нужна базовая линия. Если базовый уровень не стабилен, оценка не имеет смысла.
  2. Лучше снизу вверх. Получите подробную разбивку работы, оцените каждый компонент, а затем сверните его в большее число. Я считаю планирование покера отличной техникой.
  3. Документ на случай непредвиденных обстоятельств. Укажите, где добавлено какое-либо непредвиденное обстоятельство (если оно есть). Это добавлено к каждой позиции? Или в целом оценить? Или к конкретным рискам? Или нет?
  4. Выскажите свои предположения. Подтвердите как можно больше с учетом временных рамок.
  5. Укажите явно, что включено и исключено в оценке. Например, включен ли обзор? Включены ли технические задержки?
darreljnz
источник
25

Несколько советов от темной стороны от того, кто научился трудному пути.

Требования неясны. Никто не сделал глубокий анализ всех последствий.

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

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

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

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

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

Определение «сделано», вероятно, неясно: когда это будет сделано? «Готово», как в только что законченном кодировании, или «готово», как в «пользователи используют его»?

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

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

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

Проблема здесь в следующем: допустим, вы и Джо делали оценки времени для одной и той же задачи (но между двумя отдельными сотрудниками, не подозревая об обеих оценках одновременно). Вы доблестно оцениваете «одну неделю» . Это нормально, вы думаете, вы будете работать более 100 часов в неделю, без оплаты сверхурочных. Теперь ты опоздал на три дня.

Между тем Джо оценивает 5 месяцев. Вы думаете, что это смешно, вы думаете, что можете справиться с этим за одну неделю. Сколько работает Джо? 10 часов в неделю? ... кроме того, что он заканчивает вовремя ровно через 5 месяцев.

Угадай, кого воспринимают как осла? Это верно, ты. Джо, кажется, отличный работник, ты выглядишь ненадежным сейчас. Не имеет большого значения, что вы могли бы достичь еще лучшего результата в ~ 7% времени, которое занимал Джо. Важно то, что у вас было 3 выходных дня после одной недели.

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

ChrisF
источник
2
Это отличный ответ, он дает мне очень полезную информацию о том, как оценивать и учитывать вещи, спасибо
mboullouz
18

"Две недели!"

Шутки в сторону. Моя первая оценка всегда две недели. Потому что у меня какой-то странный умственный блок, который заставляет меня думать, что все звучит так, как будто это будет две недели.

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

Практически каждый хороший менеджер, которого я имел, научился распознавать "Две недели!" как ответ, который требует мягкого словесного шлепка в ответ.

BlairHippo
источник
3
Вероятно, именно поэтому большинство команд делают 2-недельные спринты :)
Кристиан Э.
17

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

Я сам не пробовал, но хотел бы, чтобы увидеть, насколько точны мои оценки.

Ричард
источник
2
Джоэл Фогбугз (Joel's Fogbugz) идет дальше и анализирует ваши данные для вас, используя планирование на основе фактических данных. То есть, каждый разработчик указывает, сколько времени займет выполнение каждой задачи, а затем, сколько времени заняла эта задача, и определяет, насколько точен каждый разработчик со своими оценками, чтобы получить кривую вероятности для даты окончания.
Крис Бакетт
Да, тогда сделайте немного GDD - Gauge-Driven Development и разрушите все
Claudiu Constantin
11

Это зависит от организации и того, как используются оценки.

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

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

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

грамм .
источник
2
+1 за необходимость постоянного общения. ИМО, это самая полезная часть Agile модели.
Скотт Уэлдон
Это первый приличный ответ здесь, просто потому, что он единственный (я читаю сверху вниз), который подчеркивает «постоянное общение». Все остальные, кажется, считают, что оценка - это разовое событие. Это плохой совет и плохой подход к этим вещам. Этот ответ - хороший совет.
Адам Кэмерон
9

Оценки за что? Небольшие задачи или полные решения.

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

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

MLK
источник
Ууу планирую покер!
Шон Макмиллан
7

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

Каждую неделю подсчитывайте, сколько еще нужно сделать, переоценивайте на основе того, что вы знаете. Как только вы наберете достаточный объем выборки для того, сколько работы вы проделываете каждую неделю, обеспечьте 90% доверительный интервал для того, что осталось, чтобы дать (обычно) постоянно сужающийся диапазон дат по мере выполнения проекта и объема работы (надеюсь) ) сжимается.

Paddyslacker
источник
7

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

ИМ: Сколько это будет стоить?

Я: Это зависит от того, что вы хотите, чтобы я сделал. Как правило, я начинаю этот проект примерно с $ X.

Моше
источник
6

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

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

  • Примерная цифра
  • оценка услуг
  • оценка характеристик
  • компонентная оценка

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

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

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

Вы можете прочитать больше на нашем блоге!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Надеюсь, эта информация поможет вам!

Olha
источник
5

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

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

Несколько советов, основанных на моем ~ 10-летнем опыте:

  • Всегда указывайте диапазон (т.е. нижнюю и верхнюю границу). Это сообщит ваш уровень неопределенности
  • Если у вас очень большая неопределенность, попросите об отсрочке (например, 1 день для анализа, а затем укажите более узкий диапазон)
  • Если задача слишком большая, разбейте ее и укажите диапазон для каждой части
jamesfmackenzie
источник
4

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

Но все же все планирование поможет только в определенной степени. Только когда вы начнете кодировать, вы сможете найти точные проблемы

Гопи
источник
1

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

А затем спросите себя: на какой проект это похоже? И тогда вместо того, чтобы отвечать «2 месяцами», вы можете ответить «звучит как L для меня» (или что бы то ни было, ваша калибровка для проекта оказывается).

Это довольно легко понять, и также ясно, что в этих предположениях много неопределенности.

Затем, когда требования меняются, вы можете сказать: «это изменение делает его более похожим на XL».

Moritz
источник
это довольно разумно (если вам разрешено его использовать): я предпочитаю использовать аналогичный подход, но просто обобщать значения времени, поэтому я отвечу «это займет неделю или около того» или «это будет вопрос дней »для чего-то маленького и избегайте ответов, когда проект будет больше месяца и нуждается в правильной оценке
Эдоардо
0

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

xtreampb
источник
1
Эта ссылка Бесплатный онлайн калькулятор PERT больше не работает.
Крокодилко
@krokodilko Я разработал новый инструмент PERT, который в большей степени ориентирован на оценки программного обеспечения, здесь: values.rokkincat.com .
сленг