Archive for July, 2008

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!

Times Scrum trabalhando em vários projetos ao mesmo tempo?

Tuesday, July 29th, 2008

Antes de começamos a trabalhar com Scrum na Globo.com, era comum nossa equipe trabalhar em três ou quatro projetos ao mesmo tempo. Cada projeto era tocado por um time de mais ou menos uma a três pessoas e assim íamos fazendo as coisas.

Depois, com o Scrum, acabamos criando um time um pouco maior (de aproximadamente 9 pessoas) e, pela força do hábito, várias vezes nos pegamos com vontade de trabalhar em dois ou três projetos ao mesmo tempo. Talvez dê vontade de fazer isso para ter a impressão de que as coisas estão acontecendo, mesmo que lentamente, e que os projetos estão andando… Mas será que isso vale a pena? Vejamos.

Um dos principais objetivos do Scrum é entregar o maior valor de negócio para o cliente no menor tempo possível. Quanto mais dinheiro o cliente puder ganhar e quanto mais rápido, melhor. Sendo assim, o P.O. sempre deve pensar na melhor forma de maximizar o ROI – retorno sobre o investimento.

Falando de forma simplificada, o retorno sobre o investimento é calculado da seguinte forma: se você investe R$ 100,00 em alguma coisa e no final de um período você ganhou R$ 50,00 por conta deste investimento, você teve 50% de ROI. Sendo mais prático, quando você paga alguém para desenvolver um sistema para você, se você gastar R$ 100.000,00 e ganhar R$ 10.000,00 por mês, você está tendo um ROI de 10% por mês. Neste cenário o sistema se pagará em 10 meses, e a partir daí você passa a ter lucro.

Dito isso, vamos pensar numa situação hipotética. Imagine que um time de Scrum está trabalhando em 3 projetos ao mesmo tempo. Constata-se que no fim de 3 meses o time consegue finalizar e colocar em produção todos os 3 projetos:

Tudo ao mesmo tempo 1

Para conseguir entregar esses 3 projetos, o time teve que trabalhar paralelamente em todos eles, usando sempre 1/3 do tempo de cada Sprint para cada um dos projetos. Desta forma só depois de 3 meses o cliente poderia começar a faturar com seus novos produtos.

A pergunta é: não seria muito melhor se o time tivesse trabalhado de forma serial, focando todo seu tempo e esforço em apenas um projeto e entregando uma coisa de cada vez?

Tudo ao mesmo tempo 2

Trabalhando dessa forma, no fim do primeiro mês o primeiro projeto já poderia entrar em produção, antecipando o faturamento, gerando dinheiro (ROI) para o cliente mais rápido e diminuindo o tempo necessário para recuperar seu investimento. Neste caso, a antecipação da entrega de um dos projetos faz com que o cliente comece a faturar 2 meses antes do que poderia – sem dúvidas o ROI foi maximizado.

Voltando ao ponto inicial, é preciso resistir à tentação de querer trabalhar em vários projetos ao mesmo tempo. O melhor é focar no mais importante deles (ou seja, o que vai gerar mais lucro para a empresa) e trabalhar nele até o fim, passando em seguida para o próximo projeto mais importante e assim por diante.

Cara nova

Monday, July 28th, 2008

Depois de ser invadido 5 vezes de 5 maneiras diferentes, de vários dias de downtime e muita dor de cabeça com a DreamHost, finalmente tomei vergonha na cara e mudei tudo!

Migrei meu blog para um lugar que parece ser mais decente (eApps) e atualizei a versão do Wordpress para a 2.6, que é a mais nova disponível (era 2.1.3). Como meu tema antigo não funciona direito nessa nova versão fui obrigado também a mudar a fachada – dessa vez optando por um tema bem mais simples. :)

Obrigado à galera que me reportou os problemas por e-mail! Espero que agora o site funcione direito.

Cuidando para que o software não apodreça

Sunday, July 20th, 2008

Infeliz o sujeito que teve a idéia de comparar desenvolvimento de software a construção de prédios. Até hoje, em pleno século 21, algumas pessoas ainda acreditam que para fazer software você deve fazer exatamente como na construção civil: você deve ter “engenheiros” que fazem um grande projeto especificando exatamente como tudo vai ser, depois os pedreiros constroem e no final está tudo pronto e funcionando conforme a especificação.

Desenvolvimento de software não tem absolutamente nada a ver com construção!

