Nossas experiências com metodologias ágeis estão rendendo bons resultados.

Hoje temos 2 projetos cujas expectativas foram superadas logo na segunda iteração. Interessante isso ter acontecido em ambos projetos e em ambos na segunda iteração, porque mostra justamente que há uma fase de aprendizado inicialmente, que foi rapidamente ultrapassada. Isso motiva a equipe e reforça a idéia de que usar “baby steps” não significa que o progresso seja lento.

Processos ágeis permitem esse aprendizado. Ele vem justamente do rápido feedback das iterações, e permite a rápida incorporação do aprendizado nos projetos. (Não temos que esperar todo um novo projeto, ou todo um novo planejamento pra colocar em prática nossas lições).

A retrospectiva parece boba, normalmente é negligenciada, mas aposto que as equipes desses 2 projetos já têm opiniões a favor dessa prática. Deixa eu contar um pouquinho do nosso projeto na aeronáutica, que é constantemente citado em listas de discussão.

Antes mesmo do projeto começar e qualquer equipe ser alocada, já iniciamos um trabalho de conscientização das nossas práticas, explicamos como fazíamos software e por que fazíamos dessa maneira. Tínhamos que tranqüilizar o cliente para que ele visse que a forma de fazer software diferente não ia trazer riscos contratuais ou prejuízos para eles.

Felizmente na aeronáutica tivemos um grande caso de sucesso ano passado usando XP. A equipe que acompanhou o outro projeto também passou segurança para a equipe desse novo contrato. Estamos mudando uma cultura de pouco em pouco. Trabalho de formiguinha mesmo.

Pois bem, o contrato era para a manutenção de um sistema feito em parceria entre Exército e Aeronáutica. Existiam 2 branches do sistema. Uma para cada força. E seria feito um merge antes do começo. Para nossas práticas ágeis, tivemos apoio total das equipes que já desenvolviam o projeto em ambas as forças. Todos tinham curiosidade pra colocar esses conhecimentos em prática, estavam doidos pra fazer teste automatizado mas nunca tinham encontrado um ambiente favorável pra isso.

Essa falta de ambiente favorável é comum por aí. Nunca há tempo pra criar a estrutura de testes, nunca há tempo pra desenvolver as classes de teste e continuamos desenvolvendo como sabemos que dá merlin. No entanto, sempre encontramos tempo pra consertar as merlins.

Depois de várias tentativas de início em falso, porque o tal do merge nunca ficava pronto pra começarmos numa versão definitiva, tivemos o primeiro Sprint Planning.

A equipe: Willi, Bruno, Carol, Rafael da SEA, Ten. Souto e Ten. Tarcísio da Aeronáutica, Cap. Sant’Ana e Ten. Waleska do Exército e Tiago, como terceirizado do Exército.

Continua no próximo capítulo…

Episódio II