Archive for the ‘testes’ Category

Minhas Propostas para a Agile Brazil 2010

Saturday, February 27th, 2010

Acabo de submeter algumas atividades para o Agile Brazil 2010, evento que se realizará em Junho em Porto Alegre. Pelo que entendi, as propostas serão avaliadas pelo comitê organizador do evento.

As propostas estão disponíveis no site e o público pode fazer comentários. Minhas submissões:

Líder Técnico - O Ex-Arquiteto virou Faz-Tudo!

Ele era o centro das atenções. Nenhuma classe era criada sem a sua aprovação. Nenhuma biblioteca era introduzida sem que ele homologasse. Nada entrava ou saía sem a sua verificação. Seus diagramas formavam o livro sagrado do sistema, se o sistema não reflete o diagrama então os desenvolvedores devem ser punidos, obviamente eles não entender seu Grande Plano para Tudo™.

E daí veio este tal de agile. Não apenas introduziu práticas de qualidade duvidosa (duas pessoas, um computador? Sério?) mas também quer eliminar seu papel de visionário. Como um time poderia funcionar sem a visão inpiradora? Como um mero desenvolvedor pode decidir o que é melhor para um projeto onde são investidos milhões?

Pior ainda, o que o líder faz agora que não existem mais diagramas para desenhar?

Arrumando a Casa Após a Festa: Saindo do Pseudo-Agile

Tudo parecia muito simples. Os cartões vão na parede, os times se auto-gerenciam, o tal do Product Owner escreve nos cartões, o time faz retrospectiva… Tantos casos de sucesso por aí, tantos sorrisos e tapinhas nas costas…

Por que está dando tão errado aqui? Por que está fazendo da minha vida um inferno? Por que meu time não está aumentou a produtividade? Por que meus produtos continuam sendo uma porcaria? Por que parece que ninguém sabe o que está acontecendo?

Este é o saco de dúvidas que tenho encontrado por aí.

A maioria vai achar que basta seguirmos os 12 passos do programa e, eventualmente, as coisas vão entrar nos eixos. A maioria acha que basta demitir os gerentes de projeto e colocar coisas coloridas na parede. A maioria acha que basta escrever testes e seu código vai ter qualidade. A maioria acha que basta quebrar casos de uso em histórias e você terá melhor comunicação.

A maioria vai falhar miseravelmente.

Nos últimos anos tenho gasto uma boa parte do meu tempo tentando fazer clientes entender que não importa a cor do cartão na parede, não importa a sua plataforma de desenvolvimento, não importa se você usa cruise ou hudson, não importa se retrospectivas são quinzenais ou mensais… a única coisa que importa nesses tais métodos ágeis é termos ciclos de feedback curto.

Nesta sessão vamos conversar sobre alguns cenários, todos baseados em projetos reais, e no que pode ser feito para tirar o pseudo do seu agile.

E, além das duas palestras, o Rodrigo Yoshima me convidou para ajudá-lo no seu workshop de modelagem:

Reconheça! Você não sabe modelar! Iniciando Projetos Ágeis

Neste workshop prático vamos simular o planejamento inicial de um projeto ágil utilizando as mais variadas técnicas de modelagem como Domain-Driven Design, CRC Cards, User Stories, Paper Prototyping e Brainstorming.

Ajude o cliente a compreender melhor o problema, melhorando seu planejamento e auxiliando as suas estimativas. Um bom modelo ou protótipo serve como uma simplificação de algo complexo, uma abstração útil para o desenvolvimento do projeto. Em projetos ágeis a modelagem está presente, porém, ao invés de uma modelagem solitária numa ferramenta UML, equipes ágeis inovam em colaboração, usando artefatos simples numa dinâmica divertida.

Posted in brasil, comunidade, engenharia, eventos, fragmental, gerencia, metodologias, palestras, testes | 3 Comments »

Preparações e Desculpas Esfarrapadas

Monday, October 26th, 2009

Para variar, a desculpa para não ter escrito mais frequentemente é a preparação requerida para a viagem ao Brasil. Eu sei que é uma desculpa esfarrapada mas infelizmente esta etapa envolve mais do que fechar malas e comprar canguru de pelúcia para as sobrinhas, meus últimos dois projetos requereram muita atenção e neste exato momento eu estou finalizando os últimos detalhes de um deles.

Isso fez com que meus planos se alterassem um pouco. Infelizmente não vou ter tanto tempo quanto gostaria para encontrar pessoas, especialmente fora do Rio. Ainda vou em alguns lugares mas nada perto do que tinha em mente antes.

Sobre o evento, acho difícil haver alguém que ainda não tenha esbarrado com um dos banners ou coisa parecida sobre o Caelum Day. A programação está bem interessante e promete ser um dia útil e divertido.

Minha apresentação vai focar no que eu mais tenho feito nestes últimos dois anos: fazer com que times de desenvolvimento saiam do marasmo e comecem a entregar. Não me venha com essa história de “minha metodologia não deixa”, “meu chefe é mau”, etc., todo lugar tem problemas e as coisas dependem de você. A apresentação possui dicas e fundamentos técnicos mas sem vontade nada vai pra frente.

E para, refletir de maneira bem realista o clima da indústria de desenvolvimento de software, este ano eu escolhi mais uma vez filmes de terror para servir de pano de fundo (e comic relief). Ao contrário do ano passado, entretanto, eu escolhi um filme em específico. O primeiro comentário quem acertar o filme baseado na capa da apresentação abaixo ganha… algo… que eu ainda vou decidir:

caelum rio day

As inscrições ainda estão abertas aqui.

