Системные аналитики Контура

Тест кейсы являются вспомогательным инструментом, но на мой взгляд это важная часть практики, поскольку они помогают: обеспечить покрытие проверки всех критериев приемки, сократить дальнейшее время на тестирование задач, послужить основой для дальнейшей автоматизации тестирования.

+ Практика подразумевает включение тестировщика, а это его основные артефакты работы, так что можно назвать их обязательным. Но повторюсь, что практика может быть адаптирована и под ваши процессы, у нее нет четкого регламента.

Его может заменить человек, который занимается тестированием/приемкой реализации вашего продукта. Это может быть, например, разработчик/продакт.

На мой взгляд можно выделить следующие случаи:

— для простых задач, где вы работаете с очевидными требованиями, условно «Добавить кнопку, по которой должен происходить редирект по ссылке». В таких случаях вы просто потратите зря время на обсуждения того, что уже понятно

— также в случае, когда у вас не выстроен процесс поставки бизнес-требований, и они могут хаотично меняться в процессе разработки. Вы тогда погрязнете не только в рутине изменений спецификации, но и в череде этих встреч

— для технических задач, рефакторинга — что не влияет на бизнес — эта практика также может стать избыточной.

Встречи проходят продуктивнее, когда снижаешь градус формальности и общаешься с коллегами, как со своими друзьями, не боясь сказать глупость :)

Вы можете потратить много времени на встрече, если не зададите четкий регламент. Важно следить за объемом встречи и количеством обсуждаемых сторей, иначе вы уйдете в бесконечную череду обсуждений.

Разработчик участвует в подготовке ко встрече: анализирует спецификацию и кейсы, тем самым он подключается заранее к обсуждениям, замечает нюансы технической реализации, участвует в согласовании критериев приемки и кейсов.

БА может также принимать участие во встрече, но его участие предусмотрено раньше, на этапе, когда вам поступают бизнес-требования, а вы по ним готовите спецификацию

Лично я избавилась от траты времени на актуализацию документации, сократили время на обсуждения требований во время разработки.
Сократили количество аксептанс багов на задачу.

Периодически могут возникать проблемы с таймингами и обсуждениями лишних вопросов, но это вопрос притирки участников команды друг к другу и процессам.

По инструментам: мы использовали confluence для спецификации + внутренний инструмент компании, который помогает подготавливать доски с карточками. Вы можете использовать Miro/draw.io для визуализации.

В Банке только эта практика была. Ранее были дискавери-встречи, на которых команда просто смотрела макеты от дизайнера.

Для работы с диаграммами в docs-as-code есть Mermaid — это язык визуальной разметки для создания диаграмм.

Да, в “творческом” режиме, когда вы не знаете, какой будет диаграмма и рисуете её с нуля (например, моделируете сложный пользовательский сценарий или архитектуру части сервиса), гораздо удобнее будут те же Miro или Holst. Но когда диаграмма готова и её нужно просто перенести в документацию, Mermaid прекрасно справляется.

Плюс, Mermaid позволяет делать активными ссылками блоки диаграммы, что очень удобно, например, при работе с теми же пользовательскими сценариями, когда диаграмма представляет общий вид сценария, а при нажатии на каждый конкретный шаг вы проваливаетесь в статью с описанием, что происходит на этом шаге “под капотом” у сервиса.

Всё зависит от всего размера документации и времени, выделенного на процесс переезда.

Если документация небольшая и у вас есть какое-то обозримое время (неделя-две), можно спокойно перенести всё руками, например копированием страниц (Obsidian хорошо справляется с конвертацией страниц в Markdown). Можно попробовать выгрузить все страницы и конвертировать их в md-разметку с помощью какой-нибудь библиотеки, но, насколько я знаю, таких, которые хорошо работают, не оставляют множество артефактов и бесплатные - нет.

Если документации много, а времени на переезд не выделено (приближенный к жизни вариант), организуйте процесс переезда на уровне командного процесса разработки. Заложите себе в планирование какое-то окно, в которое вы будете перевозить документацию и методично занимайтесь этим. В этом процессе тоже есть подводные камни и проблемы (например, ведение двух документаций в какой-то момент времени или неизбежное отставание одной доки от другой), но это издержки процесса, с которыми надо смириться и учесть их при планировании.