С одной стороны работа с git позволяет отслеживать изменения в документации, связанные с конкретной задачей. Но система трассировки требований тут отсутствует.
Теоретически, можно использовать скрытые теги в комментариях при написании документации и помечать те или иные части документации идентификаторами требований. Тогда поиск по этим идентификаторам будет выдавать те места, где они есть. Но для этого у вас, как минимум, должна быть система ведения бизнес требований, в которой эти требования имеют идентификаторы.
Например, в markdown это будет выглядеть так:
3. Проверить, существует ли такой пользователь. <!--#Требование FR-002 --> Для этого:
* Найти в таблице [users] запись, для которой:
В описании при просмотре из git комментария видно не будет, но поиск по 'FR-002' выдаст результат.
Если честно, то статья про то "как проводить ретро" упускает самое главное: а зачем вообще вы его проводите? Нафига вам ретро? Для кого вы использунте этот инструмент?
Я был в нескольких компаниях и в 80% случаев ретро проводят потому, что надо провести ретро. И идут по описанным в статье сценариям.
А там где понимают, зачем нужно ретро проводят её совсем по другому.
Меня раздражают эти абстрактные вопросы, мнимые решения с выбором ответсвенных, если в результате ничего не меняется. Хоть корабликом плыви, хоть гапак танцуй. Если вы сами не понимаете, зачем это нужно, то любой формат пройдёт мимо. Уверенно, задорно и мимо.
Подскажите, есть ли поддержка операции include в файлах plantuml? У меня большинство сиквенс диаграмм сборные из разных частей.
Можно ли вставлять puml файлы в статьи на markdown? В gitlab мне для этого приходится asciidoc использовать.
Если поделитесь подробностями - буду признателен.
Хороший вопрос.
С одной стороны работа с git позволяет отслеживать изменения в документации, связанные с конкретной задачей. Но система трассировки требований тут отсутствует.
Теоретически, можно использовать скрытые теги в комментариях при написании документации и помечать те или иные части документации идентификаторами требований. Тогда поиск по этим идентификаторам будет выдавать те места, где они есть. Но для этого у вас, как минимум, должна быть система ведения бизнес требований, в которой эти требования имеют идентификаторы.
Например, в markdown это будет выглядеть так:
В описании при просмотре из git комментария видно не будет, но поиск по 'FR-002' выдаст результат.
А как же plantUML?
Почему не рассматривали?
Если честно, то статья про то "как проводить ретро" упускает самое главное: а зачем вообще вы его проводите? Нафига вам ретро? Для кого вы использунте этот инструмент?
Я был в нескольких компаниях и в 80% случаев ретро проводят потому, что надо провести ретро. И идут по описанным в статье сценариям.
А там где понимают, зачем нужно ретро проводят её совсем по другому.
Меня раздражают эти абстрактные вопросы, мнимые решения с выбором ответсвенных, если в результате ничего не меняется. Хоть корабликом плыви, хоть гапак танцуй. Если вы сами не понимаете, зачем это нужно, то любой формат пройдёт мимо. Уверенно, задорно и мимо.