Я бы сказал, что не в проекте, а в управлении в целом. Мы - костыли, так сказать. Отделившиеся на 50% от БА и на 50% от разработки.

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

К сервису скорее, вряд ли документы нужны на уровне класса. А документация на сервисе вряд-ли живёт в коде.

Поэтому коменты кода это нормально, очень удобно и естевственно. Куча сложных проектов сделано именно так. Жира таски - это просто смшено, какая-то бюрократическая яма. Зашёл в исходники проекта опенсорсного и такой сразу по комитам в жиру (котоаря не всегда нужна и которой часто нет) полез, щикарно

Не согласен: разработчик все-же слишком сосредоточен на своем технологическом колмпоненте или одном -двух сервисах. Аналитик смотрит на систему, на сквозной сценарий, на бизнес-процесс.

Этот бизнес-аналитик, не СА. Или солюшен-архитектор

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

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

Аннотация git'а.

Понятно, что вместо Jira может быть любая ссылка из коммита на источник изменений.

но лучше написать коменты же, зачем страдать обходными путями

Строчка кода - это штука, доступная прогеру. И история ее изменений. А тестеры как смотреть будут? А аналитики?

Это не противоречит идее того, что аналитик взял на себя часть работы разработчика по неопределённостям. И часть работы бизнес-аналитика в сборе целей, ограничений и бизнес-требований.
В общем случае БА + разработчика (у которого достаточно времени и ресурсов для работы с предметной областью и взаимодействием с другими командами) вполне хватало бы.
Системные аналитики оптимизируют (ускоряют) процесс. Но и без них можно обойтись, увеличив затраты.

Вообще тут суть разделения профессий. Разработчикам в больших системах стало сложно разбираться (их работа становится всё медленнее и дороже) и СА отпочковались от них.

На что коммент будет ссылаться?

У нас есть практика в Confluence вести идентификаторы требований, и привязывать их к комментариям к коду.

Я скоро начну считать, сколько раз ты это сказал в этом чате))

А зачем ему ссылаться? Суть комента объянсить что тут проиходит и зачем. Хотите больше инфы - есть система контрля версий, есть доки

🤨

Кстати, ни разу не видел СА ускоряющих процесс при уровне разрабов выше среднего миддла.

Ещё раз, тут обсуждается ссылка на нормативные документы. Это не 'что происходит', а 'откуда требования'. И нужна версия требований для кода.