Pull to refresh

Оценки софтверных проектов или равно ли целое сумме слагаемых?

Reading time 6 min
Views 611
Следующий кросс-пост (ах, я, бука!) с моего основного блога.

В этой статье я собираюсь поговорить о вещах, которые вы все давно знали. Теперь я предлагаю о них задуматься.<?xml:namespace prefix = o ns = «urn:schemas-microsoft-com:office:office» /><o:p></o:p>

Если вы не новичок в софтверной индустрии, то вы в курсе, что перодически любой менеджер оказывается в фазе, когда его начинают резко интересовать оценки времени, работы… Причем обычно не как попало, а по какой-нибудь модной методике. Вам предлагают сообщить за неделю, сколько времени займут еще не найденные баги и та фича, дизайн которой еще не успели сделать, не говоря уж о том, что запланированная работа уж точно должна быть разбита на кусочки с точностью до часа, если уж нельзя поминутно...<o:p></o:p>

Как обычно оценивается время для проектов? Все знают, что большой кусок оценить верно практические невозможно, поэтому он разбивается на более мелкие куски, а потом эти мелкие куски складываются вместе, например, в какой-нибудь Gantt диаграме или просто на календаре или Excel'е.<o:p></o:p>

Сегодня я бы хотел поговорить о двух полностью неверных предположениях, которые лежат в основе этой методики.<o:p></o:p>

Для начала, а что такое оценка времени проекта или там шага проекта?<o:p></o:p>

Нет-нет, я понимаю, что в ожиданиях менеджмента, вы как Кассандра должны совершенно точно предсказать будущее, причем в отличие от Кассандры сделать это не в пример более оптимистично, как того требуют business tenets (не знаю, как эта штука переводится, ну, что-то вроде морального кодекса молодого строителя коммунизма – по ней у нас каждый год обязательный треннинг). В общем, все понимают, что это сложно, но ваши пророчества должны быть «good enough!» со всех точек зрения.<o:p></o:p>

Ну, когда менеджеры так говорят – это понятно. Но мы-то не менеджеры, мы инженеры, технари. Мы знаем, что «good enough» — это нечто сильно невнятное. А чтобы быть частью инженерной дисциплины, понятие должно быть измеряемым в цифрах. То есть хочется как-то измерить это дело, чтобы сказать внятно «good enough» или все-таки не «good enough». А когда инженер хочет чего-то измерить, он применяет такую вредную науку – математику. Вредная она потому, что постоянно говорит о менеджерах то, что она о них думает, да еще и права оказывается… <o:p></o:p>

Итак, а что такое оценка в математике, точнее в матстатистике и теории вероятностей. А это интервал, в который попадает ожидаемая случайная величина с заданной вероятностью. Случайная величина – это сколько времени займет проект или там отдельный шаг проекта. Вроде бы что надо, что доктор прописал, вот только а что делать с заданной вероятностью?<o:p></o:p>

Попробуйте подойти к менеджеру и сказать, «С вероятностью 80 процентов этот проект уложится в месяц.» Что он вам скажет?

Ага, вы уже почувствовали легкое недомогание? Дальше лучше. Хочет он «наверняка», а что говорит на это математика? Представьте себе картинку какой-нибудь привычного распределения, ну, скажем, пуассоновского или нормального-гауссова. Каков интервал, вероятность попадания в который 100 процентов? Правильно, увы, если менеджер хочет гарантированной оценки, то математически она всегда бесконечность. Ну, или практически, срок за который проект просто прибьют. Любой проект имеет шанс провала. У хороших инженеров, которым позволили сделать хорошие оценки, этот шанс провала меньше, а у плохих – значительно больше, но все-таки ни при какие условиях он не равен нулю.<o:p></o:p>

То есть, volens-nolens с вас сдерут оценки, который будут считаться как ваше обещание, хотя на деле они будут оценками для вероятности восемьдесят, девяносто, девяносто пять процентов...<o:p></o:p>

Итак, оценка проекта или шага проекта – это интервал времени в который он уложится с комфортной для вас вероятностью. Или можно сказать, с комфортным для вас риском не уложиться.<o:p></o:p>

Допустим, вы выбрали в качестве такового 80 процентов (соответственно с риском не уложиться 20 процентов). Да, я знаю, звучит весьма рискованно, но наблюдая за программистами на натуральных условиях у меня сложилось ощущение, что даже 80 процентов для большинства чрезмерно высоки. В норме умные менеджеры умножают оценки разработчиков по крайней мере в полтора-два раза.<o:p></o:p>

Итак, у вас есть проект, в нем два шага. Вы оценили, что каждый шаг займет два с половиной дня с вероятностью 80 процентов. Означает ли это, что весь проект займет неделю с той же вероятностью 80 процентов? Если вы хоть немного помните из теорвера, то вы уже ответили, что нет, вероятность будет совсем другой, ну разве что за исключением особо экзотических распределений, которые в природе обычно не случаются.<o:p></o:p>

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

