BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Como a resolução de problemas lean aumenta a produtividade de equipes ágil

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

Favoritos

Pontos Principais

  • Quando enfrentam um problema, funcionários de empresas de tecnologia normalmente sentem-se pressionados a encontrar soluções instantâneas;
  • Essas soluções podem funcionar mas frequentemente não são as ideais e podem ter consequências indesejadas;
  • Aplicar uma rigorosa abordagem para formular problemas, diagnosticando a causa raíz, realizando ações corretivas relevantes, avaliando os efeitos e ao final criar um melhor entendimento do trabalho para desta forma melhorar às práticas diárias das pessoas;
  • Pensamento enxuto traz uma abordagem estruturada para expor e remover desperdícios no processo de desenvolvimento;
  • Diferente categorias de desperdício requerem diferentes abordagens para resolvê-las.

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?

Sprint

Pontos

 

Total de funcionalidades

 

Time desperdiçado por semana
(17 vs 10 min)

Sprint 9

147

51

5h 57min

Sprint 10

98

34

3h 58min

Sprint 11

158

57

6h 40min

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.

Etapa ideal

Tempo ideal

Desenvolver a atualização da aplicação

1''

Instalar a atualização nos dispositivos

1''

Testar manualmente as funcionalidades nos dispositivos em produção

Dependente da funcionalidade

Avisar o cliente que a nova funcionalidade está disponível

1''

 

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.

Etapa ideal

Etapa

Desperdício conhecido

Tempo necessário

Desenvolvimento

 

Desenvolvimento Android

Esperando

2'08''

Desenvolvimento iOS

Esperando

4'44''

Instalação

 

Ir ao laboratório e desplugar os dispositivos

Transporte / super-processamento

30''

Instalar a atualização em todos os dispositivos

Movimentação

3'16''

Testes

Teste da funcionalidade

 

4'16''

Instalar (Voltar ao estado inicial)

Organizar o laboratório, replugar os dispositivos

Transporte / super-processamento

1'25''

Avisos

Voltar ao computador, fazer login no Trello e mover o cartão

Transporte

 

45''

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.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT