Простые методы оценки объемов работ проекта, Оценка сроков, усилий и сложности разработки программного обеспечения

Привет, Вы узнаете о том , что такое оценка сроков, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое оценка сроков, оценка усилий, оценка сложности, объемов работ проекта, сроки проекта , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.

Часто очень важным этапом проекта является оценка срока или сложности, рассмотрим какими методами это можно сделать.

Чтобы описать их, я использую кейс из ИТ-проекта (надо же кейс из реальной жизни), но использовать описанные подходы можно абсолютно в любом проекте.

Команда проекта разработки программного продукта получает техническое задание на продукт, которое содержит описание автоматизируемых процессов в нотации IDEF0, описание сценариев использования программного продукта и требования к нему. Задача команды – просчитать сроки реализации проекта и бюджет на него. Я являюсь руководителем будущего проекта. Мои действия?

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

В реальном кейсе я отдал техническое задание на изучение будущему архитектору продукта. Он на черновике набросал архитектуру продукта, разбив продукт на элементы, и мы определили список работ. Далее я попросил его дать две оценки трудозатрат по каждому элементу архитектуры. Первая оценка – это ответ на вопрос: каковы будут трудозатраты в человеко-часах на реализацию работы, если никаких проблем не возникнет и реализовывать эту часть будет программист высокой квалификации. Вторая оценка предполагает ответ на вопрос: а теперь представь, что реализовывать задачу будет самый слабый программист из нашей команды, да еще в довесок ко всему он столкнется со всеми возможными проблемами? Так я получил оптимистичную и пессимистичную оценку трудозатрат на каждую работу.

Для использования метода, о котором я пишу, мне нужен еще третий тип оценки, с которым и возникает чаще всего сложность. Эта оценка называется наиболее вероятной оценкой трудозатрат. На основании чего можно получить эту оценку? Конечно, на основании статистики похожих задач. Ага, а где в СНГ можно найти статистику по трудозатратам проектов? Я могу начать ее накапливать в своих проектах, и это будет прекрасной инвестицией в будущее, но статистика мне нужна сегодня.

На самом деле выход есть. И он называется метод Дельфи. Его суть в том, чтобы использовать группу экспертов и с помощью серии последовательных итераций добиться максимального консенсуса при определении группового решения. На практике мне понравилось использовать модификацию метода Дельфи – покерное планирование. В методе Дельфи (и его модификациях) очень важно получение независимых оценок экспертов, т.е. эксперты не должны знать об оценках друг друга до того момента, пока каждый из них не сделает свой выбор. Почему это важно? Дело в том, что на людей магическое действие оказывает так называемая «привязка». Об эффекте привязки прекрасно пишет Д.Канеман: «Эффект привязки проявляется, когда перед оценкой неизвестного значения испытуемые сталкиваются с произвольным числом. Этот эксперимент дает одни из самых надежных и стабильных результатов в экспериментальной психологии: оценки не отдаляются от рассмотренного числа, отсюда и образ привязки к определенной точке». К примеру, трое друзей оценивают трудозатраты по задаче «выкопать лопатой траншею длиной в 5 метров, шириной 25 см и глубиной в 1 м». Кто-то из них произносит число 20… И это значение уже произвело эффект мозгового штурма и стало ориентиром, отталкиваясь от которого двое других экспертов будут делать свои оценки. Конечно, они будут делать корректировки в ту или иную сторону, но будут ли эти корректировки достаточно смелыми, чтобы дать оценку, в разы отличающуюся от уже сделанной? Когнитивные психологи утверждают, что нет.

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

Как проходит покерное планирование? О, это достаточно весело.

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

В специальной колоде, как вы уже заметили, не все значения карт соответствуют ряду Фибоначчи: начиная с «20» цифры идут уже не по закону Фибоначчи (сумма двух предыдущих чисел должна давать следующее число). Это сделано намеренно, т.к. если работа занимает, по мнению эксперта, очень много времени, то будет это 21 час или 20 уже не очень важно. Тем более это неважно для значений в 40 или 100 часов – трудозатраты слишком велики, и шаг после «20» намеренно выбран очень большим. В колоде есть несколько интересных карт: например «?» означает, что эксперт не понимает суть задачи и не готов сделать оценку, а «кофейная чашка» означает, что эксперт очень хочет сделать брейк и попить кофейку (или чая).

Покерное планирование – это игра в оценки, но игра с полезным для менеджера проекта результатом. Люди любят играть в игры, и мой опыт показал, что в покерное планирование эксперты играют с удовольствием. Что еще важнее – оно дает очень неплохую точность оценок, особенно если их делают люди, хорошо понимающие предметную область и имеющие примерно одну и ту же квалификацию.

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

