A codificação Lean tem como objetivo fornecer informações sobre a atividade real de codificação, ajudando os desenvolvedores a detectar que o trabalho não está indo como o esperado, em um intervalo de 10 minutos e permitindo que elas peçam ajuda imediatamente. Os desenvolvedores podem usá-lo para melhorar suas habilidades técnicas e melhorar o código de escrita.
Fabrice Bernhard, co-fundador e CEO da Theodo UK, e Nicolas Boutin, arquiteto-desenvolvedor e coach da Theodo France, falaram sobre codificação lean no Lean Digital Summit 2018. O InfoQ cobriu este evento com resumos, artigos e perguntas e respostas.
A codificação Lean é o nosso esforço para estudar a maneira como codificamos cientificamente e, ao usar o kaizen, identificamos gargalos que nos darão informações sobre como codificar melhor, disse Bernhard. Tentamos uma técnica em particular que chamamos de programação fantasma, disse ele.
Bernhard explicou como funciona a programação fantasma:
A ideia é primeiro escrever o plano técnico detalhado do que se planeja codificar nas próximas horas em etapas de alguns minutos. E então, é como correr contra o seu fantasma em Mario Kart, comparar as etapas reais de execução e o tempo gasto em cada etapa do plano inicial. Isso permite descobrir fortes discrepâncias entre as expectativas e a realidade no nível do código, que são minas de ouro de possíveis melhorias.
Usando o código lean, o Theodo melhorou sua produtividade. Também ajuda suas equipes a melhorar sua maneira de trabalhar.
O InfoQ entrevistou Fabrice Bernhard e Nicolas Boutin sobre codificação lean.
InfoQ: O que é "codificação lean"?
Nicolas Boutin: Estávamos tentando melhorar nosso trabalho diariamente, resolvendo problemas que atrasavam no dia seguinte. E quando perguntamos o que aconteceu durante o tempo de codificação, percebemos que estava desfocado. Não é de admirar, uma vez que nosso indicador de problema mais preciso era, de fato, o quadro diário de resolução, então a percepção de que havia um problema aconteceu apenas na manhã seguinte.
Inspirado por uma viagem a uma fábrica lean no Japão, perguntamos como poderíamos criar indicadores "andon" em um nível muito mais granular. Percebemos que, se durante a fase de design antes da codificação, adicionássemos um cronograma esperado, poderíamos detectar que as coisas não estavam indo como esperado no nível de 10 minutos e sermos capazes de pedir ajuda imediatamente. Isso permitiu duas mudanças muito interessantes: primeiro, a equipe poderia reagir a problemas e pedir ajuda de membros mais experientes da equipe imediatamente, e não no dia seguinte. E no final do dia sabíamos exatamente como as coisas tinham corrido mal, ajudando a identificar onde investir nossos esforços de melhoria contínua. Chamamos de codificação lean em referência à fábrica lean que nos inspirou.
Fabrice Bernhard: A codificação lean é uma das áreas que temos explorado no cruzamento de lean e desenvolvimento de software. É interessante ver que quando o movimento ágil assumiu o controle, houve muito foco em como melhorar o trabalho de desenvolvimento do ponto de vista do gerenciamento de projetos ou operações, mas muito menos do ponto de vista da codificação.
InfoQ: Como faz a codificação lean?
Boutin: De maneira concreta, é assim que faço:
- No início do dia, escolho a próxima história de usuário que vou enviar;
- Em seguida, a história do usuário é dividida em etapas técnicas que duram menos de 10 minutos, durante o que chamamos de etapa "design técnico";
- A etapa de design técnico pode durar até meia hora para se preparar para algumas horas de trabalho;
- E então começo a codificar: cada vez que ultrapassei o tempo takt de 10 minutos, identifico uma discrepância entre expectativas e realidade. Posso "andon" para outro desenvolvedor para me ajudar a superar o problema, ou apenas gravar o problema para análise posterior.
- No final da história do usuário, dou um passo atrás para listar todos os problemas que encontrei, identificar as causas e planejar pequenas ações para me ajudar a ter sucesso no dia seguinte.
Isso é o que chamamos de programação fantasma no Theodo. Até criamos um produto digital interno para ajudar chamado Caspr:
- Vinculada ao Trello, a ferramenta que usamos para fazer gerenciamento de projetos, a Caspr ajuda durante a etapa de design técnico para transformar minha história de usuário em etapas técnicas que duram menos de 10 minutos;
- Durante a fase de codificação, criamos uma interface bash para que possa conduzir as etapas diretamente do meu IDE;
- Quando tenho um problema durante a codificação, o Caspr ajuda-me a identificar como resolvê-lo, sugerindo o padrão associado ao procedimento e a quem devo pedir ajuda;
- No final do dia, sei quais habilidades de codificação preciso melhorar primeiro, e o líder da equipe pode me treinar por meio de dojos ou sessões de programação em pares.
InfoQ: Que benefícios obteve da programação fantasma?
Boutin: Era o líder de uma equipe com 7 desenvolvedores. Cinco semanas depois de começarmos a programação fantasma, conseguimos dobrar nossa produtividade; Entregamos duas vezes mais recursos do que o esperado.
Ao mesmo tempo, treinei pessoas para melhorar suas habilidades técnicas, fazendo dojos e melhorando o ambiente de trabalho do projeto. Dessa forma, as pessoas se tornaram melhores em seu trabalho.
Uma vez que a abordagem requer uma disciplina forte, ainda há algum trabalho necessário para garantir a fácil adoção por outras equipes. Uma dimensão que estamos observando é usar as etapas de design técnico para ajudar pró-ativamente o desenvolvedor em sua próxima tarefa usando o aprendizado de máquina.
Bernhard: Vimos melhorias de produtividade de até 2x em equipes adotando programação fantasma. Mostramos esses resultados em nossa apresentação Toyota VS Tesla? O que o Lean pode aprender com os nativos digitais.
Mas além desses ganhos impressionantes de produtividade, o benefício real é o aprendizado para as equipes. Essas aprendizagens são bem amplas: alguns exemplos incluem a identificação rápida de lacunas de habilidades na equipe que podem ser resolvidas por meio de treinamento, resolvendo problemas na infraestrutura que retardaram testes e implementações, mais do que se imaginava, automatizando algumas das tarefas do desenvolvedor para evitar erros desnecessários e adotando uma nova maneira de testar o código.
Esta é a primeira vez que vejo desenvolvedores procurando cientificamente a maneira como eles codificam para aprender a codificar melhor; o potencial disso é enorme.