Para o workshop de Domain-Driven Design não há mais vagas –mas existe uma lista de espera.

Algumas pessoas ficaram curiosas porque escrevi no meu blog em inglês que acho o assunto (DDD) tedioso. Existe uma enorme demanda de cursos sobre o tema e o Paulo Silveira e eu decimnos que valia a pena realizar mais uma rodada dos cursos. Eu continuo usando Domain-Driven Design em meus projetos e textos, mas o assunto já está meio batido e mastigado.

Na minha opinião, DDD deveria ser parte de um curso maior sobre design em geral, um workshop específico tem relevância quando o assunto é novidade mas perde o apelo quando a técnica começa a ser utilizada por mais gente. Tenho lido mais sobre outras coisas e, se tudo der certo, vamos ver se em 2010 eu consigo aposentar o workshop de DDD e partir para estas novas coisas.

Bom, por enquanto é isso. Nos vemos semana que vem.

Posted in brasil, comunidade, cursos, domain.driven.design, engenharia, eventos, fragmental, fragmental.tw, gerencia, metodologias, negocios, palestras, programando, rio, testes | 5 Comments »

Refletindo sobre Tendências

Friday, July 10th, 2009

Recentemente muita gente tem me procurado nos instant messengers da vida para perguntar sobre tendências. Existe uma idéia no Brasil de que quem está de for a “traz as novidades”. Isso podia ser verdade antes da Internet mas agora as coisas se espalham com tanta velocidade que em muitos aspectos o Brasil está muito na frente da Austrália.

Mas existe o outro lado que é o trabalho na ThoughtWorks. Os projetos que nós enfrentamos geralmente começam da mesma maneira que os que qualquer consultoria, de três letrinhas ou três pessoas, enfrenta. O diferencial que faz ser um lugar interessante para se trabalhar é o que acontece durante o projeto.

O que segue neste post é uma amarrado de impressões pessoais sobre os últimos doze meses, tanto sobre a Austrália quanto o que sei de outros escritórios. Se ele não for coeso ou fácil de ler eu peço desculpas mas encare como um braindump.

Os projetos para bancos e empresas do mercado financeiro em geral continuam bem parecidos. Em 2007 houve uma euforia em torno da bolha econômica e muitos projetos megalomaníacos –e, por conseqüência, extremamente interessantes do ponto de vista técnico- apareceram mas a crise os tirou do baralho nos tempos recentes. Os bancos estão gastando menos e buscando fazer mais dinheiro reutilizando a estrutura existente. A maioria dos projetos que eu tenho conhecimento dentro de bancos é para estender uma determinada oferta para novos clientes ou é para migrar de uma plataforma legada para algo menos dispendioso.

O interessante sobre o “legado dispendioso”, dentro e fora de bancos, é que muitas vezes ele se trata de coisinhas como WebSphere, Aqualogic, Biztalk, Tibco e produtos parecidos. Apos gastar rios de dinheiro implantando estes e não ver nenhum centavo de retorno real muitos dos grandes estão migrando para plataformas mais eficientes, quase sempre baseadas em software livre. Hoje em dia são comuns projetos de migração de Websphere para Jetty ou de BizTalk para serviços RESTful usando IIS, JSON e ASP.Net MVC, por exemplo.

Na parte de aplicações para Internet, onde geralmente eu me envolvo mais, as coisas também têm mudado bastante. Basicamente os projetos têm se dividido em startups e legado. As startups aparecem com um problema e algum montante de dinheiro. A plataforma mais utilizada para atender estes cenários é Ruby on Rails, geralmente fazendo deployment em algum serviço de Cloud Computing.

Cloud Computing é um tópico extremamente relevante tanto para ThoughtWorks quanto nos nossos clientes. Uma das coisas interessantes que fizemos no início do ano foi trabalhar junto com o Google no lançamento da AppEngine em Java (e outras linguagens).

As empresas com legado de Internet são sempre interessantes. Geralmente elas são algum grande prestador de serviço na área de mídia e possuem um ou mais websites antigos que têm aquela arquitetura manjada de rodar em um Weblogic ou Tomcat com um Apache de front-end. O problema é que hoje em dia o numero de usuários é muito superior e a velocidade com que funcionalidades têm que ser adicionadas e alteradas é muito maior. Após entender que os Googles e Facebooks da vida não usam Java EE e não pagam licença para a IBM as empresas estão desesperadas para atingir o mesmo nível de eficiência.

O que temos feito nesta área é utilizar a já citada Cloud Computing para realizar tarefas que não precisam ser executadas dentro do firewall (de crawling até rodar teste de carga), refatorar aplicações grandes para atingir escalabilidade horizontal e simplificar processos de deployment e gerenciamento de recursos.

Na área mais de programação em si as coisas não têm sido lá muito excitantes. As plataformas em específico não têm nenhuma novidade marcante mas a programação poliglota é uma realidade. Até hoje todos os projetos que tive alguma participação dentro da ThoughtWorks utilizavam mais de uma linguagem de programação (já descontando Bash e JavaScript).

Uma surpresa agradável foi a que tive no meu projeto atual, em que voltei a programar em .Net após 3 anos afastado. A maioria das coisas que eu realmente não gostava sobre C# e seu ecossistema foram removidos (exceto Windows e Visual Studio, duas peças que eu considero de qualidade inferior). A Microsoft continua enfiando frameworks e ferramentas terríveis pela guela dos seus clientes (MSBuild? TFS? WCF? WTF?!?) mas no geral as coisas estão bem melhores.

Em termos de livros sobre programação eu tenho me focado quase que exclusivamente nos conceitos presentes em linguagens e paradigmas de programação. Esta é a lista de livros relacionados que eu li desde que cheguei aqui:



