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.
#1 by Carlos Gustavo on 02/03/2010 - 09:34
Nossa, só de ver essa foto da parede já me bateu uma vontade de fazer uma aplicaçãozinha em Flex pra digitalizar essa papelada…
#2 by Fernando Cézar on 02/03/2010 - 10:19
Mas o efeito visual do Papel é muito melhor do que mais um programa rodando no computador!
Utilize cartolinas e post-it’s, é muito mais satisfatório!
#3 by Saulo Arruda on 02/03/2010 - 11:19
Só para registrar, após a retrospective, rolou o momento desapego: http://www.ustream.tv/recorded/5111987
#4 by Angelina Uesato on 03/03/2010 - 11:15
Opa, legal a aplicação de agile aí na Agence.
E o efeito visual quadro + post-it é entendido por todos da empresa, não precisamos explicar a ninguém o que está planejado, em desenvolvimento, testes e pronto.
#5 by Anderson Pissurno on 17/03/2010 - 17:07
Tenho o seguinte cenário: Projetos concluídos que geram pouca manutenção. Compensa investir em Agile nesse caso? Sendo que SRUM por exemplo prega uma definição clara do SPRINT, porem as minhas tarefas do meu suposto SPRINT apareceriam conforme a demanda do cliente e não posso prever tal coisa.
Quero ressaltar que gostaria de usar Agile porem não estou achando uma saida clara.
#6 by Fernando Cézar on 21/03/2010 - 14:24
Obrigado pelo Comentário Anderson.
Mas na verdade, não aplicamos exatamente o Scrum em nossos projetos de manutenção, alguns mais “chiitas” dizem: “então não é scrum!”.
Nós simplesmente utilizamos o que é possível aplicar (Estórias, Reviews, Restrospectivas). Quando temos uma demanda prevista, tentamos definir as atividades dos sprints, mas eventualmente temos que mudar os planos devido a solicitações mais prioritárias.
O Kanban também é bem diferente dos kanbans tradicionais, e isso ocorre, exatamente porque, o indice de atividades não planejadas é muito grande, então não faz muito sentido separar o planejados e não planejados.
O que realmente faz diferença é você ter uma equipe responsável apenas por manutenções, pois com isso você deixa de interromper sua equipe de projetos de produção.