Agile методы и базы данных в начале проекта

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

Итак, как Agile проекты справляются с этим, вы начинаете с создания базы данных?

Как бы вы это сделали, например, если бы использовали Scrum, как бы вы делали пользовательские истории и тестировали БД.

Вы бы предпочли сделать части БД в истории, которая также требует кода.

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

Как Agile может помочь вам создать базу данных?

Да, вы будете наращивать базу данных постепенно, добавляя необходимые таблицы и столбцы в соответствии с требованиями истории. Обычно вам не нужна вся база данных, когда вы начинаете свой первый рассказ - например, «Как пользователь, вы должны иметь возможность зарегистрироваться ...», скорее всего, требуется одна таблица с точно определенным набором столбцов.

Если у вас есть история, для которой действительно нужна вся база данных, история Epic - она ​​просто слишком большая и ее нужно разделить.

Новичок в Agile, и я не уверен, как начать.

После прочтения вашего поста, я думаю, вы его неправильно поняли, и вам следует начать с чтения того, что на самом деле означает Agile и пытается его достичь.

Идея заключается в создании небольших частей проекта в спринте.

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

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

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

Итак, как Agile проекты справляются с этим, вы начинаете с создания базы данных?

Agile не обрабатывает базу данных или дизайн системы. Он рассказывает вам, как управлять своим проектом. Имея это в виду, вы начинаете с определения всех функций системы и помещаете их в список продуктов. Затем вы вместе с владельцем продукта назначаете приоритеты функциям, находящимся в очереди. После того, как вы это сделаете, вы начнете извлекать функции из бэклога и создавать спринты (обычно от 2 до 4 недель). Когда спринт заканчивается, у вас должна быть новая рабочая функция в системе, которая может быть доставлена ​​клиенту.

Как бы вы это сделали, например, если бы использовали Scrum, как бы вы делали пользовательские истории и тестировали БД.

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

Вы бы предпочли сделать части БД в истории, которая также требует кода.

Да.

Agile ни в коем случае не является серебряной пулей для управления проектами и может привести к катастрофе, если не применяется правильно. Постарайтесь потратить некоторое время на чтение об этом (вы можете найти много ресурсов здесь или в стеке), возможно, найти кого-то, кто уже работал гибко и может помочь вам набрать скорость.

база данных должна быть почти функциональной, чтобы что-либо делать с проектом.

Во многом ложно.

Итак, как Agile проекты справляются с этим, вы начинаете с создания базы данных?

Пустая база данных, да. Затем добавьте таблицы по мере необходимости, чтобы закончить спринт.

как бы вы делали пользовательские истории и тестировали БД?

Что ты спрашиваешь? Agile не имеет ничего общего с дизайном базы данных.

Вы пишете историю.

Вы разрабатываете решение.

Вы создаете таблицы и код.

Вы проверяете код.

Вы бы предпочли сделать части БД в истории, которая также требует кода?

Какой другой выбор есть? Делать все сначала БД? Это невозможно.

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

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

Во-вторых, вы бы создали достаточно таблиц для реализации истории.

Как Agile может помочь вам создать базу данных?

Что ты спрашиваешь?

Agile - это управление проектами. Это не помогает с любым дизайном.

Это просто поможет вам разбить большую работу на мелкие кусочки.

Хорошо, во-первых, следуйте поэтапному подходу. Выберите модуль, определите его требования, наметьте функциональность, нацельтесь на функциональную область, а затем - моделирование, дизайн БД, алгоритмы, коды и, наконец, протестируйте его и повторите процесс.

Ваш вопрос кричит об анти-паттерне разработки AgileFall .

Что это? Обычно это организация, которая традиционно разрабатывает программное обеспечение с использованием метода Водопада, но затем, поскольку они понимают, что оно не работает, они борются за внутреннее внедрение гибких методов. Возникающий «провал-газ» обычно возникает потому, что истинный Agile ТРЕБУЕТ фундаментальной организационной перестройки от того, как устроены многие известные магазины Waterfall. И, конечно, они, как правило, будут оставаться структурированными, так как многие влиятельные и опытные люди считают, что им необходимо внедрить себя в процесс, когда Agile показывает, насколько бесполезны эти люди для разработки программного обеспечения.

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

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