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

В этой заметке мне хотелось бы снова поднять тему эстимейтов.

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

Данный подход можно использовать двояко:

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

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

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

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

Предположим, в GPS-навигационную систему необходимо добавить поиск координат по адресу и поиск координат по перекрёстку. Оценка в "системе координат" разработчика предполагает, что программист сначала должен прикинуть, как он будет реализовывать пользовательскую функцию.

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

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

Архитектура модуля поиска будет выглядеть так:

При выборе такого технического решения, разработчику придётся:

1. спроектировать базу данных поиска,
2. а также – разработать:

1)      компилятор для неё;

2)      модуль доступа к данным;

3)      модуль поиска;

3. создать диалоги и меню для поиска,
4. внести изменения:

1)      в растерайзер карты;

2)      в HUD;

3)      и в логику приложения.

Эстимейт можно представить в виде таблицы, в которой строками будут пользовательские функции, а столбцами – модули программы:

Примечание: Трудозатраты даны в человеко-днях.

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

На стадии pre-production редко пишут код и, в основном, продумывают фичи (features), которые должны быть реализованы в процессе production'а. В процессе pre-production'а обычно готовят 3 вида документов:

1. Feature Design Document (FDD). Это функциональная спецификация на группу пользовательских функций с детальным описанием того, как они должны работать.
2. Engineering Requirements Document (ERD). Он содержит технические требования к отдельному модулю системы, который нужно написать или в который нужно внести изменения для реализации пользовательской функции.
3. Software Design Document (SDD). Этот документ описывает дизайн отдельного модуля (или изменения в дизайне модуля) для реализации технических требований.

С учётом разделения процесса разработки на стадии наш эстимейт принимает более детальный вид:

Примечание-1: Трудозатраты даны в человеко-днях.

Примечание-2: Задача написания функциональной спецификации (FDD) выделена в отдельный столбец. Задачи написания ERD и SDD для каждого модуля наоборот не разделены и представлены общим столбцом.

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