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

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

Все эти меры безопасности накапливаются, как будто вы предполагаете, что все неприятности ждут вас на каждом шагу, что случается редко (вопреки закону Мерфи). Эти оценки также подвержены эффекту обособления (compartmentalization effect). Хорошие разработчики трудятся сразу над группой проблем, особенно при исправлении программных ошибок. Например, часто несколько проблем могут быть связаны с каким-то одним фрагментом кода, который необходимо переработать. Наведя порядок в этом разделе кода, можно избавиться сразу от нескольких проблем. Если оценивающий исходит из того, что все ошибки будут исправляться порознь, то его результат может в два-три раза превышать реально необходимое время.

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

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

Иногда мы слишком увлекаемся профессиональным жаргоном: структура процесса, множественное наследование, полиморфизм и т. д. А как быть, если надо объяснить эти понятия «рядовым гражданам»? Как они воспримут наши методы оценивания? Роско Леруа высказывает свою точку зрения на оценку сроков.

Шоколадное или ванильное?.

Однажды Роско появился у меня в доме с номером «USA Today» под мышкой. «Похоже, что даже McPaper

начинает что-то понимать»,сказал он, зная, что я не премину заглотить наживку. Когда я поинтересовался, о чем он говорит, он показал мне короткую заметку в углу страницы: 52% населения предпочитает ванильное мороженое, а 42% - шоколадное.

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

Роско продолжил.

-Обрати внимание, что написано под столбчатой диаграммой: достоверность (accuracy) оценки составляет плюс-минус 3%.

Это важно. Они годами печатали такие вещи, ничего не сообщая о величине ошибки. Должно быть, мы стали больше понимать в опросах, если они считают, что нам надо сообщить, какова возможная ошибка».

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

Разъяснения Роско.

- Три процента ошибки, - сказал он, - это немало, потому что разрыв между предпочтениями составляет всего 4%. Поэтому полной уверенности быть не может. Но я тебе вот что скажу: бьюсь об заклад, что знаю, сколько людей они опросили.

Я был уверен, что Роско никогда не участвовал ни в каких «семинарах» по теории вероятностей и статистике, где не фигурировали бы фишки для покера, но, похоже, я ошибался.

- Вот что я думаю, - продолжил он. - Они опросили примерно 1000 человек. Ошибка для 1000 ответов составит примерно корень квадратный из 1000, т. е. 31,4. Тридцать один на 1000 составит 3,1%, т. е. примерно 3%.

- Подожди, Роско, - не удержался я, - квадратный корень из 1000 равен 31,6, а не 31,4.

- Опять ты лезешь со своим образованием. Любой дурак может запомнить, что квадратный корень из 10 - это число «пи», т. е. 3,14. А для 1000 надо переместить в ответе на один знак десятичную точку - вот тебе и 31,4.

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

Роско идет дальше.

- И еще скажу, - продолжал Роско. - Ты никогда не увидишь заметки, в которой говорилось бы, что погрешность составляет, скажем, 1%.

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

- Не нужно быть Эйнштейном, чтобы понять почему. По той же логике для снижения ошибки до 1% надо опросить 10 000 человек. Это в 10 раз дороже, чем опросить тысячу. Поэтому, чтобы понизить ошибку с 3% до 1%, надо увеличить издержки в 9 раз.

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

Календарь Роско.

К этому времени я уже поверил, что Роско знаком с квадратными корнями. Это подтвердилось, когда я заговорил с ним о проектах и графиках работы. Его представление о том, сколько недель содержит тот или иной отрезок времени было, мягко говоря, любопытным. Мое открытие сведено в табл. 10.1.

Таблица 10.1. Календарь Роско

Когда я поинтересовался трехмесячными проектами, Роско ответил: «Не люблю ими заниматься».

Эти числа ясно показывали, что тут действует какая-то очередная особая арифметика Роско. Такие схемы не устанавливают без определенных на то оснований. Любопытно также было видеть, что Роско не желает иметь дело с промежутками времени короче недели. «Мы, сынок, не поденщики, - заявил он. - Я плачу своим инженерам понедельно. Потому я не пользуюсь для оценок меньшими интервалами».