Esta é a fila dos que faltam:


(fora os que ainda estão no meu carrinho de compras na Amazon. Livro na Austrália é ridiculamente caro)

Na parte de gerenciamento de projetos e metodologias as coisas estão engraçadas. Tem horas que a euforia anima, tem hora que dá náusea. Eu acho que o Bellware resumiu muito bem:

early agile adopters were looking for a way to do things better. later adopters are just trying to do agile, thus the failures

Eu vim para a ThoughtWorks para ver como é que quem introduz métodos ágeis há anos trabalha. Nos últimos meses eu trabalhei com pessoas que fazem isto há mais de dez anos e em empresas que adotaram agile antes de eu saber que ele existia. O que eu aprendi neste período inicial é exatamente o descrito acima: quando seu objetivo é ser ágil você falha, quando seu objetivo é sempre melhorar você tem chances de sucesso.

Todos os projetos que participei foram bem sucedidos? Depende de para quem você pergunta. Mesmo os clientes mais difíceis que tive acabaram ficando satisfeitos no final mas muitos projetos que participei (e o número de projetos é bem maior que o número de clientes) foram executados de uma maneira que o time não ficou satisfeito. Eu acho que neste caso é perspectiva. Como a maioria dos projetos são um fracasso colossal basta ter algum nível de sucesso que o projeto vira referência. O time, em compensação, tem um critério de sucesso muito mais alto e não considera o projeto como bem-sucedido.

É claro que no fim das contas o que vale mais é a opinião do cliente –tanto porque o problema dele foi solucionado bem como porque é ele quem paga a conta no final- mas eu já vi diversos problemas decorrentes deste tipo de coisa. De builds que começaram em 10 minutos e terminaram em duas horas de duração até um time que perde 50% do seu tempo corrigindo defeitos por falta de uma suíte de testes decente. Os problemas podem não ser grandes para aquele projeto em específico mas não prestar atenção há eles é mortal em médio prazo.

Minha conclusão é que a indústria está num estado melhor do que há alguns anos atrás. Tecnicamente estamos entrando em uma espécie de renascimento e isso promete render muito material para posts aqui. Em termos de gerencia de projetos e processos as pessoas estão finalmente se convencendo que tudo tem limite, até ineficiência.

Posted in .net, arquitetura, australia, bancos.de.dados, beyondjava, brasil, cbd, comunidade, domain.driven.design, domain.specific.languages, engenharia, foss, gerencia, guj, java, javascript, linux, lisp, livros, metodologias, microsoft, negocios, orientacao.a.objetos, php, plataformas, programacao.funcional, programando, rails, rest, ruby, sistemas.operacionais, soa, testes, thoughtworks, unix, você.pergunta, web, ws-*/soap | 9 Comments »

Gerencie como um pr0n star!

Friday, May 15th, 2009

Se você não entendeu a piada com o título clique aqui.

Então tivemos o Scrum Gathering Brazil esta semana. Infelizmente eu não estava por lá mas acompanhei bastante a movimentação via twitter e conversando com amigos nos instant messengers da vida. Agora estou lendo a cobertura dos blogs.

A que mais me chamou atenção –e eu já previa isso tendo conversado com o autor durante a evento- foi a do Rodrigo Yoshima. Entre diversos comentários sobre apresentações que deixaram pontos de interrogação e exclamação na cabeça do autor eu destaco:

Usando Scrum com o Visual Studio Team Systeam - Fabio Camara [...]
- Ele acha incrível como a Regra de Pareto se aplica a projetos de software: 20% dos desenvolvedores fazem 80% do trabalho.
- Ele se questiona se vale a pena o programador testar. Para ele, o programador só deve verificar e um testador, que é mais barato, testa efetivamente. Na mesma linha ele questiona TDD para projetos que ele denomina “time-driven”. Não achei referências para esse termo, mas ele classifica como os projetos onde tudo é para ontem. Nesses projetos não há tempo para pensar em testes unitários.
- A maior divergência porém, é o papel do ScrumMaster na visão do Fabio Camara. Para ele o ScrumMaster Monta o Plano, Distribui Atividades, Obtém Feedback e Refaz o Plano. Ele deixou claro na palestra que essa é a opinião dele. Quando questionei a respeito da auto-organização do Scrum ele disse que também não acredita na auto-organização.

E o grande sumario disso (desculpe o hotlink, Rodrigo!):

Este é o tipo de coisa sobre a qual eu falei aqui, aqui, aqui, aqui e, principalmente, aqui.

Quanto mais as metodologias ágeis ganham o mainstream mas nós vamos ver este tipo de coisa. O fato de que Scrum possui certificações e selinhos só piora tudo já que dá credibilidade imediata a uma informação errada no seu princípio básico.

Isso me lembrou alguns casos. Uma vez uma amiga foi para um cliente que havia implantado Scrum há pouco tempo. Todos fizeram o cursinho e tinham selinho de CSM. O diretor do programa tem o selinho melhor, CSP, e estava no caminho do seu CST, o selinho máximo.

Ela é uma analista de negócios e quando chegou foi levada imediatamente para uma sala com todos os stakeholders e desenvolvedores. Eles olharam seriamente para ela e disseram algo como:

