Além do .NET

quinta-feira, julho 23, 2009

Eu na SEA!!

O Post que eu fiz sobre o curso XP na Prática era, inicialmente, um depoimento/feedback que eu postei na lista AgilDF.

O pessoal da SEA gostou e resolveu postar o meu depoimento no blog deles. E eu gostei disso! Eu na SEA!

segunda-feira, julho 20, 2009

Curso XP na Prática

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 este post. 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!

Marcadores: ,

quinta-feira, julho 16, 2009

Corrige aqui pra mim, é rapidinho…

Ultimamente tenho escutado muito essa frase de algumas pessoas diferentes, e o que essas pessoas tem em comum? Todas são Gerentes.

Quando eu escuto uma frase dessas, a primeira coisa que eu pergunto, depois do frio na espinha, é: Quem disse que é rapidinho? A resposta que eu quero tirar dessa pergunta é: “se o Gerente acha que é rapidinho” ou, ”se algum Desenvolvedor (que depois eu procuro saber quem) afirmou que tal correção é rapidinha de ser feita”.

Normalmente é o Gerente que acredita que tal correção é rápida. Porém, em 98% dos casos o Gerente não programa mais (e eu conheço alguns dos 2% que ainda programam, e seus projetos são infinitamente melhor gerenciados), e com isso, não se preocupa mais com questões do tipo: o código está sendo bem feito, o Código está bem organizado ou no mínimo padronizado. Nem preciso falar que a cobertura de testes unitários no projeto desses mesmos Gerentes é nula.

Então, sem ter testes unitários, sem ter um padrão de codificação, sem um código limpo e coeso… como ele pode afirmar que é rapidinho???

Sem essas qualidades, qualquer correção a ser feita poderá gerar erros jamais imaginados!! Isso vem acontecendo muito nas minhas últimas manutenções… O grande problema é que algo que deveria ser simples acaba tornando-se uma jornada sem fim de refatoração extremamente arriscada, pra não dizer suicida.

Acredito que enquanto Analistas de Requisitos ou Analistas Não Programadores forem mais valorizados (maior salário) do que Desenvolvedores e Programadores, as correções rapidinhas jamais serão rapidinhas de verdade.

Apelo: Gerentes do meu Brasil! Cuidem dos códigos dos seus Projetos, e cuidem ainda mais dos seus Desenvolvedores, porque vai depender sempre deles se as suas futuras correções serão ou não rapidinhas.

sexta-feira, julho 03, 2009

Desenvolvimento Ágil Funciona

Esse é o título da entrevista feita pela InfoExame com o Akita.

Pra quem não sabe, Akita é um cara muito influente no cenário do Desenvolvimento de Software Nacional. Na comunidade Ruby, ele é mundialmente conhecido e muito atuante.

Eu gostei muito da entrevista onde ele defende a adoção das Metodologias Ágeis. Achei que ele foi direto ao ponto desmistificando algumas questões que surgem principalmente de Gerentes, PMO´s e afins com relação às “limitações” das Práticas Ágeis.

Mas se tivesse que criticar algum ponto da entrevista seria o trecho onde ele diz o seguinte:

Aqui tem muitas empresas que desenvolvem para outras empresas, portanto têm pouca liberdade. Lá, elas desenvolvem produtos próprios e é aí que está a diferença.

Na minha opinião essas palavras podem servir como desculpas para os Gerentes não abraçarem a Agilidade, justificando que tais metodologias servem apenas para empresas que produzem produtos próprios e que em ambientes de licitações, terceirizações e “off-shore” seja impossível a adoção de tais metodologias. Algo que eu não considero uma verdade.

Mas eu quero destacar a resposta do Akita aos comentários/dúvidas deixadas pelos internautas, que pra mim, fechou com chave de ouro a entrevista, que pode ser lida aqui.

Espero que cada vez mais empresas e equipes acordem para as Metodologias e principalmente para as Práticas e Valores Ágeis!

Respostas do Akita aos Comentários:

Complementando as dúvidas: - não há nenhuma distinção em termos de projetos "grandes" ou "pequenos". Lembrando que projetos grandes simplesmente são um portfolio de projetos menores que podem ser feitos sequencialmente ou em paralelo por uma ou mais sub-equipes.

Cada uma delas seguindo normalmente me preceitos ágeis. É um mito que ágil só serve para projetos pequenos. - o problema de sistemas grandes que ficaram ruins de dar manutenção não é por falta de documentação e sim por falta de disciplina dos desenvolvedores.

Apenas Scrum não é suficiente, você precisa de técnicas de Extreme Programming e, claro, de desenvolvedores sênior. Uma equipe de desenvolvedores júniors sempre vai fazer sistemas ruins. Você precisa, no mínimo, de uma mistura igual de sêniors e júniors, pareando entre si.

Pair programming é importante, Test Driven Development é essencial, Integração Contínua é vital, etc.

O código precisa ser refatorado constantemente, os testes precisam rodar sempre.

Em se desenvolvendo da forma correta, o código mantém muita da sua flexibilidade em manutenção e inclusive na coesão do seu design sem que se precise fazer Big Design Up Front (BDUF), que é sempre ruim.

Detalhe: é sempre uma má idéia começar fazendo o diagrama de todas as centenas de tabelas que se "acha" que vai precisar. Design incremental, acompanhado de testes, com constante refatoração sempre funciona melhor, independente do tamanho do projeto.

Documentação por burocracia é totalmente desnecessário. Não quer dizer que "qualquer" documentação seja ruim. Veja qualquer projeto open source, no mínimo existe um README que dá uma visão geral do sistema. Em muitos casos só isso já é suficiente. Em outros casos temos Wikis que detalham um pouco mais alguns aspectos mais importantes do projeto.

Agora, documentação de tudo é irrelevante porque, por definição, toda documentação ficará obsoleta e dessincronizada com o código. Isso não é um "talvez", é um axioma.

A única "documentação" realmente efetiva é "Código Limpo", ou seja, código bem testado, bem refatorado.

O próximo programador deve conseguir ver o mínimo de documentação (o README), rodar os testes e saber começar a se inteirar com o código diretamente pelo código.

Manutenção sem testes é suicídio, e isso também é um axioma.