Как управлять отставанием продукта с несколькими приложениями

Question

Я собираюсь начать работу над проектом, который будет состоять из Windows Store, Windows Phone и веб-приложения с каждым из этих приложений, подключающихся к веб-API. Чтобы управлять ими, я буду использовать Team Visual Studio Team Services.

Для каждой функции я планировал создать элемент backlog, а связанные задачи будут описывать, как эта функция будет реализована, начиная с пользовательского интерфейса, через веб-API, в базу данных и т. Д. Таким образом, как только элемент отставания будет выполнен У меня должна быть функция, которая работает от конца до конца.

С каждым из приложений, имеющих те же функции, я нахожу, что я создаю те же элементы журнала. В этом случае для одного элемента backlog я должен создать его 3 раза, один для Web, Windows Store и Windows Phone. Кроме того, связанные с ними задачи различаются только в задачах пользовательского интерфейса. Например, каждое приложение будет иметь разные задачи пользовательского интерфейса, но задачи, связанные с веб-API, базой данных, и т. Д., Одинаковы.

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

У кого-нибудь есть предложения?

Answer 1

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

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

Затем у меня есть дополнительные Истории, которые представляют собой работу по созданию на телефоне/Магазине/планшете/etc UI на уже разработанных функциях. Это будут меньшие истории, и, хотя я, возможно, разделил его на 100 историй/функций для WebUI, когда просматривая истории для пользовательского интерфейса телефона, я могу группировать функции вместе, поэтому у меня может быть только 10 историй для создания пользовательского интерфейса телефона и каждого история включает в себя всю область приложения (например, 1 Phone Story = ~ 10 веб-историй).