Como a resolução de problemas lean aumenta a produtividade de equipes ágil

Atualmente empresas de tecnologia estão enfrentando desafios da atual era digital: aumentar a expectativa dos usuários, tecnologias disruptivas e competições acirradas. Gerentes e trabalhadores da área de TI, proativamente, tendem a desenvolver soluções tecnológicas para resolver os problemas sem a certeza dos efeitos e frequentemente não chegam a solução ideal. Ou algumas vezes todas as opções nunca são avaliadas. Falta uma abordagem apropriada e rigorosa para formular problemas, diagnosticar as causa raíz, realizar ações corretivas relevantes, avaliar os efeitos e ao final criar um melhor entendimento do trabalho melhorando as práticas diárias das pessoas;

Neste artigo iremos conhecer Marek, CTO de uma empresa francesa de desenvolvimento de aplicativos móveis e um desenvolvedor chamado Kevin. Através da observação paciente do trabalho do desenvolvedor é como se as partes do software estivessem fluindo ou sendo paradas, Marek revelou o desperdício de tempo na validação e no processo de entrega, os quais impactam significamente a produtividade do desenvolvedor.

A história continua com tentativas, falhas e sucesso das ações de Kevin seguindo a estrutura da ferramenta metodológica no núcleo lean, o método científico para resolução de problemas, Plan, Do, Check e Act, também conhecidos como método PDCA que significa: Planejar, Executar (Desenvolver, Fazer), Verificar (Checar) e Agir (atuar).

Através deste detalhado exemplo do mundo real veremos como o gerenciamento lean se posiciona e como a resolução de problemas realmente ajuda equipes ágeis, a aplicação mobile desta equipe ágil atingiu com sucesso sua melhoria de produtividade em 15%.

Parceiro para soluções mobile

A BAM French é uma empresa com sede em Paris e fornece experiência e soluções mobile para corporações e startups os ajudando a superar desafios de seus negócios. Os funcionários da BAM trabalham para fornecer valor aos clientes com eficiência e o mais rápido possível, utilizando a abordagem Lean Lean Startup e o método Scrum com sprints de uma semana.

Implementar uma aplicação realmente consome tempo e custa dinheiro.

Como engenheiros lean, os colaboradores da BAM, seguem uma corrente de passos interessantes para criar estes valores:

1. O product owner (PO), considerado cliente, formaliza a funcionalidade em um cartão Trello (Trello é uma ferramenta de software utilizado como quadro de tarefas digital);
2. O PO prioriza novas funcionalidades;
3. Cada semana a equipe técnica se empenha para desenvolver um novo conjunto de funcionalidades.;
4. Cada funcionalidades segue os próprios passos antes da entrega ser considerada "concluída".

• Um desenvolvedor pega um ticket e começa a trabalhar nele. Ele/ela agora é responsável por esta funcionalidade e precisa validá-lo junto ao PO.
• O desenvolvedor codifica a funcionalidade, os testes, refatorar o código, etc.
• Uma vez terminada a codificação, uma revisão por outro membro da equipe é feita.
• Após fornecido o feedback na conta, o ticket é imediatamente implementado na plataforma de testes.
• O desenvolvedor encarregado do ticket agora checa em todos os dispositivos especificados na "definição de concluído" se a funcionalidade desenvolvida está funcionando de acordo com a descrição escrita pelo PO.
• O desenvolvedor informa ao PO que a funcionalidade foi desenvolvida e pode ser testada em uma nova versão da aplicação.

A parte crucial aqui é que não existe estoque ou filas. Todas as funcionalidades são submetidas diretamente para o ambiente de validação e consequentemente para produção, uma vez que são validadas: Os colaboradores da BAM utilizam a técnica One Piece Flow (Uma parte por fluxo)..

Se a funcionalidade não corresponde com o ticket ou se um erro é observado o desenvolvedor precisa consertá-lo imediatamente. Ele ou ela precisa agir rápido para não comprometer o processo de validação.

A implementação da funcionalidade é um processo crítico para BAM

Vamos pegar um exemplo de projeto do mundo real, trabalhamos para uma empresa de energia que queria digitalizar todo o negócio, da assinatura do serviço passando pelas faturas e os cuidados com o cliente. A equipe da BAM, composta por três desenvolvedores e um arquiteto trabalhando full-time.

Aqui aqui está a abordagem de resolução de problemas utilizando o método científico PCDA, planejar, desenvolver, controlar e agir, que demonstra seus benefícios.

P para Planejar 

Qual é o problema? 

Marek, CTO da BAM é orientado por Marc (Parceiro de operações), durante a fase de Go / See (Vai e verifica) no projeto, eles perceberam que na implementação e validação o tempo da funcionalidade era muito longo, em torno de 20 minutos. Todos os membros da equipe gastam em torno de 1 hora por dia implementando funcionalidades para a validação dos dispositivos, este tempo precisa ser reduzido no momento da implementação.

