Archive for the ‘Agile’ Category

Como lidar com defeitos/bugs

Tuesday, December 16th, 2008

Há alguns dias recebi um e-mail com a seguinte dúvida:

Se fosse possível eu gostaria que você falasse um pouco de como funciona para vocês o tratamendo de incidentes em produção e defeitos. Como num ambiente ágil isso é tratado? Eles entram no backlog independente do projeto ou existe um tratamendo especial para fix/test/deploy? Alguma equipe específica faz o fix e corrige os testes unitários se for o caso?

Seria legal ter uma luz a respeito disso.

Como esse era um assunto que eu já estava para falar mesmo, aproveitei o gancho para fazer esse post.

Depois de conversar com muitas pessoas ao longo do tempo, o que eu percebí é que cada um trabalha de um jeito. Eu não acredito que exista uma forma certa ou errada de trabalhar, o que existem são formas diferentes que funcionam melhor ou pior em determinado lugar ou outro. Apesar disso, deve-se tomar cuidado para não criar alguma forma de trabalhar que viole os princípios básicos da metodologia/framework (Scrum no nosso caso). E por último, nem sempre conseguimos fazer dessa forma que vou falar, mas no geral é o que tentamos fazer.

Antes de tudo nós tentamos tratar cada tipo de defeito de acordo com sua gravidade. Para auxiliar, assim que um defeito chega para a equipe nós tentamos enquadrá-lo em uma das 3 categorias de defeitos, que para facilitar a explicação acabei de batizar de defeitos simples, importantes e gravíssimos.

Defeitos simples

São defeitos que têm pouco ou nenhum impacto para o usuário. Para citar um exemplo, nós tivemos recentemente um minúsculo defeito de alinhamento em um dos elementos da página do player do Globo Vídeos. Esse defeito não precisou ser visto imediatamente porque ele não impacta o uso do site e também quase não impacta visualmente, visto que o usuário está prestando muito mais atenção ao vídeo do que no resto.

Neste caso o Product Owner é notificado e a regra de priorização normalmente é “quanto antes corrigirmos isso, melhor”.

Defeitos importantes

São defeitos que não são tão simples como meros detalhes visuais mas que não impedem o produto de funcionar. Por exemplo, tivemos um caso que a Macromedia lançou uma nova major version de plugin do Flash e com isso descobrimos que a nossa verificação de versões tinha um problema. O resultado é que a exibição em tela cheia não funcionava corretamente em alguns casos, mas ainda assim o usuário conseguia ver o vídeo numa pop-up que simulava a tela cheia.

Neste caso temos duas opções. A primeira opção é colocar o defeito no backlog para que ele seja a primeira história a ser trabalhada no próximo Sprint. A segunda opção é como normalmente fazemos hoje em dia: o time sempre trabalha a 80~90% da sua capacidade para que quando esses incidentes aconteçam ele possa “puxar” ou assumir mais histórias – desde que todos se sintam confortáveis para isso. Caso não ocorra nenhum incidente durante o Sprint e sobre algum tempo no final, o time pega outra história qualquer que caiba no tempo que sobrou.

Defeitos gravíssimos

São defeitos que impedem o produto de funcionar. Usando mais uma vez o caso do Globo Vídeos, um defeito gravíssimo poderia ser algo que fizesse com que os vídeos parassem de ser exibidos, ou que alguma página estivesse indisponível, ou qualquer outra coisa que impeça os usuários de usarem o produto. Quando os defeitos desse tipo chegam para nós eles já passaram em 2 ou 3 níveis de suporte, então provavelmente trata-se de algum problema do software mesmo (e não de ambiente, de configuração do usuário, etc.) e precisa ser visto com a maior urgência possível.

Neste caso, o mais apropriado seria cancelar o Sprint imediatamente, planejar rapidamente, iniciar um novo Sprint com este item como o primeiro item a ser resolvido e fazer um release o mais rápido possível para corrigir o problema.

Para falar a verdade nunca tivemos esse terceiro caso depois que começamos a trabalhar de uma forma mais organizada com Scrum e cuidando cada vez mais da qualidade do que é entregue. Sendo bem realista, como trata-se de um defeito que coloca em risco a imagem/credibilidade/audiência/dinheiro da empresa, pode ser que seja mais apropriado parar tudo e dar atenção máxima ao problema sem seguir um script específico, afinal de contas o bom funcionamento da empresa deve estar sempre à frente de qualquer coisa. Se isso acontecesse, acho que eu daria o Sprint como cancelado, re-planejaria e começaria um novo Sprint.

