quarta-feira, junho 27, 2007

Scrum para manutenção de sistemas

Este artigo contém uma resposta a uma dúvida enviada para a lista CMM-Brasil.

Dúvida:

"Aqui na empresa temos uma suite de produtos para a área Contábil / Depto Pessoal / Fiscal. Não desenvolvemos novos produtos. O que fazemos, é dar manutenção corretiva (qdo necessária), e na maior parte das vezes manutenção evolutiva, visto que os softwares devem se adequar às legislações municipais, estaduais e federais.Trabalhamos com um repositório de solicitações de novas implementações ou manutenções em funcionalidades já existentes. Estipulamos um prazo em torno de 40 dias para contemplar algumas solicitações acordadas em reuniões de planejamento, e no fim, geramos uma nova versão do produto e encaminhamos à nossos clientes.Nem sempre as solicitações acordadas no começo do planejamento são concebidas na versão do produto, pois no meio do caminho novas solicitações mais importantes (como falhas do sistema) acabam entrando e consumindo o tempo necessário para as outras solicitações.Alguém aqui do grupo trabalha neste mesmo esquema? Quais metodologias são mais indicadas para este cenário?

Iniciamos, sem muito sucesso a implantação do CMMI nível 2 no ano passado. Definimos e institucionalizamos o processo e a política de REQM, treinamos os profissionais, mas em algumas equipes o uso no dia a dia do processo definido não foi bem aceito. Acredito que pelo fato de requisitos entrarem, saírem ou serem alterados a todo instante do "sprint" de 40 dias, o processo tenha se tornado muito burocrático e pouco dinâmico.Citei equipes pelo fato de cada equipe trabalhar com um sistema específico, exemplo: Equipe A só trabalha com sistema de Folha de Pagamento, Equipe X só com sistema de Contabilidade .. e assim por diante.Alaguem tem algum comentário a fazer sobre isso?"

Minha resposta:

Um processo excelente para trabalhar nesse formato da empresa onde você está é o SCRUM. Ele lida exatamente com essas questões de gestão de backlog de produtos. No Scrum o spint é definido como sendo de 30 dias. Porém pode-se variá-lo de uma semana até 6 semanas.

O Scrum tem uma regra clara para permitir uma organização mínima do backlog e manter a sanidade da equipe: JAMAIS pode haver mudanças de prioridades durante uma iteração ou sprint. Mas, caso seja imprescindível alguma alteração, então o SCRUM dá uma alternativa: cancela-se o sprint atual e refaz TODO o planejamento de um novo sprint. É crucial deixar claro para os stakeholders do projeto que, desse modo, parar uma sprint só deve ocorrer em casos extremos.

No seu caso talvez seja melhor também, para reduzir o número de alterações de requisitos vindos dos stakeholders durante um sprint, reduzir o tempo de um sprint entre outro. Tente fazer a empresa e a equipe ser mais ágil. Que tal, por exemplo, reduzir seus sprints de 40 dias para 20 dias?

Marcadores:

2 Comentários:

At 10:44 AM, Blogger Leandro Herrera disse...

Mas estou entendo que o SCRUM auxiliaria o processo de manutenção, quando a mesma é composta de melhorias e correções acordadas com o cliente antes de se iniciar o sprint.

No meu caso, às vezes são abertos chamados de suporte com prazos variando de 4 horas a 15 dias para atendimento. Como tratar essas demandas que surgem ao longo da iteração?

Abraços.
P.S. Muito bom o seu blog...

 
At 3:10 PM, Blogger Rafael Pimenta disse...

Tenho a mesma dúvida do Leonardo

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas