Desenvolvimento Ágil - Blog da Improve It: Tag teste

Documentação Ágil

Vinicius Manhães Teles — Fri, 01 Aug 2008 21:08:00 -0300

Documentação é assunto que as pessoas vivem me perguntando nas palestras sobre XP. Por exemplo, como fica a documentação em um projeto XP, ou em qualquer metodologia ágil?

O vídeo abaixo é uma tentativa de responder esta questão.

Documentação Ágil from Vinicius Teles on Vimeo.

Link direto para o vídeo.

PS: Amigos com iPhone, não fiquem bravos comigo. Eu sei que vocês preferem que o vídeo esteja no YouTube, para que possam ver no iPhone. Mas, dessa vez ainda não deu. Este vídeo ficou um pouco maior do que eu gostaria, de modo que ultrapassa o limite de upload do YouTube. Uma alternativa é usar o Google Video, que permite vídeos maiores, e você também consegue ver através do cliente YouTube do iPhone. Eu tentei fazer upload para o Google Vídeo, mas ainda não ficou legal. Então, vou continuar tentando obter um resultado satisfatório no Google Video, e assim que alcançar, eu coloco o link aqui no blog. Mas, para adiantar, já estou publicando o vídeo no Vimeo.

Improvecast 19: XP na Ancar

Vinicius Manhães Teles — Tue, 02 Oct 2007 01:23:00 -0300

Acaba de ser publicado o podcast mais divertido que já gravei: o Improvecast 19. Dessa vez entrevistei a equipe de desenvolvimento da Ancar (veja as fotos), que atua na gestão de shopping centers e é cliente dos serviços de mentoring da Improve It. A Ancar vem trabalhando com XP desde o início de 2005. Durante dois anos os esforços de desenvolvimento estiveram concentrados em Java e mais recentemente a equipe passou a utilizar também Ruby on Rails.

Dessa vez, além do podcast, você também pode ler o estudo de caso da Ancar e ver as inúmeras fotos da equipe da Ancar trabalhando com XP. São nada menos que doze álbuns de fotos da Ancar. Aproveite!

Esses foram os assuntos tratados no Improvecast 19:

Quem é a Ancar e o que ela faz?
Como vocês conheceram o XP?
Que tipo de problemas vocês tinham antes de adotar o XP e o que os levou a querer adotá-lo?
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 com o XP?
O que motivou vocês a adotarem o Java?
Que treinamentos vocês fizeram antes de iniciar o primeiro projeto XP e como eles foram conduzidos?
Depois do período inicial de mentoring e treinamento, vocês deram início ao primeiro projeto XP na Ancar, o Ancar2Go. O que é o Ancar2Go e que benefícios de negócio eram esperados dele?

Tela do Ancar2Go com a planta de um dos shoppings administrados pela Ancar.

Quantas pessoas havia na equipe do Ancar2Go?
Quem atuava como cliente desse projeto?
Qual o tamanho das iterações?
Que práticas do XP mais se destacaram nesse projeto?
Que tipo de transformações vocês notaram no relacionamento com o cliente a partir da adoção do XP?
O que mudou no entrosamento e motivação da equipe?
Um dos aspectos que mais me marcaram no desenvolvimento do Ancar2Go foi a troca de abordagem que ocorreu logo no início do projeto. Começamos pensando em desenvolver um sistema web. Entretanto, à medida que o projeto avançou umas duas semanas, começou a ficar claro que um sistema desktop seria mais adequado. Lembro-me até hoje de uma reunião de planejamento semanal na qual observei, pela expressão do do rosto do Rafal, que ele não estava à vontade com a maneira como o sistema estava sendo desenvolvido. Então, pedi a ele que expressasse sua opinião, o que ele fez muito bem, levando-nos ao caminho que se revelou corretíssimo: uma aplicação desktop. Vocês acreditam que a estrutura de trabalho do XP, com suas iterações curtas, foco em adaptar-se a mudanças, re-planejamento a cada início da iteração e envolvimento de todos no planejamento, contribuiu para identificarmos cedo que estávamos indo no caminho errado?
No início de 2006, após diversas tentativas de contratar desenvolvedores aqui no Rio, vocês decidiram tentar algo novo: importar profissionais do Paraná, recém-graduados, que estivessem dispostos a mudar-se para um apartamento próximo à Ancar, no Rio de Janeiro. Nesse processo, vocês adotaram a programação em par como forma de avaliar os candidatos. Vocês poderiam falar um pouco mais sobre o que foi feito nesse sentido?
Depois da contratação, como a programação em par contribuiu para o trabalho dos novos desenvolvedores?
Um aspecto muito forte aí na Ancar é a questão do desenvolvimento orientado a testes. No último projeto que vocês fizeram em Java, a taxa de cobertura dos testes era extremamente elevada, bem próxima de 100%. Agora, com dois anos de uso permanente do XP, qual a visão que vocês têm sobre a criação de testes automatizados ao longo do desenvolvimento? Eles realmente fazem a diferença e contribuem para elevar a qualidade dos produtos gerados?
Outro aspecto significativo aí na Ancar é o nível de automação dos builds. Explique um pouquinho como é conduzido o processo de integração contínua e qual é o papel do Bob Esponja nessa questão. :-)
O entrosamento da equipe sempre foi uma preocupação de todos nós aí na Ancar. Uma das tradições que criamos aí foi o almoço semanal com boliche. Vocês poderiam falar um pouco mais sobre ele?
Recentemente vocês se viram diante da necessidade de desenvolver o primeiro sistema web. Diante disso, foi preciso tomar uma decisão sobre a plataforma. Vocês estudaram várias soluções no mundo Java, mas acabaram optando por sair do Java e utilizar Ruby on Rails. O que os motivou a fazer essa migração?
Vocês podem falar um pouco sobre esse novo projeto?
Vocês acham que está valendo a pena trabalhar com o Rails?
O que vocês mais têm gostado a respeito do Rails?
Quais têm sido os maiores desafios e como eles vêm sendo tratados?
Recentemente vocês, em conjunto com o Tapajós, aqui da Improve It, desenvolveram um plugin para o Rails. O que ele faz?
Finalmente, quais são seus planos para o futuro em termos de desenvolvimento ágil e Ruby on Rails?

Além de escutar o podcast, veja as fotos. E lembre-se, quem quer aprender mais sobre desenvolvimento ágil deve ficar atento. Em breve lançaremos nossos primeiros treinamentos abertos ao público. Fique sabendo de todos os detalhes mais cedo e concorra a descontos. Basta cadastrar seu email para receber todos os detalhes. Cadastre-se.

Improvecast 18: conheça o Oi Paggo

Vinicius Manhães Teles — Mon, 24 Sep 2007 12:33:00 -0300

Acaba de ser publicado o Improvecast 18 que traz o surpreendente relato de um cliente dos serviços de mentoring da Improve It, a Paggo, que desenvolveu um sistema de cartão de crédito usando Extreme Programming do início ao fim. Entrevistei Mauricio Hermogenes, Diretor de Tecnologia da Paggo. Ele descreveu o Oi Paggo, um sofisticado sistema de "cartão" de crédito utilizando celulares desenvolvido em parceria com a operadora de telefonia Oi.

O Oi Paggo foi desenvolvido sobre a plataforma Java e XP foi usado como metodologia de desenvolvimento, o que, segundo a Paggo, permitiu que o sistema fosse implementado em tempo recorde. O Oi Paggo já está em uso em diversas cidades brasileiras e sua receptividade está superando as próprias expectativas da Paggo, como o Mauricio explica no podcast.

Fonte: http://www.oipaggo.com.br

O Oi Paggo talvez seja hoje um dos produtos mais amplamente utilizados desenvolvidos em XP no Brasil. Trata-se de um projeto inédito, tanto em termos do negócio (cartão de crédito via celular), quanto em termos da metodologia de desenvolvimento. Portanto, esse podcast, além de ser muito instrutivo, é também um ótimo case para demonstrar o potencial do Extreme Programming no mercado brasileiro.

Esses foram os assuntos tratados no Improvecast 18:

Quem é a Paggo e o que ela faz?
O que é uma solução de private label?
O que é o Oi Paggo?
Como funciona o Oi Paggo?
Quais as vantagens do Oi Paggo para os compradores?
Qual o custo do Oi Paggo para os compradores?
O que um comprador deve fazer para habilitar seu Oi Paggo?
Quais as vantagens do Oi Paggo para os lojistas?
Qual o custo do Oi Paggo para os lojistas?
O que um lojista deve fazer para habilitar seu Oi Paggo?
Quando a Paggo foi fundada e qual era seu objetivo?
Quando e como teve início o projeto do Oi Paggo?
Quando o Oi Paggo foi lançado como piloto?
Quando o Oi Paggo foi lançado em nível nacional?
Como está sendo a receptividade do mercado?
A Paggo utilizou Extreme Programming desde que começou a desenvolver sua plataforma de cartão de crédito, em 2004. O que motivou a opção pelo XP?
Como se deu a implantação do XP no início?
Que práticas foram utilizadas no início?
Quais foram mais fáceis de adotar?
Quais foram os principais benefícios observados neste primeiro momento?
Quais as principais dificuldades?
Em 2005 a Paggo deu início ao desenvolvimento do Oi Paggo e a Improve It foi chamada para ajudar a dar continuidade na implantação do XP, através de seu serviço de mentoring. Que novidades foram sugeridas e implantadas nesse momento?
Como foi conduzido o trabalho de mentoring?
Na opinião de vocês, qual a importância desse tipo de trabalho?
Quais foram os principais benefícios observados?
Que práticas foram mais fáceis de utilizar?
Quais foram mais difíceis?
Você poderia falar um pouco sobre a arquitetura tecnológica da Paggo?
Quantas pessoas havia na equipe de desenvolvimento no início do projeto Oi Paggo?
Quantas pessoas fazem parte dessa equipe atualmente?
Como vocês lidaram com o desafio de contratar pessoas capacitadas nessas tecnologias?
Como vocês conduziram o treinamento dos novos contratados?
Qual foi a importância da programação em par nessa questão?
Em 2005, enquanto eu estava fazendo mentoring com a Paggo, utilizavam-se iterações semanais para o desenvolvimento do Oi Paggo. Quem atuava como cliente nas reuniões de planejamento?
Como eram usados os cartões nessas reuniões?
Como os cartões eram estimados?
Como eles eram acompanhados ao longo da iteração?
Uma coisa interessante que aconteceu na Paggo é que os cartões saíram da área de desenvolvimento e foram adotados por outros departamentos. Você poderia falar um pouco mais sobre como os cartões passaram a ser usados em toda a empresa?
Na sua opinião, o que motivou tamanha aceitação e uso dos cartões?
No momento, qual o tamanho da iteração de vocês? Continua sendo semanal?
Em 2005, fazíamos retrospectivas ao final de cada iteração. Na opinião de vocês, que benefícios elas geravam?
As retrospectivas continuam sendo usadas atualmente?
Um dos desafios em se trabalhar com uma equipe grande é a reunião diária, o stand up meeting. Ela pode acabar se alongando demais caso a equipe seja grande. Como vocês têm lidado com essa questão?
Enquanto estive com vocês, um aspecto que trabalhamos muito foi a questão de automação de testes, utilizando fortemente mock objects e outros conceitos. Quais foram as principais inovações nessa área, comparando-se com a forma pela qual vocês começaram a adotar o XP em 2004?
Como a automação de testes vem sendo tratada atualmente?
Na opinião de vocês, qual a importância da automação dos testes e de práticas como desenvolvimento orientado a testes para a qualidade do produto final?
Vocês têm conseguido manter o design organizado através de sucessivas refatorações do código?
Qual tem sido a importância dos testes automatizados para viabilizar as refatorações?
Outro ponto que trabalhamos muito foi a questão da automação de builds e integração contínua. Quais foram as principais mudanças realizadas nessa área?
Como ela vem sendo tratada atualmente?
Como vocês têm lidado com o desafio de colocar mudanças no ar rapidamente, em um sistema que já está em plena utilização?
A Oi, como quase todas as grandes empresas brasileiras, baseia seu processo de desenvolvimento em métodos tradicionais de gestão de projetos, tais como aqueles disseminados pelo PMBOK. Como vocês vêm lidando com essa diferença cultural entre o modelo de desenvolvimento da Paggo, baseado no XP e o modelo de gestão da Oi, baseado no PMBOK?
O XP contribuiu de alguma forma para o bom relacionamento entre a Paggo e a Oi?
Na opinião de vocês, qual tem sido a importância da utilização do XP no que se refere à motivação da equipe de desenvolvimento e habilidade da Paggo em reter seus profissionais?
Que tipo de adaptações vocês tiveram que fazer no XP para que se adequasse às particularidades da Paggo?
Quais são os principais desafios que vocês estão vivenciando no momento, tanto no nível do negócio, quanto no técnico?
Como está sendo a receptividade do Oi Paggo no mercado e o que a Paggo está preparando para o futuro próximo?

Improvecast 17: Entrevista com Bruno Siqueira na Série Experiências Ágeis

Vinicius Manhães Teles — Wed, 22 Aug 2007 00:53:00 -0300

Há pouco mais de um mês eu e minha esposa fomos a uma festa onde encontramos com um velho amigo em comum, Bruno Siqueira. Embora o Bruno, minha esposa e eu tenhamos todos formação na área de TI, nós nos conhecemos em outro contexto completamente diferente: a dança de salão. Então, raramente conversamos com o Bruno sobre Informática. Porém, dessa vez acabamos falando um pouco sobre isso e fiquei sabendo que ele tinha saído, há pouco tempo, de uma empresa que implantou ISO, MPS.BR e CMMI. Hoje em dia ele trabalha com Scrum. Uma mudança significativa que, obviamente, merecia ser discutida em um novo Improvecast.

Clavius Tales, da Fortes Informática, falou, no último podcast, sobre a experiência de ter passado pelo MPS.BR e depois abandoná-lo em prol do XP. Dessa vez é o Bruno que conta como foi deixar para traz ISO, MPS.BR e CMMI. Atualmente, ele trabalha com Scrum no Tecgraf, Grupo de Tecnologia em Computação Gráfica, criado em 1987 em parceria com o Cenpes (Centro de Pesquisas da Petrobras).

Nessa entrevista, Bruno afirma que aprendeu bastante com os modelos de qualidade, mas depois de ter a oportunidade de trabalhar com Scrum, acredita que está obtendo resultados iguais ou superiores ao que tinha antes, porém com maior velocidade e muito menos esforço. Se depender dele, modelos de qualidade, tais como o que ele tinha que usar no passado, permanecerão sendo apenas parte do seu passado.

Esses foram alguns dos assuntos tratados no Improvecast 17:

Você trabalhou durante alguns anos em uma empresa que passou pela implantação da ISO, MPS.BR nível F e CMMI nível 3. Na sua opinião, o que motivou a empresa a buscar essas certificações?
Quando você foi trabalhar nessa empresa, qual era o tamanho da equipe de desenvolvimento?
Qual o perfil das pessoas?
Que tipo de projeto vocês estavam fazendo?
Que plataforma de desenvolvimento era utilizada?
Qual foi o primeiro modelo adotado?
Quanto tempo levou a adoção da ISO?
Qual era a participação dos desenvolvedores no que se referia à ISO?
O que é o TABA e para que você o utilizava?
Qual foi o modelo adotado a seguir?
Quanto tempo levou a adoção do MPS.BR?
Qual foi a participação dos desenvolvedores durante o processo de implantação do MPS.BR?
Em que o MPS.BR afetou a vida de vocês?
Em que o MPS.BR contribuiu para a melhoria da qualidade dos sistemas.
Como o MPS.BR afetava a motivação dos desenvolvedores?
Qual a sua visão sobre a avaliação do MPS.BR? O que você observou?
Depois do MPS.BR, veio o CMMI, certo?
Quanto tempo durou a implantação?
O que você identificou de diferente na implantação do CMMI, em relação ao MPS.BR?
Qual a sua visão sobre a avaliação do CMMI? O que você observou?
Quais os benefícios, para a empresa, que você identificou com a implantação desses modelos?
Quais os benefícios, para você, como desenvolvedor?
Como eram tratadas as mudanças nesses modelos?
O avaliador tem que ser um exímio desenvolvedor de software para se tornar um avaliador?
Modelos como o MPS.BR e o CMMI são complexos. Desenvolvimento de software, pela sua natureza, já é uma atividade bastante complexa. É correto tentar atacar essa complexidade intrínseca com mais complexidade?
Você enxerga alguma situação em que modelos de maturidade como esses sejam realmente válidos?
Recentemente, Marcos Pereira, desenvolvedor de software do Recife, nos concedeu um depoimento sobre a implantação do MPS.BR na empresa em que trabalha. Entre outras coisas, ele relatou:
- Dezoito meses gastos para obter o nível G.
- Pouca ou nenhuma participação dos desenvolvedores.
- Dezoito meses com grande preocupação com o processo, muito artefato para alimentar o processo, porém na visão dele, pouca contribuição para desenvolver software melhor.
- Outra coisa que ele observou é que quem define o processo não vive as conseqüências dele.
- Além disso, quem tem que seguir o processo, conhece pouco dele, portanto, sente dificuldades em propor melhorias.
- Ele também relatou que houve alta rotatividade dos desenvolvedores durante a implantação do MPS.BR. Ou seja, o MPS.BR, ao menos na empresa dele, não ajudou a reter pessoas.
- Dificuldade e lentidão para incorporar mudanças.
- Ele se queixou de que o processo não era voltado para tratar do aspecto humano do desenvolvimento. Segundo ele, o objetivo era sempre alimentar o processo, ao invés de alavancar o potencial das pessoas.
- Comitê formado por gerentes e pessoas da área de qualidade. Não havia desenvolvedores envolvidos. Pouquíssima participação dos desenvolvedores ao longo da definição do processo.
- Burocracia impele as pessoas a não mudarem de rumo. Então, como atingir qualidade? Na Toyota, por exemplo, qualidade é obtida através de melhoria contínua, ou seja, milhões de pequenas mudanças sendo feitas continuamente. Mas, que incentivos as pessoas têm para mudar em um ambiente considerado burocrático?
Você também teve essas percepções trabalhando com esses modelos de qualidade?
Por que você saiu da empresa que usava os modelos de qualidade?
Agora que você está no Tecgraf, trabalhando com Scrum, quais as principais diferenças?
Qual o tamanho das iterações?
Vocês têm feito as reuniões diárias?
Vocês têm um quadro com post its?
Então trata-se de uma equipe autogerenciável, certo?
Lá vocês estão trabalhando com desenvolvimento orientado a testes?
Como é o processo de integração contínua?
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?
O que mudou com a sua ida para o Tecgraf em termos de satisfação pessoal?
Qual a sua percepção sobre a qualidade do seu trabalho?
Você voltaria a trabalhar na empresa anterior?
Você acha que é necessário ter uma avaliação para se produzir software com qualidade?

