Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

988 views

Published on

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

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Оценка сроков IT-проектов «Всякая работа требует больше времени, чем вы думаете» 2014 - следствие из закона Мерфи Kalinichev.net
  2. 2. Здесь нет сакральных знаний! Скорее это компиляция чужих мыслей и идей, среди которых мой мозг выбрал то, что ему ближе на основе текущего опыта!
  3. 3. Какой план? • Общие слова и идеи • Что влияет на оценки • Несколько способов оценки • экспертные • параметрические • на основе истории
  4. 4. Зачем оценивать?
  5. 5. О чем нужно помнить? • Цель оценки • Чем точнее требования, тем точнее оценка • Оценка не мгновенна - это такой же этап проекта и занимает он 10-12% от всего проекта
  6. 6. Лучшее предсказание того, что будет завтра, это сказать то же самое, что сегодня imho
  7. 7. Что в результате? • Список работ • Общие временные затраты • Бюджет проекта • Расписание проекта: декомпозиция и ключевые вехи • Сколько и каких специалистов нужно. В какое время и на сколько • План проекта • Риски и варианты их минимизации • Предположения
  8. 8. Что потребуется уточнить? • Продуктовые требования - функциональные требования - нефункциональные требования - боевое и тестовое окружение • Проектные требования - технологии - процесс создания - политика общения с заказчиком - политика поддержки
  9. 9. Эффективная оценка? • Нужно помнить что оцениваем • Декомпозиция • при предварительной оценке - проект 1-2 ч/г, размер задачи 1-2 недели нормально • при распределении по людям дальше 3х дней уже плохо* • Хронологическая зависимость задач • Опыт предыдущих задач и проектов • Мнение нескольких экспертов • Объединение задач в группы и усреднение • Проецируйте на вашу команду
  10. 10. Какие хорошие вопросы? • Есть возможность объяснить одной фразой, что требуется? • Как это будет использоваться? Кто конечный пользователь? • Какова ценность? Можно ли это вообще не делать? • Что нужно сделать, чтобы уменьшить срок или цену в 2а раза? • Делали или оценивали мы это раньше? • Что нужно сделать, чтобы начать делать эту работу параллельно? Какие от этого будут плюсы и минусы? • Какой самый простой способ сделать эту задачу? • Какие зависимости у этой задачи и что зависит от ее? Какие риски? • В каком окружении будет использоваться этот функционал? …
  11. 11. Умение распараллелить очень важно, как правило это экономит время. Все чаще стоимость проекта гораздо ниже стоимости бизнеса. Обычно время важнее всего. imho
  12. 12. Какие типовые ошибки? • Различия в определении того, что такое готово • Неполные требования • Недостаточное время для оценки • Фактор больших систем • Ошибки декомпозиции, как в + так и в - • Потеря деталей или частей функциональности • Потери на коммуникацию • Размер команды • Отсутствие специфичных знаний • Различия в понимании целей заказчика • Игнорирование стоимости поддержки кода • Игнорирование рисков • Когнетивные искажения
  13. 13. Когнетивные сдвиги • Излишняя уверенность • Эффект вложенных средств (sunk cost effect) • Предубеждение доступности (availability bias) • Предвзятость подтверждения (сonfirmation bias) • Якорный эффект (anchor bias) • Иллюзия сходства (Illusory correlation)
  14. 14. Какие оценки существуют? • В зависимости от типа оценки • усилия • продолжительность • В зависимости от цели • коммерческое предложение • проектное планирование • В зависимости от техники • модели на основе исторических данных • экспертная оценка • параметрические
  15. 15. Экспертные оценки
  16. 16. Three point estimation • Эксперт дает три оценки • оптимистичная (optimistic / best case) • наиболее вероятная (most likely / normal) • пессимистичная (pessimistic / worst case) • Используется распределение двойного треугольника O M P s=0,5 s=0,5
  17. 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. 18. Three point estimation Confidence level Standard deviation 68 % SD 90 % 1,645 * SD 95 % 2 * SD 99,7 3 * SD
  19. 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. 20. Three point estimation • Плюсы • достаточно быстрая оценка • гибкость (уровень декомпозиции, confidence level) • дает информацию об интервале • Минусы • симметричность функции вероятности* • нет абсолютной оценки (в противовес интервалу)
  21. 21. Delphi method • Ведущий знакомит с требованиями к задачам и раздает карточки для заполнения оценок • Анонимные оценки экспертов с обоснованием • Ведущий объявляет средние оценки и зачитывает обоснования • Переход к следующей итерации, пока оценки не сойдутся Эксперт 1 Эксперт 2 Эксперт N Среднее Задача 1 Итерация 1 10 12 … 11 Итерация 2 12 14 12 Задача 2 Итерация 1 20 10 15 …
  22. 22. Delphi method • Плюсы • хорошие результаты при высокой неопределенности • все в итоге согласны с оценками • адаптация количества итераций • анонимность • документируемость • исключение мнения мнимых экспертов • Минусы • мало формальных обоснований оценок • минимум 4 эксперта • часть идей будет потеряно из-за отсутствия общения • исключение мнения реальных экспертов • возможное согласие с чужими оценками без размышления
  23. 23. Wideband Delphi method • Ведущий знакомит с требованиями к задачам • Просит обсудить их • Те же анонимные оценки экспертов с обоснованием • После объявления средних оценок ведущий просит экспертов снова обсудить, фокусируя внимание на пунктах самым широком разбросом оценок • и т.д. пока оценки не сойдутся Попытка минимизировать минусы за счет добавления обсуждения между экспертами
  24. 24. Wideband Delphi method • Плюсы • можно сильно повысить скорость схождения оценок • учет «особого» мнения • Минусы • потеря анонимности • больше возможностей для влияние харизматичного лидера среди экспертов
  25. 25. Planning poker • Декопозированный бэклог задач на итерацию • Собирается ВСЯ команда, раздаются каждому карты • Коротко озвучивается описание задачи • Каждый голосует в закрытую • Затем вскрываются и дается возможность обсудить и обосновать оценки тем у кого наибольший разброс • Лимит времени на обсуждение, затем повтор пока оценки не сойдутся • В качестве итоговой оценки берется наиболее близкое к среднему, но не меньше
  26. 26. Planning poker • Плюсы • весело, сплачивает команду • минимизация якорей • распространение экспертизы • Минусы • очень дорого (бэклог на 1 месяц - 1..2 дня) • требует прозрачности и понимания архитектуры • трудно учитывать вес экспертов • личная энергетика и харизма • трудности при распределенной команде
  27. 27. Proxy-Based Estimating (PROBE) • Разбиение требований на классы • Каждый класс должне быть оценен • по сложности • по размеру / продолжительности • Задачам, которые требуют оценки присваивается класс
  28. 28. Proxy-Based Estimating (PROBE) Малая Средняя Большая Простая 2 ч 4 ч 8 ч Обычная 4 ч 8 ч 16 ч Сложная 8 ч 16 ч 24 ч Класс Размер Сложность Трудозатраты Получение данных 2 1 4 ч Верстка страницы 2 2 8 ч Задача Класс Трудозатраты Выбор данных по входящим платежам Получение данных 4 ч Верстка страницы баланса Верстка страницы 8 ч
  29. 29. • Плюсы • можно узнать заранее сколько каких специалистов нужно в самом начале • похожие оценки для похожих задач • достаточно высокая скорость • Минусы • нужно понимать архитектуру • дает грубые оценки Proxy-Based Estimating (PROBE)
  30. 30. До этого все было не научно
  31. 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. 32. Use Case Points • Определяется чило и сложность пользовательских историй для системы в целом • Для расчета UUCW системы каждая пользовательская история идентифицируется и класстеризуется как простая, средняя, сложная за счет подсчета количества транзакций* Unadjusted use case weight (UUCW)
  33. 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. 34. Use Case Points • Определяется чило и сложность действующих лиц (возможных взаимодействий) с системой • Actors подсчитываются и определяется класс простой, средний, сложный в зависимости от типа Unadjusted actor weight (UAW)
  35. 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. 36. Use Case Points • Техническая сложность определяется исходя из 13 факторов по таблице • Каждый фактор умножается на коэффициент значимости от 0 - незачимый до 5 - существенный Technical complexity factor (TCF)
  37. 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. 38. Use Case Points • Для каждого из 8 факторов окружения определяются очки опыта команды от 0 - нет опыта до 5 - эксперты • Эти очки умножаются на вес каждого из факторов Environment complexity factor (ECF)
  39. 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. 40. Use Case Points • В итоге вычисляется требуемое количество человеко-дней, которое потребуется для решения пользовательской истории UCP = (UUCW + UAW) * TCF * ECF
  41. 41. • Плюсы • нет необходимости привлекать экспертов • техническа экспертиза не нужна • достаточно быстрая оценка • доступность для описания заказчику • Минусы • в итоге у нас нет задач • необходимость детальных требований Proxy-Based Estimating (PROBE)
  42. 42. Модели на основе истории
  43. 43. Внимание! До этого были умные люди, а дальше уже личное «творчество» imho
  44. 44. Следующая идея - это воплощение мысли «Лучшее предсказание того, что будет завтра, это сказать то же самое, что сегодня» ! …через математику 4-ого класса :) imho
  45. 45. Предположения • Уровень декомпозиции у одних и тех же людей не меняется со временем* • Скорость команды на период прогноза будет равна скорости за прошлый период* • Процент задач вне плана на период прогноза будет равне проценту за прошлый период*
  46. 46. Потребуется знать • Размер бэклога, количество задач • Скорость команды, среднее количество дней на задачу • Процент задач вне плана
  47. 47. Можем посчитать Дата_релиза = Дата_начала + (backlog.size + backlog.size * %вне_плана) * скорость
  48. 48. • Плюсы • нет необходимости привлекать экспертов, если есть декомпозиция • быстрая оценка, нужен только список задач • учет реальной скорости без потребности вводить магические коэффициенты pi/2..pi для корректировки оценки :) • Минусы • грубая оценка • горизонт планирования небольшой, 2..3 месяца • нужно собирать статистику* По истории
  49. 49. Как бы мы не хотели
  50. 50. Вопросы?
  51. 51. Спасибо! Kalinichev.net 2014

×