Управление версиями продукта в Confluence с PRD

Используя Confluence, я собрал серию PRD для будущего релиза. Каждый PRD описывает функциональную «единицу» приложения, такую ​​как «редактор», «управление пользователями», «управление клиентами» и т. д. Используя встроенный документ с требованиями к продукту, я устанавливаю целевой выпуск (например, «v1») для каждого ПРД. Затем, следуя методу MoSCoW, я устанавливаю важность для каждого требования. Все это очень близко следует очень полезному руководству , предоставленному службой поддержки Confluence.

Тогда возникает проблема: как установить список требований для следующего выпуска (например, "v2")?

Если PRD описывает функциональный блок, он неизменно будет содержать требования для разных выпусков (это не будет «готово» при поставке этой версии), поэтому странно, что существует Целевой выпуск для всего PRD. Кажется, что было бы более разумно ориентировать версии для каждого требования в PRD, что метод MoSCow в некотором роде эмулирует, но это не одно и то же.

1. Одним из способов решения этой проблемы может быть использование разных PRD для каждой функциональной единицы + версии, например, «редактор v1» и «редактор v2». Проблема здесь в том, что, вероятно, существует дублирование требований: что-то с «может быть» для версии 1 может быть «должно быть» для версии 2 и «должно быть» для версии 3. Это кажется грязным. Кроме того, кажется, что это противоречит понятию целевого выпуска для PRD. В руководстве по поддержке Confluence, указанном выше, есть PRD под названием «Требования к приложению Android v1» с целевой версией... подождите... «1.0». Это кажется в лучшем случае избыточным, а в худшем — запутанным.

2. Другой способ решения этой проблемы может заключаться в том, чтобы оставить PRD такими, какие они есть, а когда версия будет выпущена, обновить Целевой выпуск и Важность для каждого из оставшихся требований для каждого PRD. Итак, как только v1 выйдет, измените целевой выпуск «редактора» на «v2», удалите требования, которые были отправлены, и увеличьте важность требований, которые все еще существуют. Проблема здесь в том, что видимость ограничена следующим выпуском. Возможно, это хорошо, но если вы делаете какую-либо дорожную карту , было бы неплохо предложить руководство по требованиям для ряда различных версий, которые появятся в будущем.

3. Тем не менее, третий вариант может состоять в том, чтобы иметь отдельные документы для каждой версии и перечислять требования для каждой, возможно, даже ссылаясь на PRD. Таким образом, может быть страница «Требования v1» с разделом «Редактор», в котором перечислены все «обязательные элементы» для этого выпуска, а затем страница «Требования v2» и т. д. Проблема здесь в том, что это кажется большим количеством дублирование, которое потенциально может стать беспорядочным. Вы должны не только отслеживать все требования в PRD, но и отслеживать их все на странице требований к каждой версии.

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