Categories
Agile

Agile indo para o buraco?

Acabei de voltar de férias, já comecei a recuperar o atraso do meu Google Reader e não demorei muito para me deparar com a polêmica do momento…

Sei que muitos já fizeram isso mas não poderia deixar de comentar sobre o post do James Shore sobre o declínio e queda das metodologias ágeis. Recomendo a leitura do post, ou no mínimo do resumo do InfoQ.

O ponto do James Shore é muito simples: as pessoas estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Agile é muito mais do que desenvolver iterativamente, fazer stand-up meetings e planejamentos ágeis. Não dá para ignorar todas as práticas de engenharia de software que realmente fazem com que a produção e mudanças em softwares sejam ágeis, sem contar todos os princípios e práticas que a princípio podem não fazer muito sentido – como por exemplo exigir que o cliente esteja presente – mas no final fazem uma diferença enorme.

Outra polêmica muito grande é sobre a “popularização” do Scrum e seu mal uso. Como disse o Uncle Bob em um excelente post, usar uma metodologia ágil pura e simplesmente não faz com que você faça algo bom automaticamente. É perfeitamente possível fazer desgraças de design usando XP e com toneladas de código gerado com TDD, por exemplo. Será que ainda não deu para perceber que o caminho não é se apegar a metodologias e nomes? Elas são simplesmente uma porta de entrada!

Acho que isso tudo aconteceu porque com o “surto” de adoção e procura das metodologias ágeis, do dia para a noite surgiram milhares de especialistas ágeis. Esses agilistas espertalhões surgiram com dezenas de teorias malucas, princípios absurdos e uma quantidade incontável de barbaridades. O mais triste é ver que essas barbaridades são tantas que podem ser encontradas facilmente em listas de discussões, cursos, revistas, blogs e por todos os lados!

Estão pipocando comentários indignados (e com razão) sobre a deturpação de Agile, como o Christiano Milfont que comentou sobre a combinação estranha de Agile e CMMI, do Fernando Meyer sobre as pessoas não terem o pé no chão em relação ao Scrum, do Rafael Mueller, Phillip Calçado, Ivan Sanchez, José Papo e muitos outros comentando sobre o post do James Shore… Parece que muitas pessoas na comunidade – asssim como eu – têm receio que realmente estejamos entrando numa era de declínio das metodologias ágeis causada pelo seu mal uso e péssimo entendimento.

É realmente triste ver as metodologias ágeis sendo estupradas, é vergonhoso ver pessoas falando abobrinhas gigantescas sobre Scrum sem terem a menor idéia de como funciona e é enojante ver mensagens nas listas de discussões de pessoas que conseguem quebrar todos os valores do manifesto ágil em menos de um parágrafo. O triste resultado disso é que já dá para perceber em algumas pessoas o início de uma rejeição à metodologias ágeis…

Seja XP, Scrum, Lean ou qualquer outra, as metodologias ágeis serão tão boas e darão resultados tão bons quanto as pessoas que as usam.

Cuidado com os falsos agilistas, eles estão por todos os lados!

Categories
Agile Scrum

Mais sobre Product Owners

Para os Product Owners de plantão, seguem alguns artigos interessantes:

Em primeiro, Roman Pichler escreveu um excelente artigo no InfoQ entitulado “Creating Product Owner Success” com vários insights sobre como ser um Product Owner de sucesso. Além disso ele também fala de alguns erros comuns cometidos nesse papel. Há uma lista de outros artigos sobre Scrum e P.O.s no site do Roman, vale a pena dar uma vasculhada.

O segundo artigo é do Rodrigo Yoshima entitulado “Product Owner: Um de$graçado ganancio$o”. O Rodrigo colocou um ponto interessante que eu também vejo acontecendo em alguns projetos: a falta de compromisso com o ROI. O Scrum é totalmente “ROI-oriented” e é absolutamente essencial que o P.O. entenda isso plenamente para o sucesso dos projetos.