Improvecast 16: Entrevista com Clavius Tales na Série Experiências Ágeis

Vinicius Manhães Teles — Fri, 10 Aug 2007 00:36:00 -0300

É 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.

Improvecast 15: Entrevista com Daniel Wildt na Série Experiências Ágeis

Vinicius Manhães Teles — Mon, 06 Aug 2007 22:43:00 -0300

Essa semana temos inúmeros podcasts para colocar no ar. E só tem coisa boa! :-) Começamos nesta segunda-feira com o podcast do Guilherme Silveira e agora, acaba de ser publicado o Improvecast 15 no qual entrevistei Daniel Wildt, desenvolvedor de software de Porto Alegre, que tem forte atuação nas comunidades de Delphi, Java e desenvolvimento ágil.

Esses foram alguns dos assuntos tratados no podcast:

Como foi seu primeiro contato com abordagens ágeis de desenvolvimento de software, tais como o Extreme Programming?
O que mais chamou sua atenção em relação ao XP?
Você usa XP em seu trabalho diário? De que forma?
Que tipo de problemas você tinha antes de adotar o XP e o que o levou a querer adota-lo?
Quais foram os principais benefícios que você identificou no XP, assim que começou a trabalhar com ele?
Que abordagem você utilizou para adotar o XP e quando começou a adoção?
Que práticas foram adotadas?
Qual foi mais fácil?
Qual foi mais difícil e por que?
Você trabalha com Delphi há bastante tempo. Uma das características mais notáveis do Delphi é a possibilidade de desenvolver rapidamente usando os componentes oferecidos pela plataforma. Entretanto, muitos desenvolvedores tendem a desenvolver de forma procedural, o que eventualmente afeta a capacidade de testar o código. Como você vem trabalhando essa questão da automação de testes no Delphi e que ferramentas você utiliza?
Como é o suporte à refatoração no Delphi atualmente?
Na sua atuação como professor universitário, você ensina abordagens ágeis de desenvolvimento?
Pelo que você tem observado, as universidades estão começando a ensinar metodologias ágeis, ou ainda estão baseadas apenas nos modelos tradicionais de desenvolvimento?
Qual a importância dos grupos de usuários na sua opinião?
Você foi, ou ainda é vinculado a diversos grupos de usuários, tais como o RSJUG, o DUG-RS e o XP-RS. Você poderia falar um pouco sobre cada um deles?
No final de 2004 o XP-RS promoveu um excelente evento chamado Extreme Day. O que foi esse evento e o que aconteceu nele?
Quando será o próximo Extreme Day?
Se vocês tivesse que justificar para alguém o uso do XP, o que você diria?
Você poderia falar um pouco sobre a nova coluna que vai escrever nas publicações da DevMedia, sobre desenvolvimento ágil?
Quais são seus planos para o futuro, na área de desenvolvimento ágil?

Entrevista com Alisson Vale na Série Experiências Ágeis

Vinicius Manhães Teles — Sun, 29 Jul 2007 19:11:00 -0300

Acaba de ser publicado o Improvecast 13 no qual entrevistei Alisson Vale, Diretor da Phidelis Tecnologia e Líder de Projeto do Phidelis Acadêmico. Alisson utiliza XP desde 2003 e liderou a construção de um sistema web bastante grande, completamente desenvolvido em XP. Essa é uma das entrevistas mais notáveis até o momento, na Série Experiências Ágeis, já que aborda a utilização de XP, com sucesso, durante os últimos quatro anos.

Esses foram alguns dos assuntos tratados no podcast:

