Основано на книге Стив МакКонелл, "Сколько стоит программный проект" - Цели, План, Эстимейт, Обязательства - как они взаимосвязаны? - Переоценка и недооценка - последствия - Основные причины ошибок в оценках - Факторы и их влияние на оценку (COCOMO ||) - Методы оценки - Правильная процедура оценки Полезные ссылки: Classic Mistakes Enumerated - http://www.stevemcconnell.com/rdenum.htm CoCoMo - https://ru.wikipedia.org/wiki/COCOMO Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование

1. Эстимейты
и их точность
Elena Sharovar
2017

2. Цель - задача, поставленная бизнесом. Например: нужна бета-версия
продукта к 30 мая.
План - набор работ, стратегия достижения этой бизнес-цели. Планов
достижения цели может быть несколько.
Эстимейт - прогноз, оценка необходимого времени или бюджета для
выполнения работ из выбранного плана.
Если эстимейт показывает что цель невыполнима в срок - необходимо изменять
план, объемы работ, цель, но не умышленно занижать эстимейт.

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

4. Оценка (эстимейт) - это не конкретное число, а вероятностное утверждение,
указывающее дату и вероятность завершения проекта к этой дате.
Вероятность что задача займет 10, 12, 14
или 16 дней. Максимальная вероятность у
значения “12 дней”
Суммарная вероятность что задача будет
закончена к 10му, 12му, 14му или 16му дню
Максимальная вероятность у значения “14-16
дней”

5. Эстимейты (оценки) должны быть не столько идеально точными, сколько
полезными.
Для чего нужны оценки?
- Формирование бюджета
- Внутренние обязательства
- Внешние обязательства
- Сбор данных, прогнозирование, планирование

6. Переоценка или недооценка?
Последствия переоценки Последствия недооценки
Может вступить в работу закон Паркинсона
- работа растянется и займет все
отведенное на нее время.
Может вступить в работу “Студенческий
синдром”. Если выделить разработчикам
слишком много времени, то вначале они
работают спустя рукава, а к концу срока
начинается аврал и сроки в итоге все равно
сорваны.
Поэтому недооценка иногда используется с
целью внушить группе разработчиков
чувство срочности проекта.
Недооценка на 5-10% не несет тяжелых
последствий, однако по статистике
программные проекты часто
недооцениваются на 30% и более
Опасность умышленной недооценки
состоит в том, что разработчики и без того
склонны оценивать объем работы на 20-
30% ниже реального.
Заниженная оценка приводит к тому что на
предварительные операции (постановка
требований и проектирование) будет
потрачено слишком мало времени, и огрехи
планирования и проектирования будет
гораздо дороже исправлять позже

7. В случае недооценки, на позднем этапе команда входит в режим “опоздания”, и
приходится тратить время на действия, не нужные для “своевременных”
проектов.
- дополнительные встречи для обсуждения способов и мер необходимых для того
чтобы все-таки успеть
- выполнение переоценок для понимания новых сроков завершения проекта
- информирование третьих лиц об опоздании и новых сроках
- решение проблем с наспех сделанными решениями, которые пришлось
реализовать из-за поджимающих сроков
У всех перечисленных действий есть важная особенность - они совершенно не
нужны если работа идет по графику.
>> Переоценка или недооценка?

8. В области программного обеспечения постоянно стоит проблема недооценки. 20% проектов
выполняется вовремя, еще 60% - с опозданием
>> Переоценка или недооценка?

9. Плюсы хорошей оценки
- отслеживание прогресса, ранняя информация о рисках или срывах
- повышение качества:
Как показали исследования, около 40% ошибок программирования возникают из-за стресса; этих ошибок
можно было бы избежать за счет правильного планирования и снижения нагрузки на разработчиков
Проекты, с самого начала ориентирующиеся на минимизацию количества дефектов (заметьте что не
перфекционизм, а минимизация дефектов!), имеют самый короткий срок сдачи
- точная оценка = точный бюджет
- повышение доверия к группе разработчиков

10. Причины ошибок в оценках

11. 1. Конус неопределенности
По мере движения проекта снижается неопределенность, а соответственно оценка может быть
выполнена более точно. Нужно выбрать, на каком этапе уточнения давать оценку. Чем больше
неопределенности, тем более ошибочна оценка.
>> Причины ошибок в оценках

12. Бывает что проект идет а неопределенность не снижается
>> Причины ошибок в оценках

