Ao invés de escrever sobre nossas impressões sobre a 4a turma do minicurso “XP na Prática”, vamos transcrever aqui o feedback dado pelo Luiz Henrique Correa, originalmente enviado para a lista AgilDF@googlegroups.com (participe!), e aqui publicado com sua devida permissão.

No último dia 18/07 participei do Mini Curso XP na Prática, ministrado pelo pessoal da SEA Tecnologia. Gostaria de relatar aqui as minhas experiências e impressões sobre o curso.

Não é de hoje que eu estudo sobre metodologias ágeis, e o curso pra mim serviu como uma forma de aparar algumas arestas e experimentar de
fato um ambiente Ágil na prática. A didática utilizada é algo completamente diferente do normal, pelo menos dos cursos que eu já participei, o que na minha opinião foi um ponto muito a favor.

Início do Curso:

O curso é prático mesmo. O que faz com que os participantes mergulhem num dia de trabalho XP.
Após uma rápida (muito rápida!) apresentação dos conceitos, valores, práticas e princípios de XP, entramos de cabeça no planejamento das atividades e iterações.

Planejamento das Iterações:

Achei interessante o fato do Bruno (Instrutor) conduzir a reunião de planejamento somente “ditando” as regras (alertando o grupo sobre o tempo máximo da iteração, ajudando na quebra das histórias, etc) e não conduzindo os alunos pela mão.

A turma foi obrigada a se entender quanto aos prazos para realizar as atividades do projeto, e nesse ponto conseguimos ver o quanto é difícil estimar prazos. O problema da estimativa é “resolvido” nas retrospectivas, onde podemos reavaliar e melhorar a nossa estimativa tendo a experiência da iteração anterior. O comprometimento com os prazos também é muito mais intenso quando o próprio time é quem os define, diferente das abordagens comando-controle.

Quebrar as histórias em atividades e tarefas menores, ajuda a enxergar o problema de uma forma mais realista, e com isso podemos estimar melhor e trabalhar mais focado em cada parte do projeto. Tanto gerenciar quanto trabalhar dessa forma é muito mais viável.

Mão na Massa:

Depois do planejamento inicial, o pessoal da Sea iniciou o desenvolvimento das funcionalidades programando para que a turma pudesse começar a se familiarizar com o jeitão XP de fazer as coisas. A programação foi sempre realizada em pares e usando as técnicas de TDD. Depois da primeira iteração os alunos começaram a colocar a mão na massa, também programando em pares usando TDD. Nesse momento percebemos que na prática, a teoria é outra!

TDD:

Sem dúvida o ponto alto do curso foi a utilização das Técnicas de TDD. Logo de início, pensar no teste antes de programar era difícil, e por isso muitas vezes o monitor nos chamava a atenção: “Faz o teste primeiro!”. Mas depois, em pouco tempo, já estávamos praticamente “dependentes” de criar o teste antes de programar, pelo menos no meu grupo foi assim. Não pensávamos mais na funcionalidade sem antes pensar no teste. Com isso ganhamos em foco, comunicação, simplicidade e segurança. Não chegamos a refatorar nada, em função do tamanho do projeto e do pouco tempo que tínhamos, mas certamente com a extensa cobertura de testes (acho que uns 26 testes para umas 8 funcionalidades, pelo que eu me lembro) qualquer mudança poderia ser
feita sem as tradicionais dores de cabeça e, sem precisar “debugar” o código para entender o que estava acontecendo, bastava olhar a suite de testes.

Ao final do projeto, com todos os testes automatizados que tínhamos, estávamos com uma excelente documentação dos requisitos (atual e funcional!), com uma ótima rastreabilidade das funcionalidades e dependências de código, além de uma bruta segurança para fazer qualquer modificação necessária, sem medo de quebrar as funcionalidades existentes. Tudo isso graças aos nossos Testes Automatizados, tudo isso graças ao TDD.

Programação em Pares:

Ver o pessoal da Sea programando em pares é muito bacana. A sintonia dos pares, a troca de experiências, a comunicação, tudo parece muito necessário no contexto XP. Mas confesso que eu não sou muito adepto a essa prática, prefiro uma sessão de programação pareada mais específica, para um problema ou outro, ou até mesmo escrever alguns testes ou métodos em pares. Mas sempre programar em pares eu não vejo com muitos bons olhos e não tive tão boas experiências com essa prática. Mas tenho que admitir que existem muitos benefícios nela.

Retrospectiva:

Sempre depois de cada iteração nós realizávamos uma retrospectiva: O que fizemos, o que pretendemos fazer, e onde precisamos melhor para atingir os nossos objetivos. Nessas rertrospectivas tínhamos a chance de rever o nosso planejamento inicial e adequá-lo a nossa real necessidade naquele momento. Um ponto muito interessante das retrospectivas, era quando o Time sabia que não conseguiria entregar toda a funcionalidade prometida na release, e tinha que negociar com o cliente o que era mais importante, qual era a funcionalidade que agregava mais valor ao cliente, pois era essa que receberia o foco nas
próximas iterações. Esse exercício mostrou o quanto a figura do “cliente presente” é importante para o sucesso do projeto.

Documentação? Modelos?

Normalmente eu sempre procuro ter um diagrama de classes à mão para programar. E antes de programar eu gosto de pensar no diagrama de classes. No nosso projeto não criamos e nem usamos qualquer diagrama UML, e sabe que falta eles fizeram? Nenhuma! Fui pensar nisso depois que cheguei em casa e analisei alguns pontos do curso para escrever sobre ele. E eu creio que essa total irrelevância dos diagramas deve-se ao TDD. Criando os testes e modelando via TDD acabamos por saber exatamente o que precisamos fazer a cada passo, e com isso, os nossos métodos e classes vão nascendo de acordo com a necessidade real e momentâneas do projeto. Nada de desperdício!

Lógico que em nenhum momento foi falado que diagramas e modelos não são necessários nem importantes, mas o recado é: fazer quando necessário, fazer para auxiliar na comunicação da equipe e não fazer apenas por fazer.

O Pessoal da Sea:

Eu não participei de toda a programação, a turma ficou muito grande (um ponto negativo mas sem culpa do pessoal da SEA) e eu dei espaço para outro colega programar. Aproveitei e fui trocar idéias com o Willi, Bruno e Carol. Todos são muito acessíveis, humildes em escutar as nossas opiniões e bastante generosos ao explicar muito de como eles pensam e agem no dia-a-dia dos seus projetos. A troca de experiências é sem dúvida um outro ponto fortíssimo do curso.

Minha Conclusão:

O curso foi excelente, mas não é pra qualquer um. Eu acho - opinião exclusivamente minha - que nem todos poderão desfrutar dos ensinamentos do curso, porque ele é bem diferente de tudo que normalmente estamos acostumados (além do tema também ser bem diferente do tradicional). Para aproveitar o curso eu acredito ser extremamente necessário um conhecimento, e até mesmo uma simpatia prévia, de métodos ágeis. Em alguns pontos a ficha demora a cair, e só cai realmente se você pensar no que vivenciou e analisar de uma forma “mente aberta”, tudo o que foi visto e praticado no curso.

Pra mim, o curso serviu para reforçar todas as (boas) idéias e impressões que eu já tinha sobre as metodologias ágeis. Serviu também para que eu conhecesse na prática todo o poder de TDD e de iterações curtas, aliadas com um planejamento que nasce de dentro para fora (da equipe para o Gerente). Uma mensagem bem forte também que é passada durante todo o trabalho, é que as Metodologias Ágeis devem sempre ser adaptadas a sua realidade, então, não espere mágica!

Parabéns e sucesso ao pessoal da SEA!