Общие слова и идеи. Что влияет на оценки сроков. Несколько способов оценки: - экспертные, - параметрические, - на основе истории.

1. Оценка сроков
IT-проектов
«Всякая работа требует больше времени,
чем вы думаете»
2014
- следствие из закона Мерфи
Kalinichev.net

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

3. Какой план?
• Общие слова и идеи
• Что влияет на оценки
• Несколько способов оценки
• экспертные
• параметрические
• на основе истории

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

5. О чем нужно помнить?
• Цель оценки
• Чем точнее требования, тем точнее оценка
• Оценка не мгновенна - это такой же этап проекта
и занимает он 10-12% от всего проекта

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

7. Что в результате?
• Список работ
• Общие временные затраты
• Бюджет проекта
• Расписание проекта: декомпозиция и ключевые вехи
• Сколько и каких специалистов нужно. В какое время и на сколько
• План проекта
• Риски и варианты их минимизации
• Предположения

8. Что потребуется уточнить?
• Продуктовые требования
- функциональные требования
- нефункциональные требования
- боевое и тестовое окружение
• Проектные требования
- технологии
- процесс создания
- политика общения с заказчиком
- политика поддержки

9. Эффективная оценка?
• Нужно помнить что оцениваем
• Декомпозиция
• при предварительной оценке - проект 1-2 ч/г, размер задачи 1-2 недели нормально
• при распределении по людям дальше 3х дней уже плохо*
• Хронологическая зависимость задач
• Опыт предыдущих задач и проектов
• Мнение нескольких экспертов
• Объединение задач в группы и усреднение
• Проецируйте на вашу команду

10. Какие хорошие вопросы?
• Есть возможность объяснить одной фразой, что требуется?
• Как это будет использоваться? Кто конечный пользователь?
• Какова ценность? Можно ли это вообще не делать?
• Что нужно сделать, чтобы уменьшить срок или цену в 2а раза?
• Делали или оценивали мы это раньше?
• Что нужно сделать, чтобы начать делать эту работу параллельно? Какие от
этого будут плюсы и минусы?
• Какой самый простой способ сделать эту задачу?
• Какие зависимости у этой задачи и что зависит от ее? Какие риски?
• В каком окружении будет использоваться этот функционал? …

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

12. Какие типовые ошибки?
• Различия в определении того, что такое готово
• Неполные требования
• Недостаточное время для оценки
• Фактор больших систем
• Ошибки декомпозиции, как в + так и в -
• Потеря деталей или частей функциональности
• Потери на коммуникацию
• Размер команды
• Отсутствие специфичных знаний
• Различия в понимании целей заказчика
• Игнорирование стоимости поддержки кода
• Игнорирование рисков
• Когнетивные искажения

13. Когнетивные сдвиги
• Излишняя уверенность
• Эффект вложенных средств (sunk cost effect)
• Предубеждение доступности (availability bias)
• Предвзятость подтверждения (сonfirmation bias)
• Якорный эффект (anchor bias)
• Иллюзия сходства (Illusory correlation)

14. Какие оценки существуют?
• В зависимости от типа оценки
• усилия
• продолжительность
• В зависимости от цели
• коммерческое предложение
• проектное планирование
• В зависимости от техники
• модели на основе исторических данных
• экспертная оценка
• параметрические

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

16. Three point estimation
• Эксперт дает три оценки
• оптимистичная (optimistic / best case)
• наиболее вероятная (most likely / normal)
• пессимистичная (pessimistic / worst case)
• Используется распределение двойного треугольника
O M P
s=0,5 s=0,5

17. Three point estimation
Task 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

18. Three point estimation
Confidence level Standard deviation
68 % SD
90 % 1,645 * SD
95 % 2 * SD
99,7 3 * SD

19. Three point estimation
Задача O M P E SD
From 90%!
E - 1,645*SD
To 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

20. Three point estimation
• Плюсы
• достаточно быстрая оценка
• гибкость (уровень декомпозиции, confidence level)
• дает информацию об интервале
• Минусы
• симметричность функции вероятности*
• нет абсолютной оценки (в противовес интервалу)

