Погрешность при оценке небольших программных проектов

Максим Дорофеев

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

В большинстве случаев трудозатраты на получение оценки высокой точности сравнимы с

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

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

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

даны рекомендации по выбору подхода к планированию небольшого программного проекта.

Введение Согласно классической теории управления проектами, проект считается успешно выполненным,

если он:

1. Выполнен в рамках бюджета.

2. Выполнен в срок.

3. Выполнен в соответствии со спецификациям (функционал реализован в полном объеме).

Если мы не рассматриваем сложных комплексных проектов, а ограничиваемся проектами, целью

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

равен затратам на оплату труда, то есть бюджет и сроки связаны линейно:

Где обозначает срок проекта, а – затраты на оплату труда команды.

Затраты на оплату труда команды, как правило, известны (если даже в компании не принято

оперировать деньгами на уровне руководителей небольших проектов, то бюджет определяется в

человеко-часах). Зная объем работ, не сложно определить длительность проекта, при наличии

информации о производительности:

Здесь и обозначают трудозатраты на проект и производительность команды

соответственно.

Трудозатраты на проект определяются из объема требуемого функционала. На этом этапе многие

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

трудозатратами и размером проекта линейной, тем самым попадая в ловушку т.н. diseconomy of

scale. На самом деле связь между трудозатратами и размером проекта является нелинейной [1]:

где

1. – трудозатраты на проект,

2. – переменная, описывающая способность команды выполнить проект,

3. – окружающая среда проекта, состоящая из инструментария,

поддерживающего процесс разработки,

4. – качество конечного продукта,

5. – размер проекта,

6. – величина, характеризующая эффективность процесса.

Здесь величина – показателя экспоненты – является величиной не меньше единицы. Этот

факт пока еще никто не ставил под сомнение. Мало того, самое большее, на что пытаются

претендовать эксперты с мировым именем – это [2]. Однако, процесс с

показателем близким к единице является скорее исключением, чем правилом, и рождается в

ходе долгого и непрерывного совершенствования. Существуют сомнения, что полученный

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

Соотношение показывает одно из радикальных отличий разработки программного

обеспечения от материального производства, где существует такое понятие, как экономия

масштаба (что в переводе на язык формул означает ). На более простом языке – чем

больше ПО необходимо разработать, тем дороже обходится создание каждой единицы ПО. Это

похоже на прогрессирующую ставку транспортного налога – чем больше мощность двигателя

автомобиля, тем дороже обходится каждая лошадиная сила. В случае с автомобилем, как и в

разработке ПО, невозможно избежать дополнительных трат на мощный автомобиль, купив два

автомобиля с двигателями меньшей мощности. Затраты на интеграцию все равно сведут всю

экономию на нет.

Как говорилось выше, мы будем рассматривать исключительно маленькие проекты, как по

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

процесса разработки, окружающей среды проекта и профессионализма команды за время

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

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

не менее, будем считать, что между и существует однозначная, пусть и не

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

разработке ПО, в значительной степени определяются политикой компании и руководитель

небольшого проекта не способен оказать существенное влияние на них за время выполнения

проекта.

Сделав все эти предположения, мы избавились от величин, объективное измерение которых

является темой самых оживленных дискуссий. В этом случае критерий успешности проекта будет

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

контролем менеджера проекта, и каждую можно объективно измерить достаточно простыми

способами:

1.

2.

3.

4.

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

Задача менеджера проекта на этапе оценки сводится к нахождению значений остальных

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

внимание тот факт, что и является функцией числа человек в команде, то

процесс оценки проекта сводится, к одной из двух задач:

1. Определение размера команды, исходя из объема работ и сроков.

2. Определение длительности проекта, исходя из объема работ и состава команды.

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

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

соблюдении ряда условий, вторая задача будет иметь достаточно устойчивое в математическом

смысле решение.

Определение состава команды при известном объеме работ В любом процессе разработки ПО существует больше одной роли. Ниже мы будем рассматривать

задачу определения числа членов команды только для одной роли. Для оценки числа человек,

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

Будем считать, что нам известен размер проекта. Пусть за месяцев требуется реализовать

единиц ПО (здесь и далее под единицей ПО подразумевается любая из известных метрик: SLOC,

Functional Point, Story Points, и т.д.). Такое утверждение является достаточно смелым, так как в

