Publicado por Vinicius Manhães Teles há
mais de 3 anos.
É cada vez mais comum discutirmos sobre as diferenças e semelhanças entre abordagens ágeis de desenvolvimento de software e outras mais tradicionais, tais como o MPS.BR e o CMMI. Entretanto, poucas pessoas tiveram a chance de vivenciar os dois mundos para poder relatar o que aprenderam com cada abordagem.
Clavius Tales, Diretor de Desenvolvimento da Fortes Informática, é uma dessas poucas pessoas. Ele participou ativamente do processo de implantação do MPS.BR na Fortes Informática. Segundo ele, sua empresa colheu ótimos frutos da utilização dos conceitos trazidos pelo MPS.BR. Entretanto, depois que sua equipe adotou o Extreme Programming, os ganhos foram ainda maiores. Por conta disso, a empresa substituiu as práticas do MPS.BR pelas do Extreme Programming com excelentes resultados.
O relato do Tales acaba de ser publicado no Improvecast 16 que, devido ao tamanho, foi dividido em duas partes.
Esses foram alguns dos assuntos tratados no podcast:
- Quem é a Fortes Informática e o que ela faz?
- Que tipo de problemas vocês tinham antes de adotar o XP e o que o levou a querer adota-lo?
- Antes de adotar o XP, vocês participaram de um processo de avaliação para o MPS.BR nível G. O que motivou vocês a buscarem o MPS.BR?
- Como foi o processo de implantação do MPS.BR na Fortes?
- Quanto tempo foi necessário até se atingir o nível G?
- Quais os benefícios obtidos com o uso dos conceitos do MPS.BR?
- Qual o custo total da implantação e avaliação do MPS.BR?
- Apesar dos avanços conquistados com o MPS.BR, o que levou vocês a buscarem mais conhecimento sobre XP?
- Como você conheceu o XP?
- Que abordagem vocês utilizaram para adotar o XP e quando começou a adoção?
- Qual era a plataforma de desenvolvimento utilizada na época em que vocês começaram a adotar o XP?
- Que treinamentos vocês fizeram antes de iniciar o primeiro projeto XP e como eles foram conduzidos?
- Qual foi o primeiro projeto XP de vocês?
- Quantas pessoas havia na equipe?
- Quem atuava como cliente desse projeto?
- Qual o tamanho das iterações?
- Que práticas do XP mais se destacaram nesse projeto?
- Quais foram as mais fáceis de serem adotadas?
- Quais as mais difíceis?
- Que tipo de transformações você notou no relacionamento com o cliente a partir da adoção do XP?
- Que tipo de transformações você notou no entrosamento e motivação da equipe?
- Como a programação em par vem sendo usada?
- Como vocês estão trabalhando com desenvolvimento orientado a testes?
- Como tem sido o processo de integração contínua?
- Vocês têm utilizado retrospectivas? Elas têm se revelado benéficas para o projeto?
- Qual a sua avaliação sobre a qualidade do software produzido?
- Que tipo de adaptações vocês tiveram que fazer no processo?
- No Improvecast 8, Carlos Barbieri fala sobre os "ninjas". Você acha que XP só poderia funcionar se a equipe fosse repleta de "ninjas"?
- Na sua opinião, quais são as principais diferenças entre a filosofia por trás do MPS.BR e a das abordagens ágeis?
- Qual a sua visão da influência de "certificados" como o MPS.BR nas licitações públicas?
- Como você avalia a forma como o MPS.BR trata as questões humanas no desenvolvimento de software?
- Como XP trata essas questões?
- Como você compararia a forma como o MPS.BR lida com mudanças nos requisitos, em relação ao XP?
- Como vocês têm tratado essa questão no que se refere aos contratos de desenvolvimento de software?
Na implantação do Extreme Programming, a Fortes Informática contou com treinamento e apoio da Improve It. Veja algumas fotos do treinamento e o que nossos clientes acham dos treinamentos.
Finalmente, veja abaixo algumas fotos de uma reunião de planejamento realizada na Fortes Infomática há um mês.
Tags agile, cmmi, fotos, mps.br, par, podcast, qualidade, refactoring, retrospectiva, teste, treinamento, workshop, xp | 2 comentários
Publicado por Vinicius Manhães Teles há
mais de 3 anos.
Elisabeth Hendrickson, da Quality Tree Software, fez uma apresentação para o Google falando sobre sua longa experiência como analista de testes e como ela vê o papel das equipes de teste, ou "quality assurance", em projetos ágeis.
Veja o vídeo.
Tags qualidade, teste, vídeo | 2 comentários
Publicado por Vinicius Manhães Teles há
mais de 3 anos.
Ontem, após ler o artigo sobre janelas quebradas, o Rafael MVC, do grupo rails-br fez uma ótima pergunta: "100% de cobertura não é muito caro? Muitas vezes é desnecessário ter 100% de cobertura. O que você acha?"
Acredito que pode ser caro, ou barato, dependendo da forma como a questão é encarada e da tecnologia empregada. Na parte tecnológica, é mais fácil manter 100% de cobertura em Ruby que em Java, por exemplo. Seja como for, acho que o ponto fundamental é a forma como encaramos desenvolvimento de software.
Conheço algumas pessoas que estão sempre em forma. Não têm barriga, não têm problemas de saúde, e quase não se vê gordura pelo corpo. Ainda assim, elas fazem exercícios freqüentemente e comem pouco. Por que fazem isso, se não precisam? Porque se não mantiverem bons hábitos alimentares e se exercitarem freqüentemente, deixarão de ter um bom preparo físico e começarão a acumular gordura. Chamo isso de "paradoxo do atleta".
Em software acontece o mesmo, se você não exercitá-lo constantemente, através de uma bateria de testes automatizados, ele terá baixo condicionamento e não será tão saudável quanto o software "malhado" que está sempre sendo exercitado.
Qual o problema disso? Pense em uma pessoa obesa, como a da foto acima. Por ter baixo condicionamento, sua pressão sobe e seu batimento cardíaco se acelera quando passa por qualquer tipo de estresse. Já um atleta, se comporta de forma diferente. Diante de um estresse, sua pressão e seus batimentos cardíacos quase não se alteram.
Software é um organismo que enfrente os mais diversos tipos de estresses permanentemente. Ele se manifesta na forma de mudanças. Quando uma mudança é introduzida em um sistema, seu "batimento cardíado" e sua "pressão" podem variar abruptamente, ou permanecer estáveis dependendo de seu condicionamento. Sistemas bem testados, com elevada cobertura de testes, são como atletas muito bem preparados. Mudanças podem ocorrer, mas raramente irão comprometer o bom funcionamento e a boa saúde do software.
Trabalhando com TDD há alguns anos, comecei a notar o que chamaria de "paradoxo dos testes". Os testes automatizados que crio raramente detectam bugs! Não porque eles sejam ruins, ou pouco abrangentes. Simplesmente é raro introduzir um bug quando se trabalha com TDD. A forma de pensar se altera e leva você a criar código sem erros a maior parte do tempo.
O exercício de criar os testes é o que leva à baixa incidência de bugs. Então, se os testes raramente detectam erros, eu poderia deixar de produzi-los, certo? Aí é que está o paradoxo. Se eu não os escrever, começarei a introduzir mais bugs, porque o segredo está no exercício. É a mesma coisa com o corpo humano. Uma pessoa que esteja em forma aparentemente não precisaria se exercitar. Mas, se ela parar de se exercitar, começará a precisar!
Outra questão crítica na saúde de um software é a forma como ele é alimentado.
Você é o que você come. Portanto, se você só come porcaria, sua saúde tende a ser precária. Por outro lado, se você mantém uma dieta saudável, seu corpo tende a se manter em forma. Com nossos sistemas é a mesma coisa. Alimentá-los com gambiarras, código duplicado, métodos ilegíveis e outras coisas pavorosas é o que leva, gradualmente, à criação de um aplicativo moribundo, incapaz de ser alterado facilmente e propenso aos mais diversos tipos de defeitos. Portanto, alimente seu sistema com código saudável e bem testado.
Para fechar, relembrando um outro artigo fique atendo ao que acontece gradualmente com seu código, pois mudanças graduais são mais difíceis de serem notadas. Quando engordamos, fazemos isso um pouquinho a cada dia. Cada pequena extravagância diária leva o ponteiro da balança para o alto. Algumas gramas diárias à mais, se tornam muitos quilos depois de algumas semanas, ou alguns meses. Com o código é igual. Não é uma gambiarra que irá matá-lo. É a sucessão de pequenas gambiarras que vamos introduzindo a cada dia que condena nosso software ao caos e nos condena a dias estressantes tentando contê-lo.
Tags agile, java, qualidade, ruby, teste | nenhum comentário
Publicado por Vinicius Manhães Teles há
mais de 3 anos.
Diz a lenda que, há alguns anos, fizeram o seguinte experimento em Nova York. Estacionaram um carro em um bairro perigoso e o deixaram lá durante uma semana. Após esse período, ele ainda estava lá, inteiro. Então, os pesquisadores jogaram uma pedra no vidro do carro e foram embora. Não precisaram nem esperar uma semana. No dia seguinte o carro já estava completamente depenado e destruído. Uma única janela quebrada foi suficiente para iniciar o processo de vandalismo.
David Thomas e Andrew Hunt tratam desse assunto no livro The Pragmatic Programmer. Eles mostram como a cidade de Nova York usou a Teoria das Janelas Quebradas para reduzir a violência e como nós, desenvolvedores, podemos usá-la para evitar que o design de nossas aplicações se degradem. Resumidamente, a idéia é que um código permanentemente bem escrito, tenderá a ser mantido assim, pois as pessoas ficam "sem graça" de estragá-lo. Por outro lado, um código que já tem várias gambiarras é um convite para outras novas.
Há algum tempo tive a idéia de usar a análise de cobertura dos testes como uma forma de contribuir para achar as janelas quebradas e consertá-las rapidamente. Embora a cobertura não diga se os seus testes estão bons ou não, ela ao menos indica se existem partes do código que não estão sendo exercitadas por testes. E isso é bastante útil.
Trabalhando com XP, nós integramos o código freqüentemente, portanto, uma idéia seria rodar a análise de cobertura antes de cada commit no repositório. Assumindo que o projeto tenha 100% de cobertura, o desenvolvedor que der o commit roda a análise e, se o software continuar em 100% de cobertura, o commit é feito. Senão, ele deve implementar os testes que estão faltando. Usado consistentemente, isso pode ajudar a criar uma pressão positiva na equipe, no sentido de nunca comitar código sem teste.
Existem dois problemas com essa abordagem. O primeiro é atingir 100% de cobertura. Isso tipicamente é mais viável se o projeto já utilizar TDD desde o início. É bem mais complicado para projetos que já começaram sem testes. O segundo problema é que o desenvolvedor pode simplesmente deixar de rodar a análise de cobertura antes de fazer o commit.
Resolvemos esses problemas no desenvolvimento de nosso produto de duas formas. Primeiro, o projeto tem ênfaze em automação de testes desde o início. Sendo assim, temos 100% de cobertura. Para que isso seja mantido, fiz uma melhoria no nosso script de integração.
Temos um script que é executado antes de cada commit. Ele executa todos os nossos testes, além de fazer outras checagens, e só faz o commit se tudo estiver ok. A partir de hoje ele tem um passo adicional: executa a análise de cobertura e só permite o commit se ela estiver em 100%. Agora vai ser difícil alguém deixar janelas quebradas pelo código, quer dizer, esses tipos de janelas quebradas, já que existem outras também que não são identificadas pela análise de cobertura.
Esse projeto utiliza Ruby on Rails, portanto, a ferramenta usada para a análise de cobertura é o rcov que gera telas como essa:
Essa imagem é do próprio site do rcov. A análise de cobertura do nosso produto não tem essas cores vermelhas, naturalmnete. :-)
Tags qualidade, teste | 6 comentários
Publicado por Vinicius Manhães Teles há
mais de 3 anos.
Colocamos no ar um novo artigo que explica como usar o Emma para analisar a cobertura de testes automatizados.
O artigo tem o formato de um tutorial e explica como usar o Emma passo-a-passo, através de exemplos práticos. Confira!
Tags qualidade, teste | 1 comentário