- Precisamos muito da sua ajuda. Precisamos de aconselhamento em como deixar a informação visível. Agora com Scrum nós precisamos deixar claro o que está acontecendo aqui no desenvolvimento para todos.
- Uh. Ok, então acho que vocês podem começar me explicando o processo de negócios, acho que posso ficar algumas horas vendo como vocês trabalham e como o sistema é usado. Depois queria conversar um pouco com o time de desenvolvimento, podemos fazer uma mini-retrospectiva e uma futurospectiva para tentar entender porque a comunicação é um problema. A partir daí nós traçamos um plano, pode ser necessário conseguirmos coaches técnicos e, talvez, um gerente de projetos com experiência em métodos ágeis…
- Er… ahm. Ta. Mas… não era bem isso que estávamos pensando. Sabe, nós já fizemos tudo isso. Tivemos uma grande reunião, acertamos os fluxos de trabalho e tal.
- É? Mas… pelo que eu vi conversando com pessoas durante as últimas semanas vocês ainda têm problemas, os desenvolvedores estão reclamando de que tudo muda o tempo todo, o pessoal de negócios reclama que vocês estão quinze meses atrasados…
- Sim, sim, sabemos disso tudo. Mas nós sabemos que com o Scrum eventualmente essas coisas vão se resolver, não estamos preocupados. O que nós não conseguimos entender é como otimizar a radiação de informações utilizando kanbans distribuído pelo chão de fábrica.
- “Otimizar..kanban…” peraí, vocês querem que eu ajude você a decidir onde colocar seu story wall?
- É, acho que você pode colocar deste jeito…
- Você tem alguma idéia do quanto vocês estão pagando por hora pra eu estar aqui?!?

Eventualmente o cliente percebeu que onde posicionar o story wall era o menor dos seus problemas. Um dos principais problemas deles é que estavam fazendo exatamente o que o Fabio Câmara sugeriu: tinham um Scrum Master que criava, gerenciava e ajustava o plano. Os desenvolvedores estavam sempre atrasados porque eles nem sabiam qual era o plano, apenas sabiam das atividades. Discussão típica:

- Estamos atrasados!
- Você está atrasado, meu time está em dia.
- Como assim?
- Eu falei que precisava de dois dias para colocar o back-end em produção, bom estamos terminando agora, com o mínimo de atraso.
- Mas o front-end não está pronto, qual a diferença?
- Isso é com o time do Beltrano. Nós aqui estamos certos. Sprint goal atingido, vamos para o bar.

Ou, na “obtenção de feedback”:

- Ok, esta tarefa aqui está demorando muito então vamos acabar entregando aquela ali atrasada.
- Você está dizendo que o projeto vai atrasar?!
- Não, não. Você me entendeu mal. Meu time está OK, nós vamos entregar em dia, não se preocupa não.
[dois dias depois]
- E aí, tudo certo?
- Tudo.
- Aquela tarefa ali… está meio atrasada, não?
- Não, não. Veja bem, ela já vai estar pronta… já já.
[final do sprint]
- Então, como estamos?
- Bom. Aquela tarefa ali atrasou. Isso fez com que o Fulano ficasse preso ajudando o Beltrano e não fizesse o trabalho dele. Mas não tem tanto problema porque ele não ia conseguir fazer o trabalho dele mesmo já que esta tarefa depende da outra.
- Então… o que vocês estão entregando hoje?
- O Domain Model, todas as classes no lugar. Ta pronto. Só falta testar.

A solução neste caso específico teve que ser meio drástica. O que queríamos fazer era remover todos os Scrum Master e devolvê-los a sua posição original (geralmente gerente de projetos e desenvolvedores sênior) mas vimos que isso ia causar problemas políticos demais. A solução mais viável foi manter os Scrum Masters -pelo menos o título- e usarmos “Gerentes de Iteração”. Iteration Manager é o termo que usamos para um papel equivalente ao Scrum Master –gerente de projetos é outra coisa- e estes caras atuavam como lideres dos times e gerentes de iteração.

Os gerentes de projeto -ainda chamados Scrum Masters por razões históricas- tinham ainda o “plano”, algo em extremo alto nível que dizia que considerando a situação atual de escopo e velocidade a funcionalidade X vai ser entregue dia Y, a Z dia W e assim por diante. Arrastar barrinhas no Microsoft Project não mudava o plano, ele era apenas um retrato da situação real e para mudar a situação real você tem que resolver seus impedimentos. Sem truques.

Outro problema foi o tal do testes. Nós sabemos que desenvolvedores profissionais testam mas neste cliente eles compartilhavam da idéia do Fábio de que testar é coisa pra recurso barato. Resultado? Os recursos caros ficavam dias produzindo código caro que não funcionava. Apos um sprint inteiro de código caro produzido se tinha que reescrever boa parte. Como é aquela história de “o barato sai caro mesmo”?

Nada disso, qualidade é algo muito caro para ser produzido por “recursos baratos”. Como o Jason Yip diz: controle qualidade é responsabilidade do time todo -ele sugere o termo “Inspetor de Qualidade” para o que normalmente chamamos de QA- e para isso os desenvolvedores precisam entrar na dança.

Sendo extremamente sincero, eu não consigo entender como um desenvolvedor experiente assume que uma metodologia ágil consiga funcionar sem testes. Você não tem sequer uma especificação dizendo o que vai construir!

A única maneira que eu vejo disso meio que funcionar é se ao invés de uma metodologia ágil você utilizar apenas mini-waterfalls a cada sprint. Fica um tempo especificando o que vai ser feito, um tempo fazendo, um tempo testando. Enxágüe e repita. Mas isto não é uma metodologia ágil, o ciclo de feedback é muito longo!

E este foi só um dos múltiplos exemplos que tivemos nos últimos dois anos. É preciso ter cuidado, muito cuidado. Scrum vêm crescendo muito como hype e é um framework, cheio de lacunas por definição. Quando alguém com bastante bagagem vê as lacunas no Scrum ele logo assume que basta enfiar o que já se usa em desenvolvimento “tradicional” e acaba criando um híbrido de modelos quase sempre extremante ineficiente.