Concluindo

Apesar de tudo isso eu pessoalmente sou favorável a corrigir todo e qualquer bug o mais rápido possível, independente de sua gravidade. Eu sou totalmente contra acumular débito técnico porque já sabemos como isso pode afetar a produtividade e velocidade do time a médio/longo prazo. Porém, como já havia dito, dadas as nossas condições e restrições essa foi a forma que melhor funcionou para a nossa realidade – e para ser franco acho que tem funcionado bem.

Agile indo para o buraco?

Saturday, November 22nd, 2008

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!

Agile 2008 Conference, aí vou eu!

Thursday, July 31st, 2008

Agile 2008Na próxima semana estarei em Toronto/Canada para a Agile 2008 Conference, a maior conferência sobre desenvolvimento ágil do mundo!

Com mais de 400 apresentações em 5 dias, o calendário da conferência, divulgado no início do mês passado está ótimo! Teremos a presença de vários nomes conhecidos do mundo ágil como Jeff Sutherland, Mary Poppendieck, Robert Martin (o Uncle Bob), Mike Cohn, Henrik Kniberg, Dan North, Mishkin Berteig, Scott Ambler, Linda Rising, Jim Highsmith, Neal Ford, James Shore… Vai ter tanta coisa legal que está até difícil escolher quais apresentações vou assistir! E isso tudo sem falar do amigo brasileiro e ThoughtWorker Danilo Sato, que apresentará o case do Coding Dojo de São Paulo.

Quem lê meu blog já deve ter percebido que desenvolvimento ágil é um dos meus assuntos favoritos, por isso podem esperar que provavelmente vou blogar mais do que o normal na semana que vem!

Como estamos indo com a adoção de Scrum na Globo.com

Tuesday, May 27th, 2008

Muita gente têm me perguntado como estamos indo atualmente com a adoção do Scrum na Globo.com. Acho que já é hora de falar alguma coisa sobre isso. Esse não é um case oficial assinado pela Globo.com, são apenas alguns relatos do meu ponto de vista sobre o assunto.

Nossa história no início foi bem parecida com as histórias tradicionais. Sabe aquelas empresas que gastam uma semi-fortuna com uma consultoria para desenhar um processo de desenvolvimento de software? Assim estávamos nós no início de 2007. Poucos projetos eram entregues nas datas acordadas e muitos deles falhavam ou não satisfaziam as necessidades dos clientes. Contratar uma grande consultoria de software parecia ser uma boa tentativa de arrumar as coisas, mas o resultado do trabalho foi um documento que descrevia um processo com algumas centenas de páginas que devia ser seguido á risca, isso sem contar as dúzias de documentos padrão para todos os tipos de requisição e comunicação que se possa imaginar. Dezenas de páginas descreviam quem deveria falar com quem e quem entrega qual documento em qual momento. O processo foi feito para lidar com todas as complexidades, burocracias e exigências que nós mesmos criamos dentro da empresa.

Resumindo a história, isso não funcionou na Globo.com e acho que existem poucas chances de algo tão complexo assim funcionar em algum lugar. E por incrível que pareça, no fim das contas ninguém havia pensado em nada para resolver o problema principal: como entregar o software que nossos clientes querem no menor tempo e com a maior qualidade possível?

Um pouco de história

Ao contrário do que acontece em muitas empresas, as metodologias ágeis na Globo.com vieram de baixo para cima. Tudo começou com um movimento tímido entre alguns desenvolvedores de aplicar práticas de desenvolvimento ágil do XP (Extreme Programming) nos projetos. A porta de entrada foi a oportunidade de melhorar a qualidade dos nossos sistemas, pois tinhamos uma incidência muito grande de bugs em produção e poucas aplicações eram testadas adequadamente.

Alguns desenvolvedores mais experientes começaram a desenvolver usando desenvolvimento guiado por testes (TDD), e com isso houve uma melhora nítida na qualidade do que era entregue. Aos poucos, enquanto isso acontecia, algumas seções de programação em par aconteciam de vez em quando para difundir o conhecimento e ensinar a técnica a outros programadores, mas ainda de forma muito tímida e sutil (afinal às vezes é difícil convencer que dois programadores fazendo apenas um código é uma coisa boa).

