воскресенье, 13 февраля 2011 г.

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

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

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

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

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

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


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-части приложения.

8 комментариев:

  1. Активно пользуюсь первым подходом, который и является классическим.
    Про второй, как верно подмечено, необходимо учитывать ограничения, т.к. визуальная часть часто является только вершиной айсберга. Иначе может получиться "Когда уже будет готова комната переодевания?" при отсутствии какой бы то ни было платформы)

    ОтветитьУдалить
  2. Не думаю, что есть какие-то специальные методы декомпозиции или композиции или еще что-то. Дробить задачу конечно надо, анализ как метод освоения действительности еще никто не отменял. Я, например, всегда выдаю только грубую верхнюю границу затрат на интересующий айтем. Это, видимо, в статье называется песимистическая оценка. Стейк холдер всегда опечален, но другой оцеки у меня нет. По мере работы над проектом эта оценка меняется, как правило, в меньшую сторону. Также меняются и многие зависимые оценки.
    Основные методы здесь чисто по Гегелю: анализ и синтез. Плюс переход печали в радость для стейкхолдера.
    Спасибо.

    ОтветитьУдалить
  3. Блин, с большим трудом удалось запостить от имени Анонимный; у вас сайт глюкавый. Не люблю анонимности и таки подписываюсь: Коля

    ОтветитьУдалить
  4. Думаю что лучше все-таки объединить эти два подхода.

    ОтветитьУдалить
  5. Ответы
    1. ...ты прав Хаззик! Нужно в пятилетках

      Удалить
  6. 2 Sergey Pereslavtsev:

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

    2 Николай:

    По мнению Макконела ("Совершенный код") программистам только кажется, что выдаваемая ими оценка является верхней. На самом деле, практика показывает, что программисты практически всегда занижают даже самые максимальные, самые пессимистичные оценки.

    2 Lifter: А я так и предлагаю. Оба подхода можно использовать для взаимной перепроверки.

    2 hazzik: Простейшую навигационную систему вместе с картографическим движком может разработать команда из 4-х человек за 1 год. Если этим людям платить зарплату со всеми налогами, то затраты на разработку окупятся при продаже 2200 копий навигационной системы стоимостью в $100. Это без учета затрат на лицензирование карт.

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

    ОтветитьУдалить
  7. Не очень ясно, зачем давать три оценки времени (optimistic, awaiting, pessimistic). При такой системе подсчета лучше уж пользоваться (min max). Либо же выводить сумму по человечески^W PERT-у.

    ОтветитьУдалить