В Scrum, как вертикальные срезы работают с базой данных scemas?

Question

Я только что закончил два дня гибкого/scrum коучинга на работе, что было здорово. Я начинаю профессиональное программирование, поэтому мне это нужно. Тем не менее, я очень сильно борюсь с понятием вертикальной резки. В частности, я не вижу, как схема базы данных может появиться у нескольких разработчиков, работающих отдельно по всем уровням развития (спереди и сзади)? Проектирование схемы базы данных всего за один раз называется горизонтальной нарезкой, и считается не-нет. Я знаком с реляционным отображением объектов - немного - от работы с такими фреймворками, как Grails. Но опять же, я все еще разработал схему и работал оттуда.

Чтобы быть ясным, я не спорю против дела для гибкой/схватки/вертикальной резки, скорее я спрашиваю, как это возможно? - в частности, когда приходит отображение объектов в схему базы данных, как это может быть сделано несколькими разработчиками в тандеме, а не с самого начала?

Эта статья, которая мне действительно нравится, - если я прочитал ее правильно - предположим, что схема базы данных должна быть разработана на этапе весеннего планирования до того, как будут выполнены какие-либо истории пользователей. http://www.vertabelo.com/blog/notes-from-the-lab/data-modeling-in-agile-development-one-data-modelers-experience

Answer 1

Это сообщение объясняет это довольно хорошо: http://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-vertical-slices/

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

Из приведенной выше статьи:

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

Answer 2

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

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

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

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