Ещё раз перечитал ваш комментарий. Возник такой вопрос: а как у вас проходят change requests? Сразу же меняется исходное issue-требование? Как тогда понять к какому релизу — какое требование применялось?
Приведу пример:
Релиз 1. Появилось новое требование REQ-1 из 10-ти пунктов.
Релиз 2. По требованию REQ-1 решено изменить п.п. 2 и 3
Релиз 3. По требованию REQ-1 решено убрать п. 7
На текущий момент мы видим REQ-1 в состоянии п.п. 1,4-6,8-10 из релиза 1, п.п. 2-3 из релиза 2. Да, в истории изменений видно, что когда-то описание требования поменялось. Но как вы понимаете, что в релизе 1 всё работало, так как было в описании на момент релиза 1? Как вы видите картинку по всему продукту для релиза 1 с учётом того, что уже внесены изменения по релизу 3?
Это та самая проблема реализации Baselines.
Мы очень хотели настроить Jira под требования. И достаточно долго работали над этим. Ответ на ваш вопрос «почему не Jira» достоин отдельного поста. Тезисно могу ответить так:
Привязка к одному решению ALM
Трассировка требований. Она искусственная, и трудозатраты по поддержке её целостности — это отдельный большой труд (даже используя Structure)
Коллаборация с заказчиком для обсуждения и аппрува требований. Если у вас монопродукт — то можно пустить заказчика прямо в Jira, если несколько, то разделение доступа по проектам — это боль, которую мы не смогли преодолеть (вершина достижений — выгрузка в Trello)
Story mapping. Плагины для jira (а они есть) — мы не смогли с ними сработаться. Намного приятнее StoriesOnBoard и менее приятно FeatureMap в связке с Jira. Но тоже есть свои вопросы.
То что у нас точно летело — это требования в Confluence, там же общение с заказчиком в пределах одного пространства, использование «Handy Status» для организации WorkFlow, и отчёта по свойствам страниц — как общей картины по разработке.
Приведу пример:
Релиз 1. Появилось новое требование REQ-1 из 10-ти пунктов.
Релиз 2. По требованию REQ-1 решено изменить п.п. 2 и 3
Релиз 3. По требованию REQ-1 решено убрать п. 7
На текущий момент мы видим REQ-1 в состоянии п.п. 1,4-6,8-10 из релиза 1, п.п. 2-3 из релиза 2. Да, в истории изменений видно, что когда-то описание требования поменялось. Но как вы понимаете, что в релизе 1 всё работало, так как было в описании на момент релиза 1? Как вы видите картинку по всему продукту для релиза 1 с учётом того, что уже внесены изменения по релизу 3?
Это та самая проблема реализации Baselines.
То что у нас точно летело — это требования в Confluence, там же общение с заказчиком в пределах одного пространства, использование «Handy Status» для организации WorkFlow, и отчёта по свойствам страниц — как общей картины по разработке.