Pontos Principais
- Dois princípios importantes do Lean Manufacturing se aplicam diretamente à engenharia de software: Inventário e Tempo de Espera.
- O Inventário é representado por histórias de usuários parcialmente concluídas, códigos que não foram implantados ou histórias de usuários presas em um backlog.
- O Tempo de Espera é representado por histórias de usuário ou códigos que estão atrasados devido às aprovações, disponibilidade ou outros bloqueios que impedem a implementação em produção.
- Os Mapas do Fluxo de Valor costumam ser usados para exibir Inventário e Tempo de Espera, mas a complexidade pode mascarar os gargalos.
- Existe uma forma simplificada de mapeamento do fluxo de valor que facilita a visualização de gargalos e processos ineficientes no ciclo de vida da entrega do software.
Introdução
Este artigo descreve como criar um mapa de fluxo de valor simplificado que pode ser usado para descobrir práticas de desperdício em uma empresa de software. Iremos discutir brevemente os princípios Lean e a definição de resíduos. A partir daí, descreveremos como construir a análise e interpretar os resultados.
A Filosofia Lean do Desperdício
O desperdício é um ponto fundamental para os princípios da filosofia do Lean Manufacturing e, como resultado, tem uma definição especial. Em suma, o desperdício é definido como qualquer coisa que não contribua diretamente para disponibilizar um produto nas mãos dos clientes. Ou seja, qualquer processo ou tarefa é considerado um desperdício se não for possível mostrar que resulte diretamente em um produto que se aproxima da entrega aos clientes. Outra maneira de pensar sobre isso é, o cliente estaria disposto a pagar pelo processo ou tarefa? Se não, então provavelmente é um desperdício.
O Lean Manufacturing coloca um grande foco na redução ou eliminação de desperdício nas mais diversas formas e, ao fazê-lo, melhora a eficiência e a lucratividade dos processos de fabricação.
Mas o que isso significa para engenharia de software? Não temos fábricas e linhas de montagem produzindo widgets que serão usados para criar um produto físico. Todos os produtos são eletrônicos, uma série de zeros e uns que costuramos para formar produtos digitais. Na verdade, os princípios do Lean Manufacturing aplicam-se muito bem ao nosso campo. Neste artigo, iremos cobrir apenas dois deles, o Inventário e o Tempo de Espera.
O problema do Inventário
Na manufatura, o estoque é definido como material inacabado necessário para criar produtos ou os produtos que estão concluídos e que aguardam a entrega para os clientes. O problema é que o estoque excessivo representa certo desperdício, porque o dinheiro foi gasto para comprar ou criar o estoque, mas ainda não está sendo utilizado. Isso significa que é um desembolso de capital que não está fornecendo retorno sobre o investimento. Além disso, é necessário mais dinheiro para armazenar, mover ou gerenciar o estoque, agravando o problema. Tudo isso gera desperdício.
A forma mais óbvia de estoque na engenharia de software é o código que foi concluído, mas ainda não foi disponibilizado aos clientes. Esse código pode estar aguardando um teste final, algum tipo de processo de aprovação, outro código ou simplesmente esperando para ser implantado no ambiente de produção. Seja qual for o motivo, se o código foi escrito, mas não está nas mãos dos clientes, inevitavelmente deve ser classificado como estando no estoque.
As histórias de usuários também podem ser consideradas uma forma de estoque, embora menos visível do que o software não entregue. Se uma história foi registrada em um backlog, provavelmente é valiosa o suficiente pois alguém teve que criá-la e mantê-la, gastando tempo e dinheiro. Quando isso acontece, a história representa um estoque inacabado que está esperando para ser reunido em um produto final.
O problema do Tempo de Espera
Os princípios Lean ditam que o tempo gasto em espera é um desperdício. Por definição, qualquer coisa que perturbe o fluxo constante de uma fatia da mercadoria, desde o início até a entrega, é um desperdício. O problema mais significativo causado pela espera é o custo de oportunidade. Cada momento que se atrasa a entrega de produtos aos clientes é uma fonte cumulativa de receita perdida. Adicione os efeitos da composição nessa receita e os custos aumentam de maneira exponencial.
No mundo do software, muitas vezes vemos longos períodos de espera. Por exemplo, uma história pode ficar em um backlog por muito tempo antes do início do trabalho. Além disso, o código completo pode ter que esperar por um teste formal, o código testado pode ter que aguardar por aprovações antes que possa ser implantado em produção, além de haver janelas muito estreitas para implantar o código que deve ser agendado com muita antecedência. Finalmente, o código que fica muito tempo represado antes de ser testado ou entregue, fica obsoleto, se tornando apenas uma memória de trabalho em nossas cabeças. Isso significa que será necessário mais tempo e, portanto, aumentando os custos para nos familiarizarmos quando começarmos a testá-lo ou implantá-lo. Todos esses atrasos são um desperdício.
Estes são apenas alguns dos custos associados à espera. Certamente existem outros menos óbvios e muito mais caros.
Tornando o desperdício visível
Existem várias maneiras de exibir os desperdícios em um sistema. A abordagem mais comum é provavelmente o uso de mapas de fluxo de valor. Estes são mapas que mostram a jornada de um produto da matéria-prima até o produto acabado entregue aos clientes. São muito úteis para entender o fluxo de mercadorias e identificar atrasos desnecessários.
Isso nem sempre parece relevante para a engenharia de software porque a ideia de fábrica, caminhões e empilhadeiras não se aplicam neste setor. Mesmo as versões desenvolvidas especificamente para software às vezes parecem não ter as qualidades de serem simples e definitivas. E se quisermos apenas saber uma coisa, para qualquer processo, quanto tempo é gasto devido à espera versus o custo de trabalho? Isso nos daria uma visão simplificada do desperdício para qualquer processo e seria útil para torná-lo em algo mais eficiente.
Os detalhes para construir algo assim são bem diretos. Vamos definir o trabalho como tempo gasto ativamente na criação de um produto, tempo pelo qual os clientes pagariam com prazer. Depois, definiremos a espera como tempo gasto de espera para algo, tempo pelo qual os clientes não gostariam de pagar. Usamos a duração, não o esforço, para ambos e mantemos unidades de tempo consistentes entre eles. Atribuímos um valor positivo às unidades de tempo ao trabalhar ativamente em um produto e um valor negativo ao ficar esperando. Adicione todos e, em seguida, podemos comparar o tempo relativo gasto em espera versus o gasto em trabalho. Um processo perfeitamente eficiente mostraria uma soma positiva sem entradas negativas. Um processo de desperdício mostraria uma soma negativa com muitas entradas negativas. A Tabela 1 mostra uma forma genérica dessa abordagem.
Tabela 1. Um formulário genérico.
Observe como as entradas "Work" são valores de tempo positivos e os valores de "Wait" são negativos. Embora as unidades de tempo aqui sejam genéricas, é importante observar que são consistentes em todos os eventos, porque não podemos comparar, por exemplo, dias e horas. A soma final é ligeiramente positiva, indicando um processo geralmente eficiente, mas que pode ser claramente melhorado reduzindo a quantidade e a magnitude da espera.
Vamos agora passar para exemplos mais realistas.
Uma história sobre duas empresas
Vamos comparar duas empresas de software hipotéticas à medida que criam uma história de usuário e a transformam em software funcional. Embora hipotéticas, as práticas das empresas são baseadas na experiência do mundo real ao longo dos anos. A primeira, chamaremos de Wasteful Inc.,[a][b] é um modelo de ineficiência burocrática. Há longos períodos de espera pontuados por breves momentos de trabalho. A segunda empresa, chamaremos de Efficient Inc., e será exatamente o oposto. Um modelo de processos eficientes que transferem rapidamente uma história da ideia de um software em funcionamento para os clientes. Vamos ver como se comparam usando nossa análise simples.
A Tabela 2 mostra como a Wasteful Inc. realiza a tarefa de história do usuário.
Tabela 2. Entrega da história do usuário da Wasteful Inc.
A Figura 1 mostra a entrega de forma gráfica.
[Clique na imagem para ampliá-la]
Figura 1. Wasteful Inc: entrega da história do usuário em forma de gráfico.
Observe como a abordagem de desperdício usa um método ineficiente de começa-para-começa para fazer o trabalho ao longo da linha do tempo. Isso geralmente é o resultado da espera pela abertura de janelas de agendamento fixas, disponibilidade de equipes com overbooking e por aprovações de tomada de decisão. Várias coisas se destacam imediatamente, a história espera 10 dias antes de ser escolhida pelos desenvolvedores, o que aumenta consideravelmente o atraso. Este pode ser um número otimista, uma vez que as equipes com alocação excessiva podem precisar de meses antes de começar. A história precisa esperar vários dias até que uma equipe formal de QA tenha uma programação aberta e comece a testá-la. Por fim, quando o código é certificado pelo QA e pronto para implantação, deve ficar em uma fila para aguardar a entrega. Em organizações burocráticas, não é incomum encontrar códigos que precisem aguardar uma data de implantação antes de poder ser entregue aos clientes. Também é comum que as implantações exijam vários níveis de aprovação, exigindo reuniões, assinaturas, documentação e outras formas de desperdício. O acúmulo constante de resíduos é visível na Figura 1 como uma linha que se inclina cada vez mais negativamente. A pontuação final é de 2,3 dias de trabalho versus 24 dias de espera, uma diferença de quase dez vezes o tempo de trabalho. Outra métrica a considerar é o tempo gasto trabalhando como uma porcentagem do tempo total decorrido. Neste caso, a Tabela 2 mostra que apenas 8,7% da duração total de 26,3 dias é gasto no trabalho real. Mais de 90% do tempo é gasto devido a espera.
Também podemos considerar uma outra visão, em que analisamos um percentual cumulativo de tempo gasto trabalhando versus o tempo total decorrido. A Tabela 3 mostra isso para a Wasteful Inc.
[Clique na imagem para ampliá-la]
Tabela 3. Porcentagem de entrega da historia do usuário da Wasteful Inc.
Os tempos de trabalho e espera são os mesmos que vimos na Tabela 2, mas agora adicionamos colunas que nos dão a porcentagem do tempo total gasto trabalhando. Observe como a Wasteful Inc. cai drasticamente para menos de 20% da duração total realmente gasta trabalhando. A figura 2 mostra isso em forma gráfica.
[Clique na imagem para ampliá-la]
Figura 2. Entrega da história do usuário da Wasteful Inc. em formato gráfico com porcentagem de trabalho.
A Figura 2 mostra como o percentual de tempo gasto trabalhando na Wasteful Inc. representa apenas uma pequena fração do tempo total necessário para entregar uma história do usuário. Claramente, a Wasteful Inc. não é uma organização ágil.
Vamos ver agora a Efficient Inc., onde o código se move em um fluxo constante, do início ao fim. A Tabela 4 e a Figura 3 mostram os resultados.
Tabela 4. Distribuição da história do usuário da Efficient Inc.
Figura 3. Entrega da história do usuário da Efficient Inc. em formato gráfico.
Observe como há poucas quebras no fluxo em que o processo deve aguardar o próximo passo. Depois que uma história é criada, é passada rapidamente pelo fluxo de trabalho até a entrega aos clientes. Algumas coisas se destacam e dão dicas de como tudo é feito. Primeiro, há pouco tempo de espera para revisar a história com os desenvolvedores. Isso indica que as histórias são criadas quando são necessárias e analisadas no dia seguinte. Não há perda de contexto de memória de trabalho e o proprietário da história pode recuperar facilmente os detalhes. Em seguida, o trabalho começa imediatamente, porque a história é "a coisa mais importante no momento" e o tempo não é gasto para analisá-la depois. O teste formal de QA faz parte do processo de desenvolvimento porque os testadores do controle de qualidade são integrados aos desenvolvedores e isso significa que não há espera por transferências para outra equipe. Os desenvolvedores também estão trabalhando com os testadores para desenvolver o Test-Driven Development, que melhora a qualidade e reduz as passadas de trabalho causadas por um ciclo de reparo-implantação-teste de defeitos. O código é testado à medida que é desenvolvido, o que é uma abordagem muito eficiente. Finalmente, há pouco tempo perdido aguardando agendas de implantação e aprovações. A equipe tem um processo automatizado de implementação de teste de construção usando integração e entrega contínua. Depois que o código é registrado, passa por uma bateria de testes automatizados que verificam a qualidade e, em seguida, são automaticamente implantados no cliente. No máximo, pode haver um breve atraso enquanto o proprietário de um produto faz uma revisão final e, em seguida, pressiona um botão para enviar o código para produção. Essa eficiência é mostrada na Figura 3 como uma linha que segue uma direção positiva ao longo do tempo. A pontuação final é de 2,3 dias de trabalho e 1 dia de espera. A Tabela 4 mostra que 69,7% da duração total de 3,3 dias é gasta no trabalho real. Apenas cerca de 30% do tempo é gasto em espera.
Vamos ver agora o percentual de tempo gasto trabalhando na Efficient Inc. A Tabela 5 e a Figura 4 mostram os resultados.
[Clique na imagem para ampliá-la]
Tabela 5. Porcentagem de entrega da historia do usuário trabalhada na Efficient Inc.
[Clique na imagem para ampliá-la]
Figura 4 - Distribuição da história do usuário da Efficient Inc. em forma gráfica com porcentagem de trabalho.
Essas exibições mostram como a Efficient Inc. gasta uma quantidade significativa de tempo trabalhando quando veicula uma história do usuário. Os números ficariam ainda melhores se a história tivesse passado apenas algumas horas no backlog em vez de um dia inteiro. Esses resultados são uma melhoria dramática em relação à Wasteful Inc. Claramente, a Efficient Inc. é uma organização altamente ágil.
Outros usos
Esta análise não é de forma alguma restrita a histórias de usuários. Pode ser usada para qualquer processo ou tarefa. Por exemplo, quanto tempo é gasto trabalhando em comparação à espera devido a contratação de um novo funcionário? Há tempo gasto discutindo uma nova contratação, criando o anúncio de emprego, analisando inscrições, entrevistando candidatos, fazendo uma oferta, e assim por diante. Como isso se compara ao tempo de espera entre cada uma dessas tarefas? Ou o tempo necessário para adotar uma nova tecnologia ou processo? A partir do momento em que a decisão é considerada até que seja totalmente realizada, quanto desse tempo é gasto esperando? Em resumo, os únicos limites para essa abordagem são a imaginação de uma pessoa.
Como definir em um nome?
Não existe um nome óbvio para essa abordagem. A grosso modo, é um mapa de fluxo de valor, mas uma versão muito simplificada que omite todos os loops e ramificações e, em vez disso, simplesmente define as coisas em uma linha de tempo para facilitar a visualização do tempo gasto trabalhando versus o tempo gasto em espera.
Depois de realizar essa análise e ver quanto tempo é gasto devido a espera, é tentador reformular o título original da peça famosa de Samuel Beckett, Waiting for Godot (Esperando por Godot), para Waiting for Production (Esperando pela Produção), mais tecnologicamente apropriado. Talvez um nome interessante seja Análise de Produção em Espera.
De certo modo, provavelmente deveria ser chamado de Mapa Simples de Fluxo de Valor, mas há uma advertência: Não desperdice, e não queira desperdiçar. É assim que podem chamá-lo, um Mapa de Desperdício, mas podemos chamá-lo de qualquer outra coisa que quisermos. Afinal, o que há de errado? O objetivo é tornar visível o que geralmente está oculto e, ao fazê-lo, expor a quantidade de resíduos que não são detectados. O que quer que escolhamos chamar é irrelevante.
Impedimentos
Como acontece com qualquer ferramenta, existe o perigo de uso indevido. Mesmo que um processo possa exibir uma quantidade considerável de espera, pode haver uma razão comercial perfeitamente justificável para isso. Por exemplo, vamos analisar nossas histórias de usuários. Uma história de usuário pode ainda não estar totalmente desenvolvida quando for registrada em um backlog, a necessidade do mercado descrita pode mudar, a necessidade do negócio pode mudar ou a compreensão da necessidade pode mudar. Ou ainda, a história está inserida como um espaço reservado para uma possível revisão em uma data futura. Tudo isso significa que uma história de usuário ociosa não representa necessariamente um desperdício e, considerando-a, é um uso indevido da análise.
Em suma, a tentativa cega de minimizar a espera sem levar em conta as consequências não intencionais pode acabar causando mais malefícios do que benefícios. Usar certa discrição é algo recomendável.
Conclusão
Certamente há itens adicionais que podem ser incluídos nessa abordagem. Por exemplo, como seria se adicionássemos fatores de ponderação para os eventos de espera e de trabalho que refletem o número de pessoas envolvidas em cada uma? Um evento de espera tem muito mais peso se cinco pessoas estiverem esperando, em vez de apenas uma. E se algumas partes do sistema de software tiverem que obedecer a diretrizes ou cronogramas rigorosos por serem regulamentados e outros não tiverem esse engessamento? Aqueles com supervisão regulatória exigiriam um peso maior porque defeitos e prazos perdidos teriam impactos significativos. Outra possibilidade seria, se fôssemos calcular o custo financeiro real do trabalho versus a espera e produzíssemos uma análise que mostre o custo físico do desperdício? Isso provavelmente seria mais prontamente compreendido pelos stakeholders do que olhando para as coisas através de unidades de tempo. Existem várias maneiras de analisar os desperdícios.
Em resumo, esta é uma abordagem simples para analisar fluxos de valor. Tudo o que requer são habilidades muito básicas, e é aí que reside a atratividade: é simples, fácil e barato. É fácil criar uma linha do tempo que mostre onde os gargalos estão em um determinado processo. Esforços podem então ser direcionados para esses gargalos para melhorar a eficiência.
O autor agradece a Marc Kase (@marckase) pela ajuda na revisão deste artigo no original em inglês.
Sobre o autor
J. Meadows é um tecnólogo com décadas de experiência em desenvolvimento de software, gerenciamento e análise numérica. Este é o primeiro artigo dele no InfoQ.