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