13. Если обязательства принимаются на этапе исходной концепции
или определения продукта (или задачи), в них нужно
закладывать ошибку оценки от 2х до 4х.
При итеративной разработке продукта, каждая итерация
(спринт) - это новый конус неопределенности.
>> Причины ошибок в оценках

14. Факторы хаоса
- поверхностный анализ исходных требований
- отсутствие участия конечного пользователя в постановке требований
- плохое проектирование, порождающее ошибки в коде
- плохая методология программирования, требующая постоянного
исправления ошибок
- недостаточная квалификация персонала
- неполное или неумелое планирование проекта
- присутствие “звезд” в группах
- отказ от планирования из-за давления
- отсутствие автоматизированной системы контроля кода
Больше по ссылке http://www.stevemcconnell.com/rdenum.htm
>> Причины ошибок в оценках

15. 2. Нестабильные требования
- Увеличивают неопределенность
- Часто не отслеживаются, и проект не переоценивается, как это
должно быть. По мере добавления новых требований оценки
затрат и стоимости должны пересматриваться.
F1 F2 F3
5 10 15
7 12 -
>> Причины ошибок в оценках

16. Если рабочая ситуация не позволяет стабилизировать требования,
рекомендуют
- Короткие итерации
- Scrum
- Экстремальное программирование
>> Причины ошибок в оценках > Нестабильные требования

17. Экстремальное программирование
Короткий цикл обратной связи (Fine-scale feedback)
- Разработка через тестирование (Test-driven development)
- Игра в планирование (Planning game)
- Заказчик всегда рядом (Whole team, Onsite customer)
- Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
- Непрерывная интеграция (Continuous integration)
- Рефакторинг (Design improvement, Refactoring)
- Частые небольшие релизы (Small releases)
Понимание, разделяемое всеми
- Простота проектирования (Simple design)
- Метафора системы
- Коллективное владение кодом (Collective code ownership) или выбранными шаблонами
проектирования (Collective patterns ownership)
- Стандарт оформления кода (Coding standard or Coding conventions)
Социальная защищённость программиста (Programmer welfare):
- 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)
>> Причины ошибок в оценках > Нестабильные требования > Решения

18. Делайте запас на рост требований
- закладывайте в оценку запас на рост требований
- NASA закладывает в оценку возможность 40% роста требований
>> Причины ошибок в оценках > Нестабильные требования

19. 3. Неучтенные при оценивании задачи
- Неучтенные требования
- Неучтенные действия по разработке
- Неучтенные действия не связанные с разработкой
Психологическая ловушка: специалисты хорошо прорабатывают
понятные требования, и одной строкой прописывают непонятные с
мыслью “потом разберемся”
>> Причины ошибок в оценках

20. Часто забывают учесть
- Обучение участников группы
- Установка, настройка
- Прояснение требований
- Создание тестовых данных
- Участие в техническом ревью
- Ответы на вопросы группы QA
- Работа по исправлению дефектов
- Настройка производительности
- Изучение нового инструментария
- Преобразование данных
- Праздники, болезни, выходные
>> Причины ошибок в оценках > Неучтенные задачи

21. 4. Необоснованный оптимизм
“Никогда не следует опасаться того, что оценка созданная
разработчиком, является слишком оптимистичной, потому что
разработчики всегда назначают слишком оптимистичные сроки”
Стандартная недооценка разработчиками - 30%
(на основе исследования 300 проектов)
>> Причины ошибок в оценках

22. Примеры необоснованного оптимизма
- Над этим проектом мы будем работать более эффективно чем над
предыдущим проектом
- В последнем проекте все шло наперекосяк. В этом проекте проблем
будет меньше.
- Мы начинали медленно, но ближе к концу мы будем работать гораздо
эффективнее чем вначале
Эти заблуждения существуют потому что разработчики действительно
этого хотят!
>> Причины ошибок в оценках>> Причины ошибок в оценках > Необоснованный оптимизм

23. Ситуация которую называют “сговор оптимистов”
- разработчики дают оптимистичные оценки
- руководству нравятся оптимистичные оценки, потому что они указывают
на достижимость определенных бизнес целей
- менеджерам они нравятся, потому что они подразумевают возможность
выполнения указаний начальства
.. и никому даже в голову не приходит критически проанализировать
обоснованность самих оценок.
>> Причины ошибок в оценках > Необоснованный оптимизм

24. 5. Импровизация по памяти
Одна из ошибок при составлении оценок на базе собственных
воспоминаний - в том, что новый проект сравнивается с воспоминаниями о
том, сколько времени ушло на работу в прошлый раз.
К сожалению, люди часто запоминают свои оценки прошлых проектов, а не
фактические затраты времени.
>> Причины ошибок в оценках

