Проблемы доставки фич в больших проектах

[ldss]

есть такая штука — git flow
Если у вас scrum/agile и прочее, то как у вас таск/юзер стори может быть длиннее спринта (так, что нужно долго держать бранч)?
ну и если нельзя добавить фичу, не внеся опасных изменений в остальные куски кода — это не очень хороший код.

[Fixique]

Если у вас scrum/agile и прочее, то как у вас таск/юзер стори может быть длиннее спринта (так, что нужно долго держать бранч)?

Релиз фичи зависит от множества факторов:

1. Готовность бекенда, который на стороне банка
2. Готовность инфраструктуры банка к релизу этой фичи
3. Апрув от сторонних проверяющих организаций
4. Смена повестки в банке.

Разработка фичи заканчивается вместе со спринтом, но это не значит, что она может пойти в релиз.

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

Любое изменение кода может нести в себе импакт.

[ldss]

Релиз фичи зависит от множества факторов:

нет-нет, это понятно. Речь о том, что по эджайлу юзер стори/таск не может быть длиннее спринта; по окончании спринта все бранчи д.б. слиты в дев. Т.е., указанная проблема с долгими бранчами просто отсутствует
Если у вас одна фича == одной юзер стори, и она длиннее спринта, это прямое нарушение принципов А.

Любое изменение кода может нести в себе импакт.

Ну так надо стремиться чтоб таких ситуаций было поменьше. Они ж все про одно и то же — сильно связанный код, изменение вместо добавления и так далее.
А то будет, как один мой коллега в возрасте говорит — «Программирование — это тяжелый труд»
Ну да, с его классами по 5 тыс строк и функциями по 600-1000 строк это безусловно тяжелый труд