Os Sete Pecados Capitais do Desenvolvimento de Software

O quadro o Jardim das Delícias Terrenos é um dos mais impactantes quadros a avisar aos transgressores da fé católica o destino deles ao final de uma vida impura. Obra-prima de quase 2 metros de altura e largura, o quadro retrata o inferno dos luxuriosos, gulosos, avarentos, invejosos, preguiçosos, iracundos e vaidosos.

O Jardim das Delícias Terrenas
Obra prima de Hieronymus Bosch, pintor holandês contemporâneo de Leonardo da Vinci

 

Se a engenharia de software tivesse um inferno, poderíamos nos arriscar, como Dante Aligheri, a descrever os sete pecados capitais do desenvolvimento de software que os porquinhos de software cometem em base diária. Mary Poppendieck, uma das autoras doLean Software Development, descreva 7 formas de desperdício no desenvolvimento de software. Apresento e contextualizo estes pecados capitais abaixo no dia a dia do trabalho de software.

1. Funcionalidades extras. Pesquisas de institutos como o Standish Group (XP Conference, 2002) mostram que metade das funcionalidades de um software são raramente ou nunca usadas. Ainda assim, é muito comum que desenvolvedores “criativos” introduzam funcionalidades não desejadas em seus software que não trazem valor agregado algum para os seus clientes. A redução do desperdício tem forte relação com escrever menos linhas de código.

2. Transferência de responsabilidades, conhecimentos, ações e feedbacks. O uso de papéis muito especializados é um sintoma deste problema. “Arquitetos” e “projetistas” que não sabem codificar, “desenvolvedores” que não sabem testar ou implantar software e “gerentes de projeto” que se orgulham de não entrar em temas técnicos são exemplos de handovers (repassese fontes comuns de desperdício.

3. Defeitos. Se orgulhar de ter um time de testes que encontra muitos defeitos é no mínimo contra-produtivo. Devemos nos lembrar que defeitos são desperdícios, ou dinheiro jogado fora. As ações de projetos devem impedir que defeitos sejam introduzidos em primeiro lugar, e não focar em pegar defeitos ao final.  Um exemplo simples é no ciclo tradicional de especificação, codificação e testes. Ao invés, o teste deve validar e corrigir a especificação antes que a primeira linha de código seja escrita, visto que a maior parte dos defeitos nasce ainda na especificação do software. Da mesma forma, é papel do desenvolvedor usar técnicas diversas (refatoração, teste de unidade e integração contínua) para reduzir a quantidade de defeitos introduzidas no software.

4. Débito Técnico. Fazer código de má qualidade tende a gerar débito técnico no código, módulo e arquitetura de um produto. O débito técnico gera um efeito muito ruim a médio e longo prazo e gera efeitos colaterais no produto em pontos não imaginados. Livros como “Clean Code”, do Robert Martin, exploraram a criação de código de qualidade

5. Trabalho em progresso. Manter uma longa lista de tarefas com o status em  ”execução” esconde problemas e eventualmente gera desperdício. Cada pessoa de um time deve manter o mínimo número de tarefas abertas. Cada tarefa aberta deve ser rapidamente terminada para reduzir o seu tempo de ciclo, evitar retrabalhos e trabalho multitarefa. Um exemplo vem da metodologia japonesa chamada Kanban, que introduz o conceito chamado (WIP). O WIP (Work In Progress) tem um valor limite pequeno (tipicamente 3) e impede que uma pessoa tenha mais de 3 tarefas em execução. Um outro exemplo de combate a este desperdício é a prática de entregar software com frequência para os usuários chave, que limita o tamanho do backlog de tarefas em aberto para todo o time de desenvolvimento.

6. Trabalho multitarefa. Há algum tempo este mito assola os times de software, atolados no trabalho de novas demandas e na resolução de defeitos e adaptações de diversos softwares em paralelo. Estudos diversos mostram que o fator multitarefa reduz a produtividade, gera desmotivação e trabalho de pior qualidade, o que introduz mais defeitos e gera mais trabalho em progresso.

7. Esperas e atrasos. Provocar esperas e atrasos gera um efeito nocivo na produtividade do time e é também uma forma de desperdício. Por exemplo, enviar um email para uma equipe de desenvolvimento validar um documento de casos de uso gera espera, atraso e descontinuidade do trabalho. Apresentar este documento ao vivo melhora o entendimento para todos e também reduz ciclo de validação do documento gerado. Allistar Cockburn descreve a prática chamada de “Radiadores de Informação” em seu método ágil chamado Crystal Clear, que consiste em manter pessoas próximas e privilegiar a comunicação ao vivo com o uso de quadros brancos. Outros métodos ágeis como o Scrum ou o XP também advogam práticas similares.

Eliminar desperdícios é chave para gera software mais eficaz e em menos tempo para clientes. Um bom livro sobre este tema é o livro: Implementing Lean Software Development: From Concept to Cash, de Mary e Tom Poppendieck.

Lean Software Development

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s