O que é a Phidelis Tecnologia?
Em que áreas ela atua?
Como foi seu primeiro contato com o XP?
Qual foi sua impressão inicial sobre o XP?
Quais foram os principais benefícios que você identificou no XP, assim que começou a trabalhar com ele?
Que práticas você utilizou no seu primeiro projeto XP e quais ficaram de fora?
O que é o Phidelis Acadêmico?
Você poderia falar um pouco mais sobre as funcionalidades do Phidelis?
Você poderia falar um pouco sobre o ambiente de desenvolvimento?
Qual o tamanho da equipe?
Como as abordagens ágeis vêm sendo usadas no desenvolvimento do Phidelis?
Qual o tamanho das iterações durante o desenvolvimento do Phidelis?
Qual o tamanho das iterações atualmente?
Qual foi a prática mais fácil de adotar?
Qual foi a mais difícil e por que?
Como vocês fazem a estimativa das histórias?
Como vocês configuraram o ambiente visual e informativo de vocês?
Quais os gráficos que vocês utilizam para acompanhamento do projeto?
Por que vocês trabalham com dois stand up meetings?
Como utilizam a prática de desenvolvimento orientado a testes?
Como os eventuais bugs são tratados?
Como vocês têm utilizado a programação em par?
Como é feito o processo de integração contínua?
Como vocês utilizam retrospectivas durante o desenvolvimento?
Como vocês lidam com solicitações de diferentes clientes de um mesmo produto?
Como isso é tratado com esses clientes do ponto de vista contratual?
Qual o uso que vocês fazem do wiki no projeto?
E o blog interno, qual o propósito dele?
Como foi o processo de convencer seu cliente inicial e sua equipe a utilizarem o XP?
Quais foram as principais dificuldades que você enfrentou?
Como é o relacionamento dos membros da equipe, com o uso do XP?
Como é o relacionamento com os clientes?
No início do ano você fez o treinamento de Certified Scrum Master. A partir do treinamento, e do que você aprendeu sobre Scrum, quais os aspectos que você considera novos, em relação ao que você já vinha utilizando em XP?
Antes de fazer o curso você sabia o que realmente significava ser um Certified Scrum Master? A certificação correspondeu a suas expectativas?
Quais são seus planos para o futuro em relação ao Phidelis e às abordagens ágeis de desenvolvimento?

Esse podcast foi gravado no dia 12 de julho de 2007 e só está sendo publicado agora, mais de duas semanas depois. Houve várias razões para essa demora. A principal delas foi que estive extremamente atarefado nessas últimas semanas o que me impediu de trabalhar na edição. Para agravar o problema, a conexão da rede não estava muito boa no dia. Isso dificultou a conversa pelo Skype e causou problemas em vários pontos da gravação, tornando a edição muito mais lenta e trabalhosa. O resultado final ficou um pouco comprometido, mas acredito que está compreensível na maior parte. Peço a compreensão e a paciência de vocês para que façam um esforço de escutar até o fim. A experiência do Alisson é valiosa. Trata-se de uma verdadeira aula que merece ser escutada com atenção.

Errata

Marcos Tapajós — Tue, 22 May 2007 20:24:00 -0300

Estou escrevendo essa errata pois algumas pessoas utilizam RSS e podem não ler a correção que eu fiz no meu ultimo post.

Escrevi:

1 - Algo impossível (nunca consegui fazer) em java e simples em Ruby é testar métodos estáticos.

Mas o que eu realmente quis dizer foi:

1 - Algo impossível (nunca consegui fazer) em java e simples em Ruby é "mockar" métodos estáticos.

Ruby, Ágil ou RAD ?

Marcos Tapajós — Tue, 22 May 2007 18:20:00 -0300

Ontem recebi um e-mail do meu amigo Mestre, também conhecido como Rodrigo Lemos, me questionando sobre Ruby ser ágil ou RAD e então se iniciou um bate papo bem legal sobre essa linguagem e sobre o framework rails. Pensei em escrever um artigo sobre isso mas achei mais válido compartilhar com vocês apenas retirando o nome do lugar onde ele trabalha e de onde trabalhamos juntos.

E-mail original:

As pessoas costumam confundir muito os dois conceitos (Ágil X RAD). Aqui no meu trabalho tem um pessoal que AMA Delphi sobre todas as coisas. Daí eu resolvi dizer que preferia as plataformas "ágeis" e começaram a dizer que não havia nada mais "ágil" do que Delphi, que era muito mais "ágil" do que Java (em tempo: Java sozinho não é ágil; só o é em conjunto com outras tecnologias, tipo junit, cruisecontrol, mock objects, IDE com refactoring, entre outras ferramentas).

O exemplo típico que essa tribo dá pra dizer que isso Delphi é "ágil" é dizer que é possível montar uma aplicação com cadastro completo (Create, Read, Update, Delete), validação de dados e emissão de relatórios com meia-dúzia de cliques, em 5 minutos.

Só que esta é, na verdade, a descrição de RAD (Rapid Application Development é você conseguir montar uma aplicação em pouquíssimo tempo, com pouquíssima redundância de codificação; é algo típico de ferramentas visuais em que você arrasta meia dúzia de controle e preenche umas propriedadezinhas).

Daí expliquei que "desenvolvimento ágil" era algo muito maior, que era agilidade na hora de fazer uma modificação monstruosa num sistemão que já está no ar, funcionando há séculos. Acho que sempre funcionou muito bem no caso do nosso antigo trabalho: Java (biblioteca maravilhosa) + Eclipse (refactoring) + jUnit/dbUnit/easyMock/cruisecontrol (bateria de testes automatizados) + ant (automação) + CVS/Subversion (controle de alterações). Sempre fizemos modificações estruturais importantíssimas, que simplesmente não dá pra fazer nessas aplicaçõezinhas RAD geradas literalmente PELO Delphi. Essas tralhas RAD, uma vez que tenha sido feito, é quase impossível modificar porque fica tudo quebrado. No máximo fazem modificações de labels, fórmulas de validação simples etc.

No final se convenceram que Delphi não é "ágil" (pode ser como uma palavra genérica da língua portuguesa, que quer dizer algo como "rápido"... mas definitivamente não no conceito de desenvolvimento de software).

Também aqui no meu trabalho usa-se muito desenvolvimento de sistemas sobre Lotus Notes. Que é muito ruim. As ferramentas de edição são uma porcaria (muito mais porcaria que o Delphi). O modelo de dados é horrível e ultrapassado. Mas o pior de tudo, pior de tudo mesmo é que esta é RAD.

Ou seja, provavelmente um despreparado veio aqui no trabalho e mostrou pra não sei quem (um diretor, superintendente ou coisa que o valha) como era possível fazer "aplicações" no Notes em 10 minutos. Claro. É ridículo montar uma aplicação do zero no Notes. É realmente muito rápido: basta criar meia-dúzia de forms, colocar validação e uns botões de ação e pronto. Tá tudo pronto. Ele faz toda a renderização, armazenamento e recuperação, criação e remoção de registros, impressão de formulários, visões de resumo, envio de e-mail e um monte de outras coisas.