Historicamente, funcionários da BAM tentaram externalizar todo o processo construtivo, mesclando uma funcionalidade automaticamente poderiam iniciar uma nova implementação. Então utilizaram o Bitrise que é uma ferramenta especializada na implementação de serviços mobile. Funcionou bem mas haviam diversas desvantagens importantes. Primeiro, todo o ambiente de desenvolvimento deveria ser recriado em cada implementação. É automático, porém, é realmente lento. Todo o desenvolvimento com o Bitrise levou pelo menos 35 minutos!

Desenvolvimento no Bitrise ou CI foi mais lento que o desenvolvimento em outras máquinas

Inicialmente o processo de desenvolvimento automático pareceu ser uma ótima ideia porque possibilitava ao desenvolvedor iniciar outra tarefa enquanto espera a implementação terminar. O lado negativo é que eles perdem uma parte do fluxo e aumentaram o WIP, sigla em inglês para Work in Progress (trabalho em progresso).

Começando uma nova tarefa durante a implementação não se mostrou eficiente, os desenvolvedores tinham que parar o trabalho de uma nova funcionalidade para testar a anterior, talvez consertar um ou dois erros que não foram observados no ambiente de desenvolvimento, etc.

Eventualmente, a BAM parou de implementar com o Bitrise completamente (35 minutos para implementar) e voltou para a primeira abordagem manual (em torno de 20 minutos para implementar e testar). O desenvolvedor deveria esperar durante a implementação mas ele ou ela poderiam realizar outras tarefas pendentes (ler e responder os emails, atualizar a planilha de resolução de problemas).

Na BAM não existe um padrão de tempo máximo para implementar e testar os tickets, no conselho do CTO Marek, alcançar o objetivo levou 10 minutos (veja a figura abaixo).

Quais são os impactos?

Para os clientes da BAM cujo contrato é de tempo e material, equivalente a um desenvolvedor-dia por semana é desperdiçado aguardando a finalização das implementações.

O cliente deve absorver estes desperdícios, toda vez que uma funcionalidade é implementada, ele/ela precisa atualizar a aplicação através de muitas etapas manuais (desperdício de recurso). O processo de instalação leva aproximadamente 2 minutos em seus dispositivos (sendo Android e outro IOS), se repetindo uma ou duas vezes por dia.

Para os desenvolvedores este tempo de implementação é um desperdício de tempo e um processo doloroso.

Para a BAM como empresa, isso significa um desperdício de produtividade: 1 pessoa/dia por semana é gasto implementando, significando que 2 ou 3 funcionalidades do usuário não desenvolvidas durante o sprint para o cliente. Refletido no final do projeto em 5% menos funcionalidades: para um ciclo de 10 sprints, significa entre 20 e 30 funcionalidades não implementadas!

Qual é o processo padrão?

Agora veremos a sequência de passos requeridos para o desenvolvimentos de uma aplicação mobile.

Kevin o desenvolvedor de aplicações mobile, levou um tempo olhando e medindo o tempo gasto por cada ação requerida para implementar uma funcionalidade.

As etapas que Kevin quis melhorar foram os de desenvolvimento e instalação.

Mas quais são as causas?

Kevin identificou duas causas principais para a lentidão dos desenvolvimentos.

O primeiro é o tempo de desenvolvimento, de quase 7 minutos. Atualmente toda a aplicação (pacotes binários e código fonte JavaScript) foi refeito duas vezes, para Android e IOS. A parte dos binários é quase sempre a mesma duração do desenvolvimento de uma funcionalidade, mas de qualquer forma a reconstrução fica pronta de qualquer forma, este é um desperdício super-processado.

A segunda causa identificada foi a instalação, como movimento de desperdício. São necessários 3 minutos para atualizar a aplicação em 4 dispositivos. Durante este passo o desenvolvedor deve:

• Lançar a aplicação HockeyApp (loja privada para desenvolvedores armazenarem aplicativos);
• Atualizar a lista de aplicativos;
• Encontrar o aplicativo;
• Baixar toda a atualização do aplicativo;
• Instalar toda a atualização do aplicativo;

Ok, agora quais ações devem ser tomadas?

Relacionado ao desenvolvimento do aplicativo, um novo processo é requerido, um que possa permitir a somente a reconstrução da atualização do código sem re-compilar toda a aplicação. Este passo pode requerer uma nova ferramenta de desenvolvimento.

Baseado no tempo de instalação, desenvolvedores precisam instalar somente o código de atualização nos dispositivos, sem refazer o download da atualização completa.

Kevin observou algumas coisas interessantes na ferramenta CodePush.

1. O tempo de desenvolvimento: ao invés de reconstruir módulos nativos, somente juntar os artefatos e o código JavaScript.
2. O tempo de instalação: fazendo somente downloads do JavaScript atualizado e não todos os 10-20Mb da aplicação.

Quais são os resultados são esperados?

O resultado esperado deste novo processo de desenvolvimento foi de obedecer este novo padrão/objetivo que é desenvolver, instalar e testar novas funcionalidades nos dispositivos em menos de 10 minutos, incluindo 4 minutos para a validação da funcionalidade.

