Оценка оценок программного обеспечения: уверенные признаки нереалистичных цифр?

Question

Пока ответ «Dealing with awful estimates» отправил Ash. Я поделился несколькими советами, которые я узнал и лично использовал, чтобы определить слабые оценки. Но я уверен, что должно быть еще много!

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

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

Answer 1

• Один человек, выполнивший оценки, вместо того, чтобы использовать оценку на основе консенсуса (чтобы полностью понять предполагаемый объем требований), такой как Wideband Delphi.
  • Особенно верно, если человек, выполняющий оценку, не является лицом, выполняющим реализацию! - Я когда-то работал над проектом, оцененным кем-то еще, за 60 дней до того, как были даже предоставлены какие-либо требования. Давайте просто скажем, что я не был счастливым кроликом
• Нет времени для документации.
• Нет времени для наращивания (с точки зрения обучения и размера команды).
• Перечень рисков и их влияние на временные рамки.
• Буфер непредвиденных - с точки зрения требований к позднему прорыву и рисков.

Answer 2

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

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

• развития
• тестирование
• упаковки и развертывания
• и т.д.

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

Если оценка является чрезмерно точной, т.е. 0,25 часа, то для меня это плохой запах.

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

Редактировать: Еще одна вещь, на которую нужно обратить внимание - это старые задачи «навсегда 90% полной». Вы получаете обновление выполнения после обновления обновления, перечисляя задачу как «90% завершено». Это не хорошо!

НТН

веселит

Answer 3

оценки вида 3, 6 или 12 месяцев (в основном любой круглых номера) рейки угадать. Обычно, когда вы догадываетесь, вы выбираете какой-то круглый номер, который больше, чем вы думаете, это займет четверть, полгода и т. Д. - обычные подозреваемые. Я предпочитаю оценки с точки зрения фактических итераций развития (независимо от их размера).

Answer 4

Существует два типа оценок: оценки задачи и оценки проекта. Вы можете просмотреть их как большие и маленькие картинки.

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

• архитектуры высокого уровня;
• Время проведения испытаний;
• Ramp up times;
• Дефектные процессы;
• Время для документации;
• Соответствующая подготовка;
• Предположения;
• Зависимости (например, команда A не может делать то, что им нужно, до тех пор, пока команда B не выполнит этап 1);
• Критический путь (какие части могут определить, скользет ли проект и на сколько); и
• Риски.

Чем больше тех вещей, которые отсутствуют, тем более нереальными (или рискованными) оценками.

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

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

Другие сообщения упомянули, что время тестирования должно быть равно или превышать время dev. Я категорически не согласен с этим. Я видел, что 8-часовые задачи для разработчиков приводят к 100-часовому тестовому времени, а 80-часовые задачи для разработчиков приводят к менее чем 2 часам тестирования. В обоих случаях время тестирования было вполне разумным. Абсолютная корреляция между ними не существует. В лучшем случае есть свободная связь.

Answer 5

Что очевидное и не очень явные признаки слабых программных оценок, которые могут быть определены без много детальных знаний о задаче стороны?

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

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

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

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

Answer 6

• Является составителем оценки доступны и готовы обсудить его с другими старшими проекта членов? Если нет, то это часто относится к .

• Был оценку отправлена ​​в клиента перед тем опыт и навыков развития персонала являются известно. Двухточечные оценки могут помочь , но только в некоторой степени.

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

(Спасибо за ответ на мой вопрос, кстати.)

Answer 7

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

Я бы также сказал, если оценка представлена ​​как единое абсолютное число (скажем, 180 дней), то это не хороший знак. Одно абсолютное число указывает на то, что оценка состоит в том, что задача будет завершена со 100% -ной вероятностью по данным данным. Оценки, представленные в диапазоне (скажем, от 130 до 180 дней), указывают на то, что диапазон, в котором задача может быть завершена.

Многое из того, что я написал выше, я отношу его к книге:

Software Оценка: Прояснение Черное искусство Стив Макконнелл

Answer 8

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

Answer 9

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

Это почти наверняка не закончится в удобную для бизнеса дату.

Он будет включать в себя риски различного рода.

Он будет представлен в терминах доверительных интервалов, либо неявно (10-12 месяцев), либо с использованием больших единиц (около четырех четвертей).

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

Если есть задержки в начале, в конце будут задержки (выраженные через 10-12 месяцев с начала или около 1Q2010, если мы начнем сейчас, а не в январе 2010 года, когда проект еще не начался).

Допущения и зависимости будут четко и заметно перечислены.

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

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

Answer 10

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

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

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

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

Answer 11