No livro The Pragmatic Programmer, Dave Thomas e Andy Hunt fazem uma analogia muito mais apropriada: fazer software não é como constriur prédios mas sim como jardinagem. É muito mais “orgânico” do que “concreto”. Inicialmente você planeja muitas coisas para o seu jardim de acordo com as condições atuais de terra, clima, etc. Você precisa plantar as sementes, regar todo dia e cuidar para que as pragas não acabem com tudo. Você pode com o passar do tempo mover suas plantas de lugar para tirar vantagem de fatores como exposição ao sol, sombra ou até mesmo para fazer a rotatividade da terra. Você poda suas plantas constantemente e move alguns tipos de flores de um lugar para o outro para que o jardim fique melhor esteticamente. Se alguma planta cresce demais, pode ser que o espaço que você planejou para ela tenha ficado pequeno, e então é necessário movê-la de lugar. Enfim, não é uma coisa que você planeja, mas sim uma coisa que você tem uma idéia inicial e trabalha ao longo do tempo para fazer o melhor possível dentro daquela idéia.

Assim como o jardim, se o software não receber todos os cuidados necessários ele apodrece. Quando um software apodrece, é impossível implementar qualquer funcionalidade num tempo aceitável, é impossível colocar em produção sem que alguém tenha que ficar de babá, enfim, tudo passa a ser imprevisível. Nos piores casos passa a ser até impossível “tocar” no software, e esses monstros viram aqueles softwares que “se o servidor desligar ele não liga nunca mais”. E o pior é que isso acontece toda hora. Quantas vezes você já não pegou um projeto tão ruim, mas tão ruim que seria mais fácil fazer do zero do que consertá-lo? Isso é um sinal claro de software podre.

Para evitar que isso aconteça, o que se deve fazer é reavaliar a situação do software a cada história/funcionalidade implementada. Um bom desenvolvedor sempre avaliará se não é hora de mover algumas coisas de lugar, generalizar algumas funcionalidades, reescrever algumas porções de código e etc. – assim como faria um bom jardineiro. Isso deveria ser uma lei, não uma opção.

Os times ágeis trabalham com um conceito que é a “definição de pronto” (DOD – definition of done). A definição de pronto diz quando é que uma funcionalidade pode ser considerada pronta ou finalizada. Na minha opinião, para se considerar uma funcionalidade “pronta” é necessário no mínimo:

  • Desenvolver a funcionalidade
  • Testar unitariamente (melhor ainda se for fazendo TDD)
  • Testar a integração com outros componentes (quando for o caso)
  • Verificar se o build do projeto funciona sem erros e fazer o deploy em uma ambiente de produção simulado
  • Testar segundo os critérios de aceitação estabelecidos pelo cliente
  • Depois dos testes desenvolvidos e a nova funcionalidade passando em todos eles, avaliar a necessidade de fazer refactoring no novo código
  • Com a entrada da nova funcionalidade, avaliar a necessidade de fazer refactoring em algum módulo do sistema
  • Atualizar a documentação (quando necessário)

Pode parecer um exagero ou muito trabalho, mas não é. A questão é que você não pode deixar para fazer nenhum desses itens depois de 2 meses de desenvolvimento, você precisa fazer isso desde o primeiro dia! Quando você deixa para depois, você acaba acumulando o famoso débito técnico, e depois poderá ter que pagá-lo com juros, que poderão ser muito altos. O melhor é fazer aos poucos, a cada passo dado, porque desta forma o trabalho sempre será muito menor e não irá onerar o projeto. Mais uma vez fazendo analogias, é como câncer: você pode se previnir e tentar evitar que ele aconteça, ou você pode esperar ficar doente para depois ter que fazer uma arriscada cirurgia invasiva (e mesmo assim pode não dar certo, e aí perde-se o paciente).

Livro promissor sobre mock objects

Wednesday, July 16th, 2008

Steve Freeman e Nat Pryce do JMock, um dos meus projetos favoritos, estão escrevendo um livro entitulado “Growing Object-Oriented Software, Guided by Tests”. O assunto é muito bom e conhecendo os caras e os materiais que eles já publicaram (especialmente o artigo que fala sobre a experiência deles evoluindo uma DSL, baseando-se no desenvolvimento do JMock – “Evolving an Embedded Domain-Specific Language in Java”), acho que o livro promete.

O primeiro capítulo já está disponível no blog do JMock e chama-se “What’s the point of Test-Driven Development?”. A leitura é obrigatória e já dá uma pista do que está por vir.