21. Delphi method
• Ведущий знакомит с требованиями к задачам и раздает карточки для
заполнения оценок
• Анонимные оценки экспертов с обоснованием
• Ведущий объявляет средние оценки и зачитывает обоснования
• Переход к следующей итерации, пока оценки не сойдутся
Эксперт 1 Эксперт 2 Эксперт N Среднее
Задача 1
Итерация 1 10 12
…
11
Итерация 2 12 14 12
Задача 2 Итерация 1 20 10 15
…

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

23. Wideband Delphi method
• Ведущий знакомит с требованиями к задачам
• Просит обсудить их
• Те же анонимные оценки экспертов с обоснованием
• После объявления средних оценок ведущий просит экспертов
снова обсудить, фокусируя внимание на пунктах самым
широком разбросом оценок
• и т.д. пока оценки не сойдутся
Попытка минимизировать минусы за счет добавления
обсуждения между экспертами

24. Wideband Delphi method
• Плюсы
• можно сильно повысить скорость схождения
оценок
• учет «особого» мнения
• Минусы
• потеря анонимности
• больше возможностей для влияние
харизматичного лидера среди экспертов

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

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

27. Proxy-Based Estimating (PROBE)
• Разбиение требований на классы
• Каждый класс должне быть оценен
• по сложности
• по размеру / продолжительности
• Задачам, которые требуют оценки присваивается
класс

28. Proxy-Based Estimating (PROBE)
Малая Средняя Большая
Простая 2 ч 4 ч 8 ч
Обычная 4 ч 8 ч 16 ч
Сложная 8 ч 16 ч 24 ч
Класс Размер Сложность Трудозатраты
Получение данных 2 1 4 ч
Верстка страницы 2 2 8 ч
Задача Класс Трудозатраты
Выбор данных по входящим
платежам
Получение данных 4 ч
Верстка страницы баланса Верстка страницы 8 ч

29. • Плюсы
• можно узнать заранее сколько каких
специалистов нужно в самом начале
• похожие оценки для похожих задач
• достаточно высокая скорость
• Минусы
• нужно понимать архитектуру
• дает грубые оценки
Proxy-Based Estimating (PROBE)

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

31. Use Case Points
• Unadjusted use case weight (UUCW) - число и сложность
пользовательских историй
• Unadjusted actor weight (UAW) - число и сложность возможных
взаимодействий
• Technical complexity factor (TCF) - технические аспекты разработки
• Environment complexity factor (ECF) - факторы окружения
Является развитием Function point analysis
Разработан при создании UML
Считаются четыре величины по требованиям

32. Use Case Points
• Определяется чило и сложность
пользовательских историй для системы в целом
• Для расчета UUCW системы каждая
пользовательская история идентифицируется и
класстеризуется как простая, средняя, сложная
за счет подсчета количества транзакций*
Unadjusted use case weight (UUCW)

33. Use Case Points
Unadjusted 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)

34. Use Case Points
• Определяется чило и сложность действующих
лиц (возможных взаимодействий) с системой
• Actors подсчитываются и определяется класс
простой, средний, сложный в зависимости от
типа
Unadjusted actor weight (UAW)

35. 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)

36. Use Case Points
• Техническая сложность определяется исходя из
13 факторов по таблице
• Каждый фактор умножается на коэффициент
значимости от 0 - незачимый до 5 - существенный
Technical complexity factor (TCF)

37. 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)

38. Use Case Points
• Для каждого из 8 факторов окружения
определяются очки опыта команды от 0 - нет
опыта до 5 - эксперты
• Эти очки умножаются на вес каждого из
факторов
Environment complexity factor (ECF)

39. 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)

40. Use Case Points
• В итоге вычисляется требуемое количество
человеко-дней, которое потребуется для решения
пользовательской истории
UCP = (UUCW + UAW) * TCF * ECF

41. • Плюсы
• нет необходимости привлекать экспертов
• техническа экспертиза не нужна
• достаточно быстрая оценка
• доступность для описания заказчику
• Минусы
• в итоге у нас нет задач
• необходимость детальных требований
Proxy-Based Estimating (PROBE)

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

43. Внимание! До этого были
умные люди, а дальше
уже личное «творчество»
imho

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

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

48. Потребуется знать
• Размер бэклога, количество задач
• Скорость команды, среднее количество дней на
задачу
• Процент задач вне плана

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

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

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

52. Вопросы?

53. Спасибо!
Kalinichev.net 2014