Em seguida foi a vez de organizar as demandas de clientes e os ciclos de desenvolvimento. Lembro-me de ter colocado nessa época o mesmo software em produção quatro vezes em duas semanas, e depois disso o mesmo software foi trabalhado durante dois meses para só depois poder ir novamente para produção. Para piorar, nossos clientes nos traziam todo tipo de demanda que se pode imaginar, sempre em lotes e com prioridade máxima. Por exemplo, acontecia frequentemente do mesmo cliente demandar cinco coisas e todas elas com máxima urgência. Resumindo, os ciclos de planejamento, desenvolvimento e entrega eram totalmente irregulares e afetavam o desempenho de toda a equipe. Explicando todas as dificuldades que tinhamos para nos organizar nesse caos, conseguimos acordar que fariamos entregas constantemente de duas em duas semanas, e que dentro desse período não haveria nenhuma mudança no planejamento, que seria feito no início de cada período. Antes de iniciar cada ciclo de desenvolvimento, os clientes tinham a oportunidade de escolher quais seriam as prioridades da equipe de desenvolvimento nas duas semanas seguintes. Sem perceber eles haviam aceitado a idéia de desenvolvimento iterativo e jogo do planejamento, e nós teriamos alguma organização e paz para fazer o trabalho.

Em meados de Julho de 2007 a empresa decidiu bancar um curso de Scrum com o Boris Gloger para alguns membros da nossa equipe e o resultado foi ótimo! Na semana seguinte mesmo já começou a mudança. Todos voltaram com um novo gás e dispostos a mudar a empresa. Me lembro de nessa época alguém ter falado a seguinte frase: “Agora eu acredito em desenvolvimento de software”.

Desse momento em diante passamos a aplicar Scrum no nosso time de desenvolvimento. O problema é que estávamos no meio de um projeto feito da forma “tradicional” (leia-se waterfall) e toda a fase de análise e especificação já tinha sido concluída. Tudo indicava que seria melhor esperar uma oportunidade melhor para começarmos a adoção, só que nós sabiamos que tinha que ser “naquela hora ou nunca” e então começamos a desenvolver nosso principal projeto usando práticas do Scrum.

Quase ninguém na equipe havia trabalhado com desenvolvimento ágil, então achamos que seria mais fácil não falar de Scrum, XP ou qualquer nome diferente. Simplesmente começamos a praticar e durante o desenvolvimento o time foi introduzido às práticas e à forma de trabalhar. As regras são muito simples e por isso foi muita fácil de adotá-las. Ao longo dos cinco Sprints o time foi amadurecendo, entendendo como trabalhar e também foram nascendo algumas adaptações necessárias ao funcionamento do projeto dentro da estrutura da empresa. Por exemplo, tivemos que resolver como seriam criadas as histórias e como isso seria integrado com o nosso sistema de tracking, como integrar com a equipe de QA, como colocar os projetos em produção e diversas outras questões. O Phillip falou bastante sobre essa fase introdutória no seu blog no ano passado.

Hoje, o Globo Vídeos 4.2, que é o tal projeto, está em produção. Para os padrões da empresa na época, ele foi um projeto surpreendente do ponto de vista de qualidade. Na versão anterior do Globo Vídeos (4.0) foi necessária uma janela de mais de 24 horas para colocá-lo no ar e ela aconteceu aos trancos e barrancos. Além disso a semana seguinte foi infernal, com muitos bugs para serem corrigidos e várias mudanças arriscadas durante o dia para corrigi-los. Já a versão 4.2 foi colocada em produção em pouco mais de uma hora e na primeira semana nem ouviamos falar do Globo Vídeos. Nem parecia que um dos sites de maior audiência da empresa havia sido quase totalmente substituído por um totalmente novo e com grandes mudanças arquiteturais!

Ao mesmo tempo que acontecia o Globo Vìdeos, o site de inscrições para o Big Brother Brasil 8 foi desenvolvido de cabo a rabo usando Scrum, da forma estrita, como está nos livros. O projeto simplesmente não teria sido feito considerando-se a complexidade e o tempo disponíveis. No final, ele foi um sucesso e além de ter sido entregue no prazo houve uma percepção de muita qualidade por todos – mais uma prova viva de que o Scrum era uma possível resposta para os nossos problemas. O Danilo inclusive fez uma apresentação sobre esse projeto na semana passada num evento do C.E.S.A.R. em Recife.

