Оценка размера ПО по функциональности

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

Почему оценка размера по функциональности важна

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

Определения в одну строку

• Функциональность: конкретная возможность или набор возможностей, которые пользователь может использовать.
• LOC: lines of code, количество строк исходного кода.

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

Можно ли оценить размер до кодирования

Да, оценить можно, но точность зависит от качества требований и уровня неопределённости. До кодирования работают с описаниями функций, пользовательскими историями и use case. По мере уточнения требований оценка должна пересчитываться.

Метод: как измерять размер по функциональности

Обзор метода

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

1. Инвентаризация всех функций и возможностей

1. Составьте полный список функций и возможностей. Для этого подойдут таблицы, доски в таск-трекерах или Excel.
2. Для каждой функции добавьте краткое описание, целевого пользователя и ожидаемое поведение.
3. Опишите зависимости между функциями. Компонент без зависимостей можно оценить как автономный; его размер равен сумме составляющих функций.
4. Подсчитайте LOC при необходимости вручную или с помощью инструмента подсчёта строк кода.

Примечание: LOC полезен при комбинированном подходе, но сам по себе не отражает пользовательскую ценность.

2. Группировка и классификация функций

1. Группируйте похожие функции в компоненты или подсистемы.
2. Присвойте каждой функции баллы по сложности: например, 1 — простая, 3 — средняя, 5 — сложная. Выберите шкалу, удобную для вашей команды.
3. Выделите базовые и ключевые (core) функции. Базовые функции обязательны для работы продукта, ключевые обеспечивают бизнес-ценность.

Модель сложности помогает превратить список функций в числовую оценку, сопоставимую между релизами.

3. Подсчёт размера компонентов

1. Для каждого компонента суммируйте баллы функций и при необходимости переводите их в примерные LOC или человеко-часы.
2. Если в проекте много модульных зависимостей, увеличьте размер компонента на долю повторно используемого кода и интеграционных затрат.
3. Используйте инструмент автоматического анализа для получения грубых LOC по компонентам, затем сверяйте с функциональными баллами.

Совет: ведите историю изменений оценки в каждом релизе. Это позволяет видеть тренды и повышать точность прогнозов.

Преимущества и недостатки метода

Преимущества

• Отражает пользовательскую ценность и сложность логики
• Помогает прогнозировать усилия по доставке функционала
• Удобен для сравнения версий и планирования релизов
• Подходит для крупномасштабных и модульных систем

Недостатки

• Не даёт полной информации о качестве кода и техническом долге
• Сложно однозначно определить, что считать отдельной функцией
• Требует сочетания с другими метриками, например, LOC или оценками производительности

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

Альтернативные подходы и когда их выбрать

• Story points и agile-оценки: удобны для спринт-планирования при наличии команды и истории производительности
• Function Point Analysis: стандартизированная методика для контрактных оценок и крупных проектов
• Use Case Points: фокус на сценариях использования, подходит при наличии формализованных use case
• COSMIC: подходит для измерения функциональности в реальном времени и программного обеспечения уровня предприятия
• Чистый LOC: имеет смысл при оценке портов, рефакторинга и технических задач

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

Практические эвристики и шаблоны

Эвристики

• Простая функция = 1 балл, средняя = 3, сложная = 5. Корректируйте шкалу под продукт
• Зависимость увеличивает размер компонента на 10-30% в зависимости от интеграционной сложности
• Рефакторинг и тесты добавляют постоянную надбавку усилий в прогнозе

Шаблон таблицы для оценки

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

Роли и чеклисты

Чеклист для владельца продукта

• Уточнить приоритеты функций
• Обеспечить описание ожидаемого поведения
• Согласовать границы функциональных блоков

Чеклист для менеджера проекта

• Подготовить таблицу оценок и историю изменений
• Согласовать шкалу сложности с командой
• Установить контрольные точки для пересчёта оценки

Чеклист для разработчика

• Проверить зависимости и точки интеграции
• Оценить влияние архитектуры на сложность
• Оценить тестируемость функции

Чеклист для QA

• Определить критические пути тестирования
• Оценить покрытие тестами в прогнозе
• Добавить оценку усилий на автоматизацию тестов

Миниметодология внедрения в команду

1. Сбор начального списка функций и кратких описаний
2. Совместная сессия оценки сложности с участием PO, Dev и QA
3. Заполнение шаблонной таблицы и подсчёт суммарного размера
4. Преобразование баллов в прогноз человеко-часов и бюджета
5. Регулярный рефайн и ретроспекция точности оценок

Как обрабатывать зависимые и повторно используемые компоненты

• Повторно используемый код учитывайте один раз при подсчёте системного размера, но добавляйте интеграционные и миграционные затраты при включении в новую систему
• Микросервисы оценивайте как отдельные компоненты с учётом коммуникации и контрактов

Модель зрелости оценки размера по функциональности

Уровень 1 — Неформальный

• Оценки делаются ad hoc, нет истории

Уровень 2 — Повторяемый

• Шаблоны и шкалы сложности применяются, есть реестр функций

Уровень 3 — Измеряемый

• Метрики собираются по релизам, есть сравнение оценок и фактических затрат

Уровень 4 — Оптимизированный

• Оценка интегрирована в CI/CD и финансовое планирование, точность прогнозов улучшается

Когда метод даёт неверные результаты

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

Decision tree для выбора подхода

flowchart TD
  A[Нужно оценить размер ПО?] --> B{Есть формализованные требования?}
  B -- Да --> C{Цель оценки: коммерческий контракт?}
  B -- Нет --> F[Используйте agile story points и ранний прототип]
  C -- Да --> D[Рассмотрите Function Point Analysis или COSMIC]
  C -- Нет --> E[Функциональная оценка + шкала сложности]

Критерии приёмки оценки

• Оценка покрывает 100% известных функций
• Для каждой функции указана сложность и зависимости
• Преобразование баллов в часы или бюджет документировано
• История изменений оценки доступна и понятна

Тестовые случаи и пример критериев приёмки

• TC1: Проверка учёта зависимости. Когда функция A зависит от B, итоговая оценка A увеличивается на установленный коэффициент
• TC2: Сверка с LOC. Для выбранного компонента суммарный LOC соотносится с функциональными баллами в пределах допустимой погрешности
• Критерий приёмки: итоговая оценка не содержит незадокументированных функций и утверждена стейкхолдерами

Короткий справочник терминов

• Функция: отдельная возможность, видимая пользователю
• Компонент: логическая группа функций
• LOC: строки исходного кода, техническая метрика
• Story points: относительная оценка объёма работы в agile

Пример результата оценки и использование в планировании

1. Сумма баллов по всем функциям = 320
2. Команда исторически переводит 1 балл в 2 часов работы для данной команды
3. Итог: 640 часов, с учётом рисков и интеграций прибавляем 20% буфер
4. Результат используется для планирования релизов, распределения задач и расчёта бюджета

Важно: коэффициенты перевода баллов в часы зависят от команды и должны калиброваться по факту.

Заключение

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

Ключевые рекомендации

• Документируйте функции и зависимости подробно
• Используйте комбинированный подход: функциональные оценки плюс LOC и метрики качества
• Поддерживайте историю оценок и регулярно пересчитывайте прогнозы

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