Como evitar desperdício ao escrever código

Quanto mais pudermos reduzir o desperdício no desenvolvimento de software, melhor será para todos.

O longo caminho em direção à qualidade está repleto de desvios, falsos começos e desvios. O inimigo da qualidade é o desperdício, porque o desperdício nunca é desejável. Ninguém paga ninguém para entregar resíduos. Às vezes toleramos o desperdício como parte do processo de tornar algo útil e desejável, mas quanto mais pudermos reduzir o desperdício enquanto fazemos algo, melhor.

Na engenharia de software, o desperdício pode ser expresso de algumas maneiras:

1. Defeitos
2. Parado e esperando
3. Superprodução
4. Superprocessamento
5. Qualquer outra atividade que não agregue valor diretamente nas mãos dos usuários

Vamos examinar cada um desses cinco tipos de resíduos.

Defeitos

Parece haver um sentimento predominante na indústria de software de que bugs (defeitos) são inevitáveis. Não é se, mas quando e quantos, os bugs chegam à produção.

Você pode combater esse sentimento derrotista lembrando aos engenheiros de software que todo e qualquer bug é de autoria. Bugs não ocorrem espontaneamente. Eles são criados por nós, seres humanos tentando fazer o melhor desenvolvimento de software possível. Mas ninguém é perfeito. É claro que não criamos bugs intencionalmente, mas eles acontecem. Freqüentemente, resultam de pressa ou talvez de educação e treinamento inadequados.

Seja qual for o motivo, os bugs são causados, o que significa que podemos eliminá-los resolvendo os problemas que os causam.

Parado e esperando

Nossos parceiros de negócios que financiam nossos esforços de desenvolvimento de software tendem a perceber sempre que não estamos produzindo código de remessa como tempo gasto ocioso. Por que estamos ociosos e o que estamos esperando? É uma pergunta razoável a ser feita, se você considerar que eles estão pagando potencialmente milhares de dólares por hora para manter a equipe funcionando.

Ficar parado é um desperdício. Não contribui para os resultados financeiros e pode ser um sinal de confusão. Se a equipe disser que está esperando alguém retornar da licença, isso sinaliza habilidades de organização deficientes. Nenhuma equipe deveria chegar ao ponto de ficar encurralada e sofrer um único ponto de falha. Se um membro da equipe não puder participar, outros membros deverão intervir e continuar o trabalho. Se isso não for possível, você estará lidando com uma equipe muito frágil, inflexível e pouco confiável.

Claro, existem muitos outros motivos possíveis para a equipe estar ociosa. Talvez haja confusão sobre a prioridade mais alta atual, então a equipe está esperando para saber qual é a prioridade correta.

Existem muitas outras causas razoáveis para a inatividade, e é por isso que esse tipo de desperdício parece mais difícil de controlar. Seja qual for o caso, as organizações maduras tomam medidas preventivas para minimizar potenciais inatividade e tempo de espera.

Superprodução

Muitas vezes rotulada como “banhada a ouro”, a superprodução é uma das formas mais insidiosas de desperdício. Os engenheiros de software são notórios por sua propensão a exagerar no entusiasmo pela criação de recursos e capacidades interessantes. E como o software, como o próprio nome indica, é muito flexível e maleável, há muito pouca resistência ao ataque do inchaço.

Este inchaço terrível cria muitos resíduos. Combater o inchaço é o objetivo da disciplina prudente da engenharia de software.

Superprocessamento

Um dos maiores problemas da engenharia de software é conhecido como Geek-At-Keyboard (GAK). Um equívoco comum é que os engenheiros de software passam a maior parte do tempo escrevendo código. isto está longe de ser verdade. A maior parte do tempo gasto em atividades diárias regulares (além de participar de reuniões) é gasto em atividades de teclado não relacionadas à escrita de código: mexer em configurações e ambientes, executar e navegar manualmente no aplicativo, digitar e redigitar dados de teste, percorrer o depurador, etc.

Todas essas atividades são desperdício. Eles não contribuem para entregar valor. Um dos remédios mais eficazes para minimizar o tempo improdutivo do GAK é o desenvolvimento orientado a testes (TDD). Escrever testes antes de escrever código é um método comprovado para evitar processamento excessivo. A abordagem de teste primeiro é uma forma muito eficaz de eliminar desperdícios.

Outras atividades que não agregam valor às mãos dos usuários

Nos primórdios da nossa profissão, o valor era medido pelo número de linhas de código produzidas por unidade de tempo (por dia, semana, mês, etc.). Mais tarde, esta forma bastante ineficaz de medir o valor foi abandonada em favor de um código funcional. Não há correlação convincente entre o número de linhas de código e o código funcional. E uma vez que o código funcional se tornou a medida de valor, o número de linhas de código tornou-se irrelevante.

Hoje, reconhecemos que o código funcional também é uma métrica sem sentido. Só porque o código compila, constrói e funciona não significa que ele esteja fazendo algo de valor. A execução bem-sucedida do código pode ser um processamento fútil, como contar de 0 a 10 e depois voltar a 0. É muito mais importante focar no código que atenda às expectativas dos usuários finais.

Ajudar os usuários finais a cumprir seus objetivos ao usar seu produto de software é a única medida de valor. Qualquer outra actividade que não contribua para esse valor deverá ser considerada desperdício.