Esses dois projetos serviram de aprendizado e base para a estruturação de todos os projetos seguintes na empresa. O sucesso deles foi o grande responsável para ganharmos carta branca e começarmos a implementação de Scrum em massa na Globo.com.

Como estamos hoje

Após um ano de metodologias ágeis a empresa já está bem mais madura nas práticas e já temos mais de 10 times usando Scrum.

No fim do ano passado, após um treinamento para pessoas de todas as áreas da empresa, começamos todos a usar Scrum da forma estrita (obviamente houve uma curva de aprendizado até todos estarem mais seguros e praticando melhor). Hoje, alguns meses depois, já é possível perceber diferenças entre alguns times, que acabaram se adaptando de forma diferente por terem problemas e questões diferentes.

Sobre a duração dos Sprints, estamos trabalhando com duas semanas porque achamos que quatro semanas é muito tempo e poderiamos acabar nos tornando lentos na resposta às mudanças. Além do mais já vinhamos usando iterações de duas semanas desde que começamos a adotar desenvolvimento iterativo e continuar com este tamanho de ciclo seria mais fácil para nós.

Em virtude disso, como temos a metade do tempo de desenvolvimento recomendado pelo Scrum, decidimos que só precisamos da metade do tempo de planejamento. A recomendação é que o Sprint Planning tenha 8 horas para um Sprint de 4 semanas, e como nosso Sprint é de 2 semanas decidimos fazer um planning de 4 horas. As outras reuniões (Sprint Review, Retrospective, Daily Scrum, etc) permaneceram com a mesma duração, lembrando que essa duração não é obrigatória mas sim um limite para não ficarmos discutindo as coisas indefinidamente.

Nossos Sprint Plannings têm melhorado constantemente. No início sempre estouravamos o tempo da reunião discutindo um monte de coisas que não eram necessárias mas agora já estamos mais focados e a reunião tem funcionado bem melhor. As estimativas com planning poker também evoluiram um bocado e em várias ocasiões todos os desenvolvedores colocam o mesmo número sem combinar, o que indica que estamos evoluindo na sensação de esforço necessário para desenvolver as coisas.

A equipe, que antes era só de desenvolvedores, agora tem também um designer, um arquiteto de informação, um especialista em programação client-side (JavaScript/CSS/HTML), uma pessoa da equipe de testes e homologação e uma pessoa focada em negócios e ROI (que é o Product Owner). Todas essas pessoas sentam próximas umas das outras, e isso efetivamente aumentou muito a produtividade delas e o ritmo do projeto. Aos poucos todo o conhecimento específico está sendo difundido entre os membros da equipe. Infelizmente nem todas as equipes estão completas dessa forma por diferentes motivos (espaço físico, distância entre os prédios da empresa, etc), mas estamos trabalhando duro para resolver isso. Inclusive temos uma reunião chamada de Scrum Of Scrums, onde todos os Scrum Masters se reunem para se ajudarem a resolver esses tipos de problemas, que muitas vezes são comuns a várias equipes.

Já que o Scrum não fala nada sobre práticas de desenvolvimento de software, acabamos adotando muitas práticas do XP. Isso fica por conta de cada equipe e cada uma faz o que julga mais adequado para entregar o melhor software possível, mas muitas equipes usam desenvolvimento guiado por testes, integração contínua, programação em par, metáforas e várias outras práticas de Extreme Programming com muito sucesso. De fato a integração entre Scrum e XP funciona muito bem.

Definimos o nosso conceito de “done” (finalizado), que é a parte mais divergente entre as equipes. Na equipe de desenvolvimento de vídeos (minha equipe), uma história ou funcionalidade está pronta quando foi desenvolvida (incluindo testes unitários), integrada à base de código, testada novamente (fazemos testes de aceitação com critérios definidos no Sprint Planning ao criar as histórias) e homologada. Como nosso time tem uma pessoa da área de QA, podemos incluir a homologação da aplicação dentro do Sprint (nem todos os times fazem dessa forma).