Scrum não diz como desenvolver software? Sem problemas, nós sabemos fazer isso: escreve uma especificação no wiki, codifica, testa. Scrum não diz como compartilhar conhecimento sobre o código? Sem problemas, nós sabemos como fazer isso: antes do código ser enviado para o SCM ele tem que ser aprovado por um membro mais sênior do time. Scrum não diz como integrar código? Sem problemas: cada um cria seu branch e nós integramos no final do Sprint.

É bom notar que mesmo com as lacunas citadas o framework tem princípios bem definidos. A opinião de que o Scrum Master é o dono do plano vai de encontro com o que o Scrum prega. Pode ser a opinião de alguém experiente, você pode achar que faz sentido… só não pode dizer que isso é Scrum.

E se você soma isso ao fato de que não é preciso muita coisa para ter um certificado em Scrum o problema toma proporções gigantescas. Scrum em si não diz que é errado, digamos, escrever um documento de caso de uso de vinte páginas para cada item de backlog. E se, ainda por cima, a pessoa que sugeriu isso ainda possui um selinho dizendo que ele sabe Scrum?

Se você não tem um time experiente em metodologias ágeis então comece seguindo todas as práticas de XP. Após ganhar experiência decida o que funciona e o que não funciona –mas teste todas antes, e por um tempo considerável.

Não comece apenas por Scrum. Como falei antes você vai encontrar muitos buracos e sempre a solução mais fácil vai ser fazer o que já se fazia antes.

Repetindo um tema freqüente neste blog: eu posso programar FORTRAN em qualquer linguagem. Eu posso gerenciar waterfall e/ou comando-e-controle em qualquer metodologia.

Posted in brasil, comunidade, eventos, gerencia, metodologias, palestras, perolas, testes | 14 Comments »

Brazilian Tour 2008: Falando em Agile, Domain-Driven Design

Monday, September 1st, 2008

Outubro vai ser um mês bem interessante. Vou entregar um dos meus projetos mais importantes até agora (pelo menos é o que nossas previsões dizem) e vou passar 15 dias entre férias e eventos no Brasil.

O motivo principal é para realizar uma apresentação no Falando em Agile 2008, mais um evento da Caelum. As inscrições estão abertas e inscrevendo-se com antecedência você consegue desconto.

Minha palestra vai ser sobre um tema que venho desenvolvendo há algum tempo: como adoções ágeis que tinham tudo para dar certo afundam. Antes de entrar para a ThoughtWorks eu já tinha vivido esta situação pelo menos duas vezes, nestes nove meses trabalhando numa grande consultoria especializada eu já vi umas três. Todas tinham um grupo de sintomas bem parecidos o quais estou tentando estruturar. Não é lá muito fácil mas acho que o resultado tende a ser bom. Se você acha que Vovô viu a uva, a web somos nozes, arquitetura BOLOVO e amigos foram piadas infames e de mau-gosto mal podem esperar pela temática desta apresentação…

Uma das coisas mais interessantes sobre o FalandoEmAgile 2008 para mim vai ser a presença do Danilo Bardusco na grade. O Danilo foi meu gerente na Globo.com antes de assumir tudo-menos-webmedia, quando passei a responder diretamente ao Antônio Carlos. Naquele momento a empresa viva diversas histórias tristes com métodos baseados em Waterfall, micro-management e consultorias CMMI 5; apesar dele não acreditar que aquilo ia dar certo no início foi sua perseverança e abertura à inovação que possibilitou aquele trabalho inicial que hoje, graças ao trabalho de todos, é referencia. O grande defeito dele é aquela mania infeliz de usar Vi quando todo mundo sabe que emacs é o único editor de texto que deveria ser utilizado. Mas eu perdôo.

Como falei, são 15 dias no Brasil. Eu ainda não sei as datas do que vou fazer mas devo ter algumas outras apresentações de palestras no Rio (certamente no RioJUG) e em São Paulo.

Como eu já estava vindo para o Brasil, acabei fechando com a Caelum uma série de oficinas em Domain-Driven Design. A idéia é cobrir os principais aspectos desta filosofia de design de uma maneira descontraída mas substancial. O primeiro post que menciona Domain-Driven Design neste blog é de 2005, e foi importado do meu antigo blog no blogger.com. Nesta época quase ninguém havia ouvido falar do conceito. Hoje ainda é algo relativamente obscuro mas um pouco mais popular. Claro que com a popularidade vem os problemas. Muita gente no GUJ, em blogs e outros fóruns está simplesmente associando Domain-Driven Design com um bom design Orientado a Objetos, ou pior ainda: com qualquer design OO.

Ao contrario do recente mito popular, Domain-Driven Design não é “voltar para Orientação a Objetos”. Orientação a Objetos foi criada como uma maneira de gerenciar dependências e criar unidades coesas e atômicas de código, não necessariamente uma forma de modelar uma Camada de Negócios. O que Domain-Driven-Design traz de volta é a possibilidade de utilizar as vantagens da Orientação a Objetos para criamos um modelo que reflita o mundo real de maneira mais íntima. Você não precisa sequer de objetos para aplicar o coração de Domain-Driven Design, ou mesmo seus Patterns.

