Prosseguindo com os posts do blog, vamos entrar em um tema mais técnico.

Acredito que várias pessoas tem o mesmo que problemas que nós estamos tendo para a implantação do Scrum na empresa em que trabalho: – E os Projetos de Manutenção?

Antes que eu comece a descer a ladeira, preciso que vocês entendam a nossa situação. Somo uma empresa de desenvolvimento de softwares sob medida para nossos clientes, logo, não temos praticamente nenhum “Produto de Prateleira”, e geralmente depois da entrega do software, fechamos um banco de horas de manutenção e implementação de novas funcionalidades. E exatamente nesses projetos que estamos utilizando o Scrum da maneira que vou descrever.

Procurando algumas referencias, encontrei pouco material, e o que encontrei geralmente se aplicava a apenas um projeto. Desenvolvemos o nosso método baseado nesse 2 links: Kanban for support and operations e Applying Agile/Scrum practices in Maintenance projects

No PDF, Kanban for support and operations, eles recomendam que se utilize um Kanban que possa ser facilmente alterado a ordem dos projetos, visto que os projetos devem ser ordenados por Prioridade da esquerda para a direta horizontalmente (sendo o mais prioritário na esquerda), o fluxo das atividades e tarefas deve ser feito de baixo para cima, iniciando com o Backlog e no topo deve estar o Pronto.

Os Sprints desses projetos são semanais. Inicialmente estamos presos a desenvolvedores que conhecem o projeto para poder mexer nele, mas a idéia é que com o tempo, toda a equipe de manutenção seja capaz de resolver qualquer pendência de qualquer um dos projetos de manutenção, logo, quem estiver disponível atende.

Tomamos por Pronto tudo que é publicado em ambiente de produção. E se, por acaso, a tarefa voltar devido a algum bug, é cadastrada uma nova tarefa.

Abaixo tem algumas imagens do nosso Kanban de Manutenção.

Essa foto foi tirada no dia que desenhamos o Kanban

Essa foto, foi tirada antes da reunião de retrospectiva, após uma semana de trabalho. Após a reunião retiramos todos post-it’s que estava Prontos e Preparamos para a nova semana.

Notem que houve uma alteração no kanban, precisamos criar uma nova fase que em nenhuma das referencias é citada. Como nos projetos, por vezes, dependem do aprovação do Project Owner (PO), estava poluindo muito o kanban manter os post-it’s na fase de iniciado, enquanto o cliente não aprovava. Então criamos uma fase desenvolvido, para os Scrums Masters poderem saber o que deve ser cobrado do PO.

Bom, acho que isso já deve dar um rumo para quem está tendo o mesmo problema que nós tivemos.
Se você tem alguma experiência, compartilhe conosco nos comentários.