• Является ли оценка руководством ?
• Оценивает ли с плановой датой отправки товара на следующий номер ?
• Имеет ли вознаграждение за управление людям, которые дают хорошие новости больше, чем людям дают плохие новости?
• Была ли подготовлена ​​оценка , прежде чем знать, кто будет работать над проектом? ?
• Был ли кто-то, кто хотел, чтобы бит был функционально реализован, подготовит оценку ?
• Есть ли история программное обеспечение опоздает?
• Это нормально для разработчиков, которые должны быть перемещены на другие задач частично, хотя проект?
• У некоторые разработчики отказались от , комментируя плохие оценки как трату времени?

Подсчитайте количество вопросов вы получите «да» или «может быть» ответы. ...

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

Answer 12

Если вы видите один или несколько из них, вы можете иметь плохую оценку:

• оценок Одноточечные: оценка должна быть связана с диапазоном возможных дат или значения доверительной
• Недостаточная зернистости из задач: большое ведение задачи обычно указывает на то, что функциональность недостаточно понятна (что особенно проблематично, поскольку плохо понимаемые проблемы обычно недооценены)
• Отсутствие предположений и/или рисков
• Неадекватное усилие все ocated для обычно пропущенных или недооцененных предметов (например, строить сценарии, документацию, развертывание и т. д.)

Я согласен с sateesh, мне очень нравится Оценка программного обеспечения: Демистификация черного искусства Стив Макконнелл. У него есть несколько контрольных перечней, которые полезны при рассмотрении и/или подготовке оценок.

Answer 13

Любое из следующих действий:

• Это один большой проект, и есть не короткая стратегия высокого уровня описана
• Существует не ясно, коротко и краткое видение того, что хочет быть достичь с проектом
• Проект не структурирован по мере того, как коммерческая стоимость доставляется постепенно
• Команда пытается дать «точные» оценки для большого проекта, вдаваясь в (или завершив) долгую фазу анализа? (изменения вступят и будут, как правило, влиять на эти оценки таким образом, которые не могут быть легко определены количественно без больших усилий)
• Есть «подробные» оценки всего проекта (связанные с предыдущим)
• Там aren ' t подробные оценки для первой фазы, или что-то не так в них.

Answer 14

Вау ... Мне очень нравится ответ инструментария.

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

я придумал еще несколько показателей опасной оценки:

• Нет перекрестных ссылок - Если оценка не может быть подтверждена по крайней мере два различных способа, это, вероятно, будет ненадежным , Например, последние оценки, которые я выполнил, я смог разбить работу на мелкие фрагменты функций и подумать, как долго наша команда выполняет аналогичные функции. Затем я смог посмотреть на сумму этих затрат и посмотреть, насколько большой объем был относительно других проектов, над которыми я работал. Это два способа проверки.
• Основание оценки - если это программная оценка, сделанная аппаратным парнем, который никогда не был написан кодом, очень бойтесь. Чем более тонко - чем ближе фон оценщика к технологии и проблемной области проекта, тем лучше.
• Подробнее - как сказано несколько разных способов в нескольких разных сообщениях - мне нравится видеть детали как для отдельных функций, так и для задач, необходимых для выполнения каждой функции. Большинство оценок, которые я вижу, не показывают детали в официальном представлении, но если вы спросите человека, который сделал смету, у них должен быть файл где-нибудь. Надеюсь, это не задняя часть бумажной салфетки, окрашенной пивом и кетчупом. :)
• Документированные предположения - любой оценщик должен был бы сделать некоторый набор предположений о задаче. Они должны быть документированы где-то, как правило, в официальных документах. Я всегда немного волнуюсь, когда вижу короткое предложение с небольшим количеством задокументированных предположений. Либо они были продуманы, либо не доведены до сведения клиента, или они не были продуманы. Я не уверен, что хуже. Само собой разумеется, что предположения также должны быть разумными.
• Сбалансированный жизненный цикл - Однако задача разбита, каково соотношение дизайна, кода и теста? Как насчет документации, интеграции с внешними системами и поддержки после выпуска? Как насчет тех дополнительных вещей, которые так важны (системные администраторы, гуру CM, управленческие усилия)?
• Slack - Я уверен, что корпоративные демоны дешевизны придут и сожгут меня, но график и стоимость должны иметь некоторый провисание. Если оценка выглядит амбициозной и агрессивной для опытного глаза, она, вероятно, будет слишком низкой. Оценки почти никогда не бывают слишком высокими.

Answer 15

Как знакомый человек дает оценку людям, которые выполняют работу?

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

Answer 16

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

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

Что все сказано, с точки зрения Agile, некоторые из способов, по которым мы пытаемся получить более последовательные оценки во время проекта;

• Используйте относительный стандарт калибровки (S, M, L, XL), а не время (идеальные дни).
• внимание на сложностях не раз
• Всегда использовать группу оценки не один человек оценивает
• Собирают оценки часто на протяжении всего проекта, как правило, в начале каждого спринта
• использование обратной связи от предыдущих спринтов в определении сюжетной сложности
• скорость трека, чтобы придать смысл относительной проклейки
• частую и раннюю историю ретроспективу, чтобы изучить/понять любой обмолота

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

Answer 17

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