Погрешность при оценке небольших       программных проектов                                                               ...
где      1.          – трудозатраты на проект,      2.             – переменная, описывающая способность команды выполнить...
4.Как правило, значения одного или нескольких из этих параметров являются требованием извне.Задача менеджера проекта на эт...
Несостоятельность такого подхода заключается в том, что неявно член команды трактуется какуниверсальный «ресурс», с минима...
производительности может оказаться небольшой. Если измерения производятся на достаточнобольших проектах, то среднеквадрати...
1. Процесс разработки итеративен и инкрементален [6]. То есть, процесс создания      программного продукта состоит из сери...
Рис. 1 Итеративный процесс разработки       и      в общем случае являются случайными величинами, однако, в отличии отпрои...
Где       и         – функции плотности распределения величин          и         . Нормальноераспределение характеризуется...
Рис. 2 Качественный вид функции распределенияИтого, на данном этапе мы можем предсказать, с какой вероятностью команда вып...
На основании этих данных были рассчитаны функция плотности и кумулятивное распределениевероятности для даты поставки (см. ...
Литература  [1] Walker Royce, “Software Project Management. A Unified Framework”, Addison-Wesley, 2000        (Перевод: Уо...
Upcoming SlideShare
Loading in...5
×

PM Magazine 2009

2,221

Published on

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

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,221
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
70
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "PM Magazine 2009"

  1. 1. Погрешность при оценке небольших программных проектов Максим Дорофеев АннотацияПроекты по разработке программного обеспечения известны своей слабой предсказуемостью.В большинстве случаев трудозатраты на получение оценки высокой точности сравнимы струдозатратами на сам проект. В случае небольших программных проектов ситуацияусугубляется фундаментальными причинами, не позволяющими снизить погрешность оценкидо приемлемого уровня. В статье рассмотрена природа этих фундаментальных причин, иданы рекомендации по выбору подхода к планированию небольшого программного проекта.ВведениеСогласно классической теории управления проектами, проект считается успешно выполненным,если он: 1. Выполнен в рамках бюджета. 2. Выполнен в срок. 3. Выполнен в соответствии со спецификациям (функционал реализован в полном объеме).Если мы не рассматриваем сложных комплексных проектов, а ограничиваемся проектами, цельюкоторых является только создание программного продукта, то бюджет такого проекта практическиравен затратам на оплату труда, то есть бюджет и сроки связаны линейно:Где обозначает срок проекта, а – затраты на оплату труда команды.Затраты на оплату труда команды, как правило, известны (если даже в компании не принятооперировать деньгами на уровне руководителей небольших проектов, то бюджет определяется вчеловеко-часах). Зная объем работ, не сложно определить длительность проекта, при наличииинформации о производительности:Здесь и обозначают трудозатраты на проект и производительность командысоответственно.Трудозатраты на проект определяются из объема требуемого функционала. На этом этапе многиедаже опытные менеджеры допускают распространенную ошибку, полагая зависимость междутрудозатратами и размером проекта линейной, тем самым попадая в ловушку т.н. diseconomy ofscale. На самом деле связь между трудозатратами и размером проекта является нелинейной [1]:
  2. 2. где 1. – трудозатраты на проект, 2. – переменная, описывающая способность команды выполнить проект, 3. – окружающая среда проекта, состоящая из инструментария, поддерживающего процесс разработки, 4. – качество конечного продукта, 5. – размер проекта, 6. – величина, характеризующая эффективность процесса.Здесь величина – показателя экспоненты – является величиной не меньше единицы. Этотфакт пока еще никто не ставил под сомнение. Мало того, самое большее, на что пытаютсяпретендовать эксперты с мировым именем – это [2]. Однако, процесс споказателем близким к единице является скорее исключением, чем правилом, и рождается входе долгого и непрерывного совершенствования. Существуют сомнения, что полученныйпроцесс можно легко и без значительной переработки переносить из команды в команду.Соотношение показывает одно из радикальных отличий разработки программногообеспечения от материального производства, где существует такое понятие, как экономиямасштаба (что в переводе на язык формул означает ). На более простом языке – чембольше ПО необходимо разработать, тем дороже обходится создание каждой единицы ПО. Этопохоже на прогрессирующую ставку транспортного налога – чем больше мощность двигателяавтомобиля, тем дороже обходится каждая лошадиная сила. В случае с автомобилем, как и вразработке ПО, невозможно избежать дополнительных трат на мощный автомобиль, купив дваавтомобиля с двигателями меньшей мощности. Затраты на интеграцию все равно сведут всюэкономию на нет.Как говорилось выше, мы будем рассматривать исключительно маленькие проекты, как посрокам, так и по составу команды. В этом случае можно пренебречь влиянием измененийпроцесса разработки, окружающей среды проекта и профессионализма команды за времявыполнения проекта. Введем достаточно смелое предположение, что уровень качества конечногопродукта однозначно определяется процессом. Это утверждение является очень спорным, но, темне менее, будем считать, что между и существует однозначная, пусть и неизвестная заранее зависимость. Также будем считать, что процессы, используемые приразработке ПО, в значительной степени определяются политикой компании и руководительнебольшого проекта не способен оказать существенное влияние на них за время выполненияпроекта.Сделав все эти предположения, мы избавились от величин, объективное измерение которыхявляется темой самых оживленных дискуссий. В этом случае критерий успешности проекта будетопределяться функцией четырех независимых переменных, каждая из которых находится подконтролем менеджера проекта, и каждую можно объективно измерить достаточно простымиспособами: 1. 2. 3.
  3. 3. 4.Как правило, значения одного или нескольких из этих параметров являются требованием извне.Задача менеджера проекта на этапе оценки сводится к нахождению значений остальныхпараметров таким образом, что бы удовлетворить критерию успешности проекта. Если принять вовнимание тот факт, что и является функцией числа человек в команде, топроцесс оценки проекта сводится, к одной из двух задач: 1. Определение размера команды, исходя из объема работ и сроков. 2. Определение длительности проекта, исходя из объема работ и состава команды.Ниже мы подробно рассмотрим каждую из этих задач. Первая задача является самой сложной, иобладает наибольшим количеством подводных камней. Забегая вперед, можно сказать, что присоблюдении ряда условий, вторая задача будет иметь достаточно устойчивое в математическомсмысле решение.Определение состава команды при известном объеме работВ любом процессе разработки ПО существует больше одной роли. Ниже мы будем рассматриватьзадачу определения числа членов команды только для одной роли. Для оценки числа человек,выполняющей другую роль выводы этого раздела будут аналогичными.Будем считать, что нам известен размер проекта. Пусть за месяцев требуется реализоватьединиц ПО (здесь и далее под единицей ПО подразумевается любая из известных метрик: SLOC,Functional Point, Story Points, и т.д.). Такое утверждение является достаточно смелым, так как всамом начале проекта погрешность определения может достигать 100% [3]. Тем не менее,будем считать, что объем работ нам известен заранее с очень высокой точностью – даже в этомслучае задача определения размера команды будет крайне не простой.Будем считать, что нам известна средняя производительность потенциального члена команды исреднеквадратичное отклонение этой величины . Далее, чтобы не прятать суть за изяществомматематических выкладок, будем оперировать конкретными цифрами. А именно, будем считать,что:В итоге задача свелась к поиску ответа на вопрос: сколько человек со среднейпроизводительностью 50 единиц ПО в месяц требуется набрать в команду, что бы создатьединиц программного обеспечения за месяцев? Простота этой задачи, на самом деле,иллюзорна. Наивный подход к решению этой задачи сводится к формуле:С учетом наших цифр .
  4. 4. Несостоятельность такого подхода заключается в том, что неявно член команды трактуется какуниверсальный «ресурс», с минимальной вариацией производительности от «экземпляра» к«экземпляру». Это в корне не верно. Фредерик Брукс утверждает, что производительность дажеопытных разработчиков может варьироваться в 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 (что уже составляет ).Уменьшение разброса производительности «среднего» разработчика с ростом размера команды,объясняет, почему в компаниях, где ведутся соответствующие измерения, дисперсия
  5. 5. производительности может оказаться небольшой. Если измерения производятся на достаточнобольших проектах, то среднеквадратичное отклонение производительности будет ниже своегореального значения.Таким образом, в случае маленькой команды естественным образом возникает ошибкаопределения производительности в сотни процентов. Эта ошибка является неизбежной, ивозникает в силу двух факторов: 1. Производительность даже опытных разработчиков может отличаться в десятки раз. 2. Производительность одного и того же разработчика может варьироваться в десятки раз в зависимости от окружающей среды. 3. Эффективных разработчиков в разы меньше, чем не эффективных.К ошибке определения производительности стоит добавить еще одну ошибку планирования,присущую программным проектам по самой их природе – неопределенность объема работ,достигающая 100% на ранних этапах. Кроме того, мы специально упростили задачу, предположив,что производительность команды равна сумме производительностей отдельных ее членов. Вобщем случае это совсем не так, в реальности производительность команды может быть как иниже, так и выше суммы производительностей ее членов, что вносит еще большуюнеопределенность. Мы так же не учли, что «эффективность» каждого отдельно взятогосотрудника сильно зависит как от самого проекта, так и от его окружающей среды (включаяпрочих членов команды).Таким образом, при оценке небольшого проекта необходимо понимать, что существуютфундаментальные причины, не позволяющие приблизить точность оценки к оценкам большихпроектов. Строгого и изящного с математической точки зрения метода, при помощи которогоможно было бы дать оценку небольшого проекта с высокой точностью, не существует.Менеджеру, перед которым стоит определить размер команды можно дать лишь два совета: 1. Не оперировать абстрактными людьми. В маленьких проектах рассматривать людей как «ресурс» нельзя. Необходимо знать всех потенциальных членов команды по именам, четко понимать, кто на что способен, и кто с кем может эффективно работать. Человеческий фактор в небольших проектах играет решающую роль. 2. Размер команды стоит определять исходя больше из догадок об эффективности команды, собственных убеждений и опыта. Запуская проект, нужно понимать, что ошибка в оценке была неизбежна, а пройдя первый значимый рубеж проекта, обязательно стоит пересмотреть планы. Однако при коррекции планов следует отдать предпочтение изменению сроков, а не составу команды [4].Согласно второму совету, после начала проекта необходимо заново пройти процесс оценки.Только в этом случае задача будет заключаться в определении новых сроков проекта при заранееизвестном составе команды. Подробно эта задача рассматривается в следующем разделе.Определение сроков проекта при наличии стабильной командыИзложенный ниже метод дает адекватные результаты только при строгом соблюденииследующих условий:
  6. 6. 1. Процесс разработки итеративен и инкрементален [6]. То есть, процесс создания программного продукта состоит из серии итераций равной длины, и результатом каждой итерации является очередной прирост функционала продукта. 2. Состав команды стабилен на протяжении всего срока проекта (лучше, если у команды уже есть опыт совместной работы на аналогичных проектах). 3. Заказчик (лицо отвечающее за приемку продукта) существует в единственном лице, учавствует в регулярном процессе валидации и не меняется по ходу проекта.Эти условия являются достаточно строгими, но даже в этом случае мы не сможем определитьточную дату поставки. Точную дату завершения програмного проекта (как впрочем и любогодругого) предсказать невозможно, любая дата может быть датой поставки с той или инойстепенью вероятности [7]. Поэтому решением задачи об определении даты завершения проектамы будем называть функцию плотности распределения вероятности даты поставки.Общий вид итеративного процесса разработки изображен на Рис. 1. Существует определенныйсписок функционала, который необходимо разработать ( ). Величина измеряетсяв единицах ПО (например в функциональных точках или Story Points). В каждую итерациюкоманда реализует функционала (где обозначает номер итерации), получая на выходепотенциально готовый к поставке продукт. Под продуктом, потенциально готовым к поставке,имеется ввиду продукт, в котором весь функционал, реализованный за итерацию интегрирован,протестирован и получил одобрение со стороны заказчика.В конце итерации полученный продукт демонстрируется заказчику с целью валидации. Порезультатам демонстрации заказчик добавляет к общему списку функционала дополнительныепожелания объемом .
  7. 7. Рис. 1 Итеративный процесс разработки и в общем случае являются случайными величинами, однако, в отличии отпроизводительности отдельно взятого разработчика, для зрелых и стабильных командсреднеквадратичное отклонение этих величин достаточно небольшое.Для определения плотности распределения вероятности даты поставки нам необходимо иметьисторические данные для конкретной команды и данного конкретного заказчика. Если командауже сработалась, и заказчик у команды один и тот же, то данные о и можно брать изистории предыдущих проектов. Если команда имеет опыт совместной работы, но с закащикомтекущего рпоекта команда не работала, то для дальнейшего анализа можно использовать какминимум исторические данные об , а параметры распределения можно оценитьэкспертно.Если же команда только формируется под проект, то единственным вариантом получить оценкубудет решение задачи из предыдущего раздела. Однако спустя 3-5 итераций, уже можно считать,что необходимые исторические данные накоплены и использовать метод изложенный далее.Будем считать, что величины и являются случайными величинами,распределенными по нормальному закону, то есть:
  8. 8. Где и – функции плотности распределения величин и . Нормальноераспределение характеризуется двумя величинами: средним значением и среднеквадратичнымотклонением ( , и , соответственно).Параметры нормального распределения определяются по формулам:Здесь обозначает число итераций, которые мы можем использовать для определенияпараметров распределения. Вид формул для и будет аналогичным.Изменение объема оставшейся работы за одну итерацию определяется как разница междуколичеством выполненной работы и работы, добавленной по результатам демонстрацииочередного инкремента заказчику:Разница двух величин, распределенных по нормальному закону, будет также являться нормальнораспределенной случайной величиной с функцией распределения:Где иТаким образом, за итераций объем оставшейся работы изменится на величину с функциейплотности распределения:Качественный вид этой функции для различного числа итераций показан на Рис. 2. С ростом числаитераций наиболее вероятный объем выполненной работы увеличивается, но вместе с этимраспределение становится более размытым, что говорит об увеличении погрешности вопределении объема выполненной работы. То есть, чем более далекое будущее мы пытаемсяпредсказать, тем менее точными становятся наши прогнозы, что вполне естественно.
  9. 9. Рис. 2 Качественный вид функции распределенияИтого, на данном этапе мы можем предсказать, с какой вероятностью команда выполнитопределенное число работы, за некоторое число итераций. Теперь переходим к ответу на вопрос:«С какой вероятностью команда создаст функционала за итераций?». Для того, чтобы дать ответ нам нужно определить, с какой вероятностью значение функции будетбольше или равно . Из курса математической статистики известно, что эта вероятностьвычисляется как:Где – кумулятивная функция нормального распределения.Проиллюстрируем применение этого метода на примере одного реального проекта. После шестинедельных итераций были доступны следующие измерения (все измерения проводились в StoryPoints [8]): 8 7 69 12 8 65 9 8 64 13 6 57 8 3 52 11 5 46
  10. 10. На основании этих данных были рассчитаны функция плотности и кумулятивное распределениевероятности для даты поставки (см. Рис. 3). Рис. 3 Функция плотности и кумулятивное распределение даты поставкиИз графика видно, что наиболее вероятный номер завершающей итерации – 14. Однаковероятность завершить проект до 14-й итерации включительно равнялась примерно 60%.Фактически проект был завершен после 16-й итерации, где значение кумулятивной функциираспределения равнялось 80%.ЗаключениеПри планировании небольших программных проектов, когда число членов команды и измеряетсяединицами, а срок не превышает 2-3 месяцев, естественным образом возникает огромнаянеопределенность, подобно квантовым эффектам в микромире. При формировании команды «снуля» под очередной небольшой проект достоверно оценить число разработчиков невозможнопо фундаментальным причинам.Наибольшая точность оценки достигается в случае слаженной команды, следующей итеративнойи инкрементальной стратегии разработки ПО, когда имеются данные об ее производительности впроектах аналогичных по масштабу и длительности. Но даже при таких жестких ограничениях,накладываемых на команду и используемую методологию, невозможно получить точную датупоставки на ранних этапах (а уж тем более в самом начале проекта).Метод оценки функции распределения даты поставки, изложенный выше, используется автором вповседневной работе при управлении небольшими проектами. Пример электронной таблицы длярасчетов можно найти в блоге автора Ошибка! Источник ссылки не найден..
  11. 11. Литература [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 HICSS40, 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

×