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.
O que você achou? Coloque seus comentários e sugestões abaixo!
Acompanhe o RSS dessa página.
Comentários (1 até o momento)
wagao — 07/11/2007 13:45