Temos na empresa uma equipe que é especializada no ambiente de produção e por isso colocar os sistemas no ar fica fora do nosso Sprint. Quando nosso Sprint termina, entregamos um pacote fechado, testado, homologado e pronto para ser colocado em funcionamento, e então agendamos uma data e hora para que a subida seja feita acompanhada por um ou mais desenvolvedores do time. Todas as alterações de arquitetura e ambiente de deployment, quando necessárias, são feitas dentro do Sprint, somente as mudanças que envolvem risco de indisponibilidade nos sistemas que são feitas numa data que agendamos após o termino do Sprint, geralmente no meio da madrugada (as famosas “janelas”). Alguns times, por terem menos criticidade no seu ambiente de deployment, consideram que um Sprint está concluído quando o software está no ar, e o seu último dia do Sprint sempre é uma subida para produção. Como já havia falado anteriormente, cada time se adaptou para funcionar da melhor forma possível de acordo com suas peculiaridades.

E por último, nossas retrospectivas têm sido uma base forte para adaptações no processo e na forma de trabalhar. Para mim foi um aprendizado enorme quando o Boris Gloger veio na Globo.com e acompanhou uma retrospectiva inteira do nosso time – ele deu excelentes toques importantissimos. A última retrospectiva em especial, que aconteceu após uma grande entrega de um projeto interno, mostrou nitidamente a evolução do time e como estamos efetivamente conseguindo aos poucos achar e resolver todos os problemas. Estamos evoluindo devagar mas constantemente e já temos várias equipes com um bom nível de maturidade e evolução na empresa.

Concluindo…

Não só o Scrum como todos as metodologias ágeis dependem muito das pessoas. Na Globo.com não foi diferente e as pessoas certas fizeram toda a diferença. Também existe o outro lado da moeda: algumas pessoas simplesmente não se adaptam a essa forma de trabalhar. Desde o início da adoção nós já perdemos muitos desenvolvedores e acredito que ainda perderemos muito mais. Por conta disso nossos processos seletivos se tornaram mais exigentes e demorados, porque agora não só precisamos de pessoas que sejam ótimas tecnicamente mas também que tenham um perfil adequado para trabalhar no tipo de ambiente que criamos dentro da empresa.

Além disso é essencial que haja apoio da gerência e “carta branca” para que as equipes de desenvolvimento tenham a autonomia necessária para levar o projeto da forma correta. Como estes “processos” são muito diferentes dos tradicionais, algumas empresas acabam fazendo modificações antes do tempo por puro medo ou falta de conhecimento, que acabam atrapalhando ou até mesmo arruinando a adoção de uma metodologia ágil. Ainda em relação aos times de desenvolvimento, é essencial que os líderes de equipe (ou Scrum Masters no caso do Scrum) sejam muito bem capacitados e que conheçam profundamente as práticas/regras/princípios, não só para que tenham capacidade de argumentação com a empresa mas também para que não façam adaptações que violem os princípios básicos das metodologias ágeis.

Por fim, acho que ainda estamos muito longe do ideal e vejo muitas oportunidades de melhoria na nossa forma de trabalhar, mas o mais importante é que agora acreditamos que estamos no caminho certo.

Mais sobre Product Owners

Saturday, May 24th, 2008

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.

Perfil de um líder técnico

Saturday, May 10th, 2008

No mês passado eu havia escrito sobre como eu acredito que um Scrum Master deve atuar em um projeto de software, e o Phillip complementou em seguida com mais alguns pontos, não se restringindo apenas a Scrum Masters mas líderes de processos ágeis em geral.

O Patrick Kua postou agora há pouco sobre o que ele acredita que sejam algumas das responsabilidades de um líder técnico e colocou um link para um “Tech Lead Manifesto” escrito por Sam Newman em 2006:

A Tech Lead Should…

  • Ensure the creation of a clear and consistent technical vision for the project which can best result in a successful project
  • Ensure all members of the team have a proper understanding of the technical vision
  • Ensure that the technical vision updates to reflect new requirements
  • Track and resolve issues where the code deviates from the technical vision
  • Create an environment in which all members of the team can contribute towards the technical vision
  • Understand and address skills gaps in the team which would result in difficulties implementing the technical vision