Столь же логично, как его рассуждение о дробном количестве работников.

Роско вычисляет.

- На самом деле, - сказал Роско, - для меня вычислить квадратный корень раз плюнуть. Без всякой кнопки «кв. корень» на старом калькуляторе.

- Пятьдесят три! - крикнул я, тут же бросив ему вызов.

- Запросто, - сказал он, болтая и расправляясь с числами одновременно. - Пятьдесят три близко к 49, поэтому начнем с семи. В 53 семь умещается 7,57 раз. Ясно, что 7 слишком мало, а 7,57 слишком много, поэтому выберем среднее. Сдается мне, что это 7,28. А 7,28 помещается в 53 - ты просто не поверишь - 7,28 раза. Так что я полагаю, 7,28 - это правильный ответ.

Извлечь квадратный корень с двумя знаками после запятой за два деления - это впечатляет. Но у Роско иная точка зрения.

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

Роско обращается к программированию.

Только я подумал, что мир в безопасности, как Роско сделал новое признание. «Шахту закрыли, сынок, - сказал он. - Похоже, нужно искать новую работу. По-моему, я бы справился с каким-нибудь из этих программных проектов».

«Слава богу, что «дот-комовское» безумие утихло», - подумал я. Разве я сумел бы объяснить ему это? С другой стороны, он, несомненно, привнес бы свежий взгляд в наш бизнес. Кое-чему у него можно было бы поучиться.

«Конечно, Роско, - отвечал я. - Займись изучением итеративной разработки. Лучше всего начать с этого. Почитай что-нибудь на эту тему, поговори с людьми и возвращайся». Я надеялся, что это займет его на какое-то время.

- Я к тебе еще вернусь, - сказал он, уходя и стараясь не хлопнуть наружной дверью.

Роско докладывает.

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

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

Я признал, что процент успеха наших программных проектов оставляет желать лучшего. На Роско это не произвело впечатления.

- Похоже, ребята считают, что это очень тяжелое занятие. Чушь! Вот уголь добывать - это действительно тяжело. А здесь... Ведь не с железом работают!.

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

- Позволь тебе напомнить, что пирамиды построили египтяне. Правда, у них был этот Евклид, совсем не дурак, что и говорить.

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

Кое-что мы делаем правильно.

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

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

Я заметил нотку сарказма в сделанном Роско заявлении. Но его было не удержать.

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

Слово «контролер» он произнес правильно и, надо полагать, понимал его. Но «алгоритм» подозрительно походил на «алко-ритмы». «О, черт, подумал я,- у нас большие неприятности: Роско выучил новое слово».

- Роско, где ты подцепил это словечко - «алгоритм»? - спросил я.

- Сынок, я тут поговорил с некоторыми программными архитекторами. - начал было он.

- Так, - сказал я, - это кто же тебе посоветовал?.

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

- Согласен, - сказал я.- И что же ты выяснил?.

Роско подытоживает.

- Мне все понятно. Обычно, начиная проект, плохо себе все представляешь, поэтому первые этапы очень важны. В конце концов, не станешь же строить за $50 изгородь, чтобы стеречь лошадь, которая стоит $10, поэтому я согласен - сначала надо разобраться, что ты хочешь сделать. Мне также нравится идея не бросаться нанимать людей, пока не уяснишь хорошенько, что они должны делать. Иначе они будут просто жевать табак за твои деньги, пока кто-нибудь не придумает, чем их занять.

Мне стало интересно, как Роско оценивает положение.

- Потом я добрался до графика работ и оценки сроков. Тут есть толковые ребята. Ну, например, Барри Боэм (Barry Boehm) и Уокер Ройс (Walker Royce) немного в этом разобрались. Хотя их кокосовая модель - это уже выпендреж.

Я поежился, но не стал поправлять его. В конце концов COCOMO и «кокос» звучат похоже. Кроме того, речь Роско постоянно приходится переводить на обычный язык, поэтому особых дополнительных усилий от меня не потребовалось.

