Методы точного оценивания проекта и программные продукты для планирования.

Катерина Корж
14 июня 2021

Процесс оценивания - это, по сути, фундамент, на базе которого потом строится весь проект. Неправильный расчет - и все "строение" может завалиться от первого "столкновения с пользователями". Вместе со Светланой Корнюк, студенткой нашего курса "Эксперт в управлении проектами", мы уже изучили: цели проведения оценки, ее принципы и гибкие методы оценивания. Сегодня мы рассмотрим еще 4 метода оценивания, которые помогают создать более точную оценку, и какие есть инструменты для планирования проектов.  

  1. Function Points (Метод функциональных точек)

Впервые метод Function Points был предложен сотрудником IBM, Аланом Альбрехтом, в 1979 году. Функциональная точка (FP) – это единица измерения для выражения объема программного продукта (бизнес-функциональности), которую информационная система (как продукт) предоставляет пользователю. В FP определяется размер программного обеспечения. Они широко признаны в качестве отраслевого стандарта. 

Основные шаги:

  • Выделяются функции разрабатываемого программного обеспечения, причем на уровне пользователей, а не программного кода.
  • Определение типа оценки.
  • Определение области оценки и границ продукта.
  • Подсчет функциональных точек, связанных с данными.
  • Подсчет функциональных точек, связанных с транзакциями.
  • Определение суммарного количества не выровненных функциональных точек (Unadjusted Function Points).
  • Определение значения фактора выравнивания (FAV).
  • Расчет количества выровненных функциональных точек (Adjusted Function Points).

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

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

Недостатки: очень сложная методика. 

Точность: очень высокая. 

  1. Story Points

Это метод оценки трудоемкости задач в Agile и Scrum. Story Point – это единица измерения, используемая для оценки сложности реализации User Story и других задач. Ключевая особенность метода состоит в том, что эта метрика не привязывается к конкретному времени, такому как дни или часы разработки. Вместо этого используются относительные единицы, не позволяющие определить точное время, которое будет затрачено на разработку, но при этом помогающие быстро и эффективно приоритезировать задачи в зависимости от их сложности. 

Основные шаги: 

  • Вся команда собирается вместе.
  • Необходимо взять приоритезированный список всех требований (Backlog). Степень детализации может быть разной. Список должен содержать User story и Epic (не детальные требования).
  • Сверху списка должны стоять хорошо детализированные, понятные задачи с высоким приоритетом, которые будут выполняться в первую очередь. Внизу списка – эпики, которые будут дорабатываться в дальнейшем.
  • Автор документа презентует команде все задачи и по мере проведения оценки отвечает на возникшие вопросы. Ведет протокол совещания.
  • Из всего списка необходимо определить «Базовый элемент», относительно которого будет проводиться оценка всех требований. В качестве «Базового элемента» можно брать функционал не из сущесвующего списка, а какую-то понятную всем задачу.
  • Необходимо оценить «Базовый элемент», назначить ему какое-то количество Story Points. Есть 2 общепринятых метода оценки «Базового элемента»:
  • Выбираем требование, которое вы определили как самое легкое, и оцениваем его в 1 SP.
  • Выбираем требование средней сложности и оцениваем его, например, как 5 SP.
  • Также есть 2 шкалы оценивания:
  • Линейная (1, 2, 3, 4, 5, …) – редко используется, достаточно сложная.
  • Planning Poker (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?). Инструмент оценки, который чаще всего используется командой разработчиков, чтобы прийти к единому мнению в оценке сложности задач. Чем выше сложность, тем больше неопределенность. Все, что будет оценено выше 13, требует дополнительной детализации. Чаще всего высокие оценки ставят на эпики. 
  • Проведите оценку требований по всему бэклогу.
  • Когда проставлены все оценки, команда решает, как много пунктов можно будет реализовать в спринте.
  • По окончании спринта необходимо оценить, сколько задач было реализовано на 100% (DoD).
  • Составьте план, сколько вам нужно подобных итераций для выполнения текущего списка требований.
  • Корректируйте свой план при появлении каких-либо изменений (новые задачи, новый состав разработчиков).
  • Story Points не надо переводить в часы – это создаст дополнительные разногласия в оценках.
  • Никогда не меняйте оценку во время спринта, даже если она оказалась некорректной. Не меняйте оценку по ключевым элементам бэклога в каждом отдельном спринте.
  • Не подстраивайтесь под оценку самого опытного специалиста на совещании, так как выполнять задачу в дальнейшем может менее опытный специалист.

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

  • Более быстрая оценка, чем в случае оценки в днях и часах.
  • Фокусирует команду на ценности поставляемого продукта, а не на потраченном времени.
  • Более низкая эмоциональная нагруженность (оценить сложность проще, чем необходимое время).

Недостатки: высокая неопределенность. 

Точность: средняя.

  1. Bottom-up Estimation (Оценка от частного к общему)

Метод похож на экспертную оценку, только в данном случае прогноз делается не для всего проекта в целом, а отдельно для составляющих его задач. Собираем оценку по частям, узнавая сколько необходимо времени каждому из участников процесса разработки, и сводим все воедино с учетом дополнительных рисков. В этом методе используется структура декомпозиции работ (WBS - Work Breakdown Structure), что подразумевает разбивку на более мелкие задачи. 

