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

«Как вы знаете, мы приступаем к разработке Triad 1.0, — сказал Майк. — Техническая сторона очень близка к AccSellerator 1.0. Мне представляется, что проект будет чуть крупнее AccSellerator 1.0, но не намного».

«База данных будет намного больше, — откликнулась Дженнифер. — Но пользовательский интерфейс останется примерно таким же».

«Графиков и отчетов тоже будет гораздо больше, чем в AccSellerator 1.0, но основные классы очень похожи; думаю, количество классов останется прежним», — сказал Джо.

«Я думаю примерно так же, — сказал Майк. — Пожалуй, на основании этих данных можно предварительно рассчитать объем работы. В моих записках указано, что общий объем работ по предыдущей системе составил 30 человеко-месяцев. Как вы полагаете, какой должна быть разумная оценка объема работы по новой системе?».

А как вы думаете, каким будет объем работы по новой системе?.

11.1. Основные принципы оценки по аналогиям.

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

Несколько сотен разработчиков представили свои оценки для проекта Triad. Их оценки были разбросаны в диапазоне от 30 до 144 человеко-месяцев, а среднее значение составило 53 человеко-месяца. Стандартное отклонение оценок составило 24, или 46 % от среднего ответа. Нехорошо! Некоторое структурирование процесса принесет существенную пользу.

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

1.

Получите подробные данные об итоговом размере, объеме работ и затратах для предыдущего аналогичного проекта. Если возможно, получите данные, фрагментированные по функциональности, структуре трудозатрат (WBS) или другой схеме декомпозиции.

2.

Шаг за шагом сравните размер нового проекта с размером старого проекта.

3.

Постройте оценку размера нового проекта в процентах от размера старого проекта.

4.

Создайте оценку объема работ, руководствуясь размером нового проекта по сравнению с размером предыдущего проекта.

5.

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

СОВЕТ № 53 -.

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

Давайте рассмотрим эту процедуру на примере Triad.

Шаг 1. Получение подробных данных об итоговом размере, объеме работ и затратах для предыдущего аналогичного проекта.

После первого собрания Майк попросил участников проекта Triad собрать более конкретную информацию о размере старой системы и относительном объеме функциональности старой и новой систем. Когда сбор данных был завершен, Майк поинтересовался результатами: «Вы собрали те данные, о которых мы говорили на прошлой неделе?».

«Конечно, Майк, — ответила Дженнифер. — Проект AccSellerator 1.0 состоял из 5 подсистем. Структура проекта была примерно такой:

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

«Отличная работа, — сказал Майк. — Теперь у меня есть все необходимое для вычисления оценки к собранию. Завтра я немного повожусь с цифрами и покажу вам результат перед собранием».

Шаг 2. Сравнение размера нового проекта с аналогичным прошлым проектом.

Подробная информация о предыдущем проекте дает нам все необходимое для создания содержательной оценки методом аналогии. Группа Triad уже выполнила шаг 1, «Получение подробных данных об итоговом размере, объеме работ и затратах для предыдущего аналогичного проекта». Далее собранные данные шаг за шагом сравниваются с соответствующими показателями нового проекта. Результаты сравнения показаны в табл. 11.1.

Таблица 11.1. Сравнение размеров подсистем между AccSellerator 1.0 и Triad 1.0

Записать данные в столбцах 2 и 3 несложно — проблемав том, что делать с множителем в столбце 4. Основной принцип вам уже знаком: сначала подсчет, затем вычисления и в последнюю очередь субъективная оценка. Если найти какой-нибудь счетный показатель, результат будет лучше, чем при использовании субъективной оценки.

С множителями 1,4 для базы данных, 1,4 для пользовательского интерфейса и 1,0 для библиотеки классов вроде бы все понятно.

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

Бизнес-логика также порождает проблемы. Группа не нашла никакого показателя, поэтому наша оценка в этой области покоится на более шатком основании, чем в других областях. Для определенности мы согласимся с оценкой, что бизнес-логика Triad будет примерно на 50 % сложнее бизнес-логики AccSellerator.

