Comunicando Impedimentos através do Andon

Sabe aqueles momentos em que estamos profundamente mergulhados na resolução de um problema técnico dentro de um projeto? Muitos desses momentos são importantes em função de comumente nos oferecer grandes desafios intelectuais e que uma vez resolvidos, nos trazem grandes momentos de satisfação ao nosso sistema mental de recompensas.

Sendo que muitas vezes, principalmente quando se está num projeto solo, realmente não há outro jeito, temos que ter essa heróica atitude para sermos “matadores de problemas” no projeto, leve o tempo que for necessário (minutos, horas ou dias) e a qualquer custo, afinal senão as coisas realmente não caminham.

Porém, caso o cenário seja pertinente a uma equipe de trabalho, imagine qual o custo para o projeto quando ocorrem essas situações? E outro questionamento interessante, é que quando há uma resolução heróica e individual desses problemas, qual o prejuízo ao compartilhamento de conhecimento a essa organização?

Continue reading

Melhoria contínua e efetiva através do Hansei e Kaizen

Segundo as visões de Taiichi Ohno e Shingeo Shingo, que figuram como grandes pensadores do STP (Sistema Toyota de Produção ou TPS – Toyota Production System), um dos pontos chaves para a evolução desse sistema produtivo, é a prevenção às reincidências de problemas em qualquer nível do processo, para que seja possível alcançar um estado de melhoria contínua e efetiva sobre a forma de trabalho e acerca dos produtos desenvolvidos.

Para sustentar essa filosofia, o STP evidencia dois grandes elementos muito fortes da cultura oriental, que são o Hansei e Kaizen, que conforme mostro abaixo, apesar desses elementos serem benéficos isoladamente, sua sinergia quando juntos, torna-se essencial para a aplicação da melhoria contínua dentro do Pensamento Lean.

Continue reading

Desenvolvendo bons produtos através do Poka-Yoke

Dentro da TPS (Toyota Production System), Poka-Yoke é um dispositivo físico de controle que é acionado automaticamente quando há algum erro ou defeito no processo de produção, sendo que esse acionamento é feito normalmente por duas motivações: 
  • Para controle, pois quando o mesmo é ativado, a linha de produção é interrompida automaticamente  para que o problema detectado possa ser resolvido.
     
  • Para advertência, apenas usando algum tipo de alarme visual para sinalizar às pessoas envolvidas, que algo precisa ser revisado para evitar um problema maior.
Veja que essa forma de controle de qualidade com base em inspeção, é um dos pilares do modelo produtivo baseado no Pensamento Lean e no ciclo PDCA (Plan, Do, Check e Action), por isso, como as metodologias ágeis fornecem um bom começo para a construção desse estado de pensamento Lean e para obtenção do ciclo PDCA nos projetos de desenvolvimento de software, é importante que possamos identificar quais práticas ágeis,  podemos usar como formas de Poka-Yoke.
Portanto, vou elencar abaixo,  algumas práticas e idéias que julgo serem alinhadas a esse conceito de Poka-Yoke, porém, acredito que essa conjectura é viva e, cada um pode observar a implementação mais válida para seu contexto.
  1. TDD (Test-Driven Development)  – Talvez essa seja a prática de maior aplicação como Poka-Yoke pela comunidade ágil mundial,  pois na essência, com TDD podemos capturar quando ocorre um erro no código, parar o desenvolvimento, corrigir o erro e atualizar o teste unitário para que o mesmo possa prevenir futuras ocorrências daquele referido erro.
     
  2. Inspeção de Código  – Outra forma que também julgo ser uma importante implementação de Poka-Yoke, é a inspeção de código feita entre os membros da equipe, que apesar de ser baseada em atitudes, é uma interessante maneira de verificar,  antes de promover uma funcionalidade ao Build que será entregue, se o código produzido, está dentro dos padrões escolhidos para o projeto, se está seguindo boas práticas, se  está feito da maneira mais simples possível, ou se está em acordo com o teste desenhado previamente para aquela funcionalidade.
     
  3. Gestão de Impedimentos através de KanBan –   Talvez não seja um mecanismo com a finalidade de parar um Lead Time de um projeto, porém, a atitude de manifestar algum impedimento visualmente através do quadro informativo, têm um impacto psicológico muito forte na equipe, fazendo com que o mesmo sirva como uma forma de alerta de que algo precisa ser resolvido dentro do projeto, antes que se torne um problema mais grave.
     
  4. Feedback Contínuo –  Para concluir essa breve lista, acredito que através das cerimônias como Sprint Review ou a Sprint Retrospective, podemos ter fotografias muito nítidas de como está a qualidade do produto que está sendo desenvolvido e de quão eficiente e eficaz está o nosso processo de desenvolvimento, portanto, conforme o resultado dessa fotografia, podemos criar um Kaizen, que é outro conceito Toyota, que trabalha com a aplicação de pontos de melhoria contínua no produto ou no processo.  Inclusive, através desse feedback contínuo, podemos exercitar também o Hansei, outra idéia muito importante da  filosofia Japonesa (Aka Toyota), que consiste em fazer uma profunda auto-reflexão para identificar quais foram as falhas e os pontos de melhorias num processo ou num produto.
