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

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

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

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

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

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

процесс должны выправлять да

отдельные команды и бюджеты на исправление багов и саппорт - смешно

когда свои деньги в этом инвестируете, расскажите как оно там

Да, да, да

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

про отдельную команду это не я придумал, но мне пока видиться это довольно рабочим сценарием

ну, переписывать легаси и монолиты нужен определенный экспериенс )

и отвага

нужен. тогда что делать? выгнать всех и поискать другую команду? :)))) что-то ж надо делать

команду вряд ли, но иметь хотя бы одного технического специалиста, который может и в код и в процессы, хотя бы как консультанта над молодыми - стоит 😉

тех кто умеет и архитектуру сложных проектов и процессы - мало, на рынке буквально по именам всех можно перечислить )))

"молодые" это условно, потому что в команде все люди с опытом и уровня от миддл+ и выше.

поэтому и приходиться учиться на лету всем остальным

миддл+ это все какие-то оценки конкретной компании, там где человек сеньор был, может прийти и не объяснить чем btree от бинарного дерева отличается, и сразу станет джуниор

ладно, спасибо