Главная » Колонка редактора, факультатив

Учимся оценивать проекты на примере Закладочника

6 мая 2009 Нет комментариев

Думаю, что вы не будет спорить, если я скажу, что головной болью всякого фрилансера/разработчика является оценка сроков реализации и объема работ над очередной задачей. Сколько килограммов нервов было потрачено, сколько километров отрицательных отзывов было получено неплохими вообщем то разработчиками, которые подписались под нереальные сроки разработки, сколько интересных приложений не дожили до релиза, потому что их разработчики переоценили свои силы… Ужос!

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

Давайте рассмотрим практическое примение метода оценка по аналогии на примере такого известного в узких кругах разработчика веб-сервисов как BrokenBrake.

Историческая справка: BrokenBrake - автор скриптов Блогоферма (создание автонаполняемых сплогов), Закладочник и BMSubmitter (постинг закладок в сервисы соцзакладок).

Итак, как бы мог применить метод оценка по аналогии BrokenBrake, приступая после закрытия проекта Блогфермы к разработке Закладочника?
1. Собрать подробную информацию о размере, объеме и затратах для проекта Блогофермы. Если собранные данные будут фрагментированы по структуре трудозатрат (WBS), это сильно упростит дальнейший анализ.
2. Шаг за шагом сравнить размер Закладочника (новый проект) с размером Блогофермы (старый проект).
3. Оценить размер нового проекта в процентах от размера старого проекта.
4. Оценить объем работ, исходя из соотношения размеров нового и старого проектов.
5. Проследить за тем, что бы показатели обоих проектов проектов базировались на одинаковых предположениях.

Итак, шаг №1. Получение данных от предыдущего аналогичного проекта.
Предположим, что структура проекта Блогоферма была следующей:
База данных - 1 000 строк кода
Интерфейс пользователя - 3 000 строк кода
Бизнес-логика - 5 000 строк кода
ИТОГО - 9 000 строк кода

При этом элементы проекта Блогоферма были такими:
База данных - 4 таблицы
Интерфейс пользователя - 4 веб страницы

Бизнес-логика - ???

Теперь давайте, уважаемый BrokenBrake, давайте попытаемся определить аналогичные показатели для Закладочника. Предположим получилось следующее:
База данных - 5 таблиц
Интерфейс пользователя - 4 веб страницы

Бизнес-логика - ???

Поскольку бизнес-логика Закладочника сильно отличается от бизнес-логики Блогофермы сравнивать их напрямую некорректно. Предположим, что после длительных раздумий BrokenBrake пришел к выводу, что бизнес-логика Закладочника будет как минимум на 50% сложнее.

Исходные данные собрали, приступаем к шагу №2 - сравнению размеров.

ПОДСИСТЕМА ФАКТИЧЕСКИЙ РАЗМЕР БЛОГОФЕРМЫ ФАКТИЧЕСКИЙ РАЗМЕР ЗАКЛАДОЧНИКА МНОЖИТЕЛЬ
База данных 4 таблицы 5 таблиц 1,25
Интерфейс пользователя 4 веб-страницы 4 веб-страницы 1
Бизнес-логика ??? ??? 1,5

По поводу множителя: cчетный показатель лучше субъективной оценки. В нашем примере BrokenBrake в одном случае вынужден был прибегнуть к субъективной оценке.

Теперь перейдем к шагу №3: оценка размера нового проекта в процентах от размера старого проекта.

ПОДСИСТЕМА РАЗМЕР КОДА БЛОГОФЕРМЫ МНОЖИТЕЛЬ ОЦЕНКА РАЗМЕРА ЗАКЛАДОЧНИКА
База данных 1 000 1,25 1 250
Интерфейс пользователя 3 000 1 3 000
Бизнес-логика 5 000 1,5 7 500
ИТОГО 9 000 11 750

Пояснения нужны? Вроде все понятно :) Переходим к шагу №4: оценка объема работ.

ПОКАЗАТЕЛЬ ЗНАЧЕНИЕ
Размер Закладочника 12 000 строк кода
Размер Блогофермы 9 000 строк кода
Соотношение размеров = 1,33
Объем работ для Блогофермы x2 человека-месяца
Оценка обхема работ для Закладочника =2,7 человека-месяца

Разделив размер проекта Закладочник на размер проекта Блогоферма BrokenBrake получил соотношение размеров двух систем. Умножив его на объем работ по Блогоферме - получил оценку для Закладочника.

Остался один шаг: проверить согласованность предположений. Некорректно сравнивать проекты, если:

- размеры сравниваемых проектов отличаются более чем в 3 раза;

- в проектах использованы разные технологии;

- квалификация участников проекта существенно отличается;

- разрабатываемые программы отличаются по типу.

Все эти фильтры Закладочник прошел, сравнение BrokenBrake провел коректно.

На этом пожалуй закончим. Надеюсь BrokenBrake на меня не обидится :)

Комментирование закрыто.