Termino esse texto lembrando que o mesmo não é um manual passo-a-passo da aplicação de um Poka-Yoke em seu processo, mas sim, uma pequena semente para provocar a reflexão de como você pode usar conceitos do Pensamento Lean, para melhorar sua forma de trabalho dentro do desenvolvimento de software e ter significativos ganhos de qualidade no produto desenvolvido. Portanto, muito obrigado e até a próxima.

Sobre o autor:

Manoel Pimentel, CSP

Manoel Pimentel, CSP

 

É Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com  como Coach em metodologias para importantes empresas do segmento de serviços, indústrias e bancário.  É Diretor Editorial da Revista Visão Ágil, Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Contatos: manoel@visaoagil.com

Sobre Retrospectivas

Eu acredito que um dos pontos importantes em qualquer metodologia ágil é a possibilidade de melhoria oferecida ao time através do constante feedback recebido e também práticas como retrospectivas.

Apesar disso, não é difícil encontrar times que não estão acostumados a questionar seu próprio comportamento e acabam repetindo sempre os mesmos erros.

Esses dias, lendo o livro Toyota Way, eu obtive uma melhor compreensão desse fato, e como o mesmo é encarado na Toyota.

Segundo o autor (livre tradução):

Trabalho em equipe nunca encobre a responsabilidade individual na Toyota. Essa responsabilidade individual não é sobre culpa e punição, mas sim sobre aprendizado e crescimento.

E ainda mais importante, nas palavras de Andy Lund, que é um gerente de projeto na Toyota e cresceu no Japão (livre tradução):

Pessoas que não estiveram no Japão podem não entender que o objetivo não é prejudicar o indivíduo, mas ajudá-lo a melhorar – não é prejudicar o programa, mas sim mostrar falhas que possam ser resolvidas no próximo programa. Se você entende isso profundamente, você pode entender a crítica construtiva. Não importa o quão bom é um programa ou apresentação que alguém fez, sempre existe algo que pode ser melhorado, então nós consideramos isso uma obrigação. Não é um ponto negativo obrigatório, mas sim uma oportunidade de melhoria obrigatória — é o coração do kaizen.

E isso é exatamente o que acontece na prática. Pessoas interpretam sugestões e observações como críticas negativas, e não vêem que a única alternativa para um time manter um processo de melhoría contínua é continuamente questionar seu comportamento e enfrentar os seus pontos fracos.

Um abraço.

Francisco
Ps: Esse post é uma tradução de um post originalmente publicado no meu blog:
About Retrospectives and Accepting Criticism

Sobre o autor:

Frank Trindade

Francisco Trindade

Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.