"Время — деньги. Создание команды разработчиков программного обеспечения" - читать интересную книгу автора (Салливан Эд)

Общие проблемы и решения

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

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

Ответ однозначен: «Да». Некоторые подходы к разработке ПО подразумевают затрату значительного времени на анализ и вывод подробных формулировок требований. Но подход, рассматриваемый в этой главе (и в следующих двух) предлагает цикл определения требований — он экспериментально проверен и подтверждён положительными отзывами. Это не только не позволяет группе расслабиться, но и даёт возможность проявить творческий подход и поэкспериментировать, прежде чем черновики планов будут созданы и переданы на утверждение. Кроме того, использование прототипов пользовательского интерфейса и технических решений позволяет увидеть и почувствовать результаты работы над проектом.

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

Рассмотрим в качестве примера вышеупомянутое приложение для обработки заказов. Одно из ключевых требований таково: «Принимая заказ на товар, нужно собрать следующую информацию: X, Y и Z». Заметьте: требование содержит формулировку самой задачи, но не способа её решения. Можно привести пример требования с описанием способа его реализации: «Пользователь должен выбрать в меню пункт New|Create Order и ввести нужную информацию в диалоговом окне». Лучше позволить команде, ответственной за разработку пользовательского интерфейса, самостоятельно найти лучший способ реализации этого требования путём работы с прототипом.

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