Поздняя неоднозначность
Поздняя неоднозначность
Как решить проблему преждевременной точности? Откладывая точные определения на как можно более поздний срок. Профессиональные разработчики не формулируют требования до того, как будут готовы к разработке. Однако такой подход может привести к другому несчастью: поздней неоднозначности.
Между ключевыми участниками проекта часто возникают разногласия. В таких случаях часто бывает проще «заговорить» проблему, чем решать ее. Они находят такую формулировку требования, с которой будут согласны все, без реального разрешения спора. Однажды я слышал, как Том Демарко сказал: «неоднозначность в документе с требованиями появляется из-за разногласий между участниками[34]».
Конечно, неоднозначность не всегда появляется из-за споров или разногласий. Иногда ключевые участники проекта просто считают, что читатели требований знают, что они имеют в виду. Возможно, их формулировки абсолютно ясны им самим в их контексте, но означают нечто совершенно иное для программиста, читающего документ. Подобная контекстная неоднозначность также может возникать и при личном общении заказчиков с программистами.
Сэм (ключевой участник проекта): «Так, еще нужно организовать резервное копирование журнальных файлов».
Пола: «С какой частотой?»
Сэм: «Ежедневно».
Пола: «Понятно. И где будут храниться резервные копии?»
Сэм: «В смысле?»
Пола: «Наверное, они должны сохраняться в определенном подкаталоге?»
Сэм: «Да, пожалуй».
Пола: «И как он будет называться?»
Сэм: «Может, backup?»
Пола: «Да, нормально. Значит, журнал будет ежедневно сохраняться в каталоге backup. В какое время?»
Сэм: «Ежедневно».
Пола: «Нет, в какое именно время суток?»
Сэм: «В любое».
Пола: «В полдень?»
Сэм: «Нет, только не во время торгов. Лучше в полночь».
Пола: «Хорошо, пусть будет полночь».
Сэм: «Отлично, спасибо!»
Пола: «Всегда рада помочь».
Позднее Пола рассказывает о задаче своему коллеге Питеру.
Пола: «Значит, журнал должен копироваться в подкаталог с именем backup ежедневно в полночь».
Питер: «Понятно. А как будет называться файл?»
Пола: «Я думаю, log.backup подойдет».
Питер: «Хорошо».
В другом офисе Сэм общается по телефону с заказчиком.
Сэм: «Да, да, журнальные файлы будут сохраняться».
Карл: «Очень важно, чтобы ни один журнал не был потерян. Нельзя исключать, что нам придется когда-нибудь вернуться к любому из этих файлов, даже через месяцы или годы – в случае сбоя питания, какой-нибудь катастрофы, судебного спора и т. д.».
Сэм: «Не беспокойтесь, я только что говорил с Полой. Журналы будут сохраняться в каталоге с именем backup ежедневно в полночь».
Карл: «Хорошо, это подойдет».
Вы заметили неоднозначность? Заказчик ждет, что сохраняться будут все журналы, а Пола думает, что достаточно сохранить журнал за последний день. Если заказчик захочет вернуться к резервной копии месячной давности, он найдет только данные последнего дня.
В данном случае и Пола, и Сэм оказались не на высоте. Профессиональные разработчики (и менеджеры) должны следить за тем, чтобы из требований была исключена всякая неоднозначность.
Это сложная задача, и мне известен только один способ ее решения.
Данный текст является ознакомительным фрагментом.