Оценка сроков IT-проектов

«Всякая работа требует больше времени, чем вы думаете»

2014

- следствие из закона Мерфи

Kalinichev.net

Здесь нет сакральных знаний! Скорее это компиляция чужих мыслей и идей, среди которых мой мозг выбрал то, что ему

ближе на основе текущего опыта!

Какой план?• Общие слова и идеи

• Что влияет на оценки

• Несколько способов оценки • экспертные

• параметрические

• на основе истории

Зачем оценивать?

О чем нужно помнить?

• Цель оценки

• Чем точнее требования, тем точнее оценка

• Оценка не мгновенна - это такой же этап проекта и занимает он 10-12% от всего проекта

Лучшее предсказание того, что будет завтра, это сказать то же самое, что сегодня

imho

Что в результате?• Список работ

• Общие временные затраты

• Бюджет проекта

• Расписание проекта: декомпозиция и ключевые вехи

• Сколько и каких специалистов нужно. В какое время и на сколько

• План проекта

• Риски и варианты их минимизации

• Предположения

Что потребуется уточнить?• Продуктовые требования

- функциональные требования

- нефункциональные требования

- боевое и тестовое окружение

• Проектные требования

- технологии

- процесс создания

- политика общения с заказчиком

- политика поддержки

Эффективная оценка?• Нужно помнить что оцениваем

• Декомпозиция

• при предварительной оценке - проект 1-2 ч/г, размер задачи 1-2 недели нормально

• при распределении по людям дальше 3х дней уже плохо*

• Хронологическая зависимость задач

• Опыт предыдущих задач и проектов

• Мнение нескольких экспертов

• Объединение задач в группы и усреднение

• Проецируйте на вашу команду

Какие хорошие вопросы?• Есть возможность объяснить одной фразой, что требуется?

• Как это будет использоваться? Кто конечный пользователь?

• Какова ценность? Можно ли это вообще не делать?

• Что нужно сделать, чтобы уменьшить срок или цену в 2а раза?

• Делали или оценивали мы это раньше?

• Что нужно сделать, чтобы начать делать эту работу параллельно? Какие от этого будут плюсы и минусы?

• Какой самый простой способ сделать эту задачу?

• Какие зависимости у этой задачи и что зависит от ее? Какие риски?

• В каком окружении будет использоваться этот функционал? …

Умение распараллелить очень важно, как правило это экономит время. Все чаще стоимость проекта гораздо ниже стоимости бизнеса. Обычно время важнее всего.

imho

Какие типовые ошибки?• Различия в определении того, что такое готово

• Неполные требования

• Недостаточное время для оценки

• Фактор больших систем

• Ошибки декомпозиции, как в + так и в -

• Потеря деталей или частей функциональности

• Потери на коммуникацию

• Размер команды

• Отсутствие специфичных знаний

• Различия в понимании целей заказчика

• Игнорирование стоимости поддержки кода

• Игнорирование рисков

• Когнетивные искажения

Когнетивные сдвиги• Излишняя уверенность

• Эффект вложенных средств (sunk cost effect)

• Предубеждение доступности (availability bias)

• Предвзятость подтверждения (сonfirmation bias)

• Якорный эффект (anchor bias)

• Иллюзия сходства (Illusory correlation)

Какие оценки существуют?• В зависимости от типа оценки

• усилия

• продолжительность

• В зависимости от цели

• коммерческое предложение

• проектное планирование

• В зависимости от техники

• модели на основе исторических данных

• экспертная оценка

• параметрические

Экспертные оценки

Three point estimation• Эксперт дает три оценки

• оптимистичная (optimistic / best case)

• наиболее вероятная (most likely / normal)

• пессимистичная (pessimistic / worst case)

• Используется распределение двойного треугольника

O M P

s=0,5 s=0,5

Three point estimationTask expected time E = (O + 4*M + P) / 6

Task standard deviation SD = (P - 0) / 6

Project expected time PE = Σ E