Шаг 3. Построение оценки размера нового проекта в процентах от размера старого проекта.

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

Размеры подсистем AccSellerator в строках кода были получены по данным, собранным на шаге 1. Множители определились в ходе шага 2. Оцениваемый размер подсистемы Triad попросту равен произведению размера подсистемы в AccSellerator и множителя. Общий размер системы в строках кода становится основой для вычисления оценки объема работ, которая, в свою очередь, станет основой для оценок сроков и затрат.

Таблица 11.2. Вычисление предполагаемого размера Triad 1.0 на основании размера AccSellerator

Шаг 4. Создание оценки объема работ на основе размера нового проекта, полученного сравнением с размером предыдущего проекта.

Теперь мы располагаем достаточной информацией для вычисления оценки объема работ. Это делается так, как показано в табл. 11.3.

Таблица 11.3. Итоговое вычисление объема работ для Triad 1.0

Разделив размер проекта Triad на размер AdccSellerator, мы получаем соотношение размеров двух систем. Умножение его на объем работ AccSellerator дает оценку для Triad — 44 человеко-месяца.

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

Я предложил оценщикам, создавшим исходные оценки для Triad, воспользоваться этой процедурой, и их результаты стали более точными и согласованными. Стандартное отклонение результатов составило всего 7 % вместо 46 %, даже с учетом неопределенности, связанной с диаграммами, отчетами и бизнес-логикой.

Шаг 5. Проверка согласованности предположений между старым и новым проектами.

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

• Существенно различающиеся размеры старого и нового проектов, то есть различия более чем в 3 раза (см. раздел 5.1). В нашем случае размеры отличаются всего в 1,45 раза; этого недостаточно, чтобы беспокоиться об издержках масштаба.

• Разные технологии (например, один проект написан на С#, а другой на Java).

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

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

11.2. Замечания по поводу неопределенности в оценке Triad.

Информация, доступная для оценки бизнес-логики, была довольно туманной. Стоит ли повысить количество бизнес-правил, чтобы обеспечить консервативность оценки? Нет, не стоит. Целью оценки должна быть точность, а не консерватизм. Как только вы перестаете стремиться к точности, в оценку из разных источников начинают проникать субъективные смещения, и полезность оценки падает. Правильной реакцией на неопределенность должно быть не смещение оценки, а гарантия того, что любая базовая неопределенность будет точно отражена в оценке. Если вы абсолютно уверены в количестве бизнес-правил, то оценку можно было бы считать точной до ±10 %. Вероятно, с учетом неопределенности в бизнес-логике уровень неопределенности стоит повысить до (+25 %, -10 %).

Более качественное решение проблемы неопределенности, обусловленной составляющей бизнес-логики, заключается в использовании диапазонного фактора бизнес-логики вместо отдельного числа. Вместо точечного коэффициента 1,5 можно оценить фактор с 50%-м отклонением (иначе говоря, диапазон от 0,75 до 2,25). В этом случае вместо точечной оценки в 44 человеко-месяца вычисления дают диапазон от 38 до 49 человеко-месяцев.

В отличие от оценок, созданных описанным способом, в оценках «монолитных» (то есть не использующими декомпозицию) неопределенность в одной области может распространяться в другие области. Скажем, если в бизнес-логике существует 50%-я неопределенность, оценщик может применить ее ко всей оценке, а не только к четверти, относящейся к бизнес-правилам. Если применить то же 50%-е отклонение ко всей оценке, то мы получим диапазон от 22 до 66 месяцев, вместо диапазона от 38 до 49 месяцев. Умение идентифицировать факторы неопределенности и их влияние на оценку способствует сужению общего диапазона оценки.

СОВЕТ № 54 -.

Не решайте проблему неопределенности смещением оценки. Постарайтесь отразить неопределенность в самой оценке.

Неопределенность оценки, планы и обязательства.

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