Итак, модератор оглашает суть задачи и отвечает на вопросы экспертов по сути задачи, после чего просит оценить трудозатраты на задачу в случае, если ее будет реализовывать сам эксперт. Сделав оценку, эксперт должен вытянуть карту с цифрой, соответствующей этой оценке, но при этом положить ее рубашкой вверх, чтобы никто не видел цифру. К примеру, я оцениваю выполнение задачи в 10 человеко-часов. В этом случае я вытягиваю из колоды карту с цифрой 10.

После того, как все эксперты вытянули карты и положили их рубашкой вверх, карты вскрываются и модератор оглашает результаты. Цель процедуры – сблизить мнение экспертов, поэтому модератор просит высказаться эксперта, у которого получилась самая низкая оценка. Эксперт рассказывает в деталях, как он планирует реализовать задачу за оцененное им же время. Иногда оказывается, что эксперт неверно понял требования к работе, иногда он описывает очень изящный подход, требующий меньше трудозатрат, чем другие подходы к решению задачи. После этого модератор просит высказаться эксперта, сделавшего самую высокую оценку. После высказываний двух экспертов, как правило, требования к результатам задачи становятся более понятными, и группа зачастую выбирает подход к реализации задачи. Модератор просит участников обсуждения еще раз подумать о трудозатратах и проводится второй тур голосования. Чаще всего разброс оценок экспертов уменьшается после второго тура. После проведения второго тура можно остановиться, усреднить оценки экспертов и поблагодарить их. Но можно провести второй тур обсуждений и после него устроить третий тур оценки. На практике я ограничивался двумя турами. Полученную усредненную оценку экспертов можно принять как наиболее вероятную и использовать ее для расчета трудозатрат по методу трех точек.

Итак, теперь у меня есть три оценки для использования описываемого метода. Мне нужно выбрать вид распределения вероятности и формулы для математических вычислений оценки.

Что за распределения вероятности? Я надеюсь, вы немного помните теорию математической статистики и вид нормального распределения?

На рисунке показано наиболее часто встречающееся в результатах измерений для какого-то явления значение (µ - математическое ожидание) и диапазоны, которые указывают на отклонения от него (сигма - среднеквадратическое отклонение от математического ожидания). Вероятность попадания какого-то значения в интервал от математического ожидания плюс одна сигма равна 68,2%, а добавление к математическому ожиданию 2-х сигм позволяет быть уверенным в том, что событие случится с вероятностью 95,4%.

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

Формула, которая используется для треугольного распределения:
E = (O + M + P) / 3,
Где О – оптимистичная оценка,
М – наиболее вероятная оценка,
Р – пессимистичная оценка.

Вид треугольного распределения может быть примерно таким:

Формула, которая используется для Бета-распределения:
E = (O + 4*M + P) / 6

Почему бы не взять для расчета оценок по проекту нормальное распределение? Ответ на этот вопрос дает Н.Талеб в своей книге «Черный лебедь». Об этом говорит сайт https://intellect.icu . «Великое мошенничество» Гаусса, по мнению Талеба, способно прогнозировать только те события и величины, которые принадлежат пространству измерений, где ни одно наблюдение не может оказывать значительного влияния на результаты. Человеческий рост, вес и другие биологические величины – хороший пример для использования нормального распределения: плотность распределения вероятности группируется вокруг узкого диапазона вариантов, а разброс вариантов не так велик. Вы не найдете человека ростом 5 метров или весом в 100 грамм. Добавив к статистике рост самого высокого или самого низкого человека на планете, вы лишь незначительно повлияете на результаты выборки – средняя величина роста и сигма едва-едва изменятся.

А вот такие события, как продажи книги-бестселлера, популярность видео на Youtube, движения фондового рынка, прибыльность инвестиций, статистика инцидентов по работе информационной системы – не подлежат нормальному распределению Гаусса.

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

Надо отметить, что при использовании формулы для бета-распределения коэффициент четверки при наиболее вероятной оценке сильно смещает итоговый результат расчетов в область этой оценки. Какой бы широкий интервал ни был между оптимистической и пессимистической оценкой – в итоге расчетов оценка близка к наиболее вероятной.

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

Итак, вернемся к нашему кейсу.

