O termo "kaizen" foi introduzido pela Toyota e muito foi escrito sobre isso em livros espessos da série Toyota Tao.
O Kaizen também é chamado de "processo de melhoria contínua". Geralmente está associado à produção industrial de carros e transportadores, bem, ou pelo menos ao controle de processos. Eles falam pouco sobre desenvolvimento, mas o kaizen é muito adequado para o desenvolvimento de software.
Além disso, você aprenderá sobre vários casos que gradualmente levaram o autor a entender o kaizen no desenvolvimento.
Uma série de problemas
O primeiro caso ocorreu logo no ano novo, às 20:00. O disco rígido travou no servidor e, por causa disso, foi necessário interromper a preparação de saladas e ir urgentemente a Moscou para o site de troca de tráfego para trocar o dispositivo quebrado.
Após o disco rígido, a placa-mãe queimou. Eles mudaram tudo, mas depois decidiram descobrir por que isso acontece.
Administradores familiares deixaram claro que você precisa ter muito cuidado com o hardware do servidor, não comprar em qualquer lugar e reservar tudo e em todos os níveis.
Foi decidido alterar o servidor e ter muito cuidado ao escolher um provedor. Examinamos o hardware do servidor, pedimos recomendações e escolhemos um servidor, que mais tarde funcionou sem interrupção e sem interrupção por 7 anos. Ele continua trabalhando agora, embora cinco anos se passaram desde que o autor deixou esse trabalho.
Passou mais tempo e ocorreu um incêndio no local. O servidor sobreviveu milagrosamente. Então todo mundo tremia bem, porque havia risco de destruição total do negócio.
Depois disso, um espelho do site e do banco de dados foi criado em um site separado e completamente independente no outro extremo da cidade. E uma vez que ela foi usada.
Também houve um caso em que o tráfego foi iniciado no site que acabou de ser lançado e, de repente, parou completamente, simplesmente não pôde suportar a carga.
Após o estudo, ficou claro que a empresa de terceirização que criou o site o fez para não ter mais de 200 pessoas por dia. Engraçado e triste.
Depois disso, foi decidido abandonar a terceirização e formar sua própria equipe de desenvolvimento.
Tendo criado a equipe, tivemos mais um problema - a correção de qualquer erro causou uma avalanche de novos erros. Qualquer alteração quase sobrecarregou o site inteiro.
Cada correção implicava muitos, muitos problemas. Quando analisamos a situação, percebemos que precisamos mudar fundamentalmente tudo em geral - todo o interior. E então todo o site foi completamente refatorado, toda a sua arquitetura foi virada de cabeça para baixo. E somente depois disso a situação mudou radicalmente e os problemas desapareceram completamente.
Eliminar a causa raiz
Todas essas soluções foram unidas por uma coisa - todas elas objetivavam garantir que o problema raiz subjacente a elas nunca voltasse a aparecer, para que seja completamente eliminado. Da palavra a todos. E para que o mesmo problema nunca se repita novamente.
Você entende?
Elementar: o computador travou - percebemos que precisamos escolher o hardware certo, que nunca falhará.
O site pegou fogo - eles fizeram uma cópia para excluir a ocorrência de uma situação semelhante no futuro.
Então as palavras não sabiam disso - kaizen.
5 porque
Nem sempre a causa raiz do problema está na superfície, às vezes você precisa investigar.
Um bom exemplo foi dado em um dos livros de Toyota da Tao. Na fábrica, descobriu-se que uma das máquinas permaneceu inativa por um longo período de tempo durante o dia.
Por que ele tem intervalos no trabalho? Verificou-se que a máquina para para a limpeza.
Ao redor da máquina há lascas e sujeira. Naturalmente, se houver aparas ao redor, será necessário removê-las, caso contrário, é impossível trabalhar. Está tudo bem?
Mas o Kaizen diz: você tem que procurar a causa raiz.
Por que o chip cai? A resposta vem imediatamente: os chips são empilhados porque não estão indo a lugar algum - a máquina não possui um dispositivo que permita sua remoção e coleta. Se houvesse esse dispositivo, a máquina não precisaria ser parada.
Bem, então, vamos apresentar uma solução que permita que esse chip seja removido da máquina e faça com que ele não pare para a limpeza. Esta solução já é puramente técnica e bastante simples.
Existe uma técnica muito simples para determinar a causa raiz: o conhecido método "5 por quê".
A Kaizen recomenda usá-lo para chegar ao fundo das causas principais.
Considere sempre as causas do problema, uma após a outra:
- Por que a máquina para? Porque a limpeza é feita.
- Por que a limpeza é feita? Porque lascas e sujeira estão voando da máquina.
- Por que chips e sujeira voam? Porque eles não se afastam da máquina.
Com a ajuda do “5 why”, encontramos a causa raiz, criamos uma solução para eliminá-la, designamos uma pessoa responsável e prazos e verificamos semanalmente a obtenção do resultado.
Lembre-se de que qualquer problema pode ser resolvido de maneira cara e barata.
Kaizen diz: primeiro, escolha a maneira mais barata. Geralmente é o mais simples e o melhor.
Kaizen no desenvolvimento de software
E agora alguns exemplos recentes da vida de uma equipe de desenvolvimento de software.
Feil Jobs
A equipe está implantando suas melhores práticas no Prod, lançando o Jenkins. De fato, Jenkins é um sheduler como o crontab que pode executar trabalhos agendados. E a equipe teve esse trabalho.
Uma vez que foi descoberto que o Prod-Jobs caiu 5 vezes seguidas com o status de falha. E ninguém prestou atenção neles, apesar de, de fato, todos os arquivos no Prod serem um alarme universal.
Então eles começaram a descobrir o motivo usando o método "5 por quê":
- Por que os jobies viram 5 vezes e ninguém prestou atenção? Como todo mundo recebe constantemente notificações de trabalhos ruins, existem muitos, e eles se tornam familiares
- Por que eles estão se tornando familiares? Porque quase todos os dias recebemos algum tipo de notificação, falha e não falha. Nós não vemos a diferença. Eles simplesmente não prestaram atenção neles.
- Por que as notificações vêm todos os dias? Porque um dos desenvolvedores está testando um novo trabalho que está caindo e as notificações sobre ele são enviadas a todos. O trabalho não é importante no momento; portanto, todos pararam de prestar atenção às notificações dela e, ao mesmo tempo, de todos os outros trabalhos.
A decisão foi transparente: para trabalhos de teste, as notificações sobre os arquivos não serão enviadas a ninguém, exceto ao proprietário do trabalho, e mesmo se ele precisar.
Além disso, foi registrado oficialmente que qualquer notificação do trabalho é uma emergência excepcional, à qual todos devem responder.
Script caído
O segundo exemplo é um problema com o aplicativo QlikView.
Uma vez que a equipe foi informada de que os relatórios do QlikView eram de alguma forma diferentes. Tudo parece funcionar, mas os dados não são os mesmos. Eles começaram a entender o problema.
Descobriu-se que o script de download não funcionou até o fim. Por que não funcionou até o fim? Como havia muito código no script e em algum lugar no meio estava o operador de depuração Exit Script - eles simplesmente se esqueceram de removê-lo e não o notaram. A situação acabou quando o script de download caiu e os dados foram usados antigos.
Por que você não percebeu isso? Porque o teste não mostrou isso por causa da arquitetura. O aplicativo foi dividido em duas partes independentes (script de volta / download e frente) e assim por diante. havia muitos dados, eles tentaram não reiniciá-los novamente, para não perder muito tempo com isso.
Foi feito especialmente para que a frente não estivesse conectada ao script de carregamento. Ele apenas pegou um determinado arquivo de dados e o mostrou. Não ficou claro que esse arquivo de dados é antigo, ou seja, era impossível determinar a presença de um erro nele.
O que foi inventado para evitar uma situação semelhante no futuro?
A equipe se perguntou: como se certificar de perceber uma situação dessas no futuro? Como deixar claro que o script de download não funcionou até o fim?
Decidiu-se registrar o rótulo no início do script e, no final, excluí-lo. I.e. se o rótulo não for excluído, isso significa que o script não concluiu o download até o final. A frente verificou que, se houvesse uma etiqueta, ela exibiria uma faixa vermelha no chão da página com uma notificação sobre o problema.
Assim, embora a possibilidade do aparecimento de tais problemas não estivesse completamente descartada, pelo menos ficou imediatamente conhecido sobre eles. Solução simples e barata.
Perda de dados em reinicializações
O serviço de monitoramento da Web recebeu dados de estandes industriais. Periodicamente, ele precisava ser finalizado e corrigido, e cada correção exigia uma reinicialização. Embora a reinicialização tenha durado alguns segundos, na época os dados industriais e o abismo podiam ser garantidos. Como era impossível perdê-los, a equipe decidiu analisar o problema mais profundamente.
As perguntas "5 por quê" deixaram claro que a causa raiz do problema é a arquitetura - foi isso que não permitiu o contrário. Não importa o quão rígido o serviço seja, o que eles fizeram com ele, mesmo assim, tudo se resumiu a uma reinicialização.
A nova arquitetura resolveu o problema de uma vez por todas - o serviço foi dividido em duas partes independentes: recepção e processamento de dados. Essas partes foram fisicamente separadas, ou seja, você poderia desligar o manipulador com segurança e, enquanto recebia dados, continuava trabalhando e salvava tudo o que havia nele. E o mais importante, o receptor de dados foi criado para nunca precisar de uma reinicialização. Os manipuladores podem ser desligados, modificados e sobrecarregados com segurança sem se preocupar com o fato de que os dados podem ser perdidos.
O DevOps parece estar lá, mas não parece estar
DevOps é uma coisa mágica. Parece estar lá, mas ao mesmo tempo também acontece que não existe.
Um dos desenvolvedores postou suas melhores práticas na bancada de testes. Apesar de ter usado o DevOps, "de repente", o banco de testes foi conectado ao banco de dados de combate. Parte dos dados foi irremediavelmente perdida.
Começamos a descobrir. Aconteceu que o desenvolvedor não percebeu que estava usando a cadeia de batalha de conexão.
O principal motivo foi que o desenvolvedor precisou alterar manualmente a cadeia de conexão para diferentes suportes e servidores.
O que diz o kaizen? Certo! Precisamos encontrar uma solução para eliminar completamente o problema, ou seja, remova a necessidade de alterar manualmente a linha.
E a solução foi implementada - a cadeia de conexão começou a ser selecionada automaticamente, dependendo do servidor em que estava sendo executado. O problema foi resolvido de uma vez por todas.
Eu acho que você já entendeu a partir dos exemplos acima que a essência da melhoria contínua pode ser expressa em uma frase simples - para eliminar completamente a reincidência do problema.
Principais resultados - parte integrante do Kaizen
O resultado do kaizen é realização, não uma ideia.
Para chegar a uma solução não é tão difícil, é muito mais difícil implementá-la.
Para cada decisão tomada, é importante entregar os principais resultados, ou seja, entender quem precisa fazer o que e em que data.
Como você entende que alcançou um resultado bem-sucedido?
Vamos dar um exemplo com uma cadeia de conexão. Que resultado
material será considerado sucesso aqui? O sucesso será alcançado quando:
- uma biblioteca será criada para selecionar automaticamente a cadeia de conexão,
- o desenvolvedor criará uma biblioteca para si e lançará com sucesso seu software com ela.
Ambos os passos devem ser dados até uma certa data por certas pessoas. Somente com os dois passos podemos assumir que o sucesso foi alcançado.
Os principais resultados são critérios de sucesso; o Kaizen não funciona sem eles. Sucesso é implementação.
Somente uma solução implementada permitirá que você elimine o problema no futuro; portanto, ao falar sobre o kaizen, sempre significa que você deve implementar tudo o que foi inventado.
Onde mais isso pode ser aplicado
Como você provavelmente viu nos exemplos, o Kaizen pode e deve ser usado na análise de incidentes. Na verdade, ele foi criado para isso.
Incidentes em grupos de suporte técnico, infraestrutura e desenvolvimento de produtos são perfeitos.
Quanto à codificação, aqui você pode analisar seu código e ver como ele pode ser alterado para remover permanentemente os problemas encontrados.
Sim, e o notório retro Agile também é kaizen, porque nessas reuniões os problemas são analisados para o sprint, são feitas perguntas "5 por quê" e medidas estão sendo tomadas para evitar problemas. O kaizen mais natural!
A própria técnica kaizen funciona bem no desenvolvimento de software, é muito fácil de usar e adequada para uso em assuntos pessoais.
O segredo do sucesso é simples: elimine os problemas um a um e, em seguida, eles não permanecerão. Isso é melhoria contínua.
A própria Toyota usa o kaizen na produção com enorme sucesso. Seus resultados falam por si: defeitos de produção são apenas 3 defeitos por 1.000.000 de peças.
Por que não aplicá-lo a si mesmo?
Agora você está oficialmente bombeado. Se você ouvir esse termo, saberá o que é.
E sucesso no seu trabalho.