Я думаю, что вы сосредотачиваетесь на неправильных ценностях. В Agile бизнес-ценность находится в центре внимания. Вы создаете продукт для того, чтобы предоставить бизнес-ценность некоторым конечным пользователям.
Если вы создаете слой постоянства поздно или создаете его по пути, ваша стратегия заключается в предоставлении бизнес-ценности клиенту. Я не верю, что сам термин «agile» диктует, следует ли вам делать то или другое.
Точка зрения на отсрочку стратегии хранения данных отстаивается в этой презентации Робертом К. Мартином (один из авторов гибкого манифеста).
Это очень хорошая презентация, я могу рекомендовать вам посмотреть ее.
Но я не согласен с этим! По крайней мере, в определенной степени.
Я не верю, что вы можете назвать пользовательскую историю для «Готово», если пользовательская история включает в себя данные, которые должны быть сохранены, и у вас фактически не реализован какой-либо тип постоянства.
Если владелец продукта решит, что сейчас самое время начать работу, вы не сможете этого сделать. И если вы не начали внедрять постоянство до поздней стадии проекта, у вас также нет информации о том, сколько времени потребуется для реализации уровня постоянства, что делает его серьезным риском для проекта.
Гибкие проекты, над которыми я работал, не откладывали стратегию доступа к данным. Но он был отделен, что позволило нам изменить его по пути. И вся схема базы данных не разработана заранее. Таблицы и столбцы создаются по пути, необходимому для реализации хранимых пользователем данных, которые, в конце концов, обеспечивают ценность для бизнеса.