Оценки трудозатрат. Имеет ли значение размер?

Что такое размер при разработке ПО и зачем он нужен? Какие есть способы оценки и модели размера? В этом материале вкратце попытался суммировать эти «зачем» и «какие».

Зачем нужны модели размера?

Размер продукта или объема работ (Size) – некоторые условные единицы

Например:

  • Нормо-часы выполнения работ на СТО: поменять масло, заменить тормозные колодки и т.п.
  • Постройка дома: 5 этажей, 4 квартиры на этаж, территория, коммунальные сети

 

То же самое можно применить к:

  • Разработке ПО
  • Предоставлению ИТ решений

 

Зачем нужен размер (Size):

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

 

Зачем нужна модель размера (Size Model):

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

 

Условная взаимосвязь между качеством, количеством, размером и производительностью:

  • Количество = (производительность * размер) / качество
  • Качество = (производительность * размер) / количество
  • Производительность = (количество * качество) / размер
  • Размер = (количество * качество) / производительность

 

Подходы к оценке трудозатрат

 

Для грубых оценок (с точностью порядка +/- 50%) часто важно их быстро выдать, поэтому, естественно, использование данных по аналогам и модели размера используются редко. Хотя, если есть такая возможность, я бы рекомендовал попробовать, сравнить, что получается только лишь путем экспертной оценки, и что путем применения аналогов и-или модели размера.

Грубые оценки

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

Точные оценки

Способы оценки
Способы оценки За Против
Экспертная — Хорошо для нетипичных проектов

— Может оказаться точной

— Зависит от компетенции

— Не всегда можно проверить

По Аналогам — Базируется на подобном опыте

— Может быть пропорциональна объему работ

— Должны быть исторические данные

— меньше, но зависит от компетенции

Модели размера — Объективна, повторяема, анализируема

— Может настраиваться под исторические данные

— Наличие компетенции менее важно

— Не подходит для нетипичных проектов

— Настраивается на прошлый опыт, а не на будущее

— Может «забыть» не включенные в модель компоненты

 

Как сделать экспертные оценки точнее и проверить?
  • Оценивают специалисты, каждый в своей области
    • Инженеры по разработке, качеству, внедрению, проектные менеджеры и т.п.
  • Групповая оценка
  • Инспекция оценок
  • Пользуемся историческими данными подобных проектов.
  • Полный список работ на входе в оценку (WBS – Work Breakdown Structure)

 

Аналоговые и параметрические виды оценок

Так как такие виды оценок требуют более детального описания, то я думаю вам будет интересен более подробный документ-отчет о том, как устроены аналоговые и параметрические модели, а также подборка материалов с подробным описанием моделей FPA, UCP, Story Points в SCRUM. Плюс соображения по специфическим моделям размера. Заполнив форму подписки справа вам будет сразу же выслан такой «модельный» комплект (4.5 Мб).

Tags: , , , , , , , , , , , ,

Comments are closed.