Я хочу объяснить, почему спецификацию нельзя менять во время разработки

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

Спецификация почти всегда изменяется во время разработки для любого, кроме самого простого проекта.

Причины:

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

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

• Давление крайнего срока приводит к сокращению функций.

• Обнаружены дополнительные заинтересованные стороны для проекта (например, в середине проекта аналогичный проект обнаружен в другой области, и общие подсистемы должны быть централизованы / разделены - это произошло со мной в середине двухлетнего проекта, что привело к серьезным architeching).

• Дополнительные спонсоры проекта предъявляют новые технические требования (один из самых известных примеров - история разработки Bradley Fighting Vehicle).

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

• Изменения спецификаций приводят к изменениям кода, отвлекая вас от завершения частей проекта, которые еще не написаны (как мы все знаем и проповедуем Джоэлем Спольски, изменения фокуса очень плохи для разработчиков)

• Некоторые изменения в спецификации (иногда кажущиеся ОЧЕНЬ незначительными) могут привести к необходимости полной реинжиниринга / ре-архитектуры системы, поскольку выбор между двумя архитектурами был сделан на основе предположения, взятого из спецификации .

• В случае TDD, большая часть работы, введенная в тесты, может быть аннулирована.

• Если изменения в спецификации происходят от дополнительных заинтересованных сторон, как отмечено выше, они могут противоречить существующей спецификации, что приводит к значительному снижению качества продукта (см. «Боевая машина», Брэдли).

• Изменение спецификации может нарушать некоторые существующие бизнес-требования, о которых сменщик / заказчик, возможно, не знал или не заботился (на самом деле это то же самое, что и последний пункт).

Все это, конечно, продлевает (иногда значительно) срок поставки проекта и потенциально увеличивает вероятность появления дефектов.

Для лучшего примера того, как незначительные изменения в спецификации могут создать серьезные проблемы, у меня есть 3 буквы для вас:

Y2K .

Все, что они сделали, это изменили спецификацию, чтобы сказать « должен работать после 2000 года ».

Кроме того, в некоторых ситуациях это действительно так, что спецификация НЕ ДОЛЖНА изменяться (в отличие от «не должна меняться без уважительной причины»):

• Часть спецификации является (или зависит от) спецификацией внешней системы, с которой должны быть интерфейсы.

• Часть спецификации является (или зависит от) аппаратным обеспечением, на котором реализована система.

• Требования контракта с клиентом (хотя ограничение строго сводится к изменению спецификации без предварительной обработки изменений с клиентом и изменения контракта, а не просто факт изменения)

• Система, возможно, должна соответствовать определенным законодательным или нормативным требованиям независимо от предпочтений клиента. Примеры: шифрование кредитной карты, защита налоговых данных.

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

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

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

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

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

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

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

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

Лучшая аналогия, которую я имею, - это сравнить ее со строительством дома. Архитектор составляет планы, а затем составляет смету, а затем клиент соглашается (или нет) с планом. Если клиент хочет добавить дополнительную ванную, работа прекращается, планы меняются, делается новая оценка, и клиент соглашается (или нет).

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

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