Глава 12. Оценка трудозатрат

Чтобы оценить объем трудозатрат по какой-либо задаче, вспомните, сколько усилий уходило у вас на решение подобных задач в прошлом. Оценки трудозатрат по новой задаче будут приблизительно такими же.

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

Давайте говорить начистоту: в лучшем случае, оценка трудозатрат – это искусство. Вам просто неоткуда взять точные цифры, как бы вы не старались. Правда, приложив некоторую толику усилий, можно получить довольно хороший результат, который вы с течением времени будете уточнять.

Вот три правила для эффективной оценки трудозатрат:

l        Делайте все как можно проще.

l        Используйте знания о том, что уже случалось в прошлом.

l        Извлекайте уроки из собственного опыта.

Чтобы понять, сколько времени уйдет на решение данной конкретной задачи, поищите аналогичную ей задачу среди тех, которые вы уже реализовывали в прошлом. Согласитесь, история повторяется довольно часто. Если же новая задача существенно отличается от всех старых, придумайте какой-нибудь несложный способ, чтобы учесть это различие при подсчетах. Только без лишней изощренности и умствования: предварительные оценки все равно не бывают абсолютно точными, тут уж ничего не поделаешь.

Объем задачи

Самый простой и эффективный способ определить объем работы по задаче, это найти подобную задачу среди тех, которые вы уже делали. Загляните в свои записи – сколько времени вам пришлось потратить тогда? Теперь давайте допустим, что новая задача потребует от вашей команды таких же усилий: «Ага, еще один отчет. На отчет мы всегда тратим около недели».

Если раньше вы еще не сталкивались с задачами подобного объема, посмотрите, не было ли у вас других – вдвое меньших или вдвое больших. Теперь, соответственно, разделите или умножьте на два. Вот Мартин не смог получить пятерку по математике на первом курсе, наверное, как раз потому, что имел глупейшую привычку умножать на два там, где следовало бы делить. Но вы не беспокойтесь, у вас все получится гораздо лучше.

Неважно, в каких единицах вы будете измерять объем работ. Главное, выбрать однажды единицу измерения и в дальнейшем использовали только ее. В этой книге мы измеряем трудозатраты в идеальных неделях. В целом, идеальная неделя – это то же самое, что обычная человеко-неделя, с той лишь разницей, что в первом случае программист 100% своего рабочего времени отводит решению данной конкретной задачи.

(Вы уже наверняка заметили слабину в нашем подходе. Хорошо, говорите вы, а если я только начал работу над проектом, и мне еще просто не с чем сравнивать? Загляните в главу 15, где мы излагаем абсолютно неудовлетворительный способ решения этой проблемы.)

Оценка трудозатрат – задача для всей команды. Разработчики обсуждают пожелание заказчика, обдумывают, как много времени может занять реализация такой функциональности и, наконец, выносят решение об объеме трудозатрат. При этом мнения разработчиков могут разделиться: одним задача кажется довольно сложной, поэтому они утверждают, что реализовывать ее придется долго и трудно, другие считают ее совсем простой. В таких ситуациях мы пользуемся правилом: «Даешь оптимизм!». Иными словами, если и после подробного обсуждения у разработчиков по-прежнему нет единого мнения, мы останавливаемся на самой маленькой оценке.

Не забывайте: оценка трудозатрат это не обещание сделать все точно в срок. Одна-другая ошибка не представляет для проекта никакой опасности. Наша главная цель – оттачивать свое умение определять объемы работ, и с каждым разом давать все более точные оценки трудозатрат. Взяв за основу самую скромную оценку, мы убиваем сразу двух зайцев: во-первых, поддерживаем напряжение в самом процессе определения трудозатрат, так что оценки не вырастают до безобразно огромных размеров; во-вторых, поддерживаем напряжение в команде, так что разработчики быстро отвыкают от необоснованного оптимизма. Те программисты, чей оптимизм уже однажды «вышел боком» всей команде, в следующий раз поостерегутся давать излишне оптимистические оценки.