E por último, o Danilo Bardusco escreveu sobre “Product Owner Técnicos”, argumentando porque o P.O. também deve ter bons conhecimentos técnicos e como isso é benéfico para que ele possa guiar bem o time e expressar melhor suas idéias.

Além disso, há uns meses escreví sobre esse mesmo assunto referenciando um artigo do Antonio Carlos Silveira sobre “O papel do Product Owner e priorização do Product Backlog”, que também vale a pena ler.

Categories
Engenharia de software Eventos

[JBoss World 2008] James Ward: Porting from web 1.0 to RIA

James Ward, evangelista da Adobe, fez uma apresentação muito legal sobre como criar Rich Internet Applitacions com Flex, usando back-ends robustos em Java com JBoss.

Essa apresentação teve muito a ver com o artigo que ele publicou no InfoQ sobre como portar aplicações HTML tradicionais para Flex, escrito em conjunto com Shashank Tiwari (mais detalhes no blog do James).

No início ele mostrou um demo sensacional de uma aplicação de seguros que eles migraram de “web 1.0” para Flex. Realmente o poder das interfaces ricas é impressionante. Outro demo interessante foi do eBay Desktop, que tem uma boa combinação de HTML e Flash (usando o Adobe AIR), resultando em uma interface muito bonita e funcional.

Ultimamente na Globo.com temos trabalhado muito com Flash, por causa do player do Globo Vídeos. Antes disso eu nunca tinha trabalhado com Flash e talvez por isso nunca tenha tido a oportunidade de sentir tão de perto seu potencial. Flash/Flex/AS3/AIR/etc abrem um novo mundo de possibilidades, dando o poder de criar interfaces com usabilidade e interatividade excelentes, e ainda com um forte apelo visual.

Ele apresentou o conceito de “SOARIA” (aliás, quando ele falou isso eu comecei a rir sozinho, parecia que ele estava falando “sorria”). O que ele chama de SOARIA significa SOA + RIA, ou seja, aplicações ricas (RIA) que interagem com o back-end através de serviços (SOA). IMHO, acho essa abordagem muito legal, porque evita aquela dependência cíclica que sempre acaba se formando entre o Flash e a aplicação.

No final, vimos um benchmark interessante, comparando vários modelos de carregamento de dados em aplicações RIA usando Flex, Laszlo e Javascript/Ajax, integradas com serviços SOAP, pure-XML, HTML e JSON. O benchmark analisa como cada um desses modelos impacta em performance, consumo de banda e consumo de memória na máquina cliente. Fiquei surpreso com os resultados… Por exemplo, a aplicação mostra que o Dojo tem uma performance surpreendentemente ruim quando comparado a aplicações Flex, que têm uma performance normalmente superior a todas as outras (atenção, se você for rodar os testes não se esqueça de desabilitar o Firebug antes!).

A Adobe realmente acertou com o Action Script 3, Flex, AIR e todos esses novos produtos que têm sido lançados. Tenho que tirar o chapéu.

Categories
Engenharia de software Eventos

[QCon 2007] Slides das apresentações

Os slides de grande parte das apresentações da QCon 2007 foram liberados no endereço http://qcon.infoq.com/sanfrancisco/schedule/. Segundo a organização do evento em breve todos os slides estarão disponíveis lá!

Veja também o wiki e as fotos do evento, que continuarão sendo atualizados ao longo desta semana.

Categories
Engenharia de software

QCon 2007, aí vou eu!

Estou arrumando minhas malas e partindo daqui a pouco para a QCon 2007!

No último mês eu tenho me preparado bastante pra esse evento e justamente por isso que não tenho postado com tanta frequência. Não é todo dia que se pode ter aulas de Domain-Drinven Design com o próprio Eric Evans, de XP com o próprio Kent Beck ou de Domain Specific Languages com Martin Fowler e Neal Ford, por isso aproveitei esses dias pra refrescar algumas coisas na cabeça para poder aproveitar tudo o máximo possível!