самом начале проекта погрешность определения может достигать 100% [3]. Тем не менее,

будем считать, что объем работ нам известен заранее с очень высокой точностью – даже в этом

случае задача определения размера команды будет крайне не простой.

Будем считать, что нам известна средняя производительность потенциального члена команды и

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

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

что:

В итоге задача свелась к поиску ответа на вопрос: сколько человек со средней

производительностью 50 единиц ПО в месяц требуется набрать в команду, что бы создать

единиц программного обеспечения за месяцев? Простота этой задачи, на самом деле,

иллюзорна. Наивный подход к решению этой задачи сводится к формуле:

С учетом наших цифр .

Несостоятельность такого подхода заключается в том, что неявно член команды трактуется как

универсальный «ресурс», с минимальной вариацией производительности от «экземпляра» к

«экземпляру». Это в корне не верно. Фредерик Брукс утверждает, что производительность даже

опытных разработчиков может варьироваться в 10 раз [4]. Кроме того, основываясь на работах

Сергея Архипенкова [5], можно утверждать, что производительность одного и того же

разработчика может изменяться в 10 раз в зависимости от среды и условий работы. Все это не

позволяет относиться к людям как к ресурсу, по крайней мере, в небольшой команде.

Проиллюстрируем это на сильно упрощенном примере. Будем считать, что разработчики бывают

только двух типов: эффективные и неэффективные. В реальной жизни степень их эффективности

может принимать и промежуточные значения, но это только усложнит рассмотрение примера, не

меняя основного вывода.

Предположим, что в нашей компании работает 1000 разработчиков. Из них 100 эффективных (с

производительностью 230 единиц ПО в месяц) и 900 не эффективных (с производительностью 30

единиц ПО в месяц). Средняя производительность в этом случае будет равна 50. Выбор четырех

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

команду, от 0 до 4. Вероятность каждого из этих исходов определяется при помощи

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

Число «эффективных» разработчиков

Вероятность исхода

Производительность команды

Средняя производительность

разработчика

Прогнозируемая длительность проекта, мес.

0 66% 120 30 8,3

1 29% 320 80 3,1

2 5% 520 130 1,9

3 0% 720 180 1,4

4 0% 920 230 1,1

Из таблицы видно, что с вероятностью 66% в команде не окажется ни одного «эффективного»

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

длительность проекта превысит требуемую более чем в два раза.

Результаты, приведенные в таблице, являются оптимистичными, так как при расчете

производительности команды было сделано очень смелое и заранее неверное предположение –

производительность команды равна сумме производительностей каждого человека. На самом

деле производительность «эффективного» разработчика будет заметно ниже, если он попадет в

команду из 3-х «неэффективных» [5] в результате чего картина становится еще боле

пессимистичной.

С ростом размера команды разброс усредненной по команде производительности снижается.

Если в команде из 4-х человек средняя производительность может отличаться практически в 3

раза (от 30 до 80 единиц ПО в месяц), то в команде из 50 человек средняя производительность

окажется в пределах от 38 до 66 единиц ПО в месяц (с вероятностью 95%). Если же в команду

входит 100 человек, то с вероятностью 95% средняя производительность будет находиться в

пределах от 40 до 60. В случае команды из 200 человек с той же вероятностью средняя

производительность находится в диапазоне от 44 до 56 (что уже составляет ).

Уменьшение разброса производительности «среднего» разработчика с ростом размера команды,

объясняет, почему в компаниях, где ведутся соответствующие измерения, дисперсия

производительности может оказаться небольшой. Если измерения производятся на достаточно

больших проектах, то среднеквадратичное отклонение производительности будет ниже своего

реального значения.

Таким образом, в случае маленькой команды естественным образом возникает ошибка

определения производительности в сотни процентов. Эта ошибка является неизбежной, и

возникает в силу двух факторов:

1. Производительность даже опытных разработчиков может отличаться в десятки раз.

2. Производительность одного и того же разработчика может варьироваться в десятки раз в

зависимости от окружающей среды.

3. Эффективных разработчиков в разы меньше, чем не эффективных.

К ошибке определения производительности стоит добавить еще одну ошибку планирования,

присущую программным проектам по самой их природе – неопределенность объема работ,

