Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

Со временем безмолвная сортировка завершается и начинается обсуждение. Участники разбираются во всех разногласиях по поводу порядка карт. Возможно, для достижения согласия придется провести краткое обсуждение или нарисовать от руки несколько условных схем.

На следующем этапе между картами рисуются линии, представляющие трудоемкость задачи в днях, неделях, условных пунктах и т. д. Традиционно используются пять значений, образующих последовательность Фибоначчи (1, 2, 3, 5, 8).

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

В оценке заложена ошибка. Собственно, поэтому они и называются оценками. Один из способов контроля ошибок основан на законе больших чисел . [48]В частности, из этого закона следует, что при разбиении большой задачи на несколько меньших и независимой их оценке сумма оценок меньших задач будет более точной, чем одна оценка большей задачи. Возрастание точности объясняется тем, что погрешности оценки меньших задач взаимно компенсируются.

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

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

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

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

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

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

Какого поведения вы ждете от врача? Вы предпочитаете, чтобы он был спокойным и собранным? Чтобы он отдавал ясные, четкие приказы ассистентам? Чтобы он помнил все, чему его учили, и придерживался действующих норм?

А если врач потеет и ругается? Швыряет инструменты? Обвиняет руководство в нереалистичных требованиях и постоянно жалуется на нехватку времени? Как он должен вести себя – как профессионал или как типичный разработчик?

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

В 1988 году я работал в Clear Communications. Это была начинающая фирма, которая так никогда и не «поднялась». Мы прошли через первый цикл финансирования, потом второй и третий.

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