A Tech Lead Should Not…

  • Tell everyone what to do
  • Necessarily be the best at everything
  • Write no code
  • Write all the hard code

Esse manifesto resume muito bem algumas características altamente desejáveis para líderes de times de desenvolvimento de software e é totalmente aderente a todas as metodologias ágeis, incluindo o Scrum.

Fica como complemento para a discussão anterior.

Test infection: por onde começar?

Sunday, March 30th, 2008

Fala GC!

Cara, o que voce faria se entrasse em um projeto para implementar umas melhorias, mas esse projeto não tivesse nenhum tipo de teste, o código não fosse testável e você soubesse que daqui a 3 meses ia sair do projeto? Você perderia tempo fazendo refactoring, implementando testes, configurando CruiseControl e tal, ou ia simplesmente ligar o foda-se???

Isso acontece pelo menos 32409 vezes todos os dias em algum lugar do planeta.

Os desenvolvedores acostumados a programar com testes têm uma dificuldade enorme de trabalhar em aplicações que não tem testes. A primeira coisa que os desenvolvedores mais experientes fazem quando pegam uma aplicação nova é olhar a base de testes. Por alí já é possível descobrir uma série de comportamentos e detalhes da implementação do sistema, bem como as intenções de quem o programou. Mas o que você faz quando cai de pára-quedas num projeto que não tem um mísero teste sequer? Você não pode deixar esse problema para outra pessoa? É você o infeliz que tem que resolver o problema e fazer a faxina?

Minha resposta para essa pergunta é bem simples: SIM, você é o infeliz que tem que resolver o problema.

<história>
Uma vez eu trabalhava numa empresa e meu chefe me pediu para fazer um protótipo de um sistema que integrava um website com um PABX para fazer determinadas tarefas. Como era um protótipo e eu só tinha duas semanas, eu fiz ZERO testes (e a aplicação funcionava por milagre divino). Só que para o meu azar, esse protótipo era para fazer uma demonstração para um cliente, que adorou a idéia e comprou na mesma hora! Como meu chefe achava que já estava parcialmente pronto e funcionando, meu prazo para terminar era de mais quatro semanas. Duas semanas depois eu estava desesperado por não conseguir avançar na aplicação e não conseguir fazer o negócio funcionar. Aconteciam bugs estranhos, daqueles que te fazem pensar que você está na profissão errada. Todos os dias eu me arrependia profundamente de ter deixado os testes para trás. Meu chefe ficou desesperado e colocou mais um desenvolvedor para me ajudar. No primeiro dia ele me perguntou: “GC, onde estão os testes para eu dar uma olhada?”. Er.. bom… não tinham testes… E eu fiquei totalmente desmoralizado, fui humilhado, massacrado e apanhei quase até a morte.
</história>

Hoje em dia não abro mão dos testes. Se você entregar uma aplicação que não funciona, a culpa é sua! Então, faça tudo que é possível para garantir que tudo esteja funcionando.

Finalmente, respondendo o e-mail do meu amigo acima (que não posso dizer o nome porque não tenho permissão), eis algumas dicas para você não ficar em maus lençóis:

Dica número 1: faça sempre o melhor que puder! Mesmo que você ache que vai ficar 2 semanas ou 3 meses em um projeto, seu gerente pode mudar de idéia e você pode acabar ficando bem mais tempo do que isso. Então, tire essa idéia da cabeça já e comece a se preocupar com os testes. E mesmo que você com certeza absoluta só fique 3 meses, como que você vai sair de cabeça erguida e com a certeza de que o que você fez está funcionando se você não tem os testes para comprovar?

Dica número 2: conserte as janelas quebradas. Se alguém chega na sua casa e metade das janelas estão quebradas, então não tem muito problema se quebrar mais uma. Porém, se todas as janelas estiverem impecáveis, quebrar uma janela é péssimo! Siga este mesmo princípio para o seu código, não tenha janelas quebradas. Se você tiver 90% de cobertura de testes, todos eles forem impecáveis e nenhum falhar no CruiseControl, o próximo desenvolvedor que chegar se sentirá na obrigação de manter tudo funcionando da mesma forma, porque esta é a cultura do projeto. Já se todos os testes estiverem quebrados ou não houverem testes, não faz a menor diferença.

