цветов взяты из бренд-бука компании, который в этот момент также находится в разработке, поэтому цвет может быть и #0000BB, и #EEEEEE, и еще множество других вариантов, которые сейчас неизвестны.
Конечно, сразу возникает идея сначала закончить и утвердить в таком случае бренд-бук, а затем уже его использовать в других проектах. В реальности обстоятельства могут требовать одновременности работ, обусловленной ограниченными сроками получения результатов обоих проектов по экономическим, управленческим, регуляторным или иным причинам.
Теперь по втором требованию. Пусть, для примера, фраза «Ваша карточка сохранена!» не полностью нравится бизнес-заказчику, у него есть мнение, что текст может быть «Операция выполнена!» или «Документ сохранен!», между которыми он никак не может выбрать.
Изменения по этим требованиям вроде бы не выглядят трудоемкими, но, если они потребуются десятки раз в течение проекта (а это вполне реально, если заказчик колеблется в выборе), это уже будет ощутимо.
Одним из вариантов сразу видится вынести формулировку текста в настройки, чтобы не менять код каждый раз.
Может сработать. Но может и нет, если текст будет существенно разной длины и это повлечет изменение верстки.
Важно то, что наше внимание к особенностям реализации требования обусловлено не его содержанием «вывести текст», а его состоянием «заказчик колеблется в выборе текста».
Возвращаясь к общему случаю, получаем другую, более сложную модель требования, которая опирается на то, что:
– содержание требования, как его понимают все участники проекта, может изменяться в ходе проекта;
– связи требования с другими требованиями могут прояснятся и изменятся значимым для понимания других требований образом в ходе проекта;
– состав требований проекта может изменяться в ходе его выполнения, а именно, возможно возникновение новых требований, а какие-то существующие требования могут удалятся из рассмотрения как неактуальные.
Назовем это динамической моделью требования.
Перечитаем еще раз… Ничего стабильного… Как с этим работать то можно? Кажется, что с такими постулатами мы стоим на чем-то зыбком и совершенно неустойчивом… Как обрести твердую почву под ногами? Ответ прост – «замораживать» на время проведения работ. Именно так поступают строители, когда возводят сооружения на неустойчивых грунтах, также будем поступать и мы.
Стоит заметить, что если динамика возникает в требованиях, то в критериях приемки тоже появляется динамика, обусловленная этими изменениями требований.
Итерационные и гибкие методологии, как средства реализации динамической модели требований
Разработка чего бы то ни было, будь то программное обеспечение, опытный образец продукта, методика или иной продукт творческо-производственной деятельности, происходит по одному и тому же укрупненному циклу:
– требования;
– проектирование;