Nos dois primeiros dias eu pretendo justamente assistir os cursos de DDD do Evans e de DSLs do Fowler. Esses tutoriais duram um dia inteiro e são hands-on, aplicados num laboratório. Acho que vai ser muito legal!

Além deles vários outros apresentadores como Ted Neward, Cedric Beust, Jeff Sutherland, Obie Fernandez, Jay Fields e Rod Johnson farão uma semana inteira de apresentações sobre desenvolvimento ágil, arquitetura de software e tudo mais que alguém poderia querer para ter uma semana mais que divertida.

Vou tentar conseguir o máximo de material possível nas apresentações que eu for e ao longo da semana vou postando por aqui!

Categories
Notícias

Coordenando o RioJUG

Desde o início da semana sou o mais novo coordenador do RioJUG! Recebí um convite dos coordenadores atuais para ajudar na coordenação deste grupo, que é um dos maiores do Brasil. Com mais de 1000 usuários, o RioJUG é o grupo oficial de usuários de Java do Rio de Janeiro.

Vou trabalhar para levar novidades para a comunidade e vou me obrigar a fazer mais apresentações nas reuniões mensais! Já tenho alguns temas interessantes na cabeça. Em novembro pretendo apresentar algumas coisas que vou ver na Qcon. Vamos ver se vai dar tempo, senão fica para janeiro.

Uma coisa que também sinto falta é dos eventos. Ultimamente não teve um evento sequer que prestasse aqui no Rio de Janeiro. Vamos ver se conseguimos ressucitar o Rio Java Summit e criar mais oportunidades para trocarmos experiências! Quem sabe também não está na hora de rolar um coding dojo no Rio, a exemplo do que já tem feito o pessoal de Floripa?

Categories
REST SOAP Webservices

A guerra entre REST e WS-* acabou!

Acabo de ler um artigo no InfoQ entitulado The REST versus WS-* war is over!.

Só que pra ser bem sincero eu não concordo muito com este artigo. Para mim essa guerra nunca existiu.

Veja bem, é mais ou menos como tentar fazer uma guerra entre facas de pão e facas de peixe para tentar descobrir qual é a melhor. Oras, se você está comendo peixe, a melhor faca é a faca de peixe. Se você vai cortar um pão, a melhor faca é a de pão. Tá bom, essa analogia foi ridícula, mas é tão ridícula quanto uma comparação entre REST e WS-*/SOAP.

O que eu quero dizer é que, assim como funciona com as facas, o tipo de webservice que se usa varia em função do cenário de uso.

Nem todos os tipos de sistemas precisam da quantidade de recursos que WS-*/SOAP oferecem e isso torna-se um overhead desnecessário. Por exemplo, é muito mais fácil fazer mashups e sites com vários recursos Ajax utilizando webservices REST. Em compensação você pode precisar fazer orquestrações de webservices, operações transacionais, roteamento e outras coisas que REST não oferece mas que com WS-*/SOAP se faz com relativa facilidade.

Certamente há espaço para os dois no mercado, não vejo motivos para encararmos como uma guerra.

Categories
Controle de qualidade Engenharia de software TDD

Qual é o percentual ideal de cobertura de testes?

Ontem estava tendo uma discussão com um amigo aqui do trabalho sobre cobertura de testes.

A nossa discussão começou quando eu fui mostrar para ele um teste de aceitação em Selenium que eu fiz para uma parte do sistema de gerenciamento de conteúdo da empresa.

Ele estava argumentando que acha que os testes de aceitação com Selenium não são tão interessantes porque eles são muito frágeis – alterações na interface podem quebrar os testes. Realmente isso pode acontecer. Mas se acontecer é só reescrever o teste, oras! Antes dele quebrar ele será executado várias vezes e só nisso várias horas preciosas podem ser economizadas.

