Comments 10
Грамотное управление требованиями - залог хорошего продукта.
Я тоже делал систему управления требованиями для команды аналитиков, и тоже в Obsidian 😀
https://github.com/dimonier/Obsidian-Requirements-Management
Одновременно измененные MD через Obsidian git нормально мёрджатся, а вот если одновременно изменить canvas, тогда чуда не произойдет, и придется исправлять конфликт вручную. Это единственный недостаток командной работы над требованиями в Obsidian с синхронизацией через git, в остальном работает шикарно.
Не знаю, что такое MD, нагуглить не смог.
Canvas не пользуюсь, т к. не понимаю, как этот плагин может помочь в разработке требований.
Моя статья именно для людей, которые видят проблему коммуникации между аналитиками и программистами. Именно для этого номерные идентификаторы, именно для этого .obsidian не хранится в git.
Мне понравилось. Спасибо за статью и отдельное спасибо за Front Matter Title. Давно искал такой плагин.
После того что надо в номерах тасок делать гэпы читать стало совсем больно. Выглядит как записи в бумажном пронумерованном журнале. 20+ лет автоматизации что-бы перенести бумажный процесс в цифру не уйд от бюрокраитии. Документооборот опять пошел по спирали с наихудшего его варианта.
Дисциплина в проекте это больно, пока не привыкнешь.
Потом наоборот: экономит усилия и позволяет быстро вводить людей в курс, контролировать изменения и, главное, не переделывать лишний раз бизнес-логику в коде.
Если у Вас есть вариант лучше, чем гэпы в номерных идентификаторах (требований, а не тасок), то будет интересно прочитать. Я взял идею из Бейсика 1980-х годов.
К сожалению или к счастью, но универсального общедоступного инструмента для разработки и требований, и кода, трассируемого в требования, не существует. Раз так, то приходится брать контроль за идентификаторами в свои руки. Это, как раз, не больно.
В моей реализации по ссылке в первом комменте идентификаторы требований семантические - от общего к частному через точку.
Это даёт дополнительные возможности поиска и связи требований, ну и в принципе удобно.
P.S. MD - это Markdown, как верно отметили выше. Прошу прощения, что непонятно высказался. Думал, что в контексте Obsidian будет понятно.
Разработка требований к ПО с помощью Markdown, Git и Obsidian