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

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:

fishbone

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”.

azure-devops-bugs.png

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.

azure-devops-bugs-wi.png

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.

fishbone-ti

 

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s