Объемы работ

[Денис]

Добрый день!
Столкнулся с такой проблемой, есть план график по разработке ПО. где все работы по типу "Длительность". Длительность работ определили исходя из своего опыта, по прошлым проектам. а вот с определением объема работ возникла сложность, не понимаем, что брать за единицу. было принято решение объем оценивать в процентах, полный объем работы 100%. тут возникла другая проблема, как во время учета определить объем выполненной работы. Спасибо!

[Владимир Либерзон]

Денис,
это известная проблема, по которой проводятся международные конференции и работают исследователи.
Строчки кода не лучший вариант, ряде западных фирм используют function points, можно придумать и свои внутренние измерители.
Объем нужен для нормирования прежде всего. Если же говорить об учете, то если модель детальная, то ошибки не будут сильно накапливаться и можно исполнение мерять в процентах.
Но полезно иметь измеритель для оценки плановой длительности работ в соответствии с корпоративными стандартами.
Один из подходов - на основании прошлого опыта оценить реальную трудоемкость той или иной работы и от чего она зависит. То есть оценить трудоемкость стандартной работы и те коэффициенты, которые следует применять. Далее оценить производительности своих работников по сравнению с использованным эталоном (кто-то работает быстрее, кто-то медленнее) и использовать их в расчетах (и базах производительности ресурсов на типовых работах). Повышение производительности следует мотивировать (это сокращает стоимость разработки).
Подумайте об объемах именно с точки зрения нормирования - а уж измерение исполнения может быть следствием вашего решения.

[Алексей]

Если у Вас например план 100% равняется 400 кубов кладки, то если Вы выполнили 100 кубов, то работа выполнена на 25%.
Заведите себе поля (пользовательские) с объемами, там и делайте пересчет по формуле

[Денис]

да со строительными проектами все понятно, м,м2,м3. а вот при разработке ПО, не понятно что с чем сравнивать. есть только длительность, которую я прикидываю с учетом других проектов. а вот как оценить в чем измерять объем, не очень.... соответственно возникает проблема, как контролировать работу. Мне от программистов приходит отчет, где написано, что выполнено 20%, а я не знаю, что такое эти проценты и почему 20, а не 30,40,50.

[Алексей]

можно измерять в строчках кода, а можно в трудозатратах

[Константин Ефремов]

В строчках кода (как и в килобайтах кода) измерять трудоёмкость, очевидно, совершенно бессмысленно. Простейший пример: при создании диалоговых форм современные Visual-средства автоматически создадут вам огромный (и, кстати, очень избыточный) код при минимальных затратах труда и времени. А вот сложный алгоритм размером в пару килобайт кода иногда требует в десятки раз больше и труда, и времени. Можно множество других примеров привести.
Трудоёмкость сильно зависит от вида работы. Тупое кодирование известных алгоритмов или формирование визуальных форм - это одно, разработка новых алгоритмов - другое, разработка сложных внутренних структур данных - третье.
Так что единственный хороший способ оценки труда программиста (а также процента исполнения) - это экспертная оценка на основании прежнего опыта, которую осуществляет руководитель группы разработчиков, который сам - бывший (или не бывший) программист с большим опытом, и который заинтересован (официально мотивирован руководством) в сокращении времени разработки (а значит и затрат).
Что касается метода Function Points, то он может быть использован для весьма приближённой оценки больших ПО-проектов, но автору этого топика нужна оценка работы одного программиста и к тому же процента исполнения, а не всей работы.

Function Points — функциональные точки как метрика программного продукта — количественный показатель, предложенный сотрудником IBM Аланом Альбрехтом (Allan Albrecht) в 1979 г.; служит наиболее удачной заменой количеству строк кода (LOC) для оценки необходимых трудозатрат при разработке ПО. Оценка сложности и трудоёмкости крупных программных разработок по функциональным точкам (function point analysis, FPA) может быть выполнена на самых ранних стадиях работы над проектом и далее уточняться по ходу жизненного цикла; в контексте анализа требований к программной системе функциональная точка — это отдельное поведение, видимое извне и поддающееся проверке.

Есть ещё хороший обзор:
http://www.pmprofy.ru/content/rus/79/797-article.asp