A parte do “substancial” que falei acima é exatamente esta: não misturar Orientação a Objetos com Domain-Driven Design e sim trabalhar a relação entre eles. A parte “descontraída” é na forma de passar este conhecimento. Após alguns anos ministrando treinamentos eu não tenho a fórmula ideal para passar este tipo de conteúdo (altamente abstrato e que requer conhecimento posterior) mas eu já aprendi por tentativa e erro diversas formas em que isso não dá certo –pelo menos não comigo. Duas delas são: aulas expositivas e laboratórios. Se você não entende porque aulas expositivas não servem para este tipo de coisa pense sobre todo o conteúdo que é quase que literalmente jogado em cima de alguém numa faculdade e quanto dele é entendido (e entender não é tirar 10 na prova). O problema de laboratórios é que sempre perde-se tempo com a máquina, ou a linguagem (este não é um workshop Java ou Ruby ou C#, é um workshop sobre objetos).

Eu não tenho as datas nem preços (já encheu o saco da Caelum hoje?) mas vamos ter sessões em outubro no Rio e São Paulo, a preços acessíveis.

Posted in arquitetura, brasil, comunidade, domain.driven.design, engenharia, gerencia, guj, metodologias, orientacao.a.objetos, plataformas, programando, rio, riojug, testes | 12 Comments »

Uh-Éme-Éle

Friday, July 25th, 2008

Este tópico no GUJ chamou atenção, especialmente porque o li logo após um interessante texto noblog do Marcelo Araújo sobre uma outra faceta do mesmo tema: modelagem usando especificações não executáveis.

O que eu quero dizer com isso? Dada a tecnologia atual na maioria das empresas (desconsiderando o uso de coisas como DSLs ou mesmo alguma solução MDSD que, ao contrario de MDA, funcione) todos os documentos comumente utilizados para “modelagem” não são verificáveis, não são executáveis e requerem um trabalho manual enorme. Como bem disse o Emerson Macedo no post, você acaba programando duas vezes, uma na sua notação gráfica (UML) e uma na sua notação executável (Java, C#, Ruby… o que for).

Acontece que ao passar do diagrama (e diagramas aceitam qualquer besteira) para o código (onde o compilador e testes unitários são muito exigentes – fora os usuários) o tal do pseudo-modelo criado pelo “analista” no Rational Rose (porque a empresa não percebeu que o Rose foi descontinuado há anos) é completamente diferente do modelo implementado. As classes até têm o mesmo nome mas a mecânica interna é bem diferente. E por quê? Porque UML não vai te oferecer tudo o necessário para modelar. O mínimo que se espera de um modelo de um sistema é que ele seja verificável para saber se cumpre seus requisitos. Como é que eu vou saber isso com UML? Como eu testo UML?

Há algum tempo que eu me pergunto porque que se usa UML para “modelar”. Não me entenda mal, UML é uma ótima noção gráfica para Orientação a Objetos e com ela você consegue passar uma big picture muitas vezes mais rapidamente do que código; mas ela fica por aí: comunicação.

Quando modelamos o comportamento de objetos nós estamos descrevendo como este se comporta em diversas situações. Ao modelar uma determinada atividade você precisa descrever um conjunto grande de detalhes sobre esta, e UML não esta pronta para este tipo de coisa - e nem é a idéia por trás dela. Se modelar em UML fosse eficiente nós estaríamos programando em UML não em C#, Java ou o que for.

O primeiro problema ao tentar introduzir este pensamento na indústria é: mas eu não posso deixar que meus “implementadores” façam o que quiserem. Pergunta: o que raios é um implementador? Um datilografo de luxo?

Supondo que sua empresa seja a típica empresa de três letrinhas, aquelas que contratam qualquer um como “programador júnior” porque ele vai receber instruções do analista. Neste cenário eu pergunto: para que o tal programador? Que tal dar ao seu “analista” uma ferramenta mágica em que ele consiga criar um modelo abstrato e ao mesmo tempo executável? Que tal se ao invés de gastar rios de dinheiro pagando 10-reais-mais-o-busão para seus implementadores você eliminasse completamente a necessidade deles, fazendo com que o “analista” sozinho cuide do serviço?

Não precisa sacar seus milhões do banco nem pensar em como justificar o gasto com esta ferramenta no orçamento, você muito provavelmente já possui o necessário dentro da sua empresa: uma linguagem de programação decente. Faça seu “analista” usar código para expressar a modelagem. No final dá no mesmo para o nível de modelagem desejada e você ainda ganha algo verificável e executável. Economia de rios de dinheiro quase que instantânea.

Mas como assim? O “modelo lógico” é muito diferente do “modelo físico” e o “analista” não pode perder tempo com essas coisinhas de tecnologia, tem que pensar em modelar o negocio. Muito bem, duas coisas:

  1. Analista de Sistemas não é analista de negócios. Se você não sabe o que é um analista de negócios eu recomendo que você mande um e-mail pro Paulo Vasconcellos perguntando.
  2. Há mais de cinco anos que não há quase nenhum motivo para que uma aplicação Java ou C# não seja uma cópia de 1-para-1 de um modelo UML do tipo “diagrama de domínio”. POJO/POCO, Hibernate, IoC, Camadas, OO, AOP, EJB3, MVC… toda essa parafernália de letrinhas permite que seus objetos de negocio não tenham o menor traço de infra-estrutura. Claro que alguém vai ter que fazer a infra-estrutura –ainda que seja mínima. Caso seus “analistas” sejam de qualidade extremamente baixa eu recomendo que você contrate um bom técnico para atuar como arquiteto e líder técnico do time.

Verdade seja dita: esta não é a primeira vez que este blog trata do tema e desde a última vez muita coisa melhorou, mas ainda há muito que melhorar.

Posted in arquitetura, comunidade, engenharia, metodologias, plataformas, programando, testes | 26 Comments »

Rastreabilidade em User Stories

Friday, July 18th, 2008

Pergunta na XP-Rio:

Me ajudem no seguinte, no processo unificado, espera-se que todos os casos de uso gerem algum tipo de artefato dentro do projeto. Na verdade, com os casos de uso espera-se chegar em classes que juntas formarão o sistema. Dentro da metodologia existe artefatos que quando feitos, permitem mapear todos os artefatos gerados a partir de um caso de uso. A matriz de rastreabilidade.

Gostaria de saber como o XP permite chegar as classes (código) a partir das User Stories. Por exemplo, dado uma User Stories, quais são as classes geradas para atender essa User Stories?

O XP permite isso? Como é feito?

Provavelmente a primeira coisa a se perguntar é: por que eu precisaria deste dados? Alguns modelos de processo como CMMI definem rastreabilidade, que geralmente é definida nesta linha:

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.)

- Gotel O.C.Z and Finklestein A.C.W (tirado da Wikipedia)

A necessidade parece justa e real, é preciso saber quais partes do software são afetadas por mudanças no negocio e vice-versa. O grande problema desta métrica é que transformações de modelo não são mais tão drásticas há algumas décadas. Ao utilizar qualquer tecnologia relativamente comum (Java, Ruby, .Net, Python, JavaScript…) não existe motivo técnico para que o software não modele o negocio em uma relação próxima de 1-para-1, desta forma saber qual parte de um código realiza qual tarefa torna-se bem simples.

Outro problema é que eu nunca vi um artefato de rastreabilidade, seja qual for, que não ficasse defasado. Se você abraça uma metodologia ágil sabe que refactoring faz parte da vida.

Mesmo com todos os problemas que esta métrica possui eu entendo que existem casos onde seu uso se faz necessário –especialmente por equipes tentando introduzir agilidade em ambientes tradicionais. Supondo que exista uma necessidade justificável para algum controle deste tipo, metodologias ágeis em geral possuem um mecanismo muito mais eficiente que documentos ou mesmos sistemas: testes.

Toda história, todo cartão, deve ter um critério de aceite. O critério de aceite traz o que o cliente considera ser o mínimo para que a história seja considerada concluída. Por exemplo:

História: Como administrador eu quero criar um novo grupo para que possa aplicar permissões à diversos usuários de uma só vez.
Critérios de Aceite:

  • O novo grupo criado deve possuir o usuário que o criou como seu administrador
  • O novo grupo não deve conter outros membros
  • O novo grupo não deve ser visível na listagem de grupos

Cada um destes critérios via um teste unitário e/ou funcional que é executado como parte da integração contínua. Para saber exatamente quais classes e códigos são afetados por cada um deles é simples: use uma ferramenta de test coverage como o Emma e execute apenas os testes de aceitação para aquele cartão. A ferramenta irá gerar relatórios como estes:

[class, %]	[method, %]	[block, %]	[line, %]	[name]
25%  (1/4)!	25%  (3/12)!	40%  (3012/7446)!	25%  (3/12)!	com.sun.tools.javac.v8.resources
94%  (16/17)!	49%  (41/83)!	48%  (1111/2292)!	45%  (201.1/450)!	com.sun.tools.javac.v8
88%  (45/51)!	61%  (242/397)!	54%  (3070/5729)!	52%  (809.6/1563)!	com.sun.tools.javac.v8.tree

Classes que possuem alguma cobertura foram afetadas pelo teste, logo são parte da execução daquela história. Não é difícil escrever um script que –talvez como parte do build- processe estes relatórios e gere o artefato de rastreabilidade que seu processo te obrigar a fazer. Melhor ainda: este artefato nunca estará desatualizado.

Só não se esqueça que melhoria contínua é um conceito importante. Se o artefato de rastreabilidade é algo tão ineficiente a obrigação de um desenvolvedor que perceba isto é mostrar para sua organização que o valor desta pratica é nulo. Não se acomode.

Posted in comunidade, gerencia, metodologias, programando, testes, você.pergunta | 14 Comments »

Testadores Ágeis

Monday, March 24th, 2008

Todo mundo sabe que agilidade é sobre testes. Muitos testes. Bem, mais ou menos. Geralmente quando falamos de testes em metodologias ágeis estamos falando de testes escritos pelo desenvolvedor enquanto escreve código, e estes têm dois objetivos: feedback e bom design.

Feedback se consegue ao executar os testes. Quando você escreve uma classe que quebra um teste você sabe que existe algo errado imediatamente. Bom design se dá porque nada alem do necessário é criado, alem de que as tecnologias atuais de testes exigem que seu código siga alguns bons princípios para que seja testável, como bom gerenciamento de dependências.

Existe, entretanto, outro tipo de teste, geralmente feito por um profissional especializado, que chamamos de QA (Quality Assurance). Este teste valida o software de um ponto de vista diferente. Muita gente se engana achando que testes de desenvolvedor são suficientes para validar um sistema. Obviamente que assim como nem todo sistema exige um web designer profissional especializado nem todo exige um profissional de testes, mas a maioria dos projetos que já participei tinham nisso um benefício.

Estava lendo o artigo do Jeff Paton, ex-colega ThoughtWorker, sobre isso e lembrei das minhas experiências com testadores em time ágeis. Mas primeiro talvez seja melhor contar sobre as experiências em times não-ágeis.

Eu trabalhei em uma empresa muito interessante mas com um processo muito estranho. A empresa tem orgulho de usar waterfall para desenvolver seus produtos, ninguém está autorizado a escrever uma linha de código sem escrever 8 documentos. Obviamente todos os projetos atrasam e obviamente o software tem uma qualidade deprimente, mas eles conseguem fazer dinheiro neste cenário –ainda que pagando um preço muito alto.

Teste é uma coisa séria nesta empresa. Os produtos estão sujeitos à regulamentação de telecomunicações de diversos paises, e cada funcionalidade tinha que ser testada de acordo. O fluxo de desenvolvimento era o típico de waterfall, nós desenvolvedores criávamos nossos sistemas (programas em C++ para plataformas UNIX diversas) e enviávamos uma tag do Subversion para a equipe de testes. O testador teoricamente já lera todas as especificações funcionai do produto e já tinha os casos de testes escritos e, talvez, implementados.

Era aí que a brincadeira começava. Na melhor das hipóteses o testador encontrava um bug, rejeitava o pacote (usando um maravilhoso sistema interno desenvolvido em Lótus Notes) e enviava de volta. O desenvolvedor corrigia e o pacote era retestado. Isso nunca acontecia. O que acontecia era:

  • O pacote era aprovado. O desenvolvedor, com o sistema já em produção, olhava o plano de testes por curiosidade e via que eles não testavam absolutamente nada de relevante, ninguém garantia a qualidade do treco
  • O pacote era rejeitado. O desenvolvedor olha ao motivo da rejeição e via que o que estava sendo testado nem de perto era o que o sistema deveria fazer. O testador Não entendeu o documento, muitas reuniões explicando tudo novamente e o pacote era retestado sem modificações
  • O pacote era recebido pelo testador com total surpresa. Era uma aplicação de linha de comando e o testador esperava uma aplicação com interface web, ou o testador esperava que o sistema usasse banco de dados e ele mantinha tudo em memória, ou…
  • O testador rejeitava o pacote porque não sabia como testa-lo. O desenvolvedor não pensava no testador, o testador não pensava no desenvolvedor.

Claro que todos os membros do escritório de projetos (já falei que tínhamos CMMI?) sabiam a solução para estes problemas e é claro que para eles a solução passava pela criação de mais documentos, de 1 a 5 dependendo de quem você perguntasse.

Nas equipes ágeis que trabalhei a coisa era diferente. O testador senta ao lado do desenvolvedor, e por vezes eles trabalham em pair programming (pair testing, provavelmente). O testador está envolvido em todas as tarefas, validando que o que o analista de negócios pede é entregue, que confirma com as premissas do projeto e etc.

Para fazer isso ele está envolvido na elaboração das user stories e, principalmente, dos critérios de aceite definidos nela. Seu trabalho é verificar que os critérios de aceite são obedecidos pela implementação e que eles fazem sentido em primeiro lugar.

Um profissional come site perfil não pode ser simplesmente um usuário. Ele tem que conhecer sobre metodologia de testes de software (um campo enorme por si só), sobre o domínio do sistema e sobre desenvolvimento. Idealmente o testador é um desenvolvedor e sabe criar suas ferramentas. Um testador deve ser capaz de escrever seu próprio programa usando Selenium RC, ou suas fixtures no Fit.

Infelizmente nem sempre isso acontece. Em muitas empresas o cargo de testador é delegado à pessoas que possuem um conhecimento técnico muito baixo e executam tarefas do tipo “aperte o botão e verifique se quebra o layout”. Neste caso os desenvolvedores podem prover as ferramentas para os testadores mas ainda assim eles devem ter capacidade de escrever os casos de testes usando a ferramenta sozinhos.

O papel do testador não é dizer que a aplicação está homologada, na maioria das vezes isso é apenas uma ilusão que gerentes gostam de cultivar. O papel do testador é garantir a qualidade dele submetendo à testes rígidos. Não é um aceite formal, o testador não é quem aprova o software –o analista de negócios ou seu equivalente aprova o software- ele faz parte do desenvolvimento deste.

Minha experiência diz que assim como trabalhar com testadores apertadores-de-botão não agrega nada ao produto alem de burocracia desnecessária, trabalhar com testadores de verdade no time é uma das melhores coisas que pode acontecer num projeto de software.

No meu projeto anterior os testadores chegaram ao time apenas como apertadores de parafusos. Eles clicavam na tela e verificavam que a informação correta era disponibilizada. Como nossa participação no projeto era facilitar a adoção de metodologias ágeis isso tinha que mudar. A primeira coisa foi a participação dos testadores na definição das histórias, eles trabalham junto com o analista de negócios e o usuário definindo critérios. Eles também participam do sign-off da história –quando ela é apresentada aos desenvolvedores que vão executa-la- e quando conclui a história o desenvolvedor az um walkthrough dela para o testador. Em todas as etapas eles agregam informação, questionam as praticas e, principalmente, garantem que o software final é testável.

Foi adicionado ao time de facilitadores um testador especialista em automação –um desenvolvedor exercendo função de QA, basicamente-, a função dele era disponibilizar ferramentas e disseminar seu uso. Com o tempo desenvolvemos uma Internal DSL em Ruby para controlar nossa ferramenta de teste, o Selenium RC. A ferramenta é utilizada por desenvolvedores nos nossos testes de aceitação que fazem parte do build e pelos testadores na hora de dizer que uma história está concluída.

Os resultados desta adoção são excelentes. Quando nossa parte no projeto –facilitar a adoção das praticas- acabou a pessoas estavam aptas à continuar o bom trabalho por si mesmas. Os desenvolvedores ainda criam as ferramentas mas a gerencia, vendo os benefícios, agendou cursos de Ruby e Selenium para a equipe de QA.

Posted in domain.specific.languages, gerencia, metodologias, programando, ruby, testes, thoughtworks | 5 Comments »