Redundância

Sim, redundância. Os problemas difíceis e críticos em desenvolvimento de software devem ser resolvidos de várias formas diferentes. Mesmo que uma solução falhe completamente, as outras soluções irão prevenir um desastre. O custo da redundância é mais que pago pela economia de não ter um desastre.

Por exemplo, defeitos corroem a confiança e confiança é o que mais elimina desperdícios em desenvolvimento de software. Defeitos são problemas críticos e difíceis. Defeitos são tratados em XP por diversas práticas: programação em par, integração contínua, sentar-se junto, envolvimento do cliente real e implantações diárias, por exemplo. Mesmo que o seu parceiro não detecte um erro, outra pessoa sentada na mesma sala talvez o detecte. Ou talvez o problema seja percebido na próxima integração. Algumas dessas práticas são certamente redundantes, pegando alguns dos mesmos defeitos.

Não dá para resolver o problema do defeitos com uma única prática. É excessivamente complexo, com muitas faces e nunca será resolvido completamente. O que você espera alcançar é um número suficientemente pequeno de defeitos para manter a confiança tanto dentro da equipe, quanto com o cliente.

Apesar de redundância poder implicar em desperdícios, tome cuidado para não eliminar redundâncias que servem a propósitos válidos. Ter uma fase de testes após o desenvolvimento estar completo deveria ser redundante. Entretanto, elimine a fase apenas quando se provar que ela se tornou redundante na prática, na medida em que não pega mais nenhum defeito após inúmeras implantações consecutivas.

Autoria

Texto de Vinícius Manhães Teles.
Ilustrações de Leandro Mello.

Publicado em 02/10/2006.

Licenciado como Creative Commons Atribuição.