Глава 2.
СОВЕТ № 5 -.
Не предоставляйте процентные оценки достоверности (особенно «достоверные на 90 %»), если только они не поддерживаются количественными методами.
СОВЕТ № б -.
Избегайте искусственного сужения диапазонов. Следите за тем, чтобы диапазоны, используемые в оценках, не искажали вашего представления о достоверности оценки.
СОВЕТ № 7 -.
Если вы испытываете воздействие, направленное на сужение диапазона, убедитесь в том, что оно идет извне, а не рождается внутри вас.
Глава 3.
СОВЕТ № 8--.
Избегайте намеренной недооценки. Потери от недооценки превышают потери от переоценки. Если вас беспокоит возможная переоценка, решайте проблемы посредством планирования и управления, а не за счет смещения оценки.
СОВЕТ № 9---—-.
Несоответствие между деловыми целями и оценкой проекта следует рассматривать как ценную информацию о возможной неудаче проекта. Принимайте меры на ранней стадии, когда еще можно что-то сделать.
СОВЕТ № 10 --—.
Многие организации ценят предсказуемость выше, чем срок разработки, затраты или гибкость. Обязательно выясните, какие показатели считаются приоритетными в вашем случае.
Глава 4.
СОВЕТ № И -
-.
Проанализируйте воздействие конуса неопределенности на точность вашей оценки. Ваша оценка не может быть более точной, чем это возможно на текущей позиции проекта внутри конуса.
СОВЕТ № 12 -
-.
Не надейтесь, что конус неопределенности будет сужаться сам собой. Вы должны заставить его сужаться, устраняя источники неопределенности из проекта.
СОВЕТ № 13 -.
Учитывайте наличие конуса неопределенности, закладывая в своих оценках заранее определенную амплитуду неопределенности.
СОВЕТ № 14 -.
Учитывайте наличие конуса неопределенности, разделяя оценку на две составляющие: один специалист дает количественную оценку, а другой оценивает ее неопределенность.
СОВЕТ № 15 -;-.
Не рассчитывайте, что совершенствование методики оценки само по себе обеспечит более точную оценку в хаотических проектах. Невозможно точно оценивать процесс, который вами не контролируется. На первом шаге важнее избавиться от хаоса, чем совершенствовать оценку.
СОВЕТ № 16 -.
В условиях нестабильных требований следует ориентироваться на стратегии управления проектом вместо стратегий оценки (или совместно с ними).
СОВЕТ № 17 -.
Включайте в оценку время для всех видов требований — заявленных, неявных и нефункциональных. Ничто не создается «из ничего», и ваша оценка не должна подразумевать, будто возможно обратное.
Учитывайте в оценке все необходимые действия, связанные с разработкой программного обеспечения, не только программирование и тестирование.
В проектах, продолжительность которых превышает несколько недель, следует предусматривать допуск для дополнительных факторов: праздников, отпусков по болезни, времени обучения, собраний.
СОВЕТ № 20 -.
Не уменьшайте оценки, полученные от разработчиков, — скорее всего, они и без того излишне оптимистичны.
СОВЕТ № 21 -.
Избегайте включения «регуляторов» в свои оценки. Хотя может показаться, будто регуляторы улучшают точность, на самом деле они вводят в оценку субъективность и снижают реальную точность.
СОВЕТ № 22 -.
Не давайте импровизированных оценок. Даже если потратить на оценку всего 15 минут, она будет более точной.
СОВЕТ № 23 -.
Количество значащих цифр в оценке (ее четкость) должно соответствовать точности оценки.
Глава 5.
СОВЕТ № 24 -.
Приложите соответствующие усилия для оценки размера программы, над которой вы работаете. Размер вносит наиболее значительный вклад в определение объема работы и сроков.
СОВЕТ № 25 --.
Не следует предполагать, что объем работ линейно зависит от размера проекта. Рост происходит по экспоненте.
СОВЕТ № 26 -.
Используйте специализированные программы для вычисления влияния издержек масштаба.
СОВЕТ № 27 -.
Если ранее вы уже завершали предыдущие проекты, размер которых незначительно отличается от размера оцениваемого проекта (в диапазоне, в котором самый большой проект превосходит самый мелкий не более чем в 3 раза), для оценки нового проекта можно смело использовать масштабный коэффициент (скажем, количество строк кода на человеко-месяц).
СОВЕТ № 28 -.
В своей оценке учитывайте тип разрабатываемой программы — в отношении влияния на объем работы и сроки этот фактор является вторым по значимости.
Глава 6.
СОВЕТ № 29 -.
При выборе метода оценки следует учитывать оцениваемый показатель, размер проекта, стадию разработки, стиль разработки и требуемую точность.
Глава 7.
СОВЕТ № 30 -—--.
Считайте везде, где это возможно. Если счет невозможен — вычисляйте. Используйте оценки, полученные на основании одного лишь экспертного суждения, только в крайнем случае.
СОВЕТ № 31 ------.
Найдите счетный показатель, который может использоваться для осмысленного измерения содержания работы в вашей среде.
СОВЕТ № 32 -.
Соберите исторические данные, которые позволят вам вычислить оценку по счетным показателям.
СОВЕТ № 33 --.
Не пренебрегайте возможностями простых, грубых оценочных моделей — таких, как средний объем работы на дефект, средний объем работы на веб-страницу, средний объем работы на историю пользователя и средний объем работы на сценарий использования.
СОВЕТ № 34 -.
Не используйте экспертные суждения для подгонки оценок, полученных на основании вычислений. Подобная «экспертиза» обычно лишь ухудшает точность оценки.
СОВЕТ № 35 -.
Стройте свои оценки производительности на исторических данных. Производительность вашей организации в прошлом дает наилучшее представление о ее производительности в будущем.
СОВЕТ № 36 -.
Исторические данные помогают избежать решений, имеющих политическую подоплеку и возникающих из предположений типа «Моя группа ниже среднего».
Глава 8.
СОВЕТ № 37 -
-.
При сборе исторических данных для оценок убедитесь в том, что вы понимаете смысл показателей, и не изменяйте его между проектами.
СОВЕТ № 38 -.
Собирайте исторические данные как можно раньше после начала проекта.
СОВЕТ № 39 -.
Организуйте периодический сбор исторических данных во время работы над проектом. Это позволит вам позднее построить профиль выполнения проекта, базирующийся на собранных данных.
Используйте данные, полученные в ходе текущего проекта (проектные данные), для создания высокоточных оценок для оставшейся части проекта.
Там, где это возможно, используйте для калибровки оценок проектные или исторические данные вместо среднеотраслевых. Помимо повышения точности оценок, исторические данные сокращают разброс оценок, обусловленный неопределенностью предположений по поводу производительности.
СОВЕТ № 42 -.
Если в настоящий момент у вас еще нет исторических данных, начните собирать их как можно скорее.
Глава 9.
СОВЕТ № 43 -.
Оценки уровня задач следует поручать людям, непосредственно занимающихся выполнением соответствующей работы.
СОВЕТ № 44 -.
Создание оценок для лучшего и худшего случаев стимулирует мышление и помогает учесть весь возможный диапазон возможных результатов.
СОВЕТ № 45 -.
Используйте контрольные списки для улучшения индивидуальных оценок. Составляйте и ведите собственные контрольные списки.
СОВЕТ № 46 -.
Сравнивайте оценки с фактическими результатами, чтобы повышать качество своих оценок со временем.
Глава 10.
СОВЕТ № 47 -.
Разбейте общую оценку на фрагменты, чтобы воспользоваться действием закона больших чисел: ошибки в сторону завышения и занижения до определенной степени компенсируют друг друга.
СОВЕТ № 48 -.
Используйте обобщенную структуру трудозатрат программных проектов (WBS), чтобы не забыть о типовых операциях.
СОВЕТ № 49 -.
Используйте упрощенную формулу среднеквадратического отклонения для вычисления содержательных оценок лучшего и худшего случаев в проектах, состоящих из 10 и менее задач.
Используйте сложную формулу стандартного отклонения для вычисления содержательных сводных оценок лучшего и худшего случаев в проектах, состоящих из 10 и более задач.
Не используйте деление диапазона между лучшим и худшим случаями на 6 при вычислении отклонений стандартных оценок. Выбирайте делитель в зависимости от точности диапазонов ваших оценок.
Направьте усилия на повышение точности оценок ожидаемого случая. Если отдельные оценки точны, то и их объединение не создаст проблем. С другой стороны, если отдельные оценки неточны, объединение станет возможным лишь после того, как вы найдете способ повысить их точность.
Глава 11.
СОВЕТ № 53 -.
Оценивайте новые проекты, сравнивая их с похожими прошлыми проектами. Постарайтесь разбить оценку минимум на пять фрагментов.
СОВЕТ № 54 -.
Не решайте проблему неопределенности смещением оценки. Постарайтесь отразить неопределенность в самой оценке.
СОВЕТ № 55 -.
Используйте нечеткую логику для оценки размера программы в строках кода.
СОВЕТ № 56 -.
Рассматривайте метод стандартных компонентов как средство для получения оценки размера с минимальными усилиями на ранних стадиях проекта.
СОВЕТ № 57 -.
Метод абстрактных рейтингов используется для получения ранней оценки объема работ и сроков проекта, и в основу его закладываются данные того же проекта.
СОВЕТ № 58 -;-.
Будьте внимательны при вычислении оценок, в которых используются числовые рейтинговые шкалы. Убедитесь в том, что числовые категории на шкале действительно ведут себя как числа, а не как отвлеченные категории вроде «малый», «средний» или «большой».
СОВЕТ № 59 -.
Используйте метод футболки, чтобы помочь не-техническим сторонам проекта принять решения по включению или исключению тех или иных функций в широкой части конуса неопределенности.
СОВЕТ № 60 -.
Используйте опосредованные методы для оценки количества тестовых сценариев, дефектов, страниц документации и любых других показателей, которые трудно оценивать напрямую.
СОВЕТ №61 -.
Подсчитывайте тот показатель, который проще всего считается и обеспечивает максимальную точность в вашей среде. Соберите калибровочные данные и используйте их для создания оценки, адаптированной к вашей среде.
Глава 13.
СОВЕТ №62 -.
Используйте групповое обсуждение для повышения точности оценки.
Используйте широкополосный Дельфийский метод для формирования оценок на ранней стадии проекта, в незнакомых системах, а также тогда, когда в проекте задействовано несколько разнородных дисциплин.
Глава 14.
СОВЕТ № 64 -.
Используйте оценочные программы для логической проверки оценок, созданных ручными методами. Оценки крупных проектов должны в большей степени опираться на коммерческие оценочные программы.
СОВЕТ № 65 -.
Не относитесь к результатам оценочной программы как к божественному откровению. Проверяйте их на соответствие здравому смыслу точно так же, как любую другую оценку.
Глава 15.
СОВЕТ № 66 -
-.
Используйте несколько альтернативных методов оценки и проанализируйте совпадения или расхождения результатов.
СОВЕТ № 67 -.
Если разные методы оценки приводят к разным результатам, попытайтесь выявить факторы, из-за которых возникают различия. Продолжайте оценивать проект заново до тех пор, пока результаты, полученные разными методами, не будут расходиться в пределах 5 %.
СОВЕТ № 68 -.
Если деловая цель противоречит нескольким сходящимся оценкам, лучше доверьтесь оценкам.
Глава 16.
СОВЕТ № 69 -.
Не оспаривайте результаты оценки, а принимайте их как данность. Изменение результата может производиться только одним способом: изменением входных данных и повторным вычислением.
СОВЕТ № 70 -.
Сначала сконцентрируйтесь на оценке размера. Затем вычислите объем работ, сроки, стоимость и функциональность по оценке размера.
СОВЕТ № 71 -.
Проводите повторную оценку.
СОВЕТ № 72 -.
Переходите от неточных оценок к более точным по мере продвижения работы над проектом.
СОВЕТ № 73 -.
Когда проект будет готов к назначению индивидуальных заданий, переходите на восходящую оценку.
Если оценка пересчитывается в результате нарушения промежуточных сроков, новая оценка должна базироваться на фактическом ходе проекта, а не на запланированных показателях.
СОВЕТ № 75 -.
Представляйте свои оценки в таком виде, чтобы они уточнялись по мере продвижения проекта.
СОВЕТ № 76 -.
Сообщайте о своих планах повторного проведения оценки заранее.
Глава 17.
СОВЕТ № 77 -.
Определите стандартизированную процедуру оценки на уровне организации и применяйте ее на уровне отдельных проектов.
СОВЕТ № 78--
-.
Координируйте стандартизированную процедуру оценки с процессом SDLC, принятым в вашей организации.
СОВЕТ № 79 -;-.
Анализируйте оценки и процедуры получения оценок в своих проектах; это поможет вам повысить точность оценок и свести к минимуму затраты на их создание.
СОВЕТ № 80 -.
Используйте строки профаммного кода для оценки размеров, но помните об общих ограничениях простых метрик, а также специфических опасностях метрики LOC.
СОВЕТ № 81 -.
Воспользуйтесь методом функциональных пунктов, чтобы получить относительно точную оценку размера на ранней стадии проекта.
СОВЕТ № 82 -;-.
Используйте голландский метод для получения приближенной оценки с минимальными затратами на ранней стадии проекта.
СОВЕТ № 83 -.
Используйте подсчет элементов GUI для получения приближенной оценки с минимальным объемом работы на ранней стадии проекта.
СОВЕТ № 84 -.
При правильной методологии оценка размера становится основой для всех остальных оценок. Размер создаваемой системы является важнейшим фактором, определяющим ее стоимость. Для повышения точности используйте альтернативные оценки со сравнением результатов.
Используйте оценочные программы, основанные на формальных методах оценки, для более точного вычисления оценки объема работ по имеющейся оценке размера.
Используйте среднеотраслевые графики для получения грубой оценки объема работ в широкой части конуса неопределенности. Помните, что в крупных проектах затраты, связанные с применением более мощных методов оценки, быстро окупаются.
СОВЕТ № 87 -.
Используйте метод ISBSG для получения грубой оценки объема работ. Сравните его с другими методами и проанализируйте схождение или расхождение оценок.
СОВЕТ № 88 -.
Не все методы оценки равны. При поиске схождения или расхождения между оценками присваивайте большие весовые коэффициенты методам, дающим более точные результаты.
Глава 20.
СОВЕТ № 89 -.
Используйте базовую формулу для ранней оценки срока в средних и крупных проектах.
СОВЕТ № 90 ---.
Используйте формулу неформального сравнения с прошлыми проектами для ранней оценки срока в проектах любого размера.
СОВЕТ №91 -.
Используйте метод оценки первого порядка для получения неточной (но требующей крайне малых усилий) оценки срока на ранней стадии проекта.
СОВЕТ № 92 -.
Не сокращайте оценку срока без увеличения оценки объема работ.
СОВЕТ № 93 -.
Не сокращайте номинальный срок более чем на 25 %. Иначе говоря, не пытайтесь ввести оценки в «зону невозможности».
СОВЕТ № 94 -.
Чтобы снизить стоимость проекта, увеличьте срок и используйте группу меньшей численности.
СОВЕТ № 95 -.
В бизнес-системах среднего размера (от 35 ООО до 100 000 строк кода) не рекомендуется использовать группы численностью более 7 человек.
Используйте оценку срока для проверки реалистичности своих планов. Для формирования окончательного графика следует применять детальное планирование.
Прежде чем искать схождение или расхождение между оценками, исключите из набора данных результаты, полученные слишком общими методами.
СОВЕТ № 98 -.
При распределении объема работы проекта следует учитывать размер проекта, тип проекта, а также операции, заложенные в калибровочных данных, использованных для создания исходной монолитной оценки.
СОВЕТ № 99 -.
При распределении сроков между различными операциями следует учитывать размер проекта, его тип и методологию разработки.
СОВЕТ № 100 -.
Используйте среднеотраслевые или исторические данные для оценки предполагаемого количества дефектов в вашем проекте.
СОВЕТ № 101 -.
Данные эффективности исправления дефектов позволяют оценить количество дефектов, которые будут удалены из программы вашими методами контроля качества перед выпуском окончательной версии.
СОВЕТ № 102 -
-.
Используйте суммарный ущерб рисков вашего проекта в качестве отправной точки при планировании буферов. Проанализируйте отдельные аспекты конкретных рисков и постарайтесь понять, не должен ли запланированный буфер быть больше или меньше суммарного ущерба.
СОВЕТ № 103 -.
Планирование и оценка — взаимосвязанные темы, а тема планирования слишком обширна, чтобы ее можно было изложить в одной главе книги, посвященной оценке программных проектов. Читайте специализированную литературу по планированию.
СОВЕТ № 104 -.
Документируйте и сообщайте предположения, заложенные в оценке.
СОВЕТ № 105 -.
Вы должны четко понимать, какая неопределенность отражается в представлении оценки: неопределенность самой оценки или же неопределенность, влияющая на вашу возможность выполнения обязательств.
СОВЕТ № 106 -.
Не представляйте ответственным сторонам проекта маловероятные результаты.
СОВЕТ № 107 -.
Подумайте, не заменить ли текстовое представление оценки графическим.
Используйте стиль представления оценок, который бы подчеркивал передаваемую вами информацию о точности оценки.
Не пытайтесь выражать обязательства в диапазонной форме. Обязательства должны быть более конкретными.
Поймите, что администраторы настойчивы по своей природе и по должности, и планируйте обсуждение оценок соответствующим образом.
СОВЕТ № 111 -.
Учитывайте воздействие внешних факторов. Ваши собеседники должны видеть, что вы понимаете коммерческие требования и их важность.
СОВЕТ № 112 -.
Обсуждайте обязательства, но не оценки.
СОВЕТ № ИЗ -.
Расскажите ответственным участникам, не связанным с технической стороной проекта, о принципах эффективной оценки программных проектов.
СОВЕТ № 114 -.
Относитесь к обсуждению оценок как к решению проблемы, а не как к переговорам. Поймите, что все ответственные участники проекта находятся на одной стороне. Либо все вместе проигрывают, либо все вместе выигрывают.
СОВЕТ № 115 -.
Нападайте на проблему, а не на людей.
СОВЕТ № 116 -.
Выдайте как можно больше вариантов планирования, поддерживающих цели вашей организации.
СОВЕТ № 117 -.
В процессе совместного решения проблем не принимайте поспешных обязательств, основанных на импровизированных оценках.
СОВЕТ № 118 -.
Чтобы выйти из тупика, возникшего в дискуссии, почаще возвращайтесь к вопросу: «Что будет лучше для нашей организации?»