Основные шаги:

  • Точность оценки "снизу-вверх" определяется размером и сложностью работ, выделенных на более нижних уровнях. Обычно меньшее содержание работ увеличивает точность оценок.
  • Если проект или задача достаточно объемны, то для получения более точной оценки выполняется декомпозиция задач. Её желательно проводить до тех пор, пока продолжительность одной задачи не будет превышать 8 часов или не будет понятна для оценивания исполнителям.
  • Собираем экспертное мнение (у специалистов по анализу, разработке, тестированию, поддержке ПО) для каждого элемента работ.
  • Суммируем их оценки вместе.
  • Добавляем к ним затраты времени на взаимодействие.
  • Формируем общий прогноз.

Преимущества: разбивка на мелкие части позволяет не упустить детали при оценке. 

Недостатки: требуется наибольшее количество времени в сравнении с другими техниками.

Точность: наивысшая. 

  1. USE CASE POINTS (Метод точек использования)

Метод был разработан Густавом Карнером в 1993 году во время его работы в Objectory Systems (которая позже влилась в Rational Software и затем в IBM) для оценки объёма программного обеспечения, объектно-ориентированных систем и системных требований.

UCP (точки использования) – это метод оценки проектов на основе вариантов использования (use cases) системы, которая оценивается. Идея метода основана на том, что требования к системе записаны в виде вариантов использования, а объём ПО рассчитывается путем разложения их с учетом технических предположений и предположений об окружении.

  • Вариант использования - это серия взаимосвязанных взаимодействий между пользователем и системой, которая позволяет пользователю достичь цели.
  • Варианты использования - это способ отразить функциональные требования системы. Пользователь системы называется «Актер».

Этот метод включен в методологию RUP и применяется при использовании UML (Unified Modeling Language). В основе UCP лежит методика Function Points, но она значительно сокращена для использования не экспертами. В отличии от FP, UCP учитывает множество элементов: нефункциональные требования, организационные риски, исполнителей и их компетенцию при оценке, техническую сложность и сложность среды.

Основные шаги:

Расчет состоит из таких этапов (на основе следующих переменных):

  • Необходимо провести нескорректированную оценку Вариантов использования (рассчитать вес) – UUCW (Unadjusted Use Case Weight) – по количеству транзакций (неделимых операций) и сложности UPCs.

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

  • Необходимо провести нескорректированную оценку Актеров (рассчитать вес) - UAW (Unadjusted Actor Weight).

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

  • Рассчитать Коэффициент технической сложности – TCF (Technical Complexity Factor) для коррекции объёма, основанный на технических факторах.

Дает нам коэффициент для оценки сложности архитектуры приложения. Многие из этих факторов представляют нефункциональные требования проекта (распределенность системы, многоразовость кода, производительность, удобство использования, ремонтопригодность и т.п.).

  • Рассчитать Коэффициент сложности внешнего окружения ECF (Environmental Complexity Factor) – среды, в которой будет развиваться проект.

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

  • Когда все переменные выше рассчитаны, вычисляется итоговая оценка объёма (трудоемкости) проекта – UCP.

Итоговое число - это балльная оценка вариантов использования Use Case Points для проекта: UCP = (UUCW + UAW) × TCF × ECF.

  • Далее нужно произвести пересчет величины UCP в человеко-часы, которые приходятся на одну UCP. Этот показатель зависит от различных факторов в каждой отдельной организации. Но принято считать от 20 до 28 чел/час на 1 UCP.

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

  • Метод основан на Use Cases (сценариях / вариантах развития / взаимодействия / использования) и может быть использован на очень ранней стадии жизненного цикла проекта.
  • Оценка объема ПО не будет зависеть от размера, навыков и опыта команды, которая реализует проект.
  • Позволяет оценивать крупные проекты в несколько раз быстрее по сравнению с традиционными методами.
  • Объём оценённых задач одинаково понятный (не возникает «разночтений») для команды и заказчика.
  • Имеет готовые диаграммы вариантов использования ещё до разработки.
  • Не требует дополнительного анализа.

Недостатки:

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

Точность: близкая к фактической, особенно если оценка выполняется опытными специалистами.

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

Инструменты для управления проектами 

Существует очень много программ для автоматического тайм-менеджмента и временного планирования. Их использование избавит вас от лишней работы, сократит время на ведение и контроль, даст более точные расчеты, сократит вероятность того, что что-то будет упущено, просрочено, а также позволит добавлять и убирать задачи без потери данных. У каждой компании могут быть свои предпочтения. Вот список некоторых из них: 

  • Диаграмма Ганта (Microsoft Excel, Microsoft Project, LibreOffice Calc, OnlyOffiсe, Smartsheet, GanttPRO, Comindware, «Google Таблицы») 
  • Trello
  • Jira
  • Asana
  • ActiveCollab
  • Wrike
  • Basecamp
  • Bitrix24
  • Megaplan
  • Open Plan
  • Яндекс.Трекер
  • Comindware
  • Flowlu
  • Advanta

Надеемся, что благодаря Светлане и ее статьям вы нашли для себя что-то новое и полезное в вопросе оценивания проекта.

Похожие темы

Менеджмент