Многих беспокоит проблема зависимостей между различными пожеланиями заказчика. В главе 13 вы увидите, что в большинстве случаев об этом можно вообще не думать. Впрочем, «в большинстве случаев» не значит «всегда». Конечно, такие ситуации встречаются не один раз: «Приделать тут такую вот пимпочку? Шесть недель. А если сначала приделать вот здесь и здесь по загогулине, то всего четыре недели». В подобном случае нужно оценить объем работ по реализации «пимпочки», исходя из ее текущего положения в списке задач, а на карточке отметить, что объем работ по данной задаче зависит от наличия в системе соответствующих «загогулин». И все же такие ситуации возникают совсем не часто.

Впоследствии вы будете уточнять первоначальные оценки трудозатрат, и это позволит вам указать на карточке дополнительную информацию: например, о пропавших зависимостях, о возникших технологических проблемах (или их исчезновении, что тоже случается).

Сколько можно успеть сделать за одну итерацию

Давайте представим итерацию в виде ящика, куда может поместиться определенное количество бутылок вина. Любой поклонник Бахуса тут же начнет интересоваться – «А сколько же бутылок войдет в ящик?» Можно измерить размер ящика, размер бутылок и проделать нехитрые геометрические вычисления, можно созвать ассамблею из признанных авторитетов, можно, в конце концов, просто взять бутылки и проверить на деле.

Наш подход вам известен: принцип «вчерашней погоды». В конце каждой итерации мы измеряем объем проделанной работы и делаем вывод, что в следующей итерации сделаем столько же. Однако когда мы рассказывали вам поучительную историю о метеорологической системе, мы имели в виду только общий принцип. Чтобы применить его к процессу планирования версий системы, мы должны сначала решить, в чем измерять объем того, что мы делаем. Можно, конечно, считать количество реализованных пожеланий заказчика, но ведь пожелания бывают разные.

Значит, нужно научиться измерять объем любых задач. Тогда в конце каждой итерации мы определим, сколько пожеланий заказчика нам удалось реализовать, и запишем, сколько идеальных недель ушло на каждое пожелание. После этого мы подсчитаем общий объем идеального времени, ушедшего на выполнение всех пожеланий, и ответим на вопрос, сколько идеального времени в одной итерации.

Это простое правило идет вразрез с одним из постулатов теории управления проектами: «Работа занимает столько времени, сколько его есть в наличии». Возможно, для некоторых видов деятельности это справедливо, но только не для команды хороших разработчиков, которые заинтересованы в конечном результате.

Имейте в виду, повышать скорость работы путем увеличения числа сотрудников – довольно рискованное занятие. Как мы уже объясняли в седьмой главе, зависимость в данном случае будет нелинейной, а результат скажется только через некоторое время. Не пытайтесь предсказать его заранее – лучше измерьте его, когда он появится. Понять, когда новые сотрудники начнут приносить существенную пользу, чрезвычайно сложно. Никто не знает заранее, сколько времени им понадобится, чтобы войти в курс дела.

Кроме этого, мы будем измерять скорость работы каждого программиста. Можно, к примеру, сказать, что скорость этого программиста – 5 идеальных рабочих дней. Это значит, что он может гарантированно отработать 5 идеальных рабочих дней за каждую итерацию. У большинства разработчиков скорость будет приблизительно такой же. А вот те, кто работают неполный рабочий день или, например, недавно пришли в команду, с такой скоростью трудиться не смогут.

Вообще с понятием скорости лучше обращаться осторожно и не придавать ему чрезмерно большое значение. Скажем, у вас есть две команды разработчиков, которые работают одинаковыми итерациями. При этом у них разная скорость работы. Что же это означает?

Такой эффект может давать целое множество тесно связанных друг с другом факторов. Например, одна команда лучше соображает, или же использует лучший инструментарий. А может быть, одна команда делает более оптимистические оценки трудозатрат, поэтому ей приходится работать с меньшей скоростью, дабы компенсировать эти оценки. В конце концов, все эти рассуждения об идеальном времени – грандиозная выдумка, призванная решить труднейшую проблему определения трудозатрат, необходимых для производства программного обеспечения.

Что такое «идеальное время»

Те, кто работают по методологии ХР, нередко спорят о единицах для исчисления объема работ.

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

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

Календарный объем работы – это число сотрудников, помноженное на календарное время. Команда из шести человек работает по тридцать рабочих дней каждую календарную неделю. За четыре недели они выработают двадцать четыре календарных рабочих недели. Если один из разработчиков работает неполный рабочий день, то за тот же четырехнедельный период команда сможет выработать только двадцать две календарных рабочих недели.