<o:p></o:p>

Для наиболее популярного распределения для такого рода величин – пуассоновского, картина будет та же самая. Как и вообще для большинства встречающихся в жизни распределений. А это означает, что если вы дали оценки двух шагов проекта с вероятностью в 80 процентов как t1 и t2, то t1 + t2 вовсе не будет оценкой всего проекта с вероятностью 80 процентов.<o:p></o:p>

Чтоб не морочить голову абстрактными проблемами, давайте также взглянем на вопрос чуть более практично. А бывает ли что человек кончает работу раньше выделенного срока? Ну, изредка бывает, но как говорится, пренебрежимо малая величина. Ведь даже если вы и закончите раньше, скорее всего вы обрадованно используете освободившееся время на то, чтобы код почистить, потестировать, убедиться лишний раз, верно? Собственно, бытовая мудрость распростряняемая в сборниках, посвященных закону Мэрфи, об этом просто говорит: «Любая работа занимает все отведенное на нее время.»<o:p></o:p>

С этой поправкой все становится еще более смешным. Поскольку, если мы примем, что работа меньше запланированного не занимает, то чтобы проект по-прежнему влез в t1 + t2 надо, чтобы обе задачи выполнились за запланированное время, которое, я напомню, оценивалось с вероятностью 80 процентов. Теперь пора вытащить школьный учебник по математике и сосчитать какова вероятность всего проекта уложиться во время, сосчитанное в Project или еще как путем сложения:<o:p></o:p>

P( T1 & T2 ) = P(T1)*P(T2) = 0.8*0.8 = 0.64<o:p></o:p>

То есть, если вы разбили проект всего на две части, оценили каждую с 80 процентами вероятности, то сумма имеет «надежность» всего лишь в 64 процента! Попробуйте в качестве домашнего задания, что получится если проект разбить на десять шагов? Попробовали? Ага. Чуть больше десяти процентов. Даже если вы стрясете с инженеров оценку каждого шага в 90 процентов, шансы вашего проекта из десяти шагов будут всего 35 процентов.<o:p></o:p>

Кстати, именно поэтому Джоэль Спольски в своем Evidence Based Scheduling (http://www.joelonsoftware.com/items/2007/10/26.html) настаивает на том, чтобы оценки не складывали, а получали из оценок шагов методом Монте-Карло.<o:p></o:p>

Конечно, можно заметить, что качество отдельных оценок очень сильно влияет на качество оценки целого. Так улучшение оценки шагов с 80 до 90 процентов улучшило оценку проекта из десяти шагов с 10 до 35 процентов. Но давайте уж честно, а 35 процентов вас устроит? И как часто вы делаете проекты всего из десяти шагов? А уже с сотней шагов даже очень высококачественные оценки шагов с 99 процентами вероятности для каждого шага дадут вам в конце меньше 40 процентов шансов для всего проекта. Вас устроит 40 проценов? И где вы найдете инженеров ошибающихся только один раз из сотни и при этом не отводящие целый день на написание одной строки комментария?<o:p></o:p>
Конечно, справедливости ради надо заметить, что такое «схлопывание» шансов на успех происходит только для шагов на критическом пути. Но не забывайте, что если вы используете свои ресурсы (людей) эффективно, то и при достаточной небольшой задержке любой шаг может оказаться на критическом пути. Так что ситуация может и не так плоха, как в примерах выше, но и нет так хороша как хотелось бы. Впрочем, это вы тоже и так знаете… :-)<o:p></o:p>

Конечно, теперь будет естественный вопрос, а что же делать? Вы знаете, кое-что можно. Но это уже предмет для отдельной статьи, и не одной.<o:p></o:p>

И уж совсем расставля точки над «i», кратко, что я пытался сказать в этой статье:<o:p></o:p>

1.       Оценка – это не то, когда проект будет сделан. Это время в которое он уложится с заданной вероятностью. Даже если менеджер или инженер этого не знают, она все равно есть и зависит от оптимизма инженера и агрессивности менеджера к отстающим.<o:p></o:p>

2.       Менеджмент вносит на порядок большие ошибки в оценки проекта, складывая оценки отдельных шагов, нежели инженеры, оценивая эти индивидуальные шаги.<o:p></o:p>

3.       Даже небольшие ошибки в оценках индивидуальных шагов могут значительно снизить надежность оценки всего проекта.<o:p></o:p>

4.       И как обычно, калькулятор не заменяет мозгов, а Microsoft Project – искусства менеджмента.<o:p></o:p>

5.       О, да, еще одно: Не сотвори себе кумира. В том числе и из модных методик.<o:p></o:p>

<o:p> </o:p>
Tags:
Hubs:
+2
Comments 0
Comments Leave a comment

Articles