достигающая 100% на ранних этапах. Кроме того, мы специально упростили задачу, предположив,

что производительность команды равна сумме производительностей отдельных ее членов. В

общем случае это совсем не так, в реальности производительность команды может быть как и

ниже, так и выше суммы производительностей ее членов, что вносит еще большую

неопределенность. Мы так же не учли, что «эффективность» каждого отдельно взятого

сотрудника сильно зависит как от самого проекта, так и от его окружающей среды (включая

прочих членов команды).

Таким образом, при оценке небольшого проекта необходимо понимать, что существуют

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

проектов. Строгого и изящного с математической точки зрения метода, при помощи которого

можно было бы дать оценку небольшого проекта с высокой точностью, не существует.

Менеджеру, перед которым стоит определить размер команды можно дать лишь два совета:

1. Не оперировать абстрактными людьми. В маленьких проектах рассматривать людей как

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

четко понимать, кто на что способен, и кто с кем может эффективно работать.

Человеческий фактор в небольших проектах играет решающую роль.

2. Размер команды стоит определять исходя больше из догадок об эффективности команды,

собственных убеждений и опыта. Запуская проект, нужно понимать, что ошибка в оценке

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

пересмотреть планы. Однако при коррекции планов следует отдать предпочтение

изменению сроков, а не составу команды [4].

Согласно второму совету, после начала проекта необходимо заново пройти процесс оценки.

Только в этом случае задача будет заключаться в определении новых сроков проекта при заранее

известном составе команды. Подробно эта задача рассматривается в следующем разделе.

Определение сроков проекта при наличии стабильной команды Изложенный ниже метод дает адекватные результаты только при строгом соблюдении

следующих условий:

1. Процесс разработки итеративен и инкрементален [6]. То есть, процесс создания

программного продукта состоит из серии итераций равной длины, и результатом каждой

итерации является очередной прирост функционала продукта.

2. Состав команды стабилен на протяжении всего срока проекта (лучше, если у команды уже

есть опыт совместной работы на аналогичных проектах).

3. Заказчик (лицо отвечающее за приемку продукта) существует в единственном лице,

учавствует в регулярном процессе валидации и не меняется по ходу проекта.

Эти условия являются достаточно строгими, но даже в этом случае мы не сможем определить