Большинство людей оценивают объем работ по календарю. Это закономерно, потому что так гораздо проще делать все вычисления. Однако оценивать объемы работ при этом труднее. Лучше всего определять объем работ, заранее предположив, что все сотрудники работают с некоторой разумной производительностью. Обычно это означает, что им не мешают и не отрывают от работы. Когда речь идет о больших периодах времени, влияние подобных помех вполне может «сглаживаться», но если мы говорим о коротких сроках в одну или две недели, то тут они могут очень заметно сказаться на производительности. В этом случае они вносят путаницу в статистические данные, а ведь как раз статистика является залогом правильности будущих оценок.

Именно поэтому в ХР принято оперировать другим понятием: идеальным временем (ideal time). Идеальным  называется тот период времени, в течение которого вы работаете над поставленной задачей, не отвлекаясь на любую другую деятельность и при этом чувствуете, что ваша производительность близка к максимально возможной. Если все оценки выражены в идеальном времени, можно не беспокоиться о возможных перерывах и других факторах, которые будут отвлекать нас от основной задачи. Например, нам нужно оценить объем новой задачи, которая очень похожа на ту, что на прошлой неделе отняла у нас два идеальных дня. В таком случае, эту задачу мы оценим точно так же. При этом время, которое будет реально затрачено на эту задачу, может существенно отличаться от предполагаемого, но за этим мы следим отдельно.

Мы говорим «идеальное время», а подразумеваем «идеальный объем работ». Команда из шести человек за рабочую неделю может вырабатывать, например, только десять идеальных рабочих дней. Как правило, оценивая ту или иную задачу, разработчики говорят: «Это займет три идеальных дня». На самом деле они имеют в виду «три идеальных рабочих дня», но это слишком длинно.

Суть понятия «идеальное время» лежит совсем в иной плоскости, нежели привычное для нас понятие «время». Некоторые вообще оценивают задачи и пожелания клиентов в баллах или мишках Гамми. И это вполне допустимо. Главное – всегда использовать для всех задач одну и ту же однажды выбранную единицу измерения.

(Франческо Чирилло (Francesco Cirillo) как-то рассказал нам, что однажды купил и принес на работу тридцатиминутный кухонный таймер в форме помидора. С тех пор в команде появилось выражение «задачка на шесть помидоров».)

Нам нравится оперировать понятием «идеальная неделя», потому что слово «неделя» ясно указывает на связь с привычным представлением времени, а слово «идеальный» не дает забыть, что в реальности все получается не так, как было запланировано. Кроме того, понятие «идеальная неделя» очень удобно использовать при составлении первого плана (см. пятнадцатую главу этой книги).

Идеальным называется время, которое вы потратите на выполнение взятых на себя задач. При этом оно не включает в себя те моменты, когда вы кому-то помогаете (например, во время парного программирования). Некоторым может показаться, что необходимо учитывать все время, когда вы не занимаетесь непосредственным программированием, однако на самом деле здесь вступает в действие принцип «вчерашней погоды». Иначе говоря, вы сами увидите, сколько времени отнимут у вас те или иные задачи.

(Если вы уже знакомы с другими материалами по ХР, то вам наверняка встречался термин коэффициент нагрузки (load factor). Коэффициентом нагрузки мы называем отношение календарного объема работ (в течение итерации) к скорости работы. Таким образом, команда из пяти человек, работающая двухнедельными итерациями, вырабатывает десять рабочих недель за каждую итерацию. Если скорость команды равняется четырем, то коэффициент нагрузки такой команды составит 2,5 (10:4).) Раньше мы нередко использовали при планировании понятие коэффициента нагрузки, однако теперь пришли к выводу, что гораздо легче оперировать одним понятием скорости.

Уточняем первоначальные оценки

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

Весь этот механизм заработает только в том случае, если вы будете внимательно следить за реальными цифрами. Не забывайте фиксировать, сколько времени занимает у вас выполнение той или иной задачи. При этом записывать показатели нужно с той же подробностью, что и при планировании. Иначе говоря, достаточно будет указать время в идеальных неделях. Статистические данные – основа дальнейшего планирования и залог его точности.

 


Copyright notice

© Copyright Addison-Wesley, 2001, все права защищены
© Copyright maxkir.com, перевод, 2002
© Copyright Издательский дом "Питер", 2002, все права защищены