Repare o seguinte: você efetivamente testará as telas do sistema navegando nele, incluindo, editando e removendo itens. Se este trabalho pode ser automatizado, porque não fazê-lo? Não é melhor gastar o seu tempo para elaborar novas táticas de testes e novos testes de outras partes do sistema ao invés de ficar navegando em todas as páginas “manualmente”?

Discussões deste tipo me fazem lembrar do manifesto Testivus, que dentre outras coisas prega que: “An imperfect test today is better than a perfect test someday” (Um teste imperfeito hoje é melhor do que um teste perfeito algum dia). Mesmo que os seus testes não sejam os melhores do mundo e que vez ou outra precisem ser corrigidos, é melhor tê-los do que não ter teste nenhum. Com o tempo a cultura de testes fica impregnada na equipe e os testes vão ficando cada vez melhores e mais numerosos.

É claro que eu não concordo que os testes possam ser um monte de lixo que não testam nada. Eu só acho que não se pode ter uma abordagem dogmática em relação aos testes. Se a sua aplicação tem 50% de cobertura de testes eu não acho isso ruim. Aliás, é BEM mais do que a maioria que existe por aí. Mesmo assim você pode (deve) testar bem mais.

Concluindo, eu particularmente gosto muito de utilizar a abordagem de desenvolvimento guiado por testes (TDD). Com TDD você tem uma cobertura de testes significativa já que os testes vão sendo escritos na medida que a aplicação é escrita. Porém se isso não puder ser feito por algum motivo, não acho correto estipular um percentual mínimo ideal de cobertura de testes. Só acho que deve-se testar muito e quanto mais, melhor.

Coincidentemente saiu ontem uma matéria no InfoQ sobre este mesmo assunto que vale apena a leitura.

Categories
Comunidade Mercado

E dá-lhe ThoughtWorks!

Os caras da ThoughtWorks se empolgaram! Não tem nem duas semanas que lançaram o Mingle e acabo de ficar sabendo de mais um, o CruiseControl Enterprise.

Eu acho que eles vão ganhar bastante dinheiro com os dois. E espero que eles ganhem mesmo porque os dois são muito bons. Só espero que eles não parem de produzir as coisas livres legais que sempre produziram (XStream, XFire, PicoContainer, etc) para passar a vender tudo! Bom, pelo menos na enterevista que eles deram no InfoQ disseram que o produto pago irá contribuir com a comunidade também, o que é bem legal. Se continuar assim está bom.

Categories
AOP Java Refactoring

Refatorando para aspectos

Acabo de assistir no InfoQ uma apresentação do Ramnivas Laddad sobre refatoração de aplicações para AOP.

Assistindo a explicação dele dá para entender a linha de raciocício que ele segue e a quantidade de possibilidades que a programação orientada a aspectos traz. Realmente é um saco fazer repetidamente código para controlar permissões, erros, transações, concorrência e outros mais. Com AOP a quantidade de esforço para implementar este tipo de situação é reduzida consideravelmente e este artigo trata exatamente disso: reconhecer trechos de código que são candidatos a serem reescritos para se tornarem aspectos.

Porém eu acho que deve-se tomar muito cuidado ao sair refatorando a sua aplicação para aspectos. Imagina um sistema com centenas de classes que possuem dezenas de aspectos diferentes. A impressão que eu tenho é que se você tem aspectos demais o sistema pode ficar até mais difícil de programar. Isto porque se você tem código fora do método sendo executado “dentro” do método, a clareza em relação ao que ele faz fica reduzida. Multiplique isso por centenas de classes e métodos e você tem um monstro indomável.

Mesmo assim a abordagem dele é bem interessante pois quando utilizada corretamente estimula a produção de CÓDIGO com lógica de negócio ao invés de código que não tem nada a ver com o que o sistema realmente faz, tornando o desenvolvimento mais produtivo.