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

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

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

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

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

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

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

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

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

Значит ли это, что любой проект — это лотерея? Да, во многом так оно и есть: не разобравшись в некоторых вопросах планирования, о которых пойдёт речь в этой главе, вы сильно рискуете. Иногда этот риск оправдан, но чаще — нет. Почему? Да потому, что в данном случае все против вас: чем больше вы делаете допущений, тем больше риск.