Как делать эстимейты?

Нередко программисту приходится делать эстимейты, т.е. заранее оценивать, сколько времени займёт его работа, сколько времени придётся потратить на тот или иной проект.

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

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

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

В общем случае, хочется дать такие рекомендации:

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

При грубой оценке среднесрочных проектов (длительностью год – полтора), на мой взгляд, следует проводить декомпозицию так, чтобы длительность задач была не меньше 1-го и не больше 4-х месяцев.

При оценке отдельных подзадач в рамках конкретного проекта следует выделять задачи так, чтобы их длительность была не менее 4-х и не более 16-ти часов.

Эти цифры я логически обосновать никак не могу. Они – чисто эмпирические.

2) Для каждой подзадачи следует делать три варианта оценки: оптимистичный, нормальный и пессимистичный.

Оптимистичный вариант предусматривает затраты времени при условии, что выполнение задачи пойдёт, как "по маслу", т.е. без каких-либо проблем. Нормальный вариант предусматривает возникновение каких-либо проблем, на решение которых придётся потратить некоторое время. Пессимистичный вариант – это самый наихудшимй случай.

Приведу 2 примера эстимейтов, сделанных при помощи функциональной декомпозиции.

Пример № 1. Создание простейшей GPS-навигационной системы вместе с картографическим движком.

№	Задача	Модуль (отвечает за задачу)	Оценка (в месяцах)
			Оптим.	Норм.	Пессим.
1	Получать информацию о координатах и направлении движения от GPS-приёмника.	Location Module	1	1	2
2	Отображать карту местности и положение пользователя на ней.	Map Rasterizer	1	2	3
3	Выполнять масштабирование и скроллирование карты.	Map Viewer	1	2	2
4	Находить координаты по адресу.	Address Lookup	2	3	4
5	Находить координаты по почтовому коду.	Postcode Lookup	1	1	1
6	Находить адрес по координатам.	Reverse Lookup	1	1	2
7	Находить POIs (точки интереса) по координатам в заданном радиусе.	POIs Lookup	1	1	2
8	Прокладывать маршрут в заданную точку или между заданными точками с учётом различных ограничений.	Router	2	3	4
9	Выдавать голосовые и визуальные указания при движении пользователя по маршруту.	Direction Guide	1	2	3
10	Предоставлять пользователю информацию о текущем местоположении, направлении и скорости движения, улице, на которой он находится, расстоянии до точки назначения, времени до точки назначения и т.п.	HUD	1	2	2
11	Предоставлять пользователю удобный интерфейс для взаимодействия с программой.	GUI	2	3	4
12	Активировать карты и осуществлять проверку активации карт. Предотвращать использование не лицензированных карт.	Map Activator	1	1	2
13	Осуществлять продажу и загрузку карт с сервера.	Map Store	2	3	3
14	Выполнять преобразование карт из исходного формата во внутренний формат программы.	Map Compiler	3	3	4
15	Проверять корректность работы отдельных модулей навигационной системы.	Navigation System (каркас)	2	2	3
		Итого	22	30	41

Пример № 2. Создание небольшой мини-игры с использованием готовой технологии.

№	Задача	Время (в часах)
		Опт.	Норм.	Пессим.
1	Создание "болванки" мини-игры: 1)      написание класса и регистрация его в "фабрике"; 2)      создание папки под игровые данные; 3)      добавление уровня; 4)      создание стандартных элементов HUD'а.	4	4	6
2	Написание игрового кода	8	12	16
3	Добавление элементов HUD'а, относящихся к этой конкретной мини-игре.	4	6	8
4	Поддержка локального мультиплеера.	4	6	8
5	Добавление музыки, звуковых и голосовых эффектов.	4	6	8
6	Локализация.	4	6	8
7	Добавление дополнительного арта.	4	6	8
	Итого	32	46	62

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

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

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

Пример № 3. Создание интерфейса для небольшого web-based приложения.

№	Экран	Оценка (в часах)
		Опт.	Норм.	Пессим.
1	Экран регистрации пользователя	4	6	8
2	Эктран входа в систему	4	6	8
3	Экран запросов к базе данных	4	6	8
4	Экран результатов	4	6	8
5	Экран входа в админский интерфейс	4	6	8
6	Экран выбора действия	4	6	8
7	Экран редактирования пользователей и их прав	4	6	8
	Итого	28	42	56

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

При этом, следует учитывать ограничения экранного подхода, и понимать, что он применим для оценки GUI-части приложения.