O problema que temos é: vai mudar tudo o que foi feito.... I-M-P-O-S-S-Í-V-E-L. Não tem como. É tudo amarrado demais e ao mesmo tempo mal-amarrado. Dá medo (muito medo) de mudar uma vírgula de lugar, porque ninguém sabe o que vai acontecer no resto do "sistema".

Aí, quando recebi seu e-mail, lembrei que esse tipo de apresentaçãozinha mostrando como montar uma aplicação em Ruby (ferroviário ou não) em 5 minutinhos era a forma mais comum de mostrar seus pontos fortes. Como não conheço nada de Ruby, fiquei pensando se não era só mais um hype, como foi o Notes, e como ainda é o Delphi (na minha humilde opinião). Por isso te perguntei.

E volto a perguntar: e aí, Ruby é RAD ou Ágil? A plataforma Ruby suporta os processos de desenvolvimento ágil (teste, refactoring etc.)? É fácil fazer uma mudança estrutural (ou seja, uma mudança gigante) e garantir que tudo continua funcionando? Ou depende só do talento/experiência do programador (como era há 30 anos atrás no mainframe)?

Minha resposta:

Muito boa sua explicação e melhor ainda o seu questionamento. Acho que o Ruby é tanto RAD quanto Ágil!

O Ruby, assim como o java, possui uma ótima ferramenta de testes que trás todas as vantagens que a gente já sabe.

Quando se fala de rails as coisas melhoram ainda mais, pois não só existe a parte de testes como ele já tem na sua estrutura tudo organizadinho para os testes, com separação de testes unitários, funcionais e de aceitação.

Existe ainda o conceito de fixtures que nada mais é do que aqueles cenários de testes que a gente escrevia em XML no nosso antigo trabalho só que com o formato YAML. Sem contar que com o uso de um plugin você passa a ter testes no selenium com a possibilidade de escrevê-los em Ruby usando recursos não disponíveis quando se escreve em html.

Existe o mocha, que é o equivalente ao Easy Mock, para auxiliar nos testes. Devido a característica dinâmica da linguagem podemos fazer algumas coisas em testes que em java ou não são possíveis ou são muito complexas. Para exemplificar:

1 - Algo impossível (nunca consegui fazer) em java e simples em Ruby é "mockar" métodos estáticos.

2 - É possível trocar a visibilidade dos métodos privados facilmente e assim testa-los. Em java é possível, mas muito chato pois envolve reflexão. Para finalizar em Ruby existe o cruisecontrol.rb que é exatamente a mesma coisa que o de java só que com uma interface web mais bonitinha.

Bem, acho que na parte de testes podemos dizer que é Ágil, de acordo ?

Agora com relação a ferramenta de refactoring realmente o Ruby ainda deixa a desejar pois não faz as coisas de forma tão automatizada quanto o java. Por exemplo, não existe como extrair um trecho de código para um método de forma automática.

Isso é chato? SIM, muito! Porém não é o fim do mundo pois temos o suporte dos testes e como escrevemos MUITO menos código isso acaba ficando mais simples de se fazer.

Então nesse aspecto Ruby não é tão ágil assim mas também não deixa de ser por isso! Certo?

Na parte de automação existe o RAKE que é um similar ao ANT só que novamente o XML é deixado de lado e escrevemos nossas tasks em Ruby mesmo. Acho que nessa parte podemos dizer que é Ágil.

A parte de controle de versão nem precisamos discutir.

Expliquei o porquê considero Ruby ágil, agora tenho que explicar porque ele também seria RAD.

Creio que o Ruby sozinho não seria RAD mas o framework Ruby On Rails definitivamente é. Realmente aquelas apresentações que escrevem aplicações em 10,20 ou 25 minutos deveriam ser encaradas como uma motivação e não para mostrar tudo da linguagem nem do framework pois em quase todas esses aspectos que você questionou são deixados de lado.

É perfeitamente possível se escrever aplicações de forma rápida e bem estruturada com testes, integração continua automatizada e muito mais.

É provável que você não entenda como isso é possível por não conhecer muito a fundo o Ruby e o rails mas vou te explicar umas coisinhas para você ficar mais dentro do contexto.

Um dos principais fatores que permite esse desenvolvimento rápido é o principio de Convention over Configuration onde poupamos muito tempo com configurações simplesmente por obedecer padrões bem simples, como localização de classes, nome de métodos, tabelas e assim por diante.

Além disso o Ruby possui algumas bibliotecas que facilitam muito o nosso trabalho e vou destacar duas que estão presentes no rails (na verdade elas vieram do rails).

1 - Active Record: Ele nos permite relacionar nossas classes de modelo com o nosso banco de dados. Seria algo semelhante ao EJB, HIBERNATE só não é necessário fazer nenhum mapeamento com XML, basta criar a classe com nome composto pelo singular do nome da tabela e herdar do Active Record. Mas isso não é tão engessado como pode parecer, podemos não usar plural e singular, assim como usar um nome de tabela diferente mudando-se duas linhas de código. Ele também permite o mapeamento de relacionamentos de forma bem simples.

Não é necessário mapear os campos com get and set pois ele utiliza o conceito de method_missing para descobrir diretamente no banco de dados os campos e gerar em tempo de execução. Só para você entender um pouco melhor vou te dar o exemplo de duas classes que estão relacionadas e de uma operação de Create.

class Estate < ActiveRecord::Base belongs_to :city validatespresenceof :city_state, :message => "Cidade inválida" end

class City < ActiveRecord::Base has_many :estate end

e = Estate.new e.name = "Blah" e.city = City.find_by_name("Rio de Janeiro") e.save

Com relação ao find usado é semelhante a historia do get and set, ele te disponibiliza em tempo de execução métodos findby_campo. Para resolver o problema do relacionamento basta que na tabela Estate exista a coluna cityid.