точную дату поставки. Точную дату завершения програмного проекта (как впрочем и любого

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

степенью вероятности [7]. Поэтому решением задачи об определении даты завершения проекта

мы будем называть функцию плотности распределения вероятности даты поставки.

Общий вид итеративного процесса разработки изображен на Рис. 1. Существует определенный

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

в единицах ПО (например в функциональных точках или Story Points). В каждую итерацию

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

потенциально готовый к поставке продукт. Под продуктом, потенциально готовым к поставке,

имеется ввиду продукт, в котором весь функционал, реализованный за итерацию интегрирован,

протестирован и получил одобрение со стороны заказчика.

В конце итерации полученный продукт демонстрируется заказчику с целью валидации. По

результатам демонстрации заказчик добавляет к общему списку функционала дополнительные

пожелания объемом .

Рис. 1 Итеративный процесс разработки

и в общем случае являются случайными величинами, однако, в отличии от

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

среднеквадратичное отклонение этих величин достаточно небольшое.

Для определения плотности распределения вероятности даты поставки нам необходимо иметь

исторические данные для конкретной команды и данного конкретного заказчика. Если команда

уже сработалась, и заказчик у команды один и тот же, то данные о и можно брать из

истории предыдущих проектов. Если команда имеет опыт совместной работы, но с закащиком

текущего рпоекта команда не работала, то для дальнейшего анализа можно использовать как

минимум исторические данные об , а параметры распределения можно оценить

экспертно.

Если же команда только формируется под проект, то единственным вариантом получить оценку

будет решение задачи из предыдущего раздела. Однако спустя 3-5 итераций, уже можно считать,

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

Будем считать, что величины и являются случайными величинами,

распределенными по нормальному закону, то есть:

Где и – функции плотности распределения величин и . Нормальное

распределение характеризуется двумя величинами: средним значением и среднеквадратичным

отклонением ( , и , соответственно).

Параметры нормального распределения определяются по формулам:

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

параметров распределения. Вид формул для и будет аналогичным.

Изменение объема оставшейся работы за одну итерацию определяется как разница между

количеством выполненной работы и работы, добавленной по результатам демонстрации

очередного инкремента заказчику:

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

распределенной случайной величиной с функцией распределения:

Где и

Таким образом, за итераций объем оставшейся работы изменится на величину с функцией

плотности распределения:

Качественный вид этой функции для различного числа итераций показан на Рис. 2. С ростом числа

итераций наиболее вероятный объем выполненной работы увеличивается, но вместе с этим

распределение становится более размытым, что говорит об увеличении погрешности в

определении объема выполненной работы. То есть, чем более далекое будущее мы пытаемся

предсказать, тем менее точными становятся наши прогнозы, что вполне естественно.

Рис. 2 Качественный вид функции распределения

Итого, на данном этапе мы можем предсказать, с какой вероятностью команда выполнит

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

«С какой вероятностью команда создаст функционала за итераций?». Для того, что

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

больше или равно . Из курса математической статистики известно, что эта вероятность

вычисляется как:

Где – кумулятивная функция нормального распределения.

Проиллюстрируем применение этого метода на примере одного реального проекта. После шести

недельных итераций были доступны следующие измерения (все измерения проводились в Story

Points [8]):

8 7 69

12 8 65

9 8 64

13 6 57

8 3 52

11 5 46

На основании этих данных были рассчитаны функция плотности и кумулятивное распределение

вероятности для даты поставки (см. Рис. 3).

Рис. 3 Функция плотности и кумулятивное распределение даты поставки

Из графика видно, что наиболее вероятный номер завершающей итерации – 14. Однако

вероятность завершить проект до 14-й итерации включительно равнялась примерно 60%.

Фактически проект был завершен после 16-й итерации, где значение кумулятивной функции

распределения равнялось 80%.

Заключение При планировании небольших программных проектов, когда число членов команды и измеряется

единицами, а срок не превышает 2-3 месяцев, естественным образом возникает огромная

неопределенность, подобно квантовым эффектам в микромире. При формировании команды «с

нуля» под очередной небольшой проект достоверно оценить число разработчиков невозможно

по фундаментальным причинам.

Наибольшая точность оценки достигается в случае слаженной команды, следующей итеративной

и инкрементальной стратегии разработки ПО, когда имеются данные об ее производительности в

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

накладываемых на команду и используемую методологию, невозможно получить точную дату

поставки на ранних этапах (а уж тем более в самом начале проекта).

Метод оценки функции распределения даты поставки, изложенный выше, используется автором в

повседневной работе при управлении небольшими проектами. Пример электронной таблицы для

расчетов можно найти в блоге автора Ошибка! Источник ссылки не найден..

Литература [1] Walker Royce, “Software Project Management. A Unified Framework”, Addison-Wesley, 2000

(Перевод: Уокер Ройс, Управление проектами по созданию программного обеспечения,

Лори, 2007).

[2] J. Sutherland, A. Viktorov, J. Blount, and N. Puntikov, "Distributed Scrum: Agile Project

Management with Outsourced Development Teams," in HICSS'40, Hawaii International

Conference on Software Systems, Big Island, Hawaii, 2007.

[3] G. Stepanek, “Software Projects Secrets. Why Software Projects Fail”, Apress, 2005.

[4] F. P. Brooks, Jr., “The Mythical Man-Month. Essays on Software Engineering”, Addison-Wesley,

2002 (Перевод: Ф. Брукс, «Мифический человеко-месяц или как создаются программные

системы», Символ-Плюс, 2006).

[5] С. Архипенков, «Руководство командой разработчиков программного обеспечения.

Прикладные мысли», Москва, 2008

(http://www.arkhipenkov.ru/resources/sw_team_management.pdf).

[6] C. Larman, “Agile and Iterative Development: Manager’s Guide”, Addison-Wesley, 2003

[7] T. DeMarco, T. Lister, “Waltzing with bears. Managing Risk On Software Projects”, Dorset House

Publishing Company, 2003 (Перевод: Т. ДеМарко, Т. Листер, Вальсируя с медведями:

управление рисками в проектах по разработке программного обеспечения, Компания

p.m.Office, 2005).

[8] K. Schwaber, “Agile project management with Scrum”, Microsoft Press, 2004

[9] http://cartmendum.livejournal.com/75371.html