Живые требования – тот еще фрукт. Актуализируем и реализуем, пока не испортились

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

Одним из вариантов сразу видится вынести формулировку текста в настройки, чтобы не менять код каждый раз.

Может сработать. Но может и нет, если текст будет существенно разной длины и это повлечет изменение верстки.

Важно то, что наше внимание к особенностям реализации требования обусловлено не его содержанием «вывести текст», а его состоянием «заказчик колеблется в выборе текста».

Возвращаясь к общему случаю, получаем другую, более сложную модель требования, которая опирается на то, что:

– содержание требования, как его понимают все участники проекта, может изменяться в ходе проекта;

– связи требования с другими требованиями могут прояснятся и изменятся значимым для понимания других требований образом в ходе проекта;

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

Назовем это динамической моделью требования.

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

Стоит заметить, что если динамика возникает в требованиях, то в критериях приемки тоже появляется динамика, обусловленная этими изменениями требований.

Итерационные и гибкие методологии, как средства реализации динамической модели требований

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

– требования;

– проектирование;

– изготовление;

– проверка соответствия требованиям;

– устранение несоответствий;

… (пока не будет устранено несоответствие требованиями)

– проверка соответствия требованиям;

– приемка (передача в эксплуатацию)

Предсказуемость (да и возможность) выхода из этого цикла зависит от двух параметров:

– фиксированы ли требования,

– возможно ли исправить несоответствие требованиям.