Como visualiza o uso de Scrum em sistemas que estão em produção e sendo evoluídos\mantidos, e possuem times praticamente "estáticos". Imagino o cenário onde define que o Scrum master define os times, etc, como algo muito mais dinâmico e com características de rotação de jobs, aprendizados contínuos, etc. Em suma, como é sua visão para a manutenção de software? Afinal Scrum trabalha com projetos, projetos tem INICIO, MEIO e FIM. Como entende esta situação?
hoje, com a Alura e o Google Gemini
Oi, Diogo. Esta é uma ótima pergunta.
Até onde entendo, o objetivo do Scrum é entregar um produto em entregas incrementais. Para isso, existe um projeto, com uma equipe ágil, todos empenhados em uma meta.
No caso de manutenção evolutiva e/ou corretiva, a menos que seja uma grande evolução/correção(?), não há entregas incrementais. ocorrem pequenas entregas ao longo do que seria uma sprint (faz sentido esperar o final da sprint para entregar uma correção em que o usuário está parado?).
Na verdade, cada Dev acaba ficando "isolado" porque cada um está corrigindo e ficando responsável por uma demanda. Não há aquele espírito de equipe, por mais que ocorram as reuniões diárias, etc.
Não quero desmotivá-lo, mas aparentemente, dá pra usar alguns princípios de Scrum, mas não sei se de forma plena (e portanto, efetiva). O que tem que ser implantado é o ágil. Talvez, se adotar o Kanban (com "K" maiúsculo, pode vir a ser uma solução). Ou apenas um quadro kanban (com "k" minúsculo), para dar visibilidade às demandas, adotando XP, etc.
Seria uma boa mais pessoas participarem deste tema. Onde trabalho, há o mesmo problema: querem forçar o uso do Scrum em equipes de manutenção, mas há enorme dificuldade por não ser o mais adequado. Aparentemente.