«А потом я почитал неких Крухтена и Буча и даже наткнулся на твое имя. Вот здесь», - сказал он, показывая мне страницу в замусоленной книжке Гради «Объектные решения».

Точно, он застал меня на месте преступления. Вот он я, черным по белому, на стр. 136.

Роско расправляется со всеми.

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

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

- Я даже поговорил со своим приятелем архитектором, и он сказал, что есть особый термин для обозначения тысячи строк кода. Говорит, что это называется KSLOC - от «kilo source lines of code». Тьфу!.

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

- Какая-то шайка бакалавров. Все равно что оценивать проект постройки пирамид и выбрать «кирпич» в качестве единицы измерения. Звучит нелепо, поэтому изобретается «килокирпич». Глупость, какой я еще не встречал.

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

- Однако, как я выяснил в разговоре с этим архитектором, главная проблема в том, что никто не знает, как считать эти «слоки» или «килослоки». Считать ли все строки, включая комментарии. Считать ли заголовки вместе с файлами исходного кода реализации, в которых явно много повторений? И как быть с теми огромными библиотеками, которые вы просто берете, не создавая их с нуля? В принципе для получения этого числа можно воспользоваться услугой «молитва по телефону».

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

Но у него была своя точка зрения. Мы состряпали формулу, основанную на числе, которое, если выразиться мягко, допускало разные интерпретации. Точность прогноза обусловлена нашим определением для SLOC - количества строк исходного кода.

Кое-что мы делаем правильно, часть вторая.

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

- Кое-что ты уловил правильно, Джо. Все дело в квадратном корне. Идея в том, что итераций не должно быть слишком много, потому что начало и конец каждой из них связаны с накладными расходами, которые, как всем понятно, совершенно непроизводительны. С другой стороны, итераций не должно быть слишком мало, потому что тогда теряется весь смысл итеративной разработки. Как в сказке братьев Гримм про горшочек каши все должно быть в меру. Я думаю, что ты был прав, связав длину итерации с квадратным корнем из размера проекта. И выбор недели в качестве единицы измерения тоже был правильным, поскольку это основная единица измерения труда. Ты ошибся только в том, что связался с этими «килослоками». У меня есть гораздо более простой способ.

Я приготовился слушать. Со всем вниманием.

- Главная проблема в том, что ты неверно начинаешь. Надо взять эту кокосовую модель или воспользоваться каким-то другим приемом, чтобы договориться о том, сколько всего времени тебе дадут на выполнение проекта. Руководство всегда хочет получить все быстрее, и ты всегда будешь в итоге обсуждать конечную дату, а не число строк кода. Ты можешь в зависимости от даты выторговывать, скажем, численность команды или набор функций, но в конечном счете фиксированной останется только длительность проекта. Когда она определена, все становится просто. Длительность одной итерации должна быть равна квадратному корню из общей длительности проекта. Дай я тебе покажу свою маленькую табличку. - С этими словами он вытащил табл. 10.2.

Меня нисколько не удивило появление календаря Роско. Его увлечение квадратными корнями не миновало и этих расчетов.

Черт возьми! Посмотрев в свою базу данных проектов, я обнаружил, что оценки Роско не очень с ней расходились. Как он любит говорить: - «одной динамитной шашкой больше или меньше.».

И никаких «слоков». Я был потрясен.

Таблица 10.2. Справочник Роско для вычисления длины итерации

Роско допущен в компанию менеджеров программных проектов.

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

- Послушай, Роско, - сказал я,- ты столкнешься с тем, что заправлять программными проектами - это занятие невероятно щекотливое. Если у тебя возникнут какие-то идеи, я очень хочу, чтобы ты ими со мной поделился.

- Не сомневайся, - сказал он. - До встречи через месяц.

Резюме.

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

Я, конечно, еще не все сказал об оценках сроков. Практическая часть оценивания начинается с графика работ.

В следующей главе Роско высказывает свое мнение о графиках разработки ПО.