25. Другие причины ошибок в оценках:
- незнакомая область деятельности
- незнакомая технологическая область
- неверное преобразование календарного времени в
проектное
- завышенные ожидания от применения новых средств или
методов разработки
>> Причины ошибок в оценках

26. Издержки масштаба команды
>> Причины ошибок в оценках

27. Факторы персонала (CoCoMo)
>> Причины ошибок в оценках
CoCoMo - constructive cost model - метод оценки стоимости программного обеспечения, в нем
перечислен список факторов влияющих на стоимость (время) разработки и степень их влияния
Низкая квалификация
аналитиков может увеличить
стоимость разработки до
+42% (больше времени будет
уходить на багфиксы), а
высокая - уменьшить на -29%.
Интересно что квалификация
программистов влияет на
стоимость в меньшей степени!
Также интересно что в этой
модели учтены даже такие
факторы как слаженность
команды и другие

29. Методы оценки

30. 1. Подсчет и вычисления + экспертное суждение
Найдите факторы которые можно посчитать
- Количество скринов
- Количество таблиц в базе данных
- Среднее количество времени на класс при разработке
и основывайте эстимейты на количественных факторах
Экспертное суждение - наименее точный метод оценки, поскольку более
субъективный. Наибольшая точность достигается когда оценка
привязывается к чему-то конкретному.
>> Методы оценки

31. 2. Калибровка историческими данными
Собираются:
- среднеотраслевые данные
- исторические данные (по другим проектам)
- проектные данные (по текущему проекту)
и на основе их создаются оценки.
Наиболее точный источник - проектные данные (с текущего проекта).
>> Методы оценки

32. 3. Индивидуальные экспертные оценки
“Большой опыт в технологии или разработке
еще не делает работника экспертом в области оценок”
Для улучшения оценки рекомендуется:
- поручать оценку тем людям которые будут выполнять работу
- разбиение на задачи длиной не более 1 дня
- чек-листы для процесса оценки
- вести учет оценок и фактически затраченного времени
>> Методы оценки

33. 4. PERT (program review and evaluation technique)
>> Методы оценки
Почему используется?
Было замечено что единичные, “наиболее вероятные” оценки склонны к
излишнему оптимизму.
В чем состоит метод?
Нужно дать три оценки, для таких случаев
- Лучший случай (BEST)
- Наиболее вероятный случай (AVERAGE)
- Худший случай (WORST)
Затем результирующая оценка вычисляется по формуле:
RESULT = (BEST + 4 * AVERAGE + WORST ) / 6

34. >> Методы оценки > PERT
В чем плюсы оценки методом PERT?
Создание оценок для лучшего и худшего случаев стимулирует мышление и
помогает учесть весь диапазон возможных результатов.
Пример
В лучшем случае задача займет 10 дней
В ожидаемом случае - 12 дней
В худшем случае - 18 дней
Результат = (10 + 12 * 4 + 16 ) / 6 = 12.6 дней
Для одной задачи оценка очень близка к ожидаемой но при наличии
нескольких задач разница становится существенной (несколько дней)

35. 5. Абстрактные рейтинги
- истории оцениваются в абстрактных пунктах
- на основании нескольких итераций вычисляется скорость
разработки в абстрактных пунктах
- на основании вычисленной скорости делаются прогнозы в
следующих итерациях
>> Методы оценки

36. Другие методы оценки:
- Оценка по аналогии
- Разбиение на стандартные компоненты
- Метод футболки
>> Методы оценки

37. Хорошая процедура оценки:
- базируется на подсчете и вычислениях, а не субъективных
оценках
- использует несколько методов оценки и сравнивает результаты
- содержит указание неточности оценки
- определяет, когда оценка может быть использована для
формирования бюджета проекта
- определяет, когда оценка может использоваться для внутренних
и внешних обязательств
>> Методы оценки

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

39. Влияющие на оценку факторы
- масштаб команды
- квалификация персонала (CoCoMo)
Методы оценки:
- Подсчет, вычисления
- Калибровка историческими данными
- Экспертное суждение
- PERT
- Абстрактные рейтинги
>> Итого

40. >> Итого
Психологические ловушки в оценке
- точечные (наиболее вероятные) оценки близятся к оптимистичным
- люди запоминают свои прошлые оценки а не фактические затраты
времени

41. Ссылки
Сколько стоит программный проект
Classic Mistakes Enumerated
Экстремальное программирование
Модель CoCoMo