Para alcançar os resultados os tempos de desenvolvimento e instalação precisam ser cortados pela metade, indo de 13 para 6 minutos.

Fazer 

Kevin instalou o modulo nativo do CodePush com a funcionalidade de atualização automática padrão, reconstruiu a aplicação nativa, instalou nos dispositivos e enviou uma atualização.

Primeiras impressões: O tempo de desenvolvimento foi rápido e o instalação também pareceu ser. Kevin o manteve e continuou fazendo pequenas alterações por uma semana.

Foi horrível!

Por quê? O desenvolvedor poderia nunca saber quando a aplicação foi atualizada, qual versão do código estava rodando. O desenvendor somente iniciou o aplicativo e aguardou pela atualização que poderia nunca ter chegado, encerrado a aplicação e realizado a atualização...

Então Kevin melhorou a integração do CodePush na aplicação e adicionou um botão de atualização com o status da atualização, ele ainda exibiu a versão do CodePush e o ID da implementação entregue.

Instalar as atualizações manualmente permite aos desenvolvedores se sentirem realmente responsáveis pela atualização. Exibindo a versão implementada também permite melhorar a comunicação com o PO quando os erros aparecerem, além disso saberão o exatamente em qual commit encontrar os erros.

Check 

E aqui temos alguns resultados:

• O tempo de desenvolvimento foi de 10 para aproximadamente 5 minutos.
• O tempo de instalação foi de 3 para menos de 1 minuto.
• A instalação está rápida, os desenvolvedores frequentemente mantém os dispositivos plugados no computador, eles ganharam mais 30 segundos ou menos nesta etapa.

A duração média foi de 35 minutos com o uso do Bitrise, para 17 minutos manualmente e eventualmente por volta de 9 minutos com o CodePush.

Ação 

Por resolver este problema Kevin criou diversas "estações de trabalho". Um padrão de tempo máximo para o desenvolvimento, instalação e teste além de um novo processo de implementação para respeitar este padrão.

A primeira ação tomada foi conversar sobre este problema em uma escala horizontal, Kevin fez uma sessão Yokoten onde compartilhou o problema e as soluções propostas.

A segunda ação foi a de escrever o novo processo para implementar o CodePush em diversos aplicativos. Cada novo empregado da BAM agora tinha conhecimento disso e eram treinados na sessão inicial ao entrar para o grupo.

A última ação de Kevin foi rodar um "CodePush Dojo" e encorajar todos a instalar o CodePush em seus aplicativos com sua ajuda.

Se focarmos na abordagem enxuta poderíamos descrever a seguinte sequência:

• Go / Sees do CTO são cruciais para fazer os desenvolvedores enxergarem os desperdícios que devem sofrer, e ajudá-los a identificar os desperdícios eles mesmo.
• Ser cuidadoso com soluções automáticas conhecidas como "Balas de prata" que tentam resolver o problema de primeira (Ex: Bitrise).
• Focar apenas no fluxo de uma única parte evitando ter múltiplas partes da atividade em progresso.
• Reduzindo o ciclo de entrega, é possível identificar e quantificar os desperdícios que podem ser removidos ou reduzidos.

Conclusão

Enfrentando desafios da atual era digital, gerentes e trabalhadores da TI tendem a buscar soluções tecnológicas para resolver problemas sem entender os detalhes do que está acontecendo e sem checar realmente se a situação melhorou.

Seja como um gerente ou funcionário o ideal é voltar uma etapa e fazer as pessoas pensarem em como melhorar seu próprio trabalho. O sistema enxuto tem provado ser uma abordagem estruturada que ajuda equipes alcançarem seu objetivo. No mundo da TI isso é chamado Lean IT e ela definitivamente auxilia na identificação de problemas significativos além de superá-los.

Sobre os autores

Kevin Raynel é arquiteto, desenvolvedor de software e coach na Theodo, anteriormente na BAM. Ele desenvolveu aplicações web e mobile nos últimos cinco anos utilizando diversas tecnologias. Além da parte técnica de seu trabalho, ele tem como objetivo ajudar sua empresa e seus clientes a desenvolverem aplicações da forma mais eficiente possível utilizando resolução de problemas e pensamento enxuto.

Marc Legru é coach Ágil/Lean para CEOs/CTOs, gerente, líder de times e equipes. Ele ajuda CEOs/CTOs de startups a crescerem de forma sustentável. Também é parceiro na Operae Partners, uma empresa de consultoria especializada em Lean IT e servicos Lean para startups e organizações tradicionais. Marc foi autor do primeiro MOOC Francês de Lean Management com a startup francesa UNOW. Siga ele no Twitter em: http://twitter.com/MarcLegru

Stéphane Wojewoda ajuda pessoas e corporações a crescer e se desenvolver em um ritmo sustentável. Ele gosta de se manter atualizado com as últimas novidades sobre cultura e tecnologia. Fica feliz quando a equipe em que trabalha atinge o ponto onde sentem que entenderam porque fazem o que fazem e conseguem fazer direito a coisa certa no tempo certo somente com o esforço necessário.