Project standard deviation PSD = √ Σ SD^2

Three point estimationConfidence level Standard deviation

68 % SD

90 % 1,645 * SD

95 % 2 * SD

99,7 3 * SD

Three point estimationЗадача O M P E SD From 90%!

E - 1,645*SDTo 90%!

E + 1,645*SD

Механизм запуска алгоритмов анализа сайта

0,5 1 3 1,25 0,4167 0,56 1,94

Вертска всей зоны достижений 1,5 2 3 2,08 0,2500 1,67 2,49

PE!Σ E

PSD!√ Σ SD^2

From 90%!PE - 1,645*PSD

To 90%!PE + 1,645*PSD

3,33 0,49 2,53 4,13

Three point estimation• Плюсы

• достаточно быстрая оценка

• гибкость (уровень декомпозиции, confidence level)

• дает информацию об интервале

• Минусы

• симметричность функции вероятности*

• нет абсолютной оценки (в противовес интервалу)

Delphi method• Ведущий знакомит с требованиями к задачам и раздает карточки для заполнения оценок

• Анонимные оценки экспертов с обоснованием

• Ведущий объявляет средние оценки и зачитывает обоснования

• Переход к следующей итерации, пока оценки не сойдутся

Эксперт 1 Эксперт 2 Эксперт N Среднее

Задача 1Итерация 1 10 12

…

11

Итерация 2 12 14 12

Задача 2 Итерация 1 20 10 15

…

Delphi method• Плюсы

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

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

Wideband Delphi method

• Ведущий знакомит с требованиями к задачам

• Просит обсудить их

• Те же анонимные оценки экспертов с обоснованием

• После объявления средних оценок ведущий просит экспертов снова обсудить, фокусируя внимание на пунктах самым широком разбросом оценок

• и т.д. пока оценки не сойдутся

Попытка минимизировать минусы за счет добавления обсуждения между экспертами

Wideband Delphi method• Плюсы

• можно сильно повысить скорость схождения оценок

• учет «особого» мнения

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

Planning poker

• Декопозированный бэклог задач на итерацию • Собирается ВСЯ команда, раздаются каждому карты • Коротко озвучивается описание задачи • Каждый голосует в закрытую • Затем вскрываются и дается возможность обсудить и обосновать оценки тем у кого наибольший разброс

• Лимит времени на обсуждение, затем повтор пока оценки не сойдутся • В качестве итоговой оценки берется наиболее близкое к среднему, но не меньше

Planning poker• Плюсы

• весело, сплачивает команду • минимизация якорей • распространение экспертизы

• Минусы • очень дорого (бэклог на 1 месяц - 1..2 дня) • требует прозрачности и понимания архитектуры • трудно учитывать вес экспертов • личная энергетика и харизма • трудности при распределенной команде

Proxy-Based Estimating (PROBE)

• Разбиение требований на классы

• Каждый класс должне быть оценен

• по сложности

• по размеру / продолжительности

• Задачам, которые требуют оценки присваивается класс

Proxy-Based Estimating (PROBE)Малая Средняя Большая

Простая 2 ч 4 ч 8 чОбычная 4 ч 8 ч 16 чСложная 8 ч 16 ч 24 ч

Класс Размер Сложность Трудозатраты

Получение данных 2 1 4 ч

Верстка страницы 2 2 8 ч

Задача Класс ТрудозатратыВыбор данных по входящим

платежам Получение данных 4 ч

Верстка страницы баланса Верстка страницы 8 ч

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

• похожие оценки для похожих задач • достаточно высокая скорость

• Минусы • нужно понимать архитектуру • дает грубые оценки

Proxy-Based Estimating (PROBE)

До этого все было не научно

Use Case Points

• Unadjusted use case weight (UUCW) - число и сложность пользовательских историй

• Unadjusted actor weight (UAW) - число и сложность возможных взаимодействий

• Technical complexity factor (TCF) - технические аспекты разработки • Environment complexity factor (ECF) - факторы окружения

