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.
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.
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 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.
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.
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.