Retrabalho significa jogar tempo, dinheiro, etc. fora. Certamente, ninguém quer isso. Para tentar evitar esse retrabalho, normalmente a solução proposta envolve especificar “bem especificado”, planejar “bem planejado”, tudo com muita antecedência. É a velha muscle memory agindo. Sabemos que isso não funciona. Simplesmente porque é impossível prever o futuro.
A solução que eu acredito funcionar é aplicar as práticas de XP. E não basta aplicar uma ou outra, temos que aplicar todas. Juntas elas promovem uma sinergia que não existe quando são utilizadas de forma isolada.
Práticas como TDD, refactoring, integração contínua, programação em par, cliente presente, sentar-se junto, design incremental garantem uma base de código saudável, com design simples. Com isso o custo de mudança permanece constante ou mesmo pode cair com o tempo.
Kent Beck viu em muitos times XP que ao longo do tempo os sistemas desenvolvidos por esses times ficavam cada vez mais flexíveis e fáceis de mudar ao invés do que estamos mais acostumados a ver, que são aqueles sistemas legados cujo custo de mudança cresce exponencialmente com o tempo. Tal afirmativa pode parecer ir contra o senso comum mas faz todo o sentido quando temos as práticas do XP aplicadas corretamente.
O custo de um time XP competente é inegavelmente alto. Mas compensa no longo prazo por permitir que sistemas não precisem ser reescritos do zero a cada x anos. Além disso, outros motivos existem para se ter um time competente. Por exemplo, evitar o custo dos Net Negative Producing Programmers. Ou seja, na minha opinião vale a pena pagar pelos melhores.
Tenho vendido a idéia de que se uma equipe ágil está funcionando bem, nunca haverá retrabalho e sim, simplesmente, trabalho.
Guilherme Cirne 
Isso aí.
Uma das premissas desse modelo de desenvolvimento é que o desenvolvimento do software/produto é feito de forma incremental. Sendo assim, o que se consideraria retrabalho num modelo BDUF é simplesmente “traballho para acomodar as mudanças e novas features” em Agile.
[ ]s, gc
@GC
Exatamente!
Nao acho que as praticas do XP sao todas recomendadas sempre, acho que depende de cada equipe e ate mesmo projeto, mas concordo que existe uma sinergia entre todas elas.
Em relacao ao design simples, a complexidade reside em ter que corrigir equivocos de design ao mesmo tempo que os requisitos sao entendidos e implementados, e pra esse tipo de “metadesenvolvimento” é necessario programadores com conhecimento do negocio, alem de obviamente tecnicas de engenharia de sw, como vc fez questao de mencionar.
É isso ai!
@Carlos Alexandre
Concordo que as práticas não são todas recomendadas sempre e em qualquer contexto. Mas para tirar uma ou outra, é preciso saber muito bem o que se está fazendo para poder avaliar as consequências dessa decisão de forma adequada.
Grande abraço Moscoso!
Cirne,
Parece um desabafo 🙂 Seu post fala sobre algumas das premisas para se ter uma equipe trabalhando nos moldes do Agile Manifesto. Na verdade qq pessoa que tenha estudado um pouco mais sobre metodologias ágeis saberia o que vc cita neste seu post.
Boa conclusao sobre o que as pessoas acham que é retrabalho e nos times ágeis é simplesmente evolução, vemos nitidamente que as pessoas que falam isso nao entendem nada e isso é totalmente ligado ao Muscle Memory que o Ken Schwaber fala em um dos seus livros. Acaba sendo um reflexo por nao conhecer e nao confiar no time, eu acho 🙂
Alias, mais uma fez parabéns pelo filhote 🙂
abs,
Antonio
[…] Retrabalho Não Combina Com Equipes Ágeis […]