Является развитием Function point analysis

Разработан при создании UML

Считаются четыре величины по требованиям

Use Case Points

• Определяется чило и сложность пользовательских историй для системы в целом

• Для расчета UUCW системы каждая пользовательская история идентифицируется и класстеризуется как простая, средняя, сложная за счет подсчета количества транзакций*

Unadjusted use case weight (UUCW)

Use Case PointsUnadjusted use case weight (UUCW)

Use case classification # Transactions Weight

Simple 1..3 5

Average 4..7 10

Complex 8… 15

UUCW = Σ Weight (use case[i]) = 5*count(Simple) + 10*count(Average) + 15*count(Complex)

Use Case Points

• Определяется чило и сложность действующих лиц (возможных взаимодействий) с системой

• Actors подсчитываются и определяется класс простой, средний, сложный в зависимости от типа

Unadjusted actor weight (UAW)

Use Case Points

Actor classification Type of actor Weight

Simple Взаимодействие полностью определено - АПИ 1

Average Взаимодействие ведется через некоторый стандартный протокол - HTTP, FTP, DB 2

Complex Взаимодействие с пользователем - UI 3

UAW = Σ Weight (actor[i]) = count(Simple) + 2*count(Average) + 3*count(Complex)

Unadjusted actor weight (UAW)

Use Case Points

• Техническая сложность определяется исходя из 13 факторов по таблице

• Каждый фактор умножается на коэффициент значимости от 0 - незачимый до 5 - существенный

Technical complexity factor (TCF)

Use Case Points

Factor Description Weight

T1 Распределенность системы 2

T2 Скорость ответа 1

…

TCF = 0,6 + 0,01 * Σ Weight (factor[i]) * Score(factor[i])

Technical complexity factor (TCF)

Use Case Points

• Для каждого из 8 факторов окружения определяются очки опыта команды от 0 - нет опыта до 5 - эксперты

• Эти очки умножаются на вес каждого из факторов

Environment complexity factor (ECF)

Use Case Points

Factor Description Weight

E1 Знакомство с используемой технологией разработки 1,5

E2 Опыт разработки 0,5

…

ECF = 1,4 - 0,03 * Σ Weight (factor[i]) * Score(factor[i])

Environment complexity factor (ECF)

Use Case Points• В итоге вычисляется требуемое количество человеко-дней, которое потребуется для решения пользовательской истории

UCP = (UUCW + UAW) * TCF * ECF

• Плюсы • нет необходимости привлекать экспертов • техническа экспертиза не нужна • достаточно быстрая оценка • доступность для описания заказчику

• Минусы • в итоге у нас нет задач • необходимость детальных требований

Proxy-Based Estimating (PROBE)

Модели на основе истории

Внимание! До этого были умные люди, а дальше

уже личное «творчество»

imho

Следующая идея - это воплощение мысли «Лучшее предсказание того, что будет завтра, это сказать то же самое, что сегодня» !…через математику 4-ого класса :)

imho

Предположения

• Уровень декомпозиции у одних и тех же людей не меняется со временем*

• Скорость команды на период прогноза будет равна скорости за прошлый период*

• Процент задач вне плана на период прогноза будет равне проценту за прошлый период*

Потребуется знать

• Размер бэклога, количество задач

• Скорость команды, среднее количество дней на задачу

• Процент задач вне плана

Можем посчитать

Дата_релиза = Дата_начала + (backlog.size + backlog.size * %вне_плана) * скорость

• Плюсы • нет необходимости привлекать экспертов, если есть декомпозиция

• быстрая оценка, нужен только список задач • учет реальной скорости без потребности вводить магические коэффициенты pi/2..pi для корректировки оценки :)

• Минусы • грубая оценка • горизонт планирования небольшой, 2..3 месяца • нужно собирать статистику*

По истории

Как бы мы не хотели

Вопросы?

Спасибо!

Kalinichev.net 2014