Для оценки объемов работ на старте проекта я использовал знания самого сильного эксперта в предметной области проекта, чтобы получить высокоуровневый список работ по проекту и пессимистическую и оптимистическую оценки трудозатрат по каждой работе проекта. Для оценки по трем точкам мне нужна была наиболее вероятная оценка, которую я мог бы взять из статистики по похожим задачам, но она мне не доступна. Я привлек несколько экспертов и провел оценку трудозатрат методом покерного планирования. Полученные значения взял как наиболее вероятные и использовал формулу оценки для бета-распределения. Для получения трудоемкости проекта мне осталось суммировать оценки по всем задачам проекта, полученные по методу трех точек, и добавить резерв на риски. Резерв на риски можно рассчитать с помощью среднеквадратического отклонения. Дело в том, что для большого количества задач проекта с независимыми свойствами действует центральная предельная теорема, форма распределения вероятности для всего проекта будет близка к нормальной.

Для определения трудоемкости проекта с точностью свыше 50% мне нужно подсчитать среднеквадратическое отклонение по каждой задаче проекта, возвести его в квадрат, а потом извлечь корень квадратный из суммы квадратов СКО по всем задачам. Читать трудно, делать просто. Смотрите на формулы.

Для расчета трудоемкости одной задачи по методу PERT используется формула:

Трудоемкость же всего проекта с точностью 95% определяется по формуле:

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

Я знаю о попытках выводить нормативы на виды работ в строительстве и в некоторых ИТ-компаниях, разрабатывающих софт.

В своей статье о различиях американского подхода к управлению проектами от советского Иванов В. указывает на преимущества ресурсного метода (где есть строго нормо-часы, строгая квалификация работника и т.п.) в рамках ограниченности этих самых ресурсов. Теперь вопрос. Метод оценки длительности работ может включать и вариант расчетов по нормативам трудозатрат. Подскажите, существуют ли такие нормы нынче вообще, если и существуют, то в каких отраслях? Причина вопроса - часто сталкивался с некорректностью "экспертной оценки" длительностей операций, например, в проектировании. А вот если бы были такие нормативы, то можно просто подгружать их в проджект (здесь имя нарицательное) и все.

.

оценка сложности по разработке программного обеспечения

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

Практика

Опубликованные обзоры практики оценивания показывают, что экспертная оценка является доминирующей стратегией при оценке усилий по разработке программного обеспечения.

Как правило, оценки усилий слишком оптимистичны, и есть сильная чрезмерная уверенность в их точности. Средний перерасход усилий составляет около 30% и не уменьшается со временем. Для обзора обзоров ошибок оценки трудозатрат см. Однако измерение ошибки оценки проблематично, см. Оценка точности оценок . Сильная самоуверенность в точности оценок усилий иллюстрируется выводом о том, что в среднем, если профессионал в области программного обеспечения на 90% уверен или «почти уверен» в том, что он включит фактические усилия в минимальный-максимальный интервал, наблюдаемая частота включения фактическое усилие составляет всего 60-70%.

В настоящее время термин « оценка усилий » используется для обозначения различных концепций, таких как наиболее вероятное использование усилий (модальное значение), усилие, которое соответствует вероятности 50% непревышения (медиана), запланированное усилие, запланированное усилие. или усилие, используемое для предложения клиенту ставки или цены. Это считается неудачным, потому что могут возникнуть проблемы с коммуникацией и потому, что концепции служат разным целям.

История

Исследователи и практики программного обеспечения занимаются проблемами оценки трудозатрат для проектов разработки программного обеспечения, по крайней мере, с 1960-х годов; см., например, работу Фарра и Нельсона.

Большая часть исследований была сосредоточена на построении формальных моделей оценки усилий по программному обеспечению. Ранние модели обычно основывались на регрессионном анализе или математически выводились из теорий из других областей. С тех пор было оценено большое количество подходов к построению моделей, таких как подходы, основанные на рассуждениях на основе конкретных случаев , деревья классификации и регрессии , моделирование , нейронные сети , байесовская статистика , лексический анализ спецификаций требований, генетическое программирование , линейное программирование , экономическое производство. модели, мягкие вычисления ,нечеткое логическое моделирование, статистический бутстрэппинг и комбинации двух или более из этих моделей. Пожалуй, наиболее распространенными методами оценки сегодня являются модели параметрической оценки COCOMO , SEER-SEM и SLIM. Они основаны на оценочных исследованиях, проведенных в 1970-х и 1980-х годах, и с тех пор обновляются новыми данными калибровки, причем последним крупным выпуском является COCOMO II в 2000 году. Подходы к оценке основаны на функциональных показателях размера, например функции баллов , также основан на исследованиях, проведенных в 1970-х и 1980-х годах, но повторно откалиброван с использованием модифицированных мер размера и различных подходов к подсчету, таких как точки варианта использования [11] или объектные точки в 1990-е гг.

Подходы к оценке

Есть много способов категоризации подходов к оценке, см., Например.Категории верхнего уровня:

• Экспертная оценка: этап количественной оценки, т. Е. Этап, на котором оценка производится на основе оценочных процессов.
• Формальная модель оценки: этап количественной оценки основан на механических процессах, например, использовании формулы, полученной на основе исторических данных.
• Комбинированная оценка: этап количественной оценки основан на субъективной и механической комбинации оценок из разных источников.

Ниже приведены примеры подходов к оценке в каждой категории.

Выбор подходов к оценке

Данные о различиях в точности оценки различных подходов и моделей оценки предполагают, что не существует «наилучшего подхода» и что относительная точность одного подхода или модели по сравнению с другим сильно зависит от контекста. Это означает, что разные организации извлекают выгоду из разных подходов к оценке. Результаты , которые могут поддержать выбор метода оценки на основе ожидаемой точности подхода, включают:

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

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

Важно знать об ограничениях каждого традиционного подхода к измерению производительности разработки программного обеспечения. [22]

Кроме того, в процессе выбора следует учитывать другие факторы, такие как легкость понимания и передачи результатов подхода, простота использования подхода и стоимость внедрения подхода.

Оценка точности оценок Наиболее распространенной мерой средней точности оценки является MMRE (средняя величина относительной ошибки), где MRE каждой оценки определяется как:

MRE =

Эта мера подвергалась критике , и есть несколько альтернативных мер, таких как более симметричные меры, [26] Средневзвешенное значение квартилей относительных ошибок (WMQ) и Среднее отклонение от оценки (MVFE). ).

MRE не является надежным, если отдельные элементы перекошены. PRED (25) предпочтительнее в качестве меры точности оценки. PRED (25) измеряет процент предсказанных значений, которые находятся в пределах 25 процентов от фактического значения.

Высокая ошибка оценки не может автоматически интерпретироваться как индикатор низкой способности оценки. Альтернативные, конкурирующие или дополняющие причины включают в себя низкую стоимость контроля над проектом, высокую сложность разработки и большую функциональность, чем первоначально предполагалось. Структура для улучшенного использования и интерпретации измерения ошибки оценки включена в

Психологические проблемы

Существует множество психологических факторов, потенциально объясняющих сильную тенденцию к чрезмерно оптимистичным оценкам усилий, которые необходимо учитывать, чтобы повысить точность оценок усилий. Эти факторы важны даже при использовании формальных моделей оценки, поскольку большая часть входных данных для этих моделей основывается на суждениях. Доказано, что важны следующие факторы: принятие желаемого за действительное , привязка , ошибка планирования и когнитивный диссонанс . Обсуждение этих и других факторов можно найти в работе Йоргенсена и Гримстада.

• Легко оценить то, что вы знаете.
• Трудно оценить то, что вы знаете, чего не знаете. (известные неизвестные)
• Очень сложно оценить то, чего вы не знаете, чего не знаете. (неизвестные неизвестные)

Юмор

Хроническая недооценка усилий по разработке привела к появлению и популярности множества юмористических пословиц, таких как ироничное обращение к задаче как к « небольшому вопросу программирования » (когда, вероятно, требуется много усилий) и цитирование законов о недооценке:

• Правило девяноста девяноста :

Первые 90 процентов кода составляют первые 90 процентов времени разработки. Остальные 10 процентов кода составляют остальные 90 процентов времени разработки. ^[31]

-  Том Каргилл, Bell Labs

• Закон Хофштадтера :

Закон Хофштадтера: это всегда занимает больше времени, чем вы ожидаете, даже если принять во внимание закон Хофштадтера.

-  Дуглас Хофштадтер , Гедель, Эшер, Бах: вечная золотая коса ^[32]

• Закон Фреда Брукса :

То, что один программист может сделать за один месяц, два программиста могут сделать за два месяца.

-  Фред Брукс

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

Сравнение программ оценки разработки

Что скажете по поводу изложенного подхода? Что вам мешает в ваших проектах использовать этот подход?

Жду комментариев и до встречи в эфире!

Вау!! 😲 Ты еще не читал? Это зря!

• оценка трудоемкости , оценка сроков разработки по ,
• эустресс и производительность труда
• Конус неопределенности
• Оценка затрат в программной инженерии
• Модели оценки затрат
• Перерасход
• Функциональные точки
• Ошибка планирования
• Оценка на основе прокси
• Модель Патнэма
• Модель Патнэма Путнема
• Метрика программного обеспечения
• Программные параметрические модели
• Оценка затрат в программной инженерии
• Превышение запланированных расходов
• функциональная точка
• Proxy-based estimating
• Дедлайн (от англ. deadline)

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

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.