2 - Action Pack: Com ele temos uma junção do seu chamelleon com o LABASE, onde temos os conceitos de controller e actions e ao mesmo tempo podemos ter um, ou mais, layouts que dá a cara geral da aplicação e onde só escrevemos o trecho de tela que nos interessa. Ele nos oferece vários helpers para facilitar a construção das nossas views que são chamadas de rhtml e são similares ao JSP e as telas de PHP.

Acho que vale destacar também que em Ruby existe o RJS, onde escrevemos código em Ruby e eles são transformados em javascript tornando mais fácil fazer determinadas coisas em AJAX. Falando em AJAX ele já tem todo o suporte ao scriptaculos, tornando trivial gerar uma tela usando AJAX.

Mestre, eu achei realmente válido esse seu questionamento e espero ter explicado um pouquinho de várias coisas e que você entenda que não é apenas hype, a coisa é realmente boa!

Várias pessoas criticam e defendem outra linguagem sem conhecer e você foi bem coerente em questionar sobre alguma coisa que você não conhece tão a fundo.

Resposta dele:

Ah bom. Legal que as coisas sejam assim. É que eu fico muito, muito preocupado mesmo com o hype que se cria em torno de uma nova tecnologia. E fico com a pulga atrás da orelha sempre que vejo essas apresentações RAD, que pra mim parecem uma enganação (não que o fato de ser RAD em si seja ruim; acontece que estamos fartos de sistemas que começam RAD e viram uma dor-de-cabeça, uma âncora que arrasta uma instituição). Eu gostaria até de sugerir, mais pra vocês do que pra mim (que dificilmente vou usar Ruby algum dia por aqui), que façam apresentações mostrando o lado ágil da plataforma; que comecem com um sistema pronto, que seja grande, e façam alterações PROFUNDAS no mesmo, pra mostrar que aquilo não vai virar um peso com o tempo. Da minha parte (ok, sou uma minoria aqui), eu olharia com bons olhos uma tecnologia que começasse a ser apresentada desta forma, e não da forma RAD.

É uma pena não ter ainda a parte de refactoring bem resolvida. Na verdade, Java também não tem refactoring, quem tem é o Eclipse, o IDEA (será que o JBuilder já tem alguma coisa) etc. O povo do Eclipse não está fazendo nada pra Ruby não?

Quanto ao "Convention over Configuration", já tinha notado que algumas tecnologias caminhavam nesta direção (por exemplo, o XDoclet, que "infere" coisas a partir da cara da classe, mesmo que não estejam explicitamente configuradas como tags). Acho que podiam avançar ainda mais.

Sobre o ActiveRecord, muito legal que uma camada de persistência possa ser construída de forma tão simples. É realmente algo de que qualquer linguagem carece... e o pior é que persistência nem é um problema novo nem raro... TODOS os sistema de informações (e HÁ DÉCADAS) PRECISAM persistir informações. Meu sonho era que isso fosse ainda mais um passo adiante: que só o fato de existir uma tabela no banco de dados já criasse a classe on-the-fly (obviamente com a possibilidade de se programar algum comportamento específico de validação/verificação/aviso/notificação para alteração/criação/remoção de registros) sei lá de que forma, seja por uma máquina virtual pirada, ClassLoader malandreado ou sei lá o quê.

Mas, ainda sobre o ActiveRecord, me chama atenção a necessidade de herdar de uma classe. Espero que Ruby tenha herança múltipla (uma grande falha do Java); porque se só for permitida a herança simples, então o conceito de "super-classe" é um artigo de luxo (já que cada classe pode possuir apenas uma super-classe) e não deveria ser desperdiçado na implementação de um aspecto puramente tecnológico (ao invés disso, esse artigo de luxo deve ser gasto para fins mais nobres, como a implementação da verdadeira hierarquia objetos do mundo real no modelo de dados da aplicação). Obviamente essas considerações morrem se for permitida herança múltipla.

Valeu pelos esclarecimentos.

Mais uma resposta minha:

Mestre, em Ruby existe um conceito de mixin que permite que você faça a herança múltipla. Então esse problema estaria resolvido. Vou bolar um exemplinho e te mando em breve. Me cobra !

Com relação ao seu sonho de on-the-fly ele existe em Ruby! Existe um plugin chamado Magic Model que permite isso.

Análise de cobertura de testes com Rcov

Marcos Tapajós — Mon, 14 May 2007 18:51:00 -0300

Colocamos no ar um novo artigo que explica como usar o Rcov para analisar a cobertura de testes automatizados.

O artigo tem o formato de um tutorial e explica como usar o Rcov passo-a-passo, através de exemplos práticos. Confira!

Time que está ganhando não se mexe ?

Marcos Tapajós — Mon, 09 Apr 2007 22:11:00 -0300

ERRADO ! Desde pequeno escuto essa frase e acho que nunca tinha parado para pensar muito nisso mas hoje algumas coisas me chamaram atenção. Na verdade acho que tudo começou na semana passada mas como só hoje tive um pouco mais de tempo comecei a organizar minhas ideias.

Como fiquei preso fora da minha garagem e tive que ir trabalhar de metro resolvi ocupar meu tempo na leitura do livro Transformando suor em ouro do Bernardinho que é um livro muito bom pois é muito mais do que uma biografia, é uma lição de vida. São inúmeras as lições que ele escreve nesse livro e sabiamente ele diz que em time que tá ganhando se mexe sim, para continuar ganhando.

Semana passada, em um dos projetos da empresa vimos claramente a importância de mexer em um time que estava ganhando. Após "perder" um tempo numa refatoração possibilitamos que nosso código ficasse tão claro que em poucos minutos tínhamos duas novas funcionalidades com pouquíssimo custo.

