Análise de causa e efeito em projetos ágeis com Fishbone (Ishikawa) e Azure DevOps

Blog: http://leonardo-matsumota.com

Quando executamos projetos ágeis no âmbito de desenvolvimento de sistemas, trabalhamos com algumas técnicas que ajudam a evitar deploys de novas releases com bugs em produção. Algumas práticas de CI/CD nas práticas DevOps, por exemplo, mitigam os riscos por gerenciar todo o ciclo de vida da aplicação — gestão de configuração, integração contínua, estratégia de testes, build e release pipeline, etc.

Mesmo com publicações frequentes e pacotes menores para diminuir os riscos, lidamos com algumas implementações complexas e inúmeras dependências entre os times. Nem sempre temos o “estado da arte” na nossa empresa, contando com os investimentos adequados em ferramentas ou até mesmo a maturidade do time no uso de práticas e processos de desenvolvimento.

E assim, alguns antipatterns podem surgir neste âmbito de implementação:

• Correções frequentes durante a implementação de releases
• Confiança em testes manuais para validação das aplicações
• Resultados imprevisíveis na publicação de novas releases, e ainda muitas vezes apresentam problemas e precisam ser revertidas

Quando isso acontece, uma boa orientação é atuar na causa real dos problemas afim de evitar a recorrência (o mesmo problema apareça novamente) e até mesmo não resolver em definitivo aquele bug. Já falamos anteriormente sobre o uso do 5 Porquês (5-Why). Neste post, vamos abordar o Diagrama de Ishikawa, também conhecido como Espinha de Peixe ou Causa e Efeito, ferramenta de qualidade para identificar a relação de causa e efeito dos problemas. É muito utilizada por gestores na área de TI para descobrir a causa raiz daquele bug apresentado na aplicação em produção.

O uso do diagrama é bem simples. Na “cabeça” do peixe colocamos o problema a ser resolvido. Uma frase como “por que este <problema> aconteceu?” é mais recomendado do que apenas escrever o problema. A “espinha do peixe” serve para descrevermos a causa dos problemas. Por fim, agrupe pelo tipo da causa. Os grupos recomendados no Ishikawa são os 6M: Método, Meio ambiente, Medida, Mão de Obra, Material e Máquina. Em TI trabalhamos com o diagrama adaptado do fishbone. Veja o modelo:

Download do template (PPTX): fishbone template

No meu exemplo, estou utilizando o Azure DevOps (da Microsoft) como solução de ALM e assim registrar os erros encontrados nas aplicações. Para relacionar os bugs em aberto, acesse a área Boards > Work Items > faça o filtro do work item tipo “Bug”.

No work item (do tipo Bug) existe o campo de classificação (Classification) que possui uma lista de valores a ser escolhido como a causa do problema. Este pode ser utilizado como o grupo de problemas na construção do Ishikawa. Customize se necessário. Adicionalmente, deve haver o preenchimento da causa do problema no campo symptom. Oriente seu time para realizar o preenchimento correto dos campos.

Após coletar todos os erros da aplicação, chegou a hora de analisar a causa raiz do problema, agrupando conforme as causas em grupos. Com os principais erros relacionados, podemos atuar na causa e resolver o problema em definitivo. Em processos de melhoria contínua, este aprendizado certamente trará melhorias, sendo o input para implementações futuras.