Dica número 3: não abraçe o mundo com as pernas! Não precisa refatorar a aplicação inteira de uma vez, até porque você corre um grande risco de tudo parar de funcionar e você ser demitido, além de que não vai conseguir implementar as features. Neste caso, minha estratégia seria refatorar o código na medida que precisasse implementar as features. Faria o ciclo normal de TDD: implementaria os testes fazendo refactor na implementação para torná-la testável, implementaria a feature, garantiria seu funcionamento e depois um novo refactor para deixar tudo bonito.

Dica número 4: get them Test Infected! Faça um workshop com os outros desenvolvedores do time e mostre para eles a importância de escrever testes. Ensine-os a usar o CruiseControl, JUnit, JMock, injeção de dependência e tudo mais que for necessário para que os testes aconteçam. Mesmo que você “perca” dois ou três dias de trabalho, com certeza ganhará muito mais desse dia em diante.

<piada>
Dica número 5: só por via das dúvidas, para ajudar nos momentos de fraqueza, coloque alguém para te vigiar em tempo integral. O “Dijkstra is watching” é ótimo para isso, tenha ele sempre por perto.
</piada>

Rio on Rails

Tuesday, October 23rd, 2007

Logo Rio on RailsNo início de dezembro teremos um evento bem legal no Rio: o Rio on Rails. O evento será realizado no auditório do SENAC, na Rua Santa Luzia, 735 – o mesmo local onde são realizadas as reuniões do RioJUG.

Ainda não foram divulgados os tópicos do evento mas considerando os palestrantes podemos esperar muita coisa sobre Rails (obviamente) e desenvolvimento ágil.

O evento terá participações de Fábio Akita, Carlos Eduardo, Ronaldo Ferraz, Danilo Sato, Demetrius Nunes e a equipe da ImproveIt.

Fique ligado e faça sua inscrição voando porque serão poucas vagas!

Scrum Rules Cheat Sheet

Monday, October 22nd, 2007

Baseando-se na sua experiêcia e aprendizado, Mishkin Berteig criou uma lista das principais regras para implementação do Scrum. Para quem já conhece todos os conceitos envolvidos, esta lista de regras pode ser um resumo útil para auxiliar na implementação da metodologia.

Veja a Scrum Rules Cheat Sheet no site, ou se preferir, veja a versão em PDF para download.

Para que você vai usar isso?

Tuesday, September 4th, 2007

Quando você se reune com seus usuários para definir um sistema é muito comum que alguém apareça com requisitos que não fazem o menor sentido e que não agregam o menor valor para o software.

Uma vez fazendo levantamento para o desenvolvimento de um sistema alguém me pediu para mostrar em algum lugar da tela a quantidade de pessoas logadas. Tá, eu confesso que era uma coisa relativamente simples de ser feita. O que acontece é que no meio de tantas coisas realmente importantes fazer aquilo me parecia completamente estúpido e inútil.

Então, tentando espremer o usuário, fiz aquela pergunta clássica: “e para que você vai usar isso?”. Normalmente o cara responde alguma coisa vazia como: “eu preciso saber quantas pessoas tem logadas no sistema para ver se tem um número bom de pessoas trabalhando”. E você fica sem saber o que responder e acaba aceitando.

Segundo Scott Bellware, uma forma eficiente de resolver este problema é perguntar para o usuário da forma correta. Ele escreveu um post no Code Better sobre como utilizar uma abordagem de behaviour-driven development para discutir funcionalidades de um sistema.

Neste caso, eu poderia ter perguntado para o usuário: “você poderia me descrever uma história com este requisito?”. Desta forma eu faria com que o usuário percebesse que nenhuma situação de uso real do sistema iria requerer que tal funcionalidade existisse. Na verdade este é o benefício principal de Behaviour-Driven Development. A idéia é que pensando na forma como o software irá se comportar você consegue perceber com mais clareza qual é o comportamento realmente necessário e não o que você imagina que seja necessário.

Desenvolver um sistema a partir de um comportamento necessário faz com que você desenvolva software que atende aos usuários. Já desenvolver um sistema a partir um dado que deverá ser apresentado pode fazer com que você desenvolva software inútil sem se preocupar ou entender o que realmente importa.

Parte da nossa missão trabalhando com desenvolvimento de software é guiar o usuário e fazê-lo entender o que ele realmente precisa, não o que ele acha que quer ou acha que precisa.