Комментарии 4
А почему не захотели настроить Jira под требования? У нас все требования в Jira, а Confluence служит только для выдачи их в структурированном виде. В итоге получается интересная база знаний. В каждом требовании есть поле Justification, которое определяет, почему оно есть. Можно делать ссылки на взаимосвязанные требования. Также есть классификация по компонентам, стейкхолдерам, другим фичам и таким образом каждый может отсортировать и сгруппировать требования, как им хочется. Вся эволюция видна, как на ладони в виде комментариев и истории изменений. Также есть workflow для прохождения комментариев через жизненный цикл — создания, ревью, утверждения.
Дальше из этих требований идут линки на тестовый план, опять же в виде тестовых кейсов в 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.
Ну нельзя сказать, что этот процесс до конца отработан, но как-то так:
Каждому требованию присваиваются релизы где оно применяется.
Если требование изменилось — то старое требование не меняется, а создается новое, которое присваивается новому релизу, а старое остается на последнем релизе. Есть линки clone между этими требованиями, так как новое основывается на старом.
Т.е. все ваши три изменения приведут к трем индивидуальным REQ с разными номерами, присвоенными соответственно к релизу 1, 2 и 3.
Тогда в Confluence по фильтру нужного релиза получается список всех требований, которые к нему относятся.
Полевые исследования концепции «Documentation as code»