É muito fácil entender esse paradigma se você olhar para alguma empresas que eram modelos de sucesso e hoje ou estão falidas ou estão em sérias dificuldades financeiras. Alguém poderia imaginar que empresas como a Mesbla, Estrela ou Mappin fossem falir ? Seria um pensamento do tipo “Já tenho uma marca conhecida, ninguém me pega mais” ?

No desenvolvimento de software constantemente vemos esse tipo de pensamento. É muito comum ninguém querer mexer no que está funcionando mesmo que esse trecho de código esteja completamente confuso ou mal implementado pois afinal de contas ninguém quer ser responsável por quebrar algo que estava funcionando.

Com certeza esse é um pensamento errado, porém compreensivo se você analisar o contexto onde a maioria dos desenvolvedores trabalham. Frequentemente eles estão subordinados a prazos impossíveis onde "perder" tempo numa refatoração é algo inaceitável e com isso esses códigos vão se acumulando tornando qualquer mudança muito arriscada.

Em desenvolvimento de software devemos encarar a refatoração como cuidar da nossa casa. Quando deixamos de cuidar de nossa casa rapidamente teremos uma zona completa. Para evitar que isso ocorra, frequentemente perdemos tempo com pequenas arrumações que tornam nossa vida mais fácil naquele ambiente e nos permite que utilizemos a nossa casa para o que desejarmos sem muitas preocupações.

É necessário ter muita coragem para se mexer em "time que está ganhando" porém em software isso é muito fácil se você fizer as coisas da forma correta. É muito tranquilo fazer modificações no seu código se você tiver uma rede de proteção em testes que garanta que tudo que você está modificando ainda está funcionando da forma esperada.

Mais uma conferência.

Marcos Tapajós — Fri, 09 Mar 2007 18:11:00 -0300

Para complementar a lista de conferências interessantes que o Vinícius postou recentemente, vou adicionar uma sobre automação de testes promovida pelo Google. Será a 2nd Annual Google Test Automation Conference (GTAC) que irá acontecer em Nova York nos dias 23 e 24 de Agosto de 2007.

O assunto por si só já seria algo interessante mas a promessa de criar um ambiente bem dinâmico voltado para discussões dos participantes torna esse evento ainda mais atraente. Sem contar o fato de envolver o Google !

A conferência estará aberta para submissão de artigos até o dia 6 de abril, ou seja, ainda dá tempo que você escrever alguma coisa para representar o Brasil !

Realmente esse ano promete !

Code Kata

Vinicius Manhães Teles — Wed, 28 Feb 2007 19:39:00 -0300

Durante a viagem para o Paraná, aproveitei para escutar diversos podcasts que estavam há tempos no notebook. Um dos mais interessantes foi a entrevista que Dan Benjamin fez com Dave Thomas. Dave falou sobre como virou editor de livros "acidentalmente". Aliás, editor de alguns dos melhores livros de computação da atualidade. Além disso, falou sobre Ruby e Rails, naturalmente. Mas, o que mais me chamou a atenção foi o conceito de Code Kata.

O Ivan Sanchez toca uma bela iniciativa nesse sentido através do Coding Dojo Floripa. Eu já tinha uma noção do significado de Dojo e Kata através de seu site. Mas, ouvindo as explicações do Dave Thomas, a idéia ficou mais clara ainda e compreendi o quanto é poderosa.

Ele explica que seu filho luta Karatê, onde se aprende diversos tipos de Kata. O Kata é uma seqüência de movimentos que o lutar repete inúmeras vezes à medida que se exercita. São movimentos de ataque e defesa que o lutar faz para "simular" uma luta real. Provavelmente nenhuma luta irá se assemelhar ao Kata, mas o objetivo não é esse.

A idéia é fazer com que os movimentos sejam "internalizados" pelo lutador. Ou seja, eles precisam sair do nível consciente para o subconsciente. Precisam "entrar no sangue" e se tornar tão naturais que o corpo passe a agir de forma reflexiva, sem que a mente consciente tenha que entrar em ação. De tanto repetir os movimentos, o corpo acaba aprendendo e o lutador passa a executá-los sem se dar conta do que está fazendo. É como passar marcha, acelerar e frear. São ações feitas de forma praticamente subconsciente quando estamos dirigindo.

O Code Kata é um exercício de programação que o desenvolvedor executa para treinar suas habilidades de desenvolvimento. A idéia é, de tempos em tempos, refazer o exercício, mas sempre se esforçando para criar uma solução diferente para o mesmo problema. Isso ajuda a explorar novos pontos de vistas e pesquisar abordagens alternativas.

Há também o formato de reuniões, onde um ou dois desenvolvedores trabalham na solução de um exercício de programação, com uma platéia assistindo e fazendo perguntas, como o que fizemos no XP Rio há alguns meses: o XP Rio on Rails.

Adorei esse conceito e hoje mesmo o utilizei durante o treinamento Imersão Ágil aqui em Fracisco Beltrão. O único detalhe é que misturei isso com programação em par e o resultado parece ter sido bem proveitoso, sobretudo para ajudar os alunos a fixar alguns dos conceitos mais importantes de TDD.

OBS: Figura retirada do Wikipedia.

O papel de "Quality Assurance" em projetos ágeis

Vinicius Manhães Teles — Thu, 11 Jan 2007 05:38:00 -0200

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.

Software saudável

Vinicius Manhães Teles — Sat, 06 Jan 2007 13:11:00 -0200

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.

Nada de janelas quebradas

Vinicius Manhães Teles — Fri, 05 Jan 2007 08:12:00 -0200

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. :-)

Análise de cobertura de testes com Emma

Vinicius Manhães Teles — Mon, 16 Oct 2006 01:57:00 -0300

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!

Testes de unidade com mock objects

Vinicius Manhães Teles — Sun, 15 Oct 2006 17:34:00 -0300

Colocamos no ar um novo artigo que explica como usar mock objects para ajudar a implementar testes de unidade automatizados. Trata-se de uma ferramenta essencial, sem a qual fica difícil atingir um nível elevado de cobertura de testes.

O artigo mostra exemplos baseados no EasyMock. Confira!