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

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

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

Поздняя неоднозначность

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

Между ключевыми участниками проекта часто возникают разногласия. В таких случаях часто бывает проще «заговорить» проблему, чем решать ее. Они находят такую формулировку требования, с которой будут согласны все, без реального разрешения спора. Однажды я слышал, как Том Демарко сказал: «неоднозначность в документе с требованиями появляется из-за разногласий между участниками[34]».

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

Сэм (ключевой участник проекта): «Так, еще нужно организовать резервное копирование журнальных файлов».

Пола: «С какой частотой?»

Сэм: «Ежедневно».

Пола: «Понятно. И где будут храниться резервные копии?»

Сэм: «В смысле?»

Пола: «Наверное, они должны сохраняться в определенном подкаталоге?»

Сэм: «Да, пожалуй».

Пола: «И как он будет называться?»

Сэм: «Может, backup?»

Пола: «Да, нормально. Значит, журнал будет ежедневно сохраняться в каталоге backup. В какое время?»

Сэм: «Ежедневно».

Пола: «Нет, в какое именно время суток?»

Сэм: «В любое».

Пола: «В полдень?»

Сэм: «Нет, только не во время торгов. Лучше в полночь».

Пола: «Хорошо, пусть будет полночь».

Сэм: «Отлично, спасибо!»

Пола: «Всегда рада помочь».

Позднее Пола рассказывает о задаче своему коллеге Питеру.

Пола: «Значит, журнал должен копироваться в подкаталог с именем backup ежедневно в полночь».

Питер: «Понятно. А как будет называться файл?»

Пола: «Я думаю, log.backup подойдет».

Питер: «Хорошо».

В другом офисе Сэм общается по телефону с заказчиком.

Сэм: «Да, да, журнальные файлы будут сохраняться».

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

Сэм: «Не беспокойтесь, я только что говорил с Полой. Журналы будут сохраняться в каталоге с именем backup ежедневно в полночь».

Карл: «Хорошо, это подойдет».

Вы заметили неоднозначность? Заказчик ждет, что сохраняться будут все журналы, а Пола думает, что достаточно сохранить журнал за последний день. Если заказчик захочет вернуться к резервной копии месячной давности, он найдет только данные последнего дня.

В данном случае и Пола, и Сэм оказались не на высоте. Профессиональные разработчики (и менеджеры) должны следить за тем, чтобы из требований была исключена всякая неоднозначность.

Это сложная задача, и мне известен только один способ ее решения.

Приемочные тесты