И всё-таки про оценку проектов

Елена Тупикова (Котина), 13 лет в управлении проектами и продуктами, автор канала «Games of Projects and Products».

Лет 10 назад менеджера от остальных сотрудников можно было отличить по вопросу в конце встречи: «Всё понятно, и когда вы это сделаете?»

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

И честно говоря, что-то планировать и приоритезировать, когда разработчики постоянно говорят: «Ну… сроки можно понять только когда начну разбираться», совершенно невозможно. [Стоп-стоп, я не говорю про точную оценку в 103 дня! ]

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

Вот некоторые методы:

Дальше расскажу подробнее про часть способов.

Параметрическая оценка применяется на ранних этапах проекта (на стадии определения проекта и на начальных стадиях проектирования), когда еще нет достаточного количества информации.

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

А потом строится математическая модель.

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

При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов.

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

Недостаток: низкая точность (-30%-+50%).

Стоимость подготовки параметрической оценки: 0,04%-0,45% от общей стоимости проекта.

Важно помнить, что на любом этапе проекта, до того, как попытаться оценить или взять в работу его целиком, разделите «слона» на требования/более мелкие задачи, тогда вероятность получить точную оценку станет чуточку выше.

Как-то я работала над проектом по масштабному обновлению интерфейса системы. Это была гигантская задача.

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

Мы разбили проект на этапы: брали один кусок системы, меняли его, переписывали, выкладывали, давали людям уже этим пользоваться.

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

Методы получения экспертной оценки:

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

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

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

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

Важно подбирать экспертов в соответствии с их компетентностью!

Если вы хотите подробнее почитать про эту тему, есть целое учебное пособие «экспертные оценки» (автор А.И.Орлов), но это будет полезно для масштабных глобальных прогнозов, а не для IT проекта на 2 месяца.

В этом варианте оценки нужно сравнить текущий проект с фактически потраченными человеко-часами на подобном проекте в прошлом, но не с изначально предполагаемым объемом!

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

Основными шагами тут будут:

- найти возможные аналогии, выделить подобные задачи,

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

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

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

Тогда вы понимаете, что сложность при строительстве этого дома будет несколько выше.

Да ещё может быть ваш новый участок земли на склоне?!

Оценка на основе оптимистичного, пессимистичного и наиболее вероятного времени.

Формула:

(О + 4 х Р + П) / 6

или более пессимистичный вариант:

[О + (3 × Р) + (2 × П)] / 6

где:

О = оптимистично: минимально возможная длительность выполнения задачи, если все идет отлично и нет неожиданных сюрпризов.

Р = реалистично: как долго вы думаете, это займет, по всей вероятности?

П = пессимистично: всё окажется сложнее, чем ожидалось, и складывается наименее удачным образом (исключая крупные катастрофы).

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

Оценка идёт по вариантам использования системы.

Этот метод разработал Gustav Karner в 1993 году.

Количество UCP в проекте зависит от:

- количества и сложности вариантов использования системы,

- количества действующих лиц в системе,

- различных нефункциональных требований (аля производительность), которые не описаны в пользовательских сценариях,

- среды, в которой будет развиваться проект (например, язык, мотивация команд,… ).

Процесс подсчета состоит из следующих этапов:

- Рассчитать нескорректированные UCPs

- Учесть техническую сложность

- Скорректировать на «окружение»

- Рассчитать скорректированные UCPs

И формула в итоге будет такая:

UCP = UUCP × TCF × EF

где

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

UUCW — Unadjusted Use-Case Weight

UAW — Unadjusted Actor Weight

TCF = 0.6 + (0.01 × TFactor)

TFactor - Total Technical Factor

EF =1.4 + (-0.03 × EFactor)

EFactor — Total Environment Factor

И всё!: )

Подробнее можно почитать, например, тут — https://www.tutorialspoint.com/estimation_techniques/estimation_techniques_use_case_points.htm

→ Одна из книг про оценку «Software Estimation: Demystifying the Black Art» (Steven C. McConnell).

Если не хотите целую книгу читать, то есть конспект по ней: http://igorshevchenko.ru/blog/entries/software-estimation

Некоторые считают, что оценка проектов не нужна:

Но мое мнение: Если вы не тратите на это много времени, то от оценки много пользы.