quarta-feira, 27 de dezembro de 2017

Tem desperdício em Desenvolvimento de Software?

Introdução

Estima-se que 2/3 de alimentos são jogados fora todos os anos no mundo inteiro. Isso equivale a 1,3 bilhões de toneladas de produtos que não serão utilizados por nenhum ser humano. Para alarmar ainda mais, isso equivale à 1 trilhão de dólares jogados no lixo anualmente.[1]

Quando citamos estes números, estamos falando em números absolutos focando estritamente nos alimentos, mas existem outros desperdícios durante toda a cadeia de produção destes alimentos. E a água que foi utilizada? A energia elétrica? Os adubos? Tudo isso torna-se desperdiçado também, haja vista que o propósito para a qual foram utilizados, não serviu para ninguém.

O desperdício mencionado no exemplo dos alimentos, pode muito bem ser aplicado também ao desenvolvimento de software, pois quando entregamos software que não será utilizado em 100%, gastamos tempo de funcionários, infra estrutura, esforço, e principalmente o dinheiro do cliente. Enquanto o desperdício de alimento gera revolta, o desperdício em desenvolvimento de software gera prejuízo.

Símbolo do Desperdício


Frederick Winslow Taylor, em 1911 escreveu que "No passado, o homem estava em primeiro lugar; no futuro, o sistema terá primazia".[2] Em seu escrito, o que Taylor está dizendo, é que construiríamos ferramentas poderosas que aumentariam exponencialmente nosso poder de produção. Hoje existe uma grande facilidade de se criar software, as ferramentas cada vez mais robustas, permitem que se construa um sistema com uma velocidade extraordinária, comparada à poucos anos atrás, dá-se a isso o nome de Eficiência.

Mas onde estão os desperdícios na construção de Software?

Como definir o que realmente é desperdício no desenvolvimento de Software? Baseado nos 7 desperdícios dentro do conceitos Lean de Produção, Mary e Tom Poppendieck desdobraram isso para Desenvolvimento de Software.[3]

Vejamos quais são:

Trabalho Inacabado

O problema do trabalho parcialmente feito é um dos grandes problemas dentro do desenvolvimento de software. Frases como "já está pronto, só falta testar" exemplificam muito isso. Alguns exemplos de trabalho inacabado podem ser: documentações não codificadas, código não 'mergeado' no repositório master, código não testado, sistema não instalado;

Funcionalidades Extras

É o famoso gold plating, ou seja, é desenvolver funcionalidades não requeridas pelo cliente como forma de agradá-lo, colocando uma "cerejinha no bolo". Este é o pior dos desperdícios, onde Taiichi Ohno chama de superprodução, ou seja, é criar estoque que não será "imediatamente" necessário.

Reaprendizagem

Há dois níveis de desperdício dentro deste tópico que são: 1) esquecer o que foi aprendido no passado e ter que reaprender; 2) ignorar conhecimento de outras pessoas não envolvidas no processo de desenvolvimento. Resumidamente, é perder o controle do conhecimento gerado/absorvido.

Transferências de Controle (handoffs)

Esse é um problema que raramente será eliminado, mas pode ser mitigado. Isso porque a comunicação do conhecimento tácito, aquele adquirido pela experiência, sempre resulta em perda de conhecimento. Estima-se que 50% do conhecimento tácito fica para trás na primeira transferência de controle.

Troca de tarefas

É o famoso dividir o foco em mais de uma atividade. É cientificamente comprovado, segundo Vítor Massari em Gerenciamento Ágil de Projetos, que 40% do esforço é desperdiçado quando um desenvolvedor alterna de uma tarefa para outra. Existe um consumo de energia no cérebro para que o desenvolvedor se desligue de uma tarefa e inicie uma outra.

Atrasos

O software implementado e testado precisa ser homologado pelo cliente ou designados por ele, mas eles não tem tempo disponível para homologar: desperdício. Aguardar pela disponibilidade de pessoas de outras áreas é uma das grandes causas de desperdício gerando o famoso "atraso".

Defeitos

Este desperdício gera um sentimento negativo diante do cliente: falta de credibilidade. Construir um software cheio de bugs é terrível, porque além de gerar uma sensação de desconfiança, gera custo de qualidade e gasta tempo de desenvolvedores.

Como resolver a questão dos desperdícios?

Os métodos ágeis possuem muitos profissionais experientes, mas que muitas vezes tropeçam em uma armadilha que é corriqueira demais: focar em ferramentas e técnicas e não na resolução de problemas e eliminação de desperdícios. O desenvolvimento de software, deveria abarcar tanto o foco no método ágil, otimizando o processo de construção, quanto na melhora do fluxo inteiro de valor.

Estima-se que apenas 20% dos recursos e funcionalidades em software são utilizados com regularidade e que 50% dos recursos de um software (utilizados ou não) nao agregam valor ao negócio.[4]

Os desenvolvedores, segundo pesquisa feita pela Carnegie Mellon com 13.000 programas, cometem entre 100 e 150 erros em cada mil linhas de código, comprometendo assim a qualidade do produto, demandando 80% do orçamento para correção destes erros.

Em suma, uma boa metodologia de desenvolvimento de software inicia-se com uma premissa simplória: identificar 20% do código que proporcionam 80% de valor e executá-los dentro do tempo de forma puxada ao invés de empurrada e sempre envolver o cliente na definição dos requisitos e testes.[4]

De forma sintética, usando o contraponto mencionado no início deste post, quando falamos que crescemos em Eficiência, deixo uma frase do famoso Peter Drucker e logo em seguida abordaremos os métodos resolutivos para cada tipo de desperdício demonstrado até aqui:
Sem dúvida, não há nada tão inútil quanto fazer com grande eficiência o que não devia ser feito de modo algum[2]
Drucker está confrontando aqui Eficiência versus Eficácia. Isso é assunto para um outro post.

Métodos resolutivos


Desperdício Resolução
Trabalho Inacabado - Uma boa definição de pronto (done);
- Dividindo o trabalho em pequenos lotes ou iterações;
Funcionalidades Extras - Se não houver uma necessidade econômica, a funcionalidade não deve ser implementada;
- Entregue somente o que o cliente pediu (concentre-se no trabalho dele);
- Entregue VALOR e QUALIDADE
Reaprendizagem - Registre tudo o que você sabe;
- Anote todas as decisões tomadas
Transferências de Controle - Reduza o número de transferências;
- Faça transferências face a face ao invés de documental (mas mantenha o documento);
- Faça transferências através de modelos, protótipos e simulações
Troca de Tarefas - Comece a terminar e pare de começar;
- O time que construir, deverá manter;
Atrasos - Todos envolvidos devem estar completamente disponíveis a qualquer hora;
- Conhecimento compartilhado evita silos;
- Iterações curtas com feedbacks frequentes;
Defeitos - Testes automatizados, antecipados e frequentes;
- TDD (prática do XP)

Espero ter contribuído. Até mais!


Referências

1. https://www.embrapa.br/busca-de-noticias/-/noticia/28827919/os-desperdicios-por-tras-do-alimento-que-vai-para-o-lixo (27/12/2017);
2. Startup Enxuta. Ries, Eric
3. Implementando o Desenvolvimento Lean de Software. Poppendieck, Mary; Poppendieck, Tom
4. TI Lean, capacitanto e sustentado sua transformação Lean. Bell, Steven.

Total de visualizações de página

Pesquisar este blog

Seguir

Sobre mim

Minha foto
Daniel C. Moreira
Sou um apaixonado por leituras. Desde 2000 trabalhando com tecnologia, posso me considerar um "fanático" por resolver problemas da melhor maneira possível e idealizar soluções que atendam ao negócio. Atuo atualmente como Agile Coach, mas já foi Professor, Instrutor, Programador, Desenvolvedor, Analista de Sistemas, Líder Técnico, Analista de Negócio, Gerente de Projetos, além de na vida pessoal atuar como Pastor Evangélico desde 2013.
Visualizar meu perfil completo

Followers