PMMagazine Statistcis4PM
Upcoming SlideShare
Loading in...5
×
 

PMMagazine Statistcis4PM

on

  • 3,752 views

Статистика для менеджера проекта

Статистика для менеджера проекта

Statistics

Views

Total Views
3,752
Views on SlideShare
3,492
Embed Views
260

Actions

Likes
7
Downloads
125
Comments
0

11 Embeds 260

http://ggenikus.github.com 115
http://lj-toys.com 71
http://ggenikus.github.io 37
http://localhost 21
https://twitter.com 8
http://unitofanalysis.wordpress.com 3
https://si0.twimg.com 1
http://www.diffbot.com&_=1358954038513 HTTP 1
http://xss.yandex.net 1
http://www.linkedin.com 1
http://ggenikus.com.ua 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

PMMagazine Statistcis4PM PMMagazine Statistcis4PM Document Transcript

  • Математическая статистика дляменеджера проектов Максим Дорофеев АннотацияСреди менеджеров программных проектов встречается очень много выпускников техническихВУЗов. Однако подавляющее их большинство твердо убеждены в неприменимости полученногообразования к управленческим задачам. Это совсем не так, мало того, элементарнаяматематическая грамотность крайне необходима менеджеру проекта, особенно если проектзатрагивает область разработки ПО, известную своей плохой предсказуемостью и высокимпроцентом неудач. В статье будут даны намеки на то, как математическая статистикапомогает взглянуть с другой стороны на задачи планирования и оценки проекта.ВведениеСамая главная мысль, с которой стоит начать, и которую я считаю аксиомой это то, что в началепроекта узнать точную дату его завершения невозможно по фундаментальным причинам(подробно эта тема рассматривалась в [1]). С той или иной вероятностью любая дата может бытьдатой завершения, и основной задачей планирования является поиск функции плотностираспределения вероятности даты завершения проекта.В идеальном мире длительность проекта выражается простой формулой:Несмотря на свою простоту, справедливость этой формулы не вызывает сомнений. Основнаяпроблема заключается в том, что ни одна величин, стоящих в правой части нам точно неизвестна.На неопределенность объема работ влияют следующие фундаментальные факторы: 1. IKIWISI – этот термин хорошо известен в Agile-сообществах и является аббревиатурой I’ll Know It When I See It1. Наличие многостраничного технического задания, подписанного собственной рукой заказчика, вовсе не означает, что разработанный в точном соответствии с этим документом продукт, окажется способным решить основную задачу. Если основной целью проекта является решение проблемы заказчика, а не дословное следование техническому заданию, то большая часть спецификаций в начале проекта просто неизвестна или не верна. 2. Естественная погрешность оценки отдельных задач. Обычно точность оценки индивидуальных задач при правильном подходе составляет 10%-20%. Такая точность является очень хорошей для программной инженерии, но все равно эту погрешность необходимо принимать в расчет при планировании проекта в целом.1 Я узнаю это, когда я это увижу 1
  • 3. Неполнота WBS. В самом начале проекта с очень высокой вероятностью, в план будут не включены те задачи, которые в итоге придется выполнить. Это может происходить по многим причинам. Например, из-за недостаточного четкого видения проекта либо из-за наличия рисков: практически никогда в первой версии плана по разработке ПО не встречаются задачи вида «Починить сломавшийся сервер» или «Исправить конфликт с библиотекой стороннего производителя», хотя в реальности эти задачи приходится выполнять достаточно часто.Производительность команды нам так же не известна и опять по фундаментальным причинам [2]: 1. Производительность даже хороших программистов может отличаться в разы, 2. Производительность одного и того же программиста так же может отличаться в разы в зависимости от внешних условий (состав команды, предметная область проекта, личные обстоятельства).Таким образом, хоть формула и верна, но определить точные значения величин, стоящие вправой части со сколь-нибудь приемлемой точностью оказывается практически невозможно.Конечно, существуют более сложные методики оценки программных проектов, но они обладаютаналогичными недостатками, и так же оказываются неспособными дать удовлетворительнуюоценку на ранних этапах.Существует два принципиально различных подхода к управлению проектом в условиях большойнеопределенности: 1. Приложить как можно больше усилий к выяснению всех деталей с самого начала, составить подробный план и следовать ему, стараясь подчинить реальность составленному плану 2. Смириться с наличием неопределенности и быть готовым предсказывать ход проекта на основе вероятностных характеристик, уточняя план по мере выявления нового знания о проекте.В этой статье будут рассматриваться элементы второго подхода и способы их применения куправлению проектом, выполняемым по итеративной и инкрементальной методологии.Подвижная мишеньМногие даже опытные менеджеры считают итеративный подход не предсказуемым. «Как выможете предсказать дату окончания проекта, если в каждую итерацию вам добавляются новыезадачи?» - этот вопрос является номером 1 по популярности среди менеджеров, не имевшихопыта работы в хорошо настроенном итеративном процессе. Одной из причин этого вопросаявляется слабая визуализация проекта. Диаграммы Гантта, считающиеся чуть ли не стандартнымспособом визуализации, совершенно не подходят для итеративных проектов, в то время какальтернативные инструменты пока еще не столь популярны. Ниже будет показан один изальтернативных инструментов контроля итеративного проекта, известный как Enhanced Burn DownChart.Детали итеративных и инкрементальных методологий достаточно хорошо изложены в литературе(например [4]) и поэтому я позволю себе не останавливаться на этом. В общем случае в каждуюитерацию происходит одно и то же: 2
  • 1. В процессе планирования итерации команда берет в работу определенное число задач из общего пула (пусть в начале проекта он имеет размер относительных единиц трудозатрат) 2. На протяжении этой итерации команда полностью реализует определенное число задач, общей «стоимостью» относительных единиц трудозатрат, где обозначает номер итерации. 3. В конце итерации команда демонстрирует потенциально готовый к поставке продукт заказчику. Демонстрация дает возможность глубже понять потребности заказчика и в результате в общий пул задач добавляются задачи «стоимостью» . Заметим, что на практике может быть и отрицательным, например, в случаях, когда заказчик понимает бесполезность определенных, ранее заявленных требований.Предположим, у нас есть проект, имеющий в самом начале пул задач общим объемомотносительных единиц. Пусть прошло 5 итераций со следующими параметрами: Итерация Out(n) In(n) 1 8 4 2 12 5 3 14 1 4 14 2 5 15 3 Табл. 1Enhanced Burn Down Chart для этого проекта изображен на Рис. 1. Правила его построения просты: 1. В самом начале проекта рисуется столбик, по высоте равный общему объему задач (соответствует итерации 0) 2. В конце первой итерации рядом рисуется такой же столбик, только сверху «отрезается» объем выполненных задач , а снизу «приклеивается» объем добавленных задач . 3. Для каждой последующей итерации аналогичным образом рисуется очередной столбикТаким образом, высота столбика обозначает объем оставшейся работы по окончанию итерации.Разница между верхней границей самого первого столбика, и верхней границей столбика длятекущей итерации показывает объем работ, выполненный командой. Аналогичным образом,нижняя граница столбиков показывает суммарный объем добавленных задач.На Рис. 1 также присутствуют черные прямые – они являются линиями тренда, их углы наклонапоказывают средние скорости выполнения задач (верхняя прямая) и добавления новых задач(нижняя прямая). Очевидно, что спустя несколько итераций эти линии тренда должныпересекаться, и точка их пересечения показывает ориентировочный номер последней итерациипроекта. 3
  • Рис. 1 Пример Enhanced Burn-Down ChartВо введении было сказано, что любая дата в будущем с той или иной вероятностью можетоказаться датой завершения проекта. Это утверждение справедливо и к номеру итерации. Нижебудет дана схема оценки вероятности завершения проекта в ту или иную итерацию.Таблица 1 содержит данные, полученные в ходе выполнения проекта, что позволяет судить опроизводительности команды, основываясь на реальных цифрах. По большому счету и являются случайными величинами, распределенному по определенному закону. Дляпростоты будем считать закон распределения нормальным. В общем случае это не верно, но вслучае хорошо слаженной команды, делающей не первый проект для одного и того же заказчика,это утверждение не далеко от истины. Как известно, нормальное распределение полностьюописывается двумя параметрами: средним значением и среднеквадратичным отклонением. Имеяреальные данные проекта по нескольким итерациям, мы можем вычислить эти значения:Где и обозначают средние значения «стоимости» выполненных и добавленных задач, а , среднеквадратичные отклонения этих величин.Предполагая параметры распределения постоянными, легко получить функцию плотностираспределения объема работ, выполненных за N итераций. Эта функция будет так жераспределена по нормальному закону со средним значением: 4
  • и среднеквадратичным отклонением:Имея параметры распределения, и используя способ, подробно описанный в [1], можновычислить вероятность каждой будущей итерации стать последней. Получив эти вероятности ихможно нанести на график с Enhanced Burn-Down Chart (см. Рис. 2). На этом графике столбикамислева показаны вероятности закончить проект в определенную итерацию, а сплошной линиейпоказана кумулятивная функция распределения или вероятность завершить проект до указаннойитерации включительно. Рис. 2 Enhanced Burn Down Chart с функциями распределенияТаким образом, общая схема оценки и контроля итеративного проекта выглядит примерноследующим образом: 1. В самом начале проекта мы делаем наши лучшие предположения относительно параметров производительности и притока новых задач, 2. После завершения каждой итерации на основе реальных данных вычисляются новые значения параметров, и корректируется общая картинаВ случае, когда состав команды не меняется от проекта к проекту, можно использоватьнакопленные исторические данные, измеренные в прошлом, для оценки будущих проектов. Этиммы минимизируем неопределенность в производительности команды. В случае работы на одногои того же заказчика над проектами примерно из той же самой области, исторические данные попритоку новых задач также могут быть использованы, и тем самым мы учитываем IKIWISI-эффект.Использование относительных оценок для трудозатрат позволяет нам минимизировать влияниеестественной погрешности и частично негативный эффект неполноты WBS. 5
  • Учет неучтенных задачВ ряде случаев команде проекта приходится заниматься задачами, не относящимися, например, кподдержке других проектов. Такое часто встречается в заказной разработке, где преобладаютнебольшие по трудозатратам проекты, или в отделах внутренней автоматизации, где команда,едва закончив работу над одной системой, берется за разработку следующей, оставляязавершенную систему без подготовленной линии поддержки.Подобные задачи возникают случайным образом и, как правило, в самый не подходящий момент.Правильно учесть влияние внешних задач не сложно, но есть одна тонкость. Часто для вычисленияпоправки к плану менеджеры используют только средние величины, игнорируя их разброс. Этоможет привести к очень серьезным промахам.Рассмотрим пример. Пусть у нас имеются данные по числу внешних задач, выполненныхкомандой в предыдущие 10 итераций (Табл. 2). Номер Число внешних итерации задач 1 0 2 2 3 1 4 7 5 2 6 5 7 2 8 4 9 2 10 5 Табл. 2В среднем за одну итерацию добавляется 3 задачи. Однако за предыдущие 10 итерации ни разуне было добавлено ровно 3 задачи, и это должно насторожить. Данная выборка не достаточна,что бы судить о точном виде распределения, поэтому мы не сильно ошибемся, если будемсчитать, что число добавленных внешних задач подчиняется распределению Пуассона. Еслисделать такое предположение, то построить предполагаемые функции плотности для числавнешних задач (см. Рис. 3). Кумулятивная функция распределения говорит о том, что вероятностьполучить 3 и менее внешних задачи равна 65% (в нашем примере таких случаев 6 из 10).Соответственно, вероятность получить 4 и более внешних задач в следующей итерации равна 35%,что совсем не мало. 6
  • Рис. 3 Функции распределения числа внешних задачУчет подобных флуктуаций особенно важен на относительно коротких проектах. Предположим,что предполагаемая длительность нашего проекта составляет всего 5 итераций, с какойвероятностью минимум в 3 итерации нам придет 4 и более задач по поддержке? Помочь ответитьна этот вопрос поможет биномиальное распределение, возвращающее вероятность получитьуспехов при испытаниях при вероятности успеха равной . Здесь под успехом мы понимаемитерацию, с числом задач по поддержке большим или равным 4. Вероятность подобного исхода,как это видно из Рис. 3 равна 35%. При помощи обычных офисных приложений можно вычислить,что с вероятностью 24% не менее, чем в 3 из 5 итераций придет не менее 4-х задач по поддержке.Другими словами, с такой вероятностью больше половины времени выполнения проекта,команда получит число задач по поддержке, превышающее среднее значение.Аналогичным образом можно вычислить вероятность того, что минимум в 3 из 5 итерацийкоманда будет получать по 2 и менее внешних задач. Вероятность такого исхода равна примерно35%. То есть с ненулевой вероятностью команда может оказаться загруженной задачами поподдержке меньше среднего. Опять естественным образом возникает неопределенность: снемалой вероятностью задачи по поддержке не будут тревожить команду, и с чуть меньшейвероятностью команда наоборот может оказаться перегруженной внешними задачами.Выше рассматривалось просто число внешних задач, в то время как для планирования проектанужно уметь оценивать трудозатраты. Очевидно, что невозможно дать точную оценку задаче,которая еще не возникла, но вполне возможно оценить вероятностные характеристики. Еслисделаны хоть сколько-нибудь адекватные предположения относительно вида плотностираспределения трудозатрат одной задачи, можно рассчитать и плотность распределения общихтрудозатрат на внешние задачи в течение проекта. Однако с практической точки зрения будетболее целесообразным измерять сразу статистические параметры трудозатраты на поддержку иучитывать их, делая поправки параметров и в модели, описанной в предыдущем разделе. 7
  • Проекты с фиксированной стоимостьюВопросом под номером 2 по популярности является вопрос о стратегии оценки проектов сфиксированной стоимостью. В случае проекта с фиксированной стоимостью нам не нужно знатьточную дату завершения, будет достаточно оценить дату, до наступления которой проект можетбыть завершен с хорошей вероятностью, то есть дать оценку сверху. Естественно, еслинеоправданно завысить стоимость проекта, то есть риск потерять заказчика, а если стоимостьокажется заниженной, то прибыль проекта может стать отрицательной. В случае, когда требуетсяозвучить дату или стоимость еще до начала проекта, можно воспользоваться следующимподходом: 1. На основании исторических данных, экспертных оценок и интуиции (источники перечислены в порядке убывания степени доверия), вычисляется кумулятивная функция распределения для длительности или стоимости проекта, 2. На основе текущей стратегии компании определяется уровень толерантности к риску, то есть тот риск, на который компания готова идти, 3. Используя функцию плотности распределения, находится значение длительности/стоимости, соответствующее определенному уровню толерантности к риску. Рис. 4 Определение длительности проекта, соответствующей установленному уровню толерантности к рискуНа Рис. 4 показан пример кумулятивной функции распределения номера завершающей итерации.В этом примере уровень толерантности к риску равен 80%. Если использовать хорошуюстатистическую модель оценки проектов, и следовать описанному выше подходу, то вдолгосрочной перспективе это позволит получить точную оценку сверху для 80% проектов. Чтоестественно, в 20% случаев оценки окажутся ниже и для удачного завершения проекта придетсяприбегать к методам компенсации заниженной оценки. К сожалению, способ, дающий 100%точность при оценке проектов до их начала, в индустрии разработки программного обеспеченияпока не известен. 8
  • Литература [1] М. Дорофеев, «Ловушки статистического планирования», Управление Проектами, N4(17), 2009 [2] Э. Йордон, «Путь камикадзе», Лори, 2008 [3] G. Stepanek, “Software Projects Secrets: Why Software Projects Fail”, Apress, 2005 [4] C. Larman, “Agile and Iterative Development: Manager’s Guide”, Addison-Wesley, 2003 9