Оценка программных оценок: верные признаки нереальных цифр?

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

Подсчитайте количество вопросов, на которые вы получите ответы «да» или «возможно».…

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

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

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

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

НТН

ура

Answer 7

Если вы видите один или несколько из них, у вас может быть неверная оценка:

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

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

Answer 8

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

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

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

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

Answer 9

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

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

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

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

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

Answer 10

Насколько хорошо человек оценивает людей, выполняющих работу?

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