Posts Tagged ‘XP’

Simplicidade

Saturday, August 30th, 2008

Há mais ou menos um mês terminei de ler o livro Presentation Zen do Garr Reynolds. O livro é muito legal e tem excelentes dicas sobre como fazer apresentações baseadas nos princípios Zen. O Garr trabalhou durante muito tempo na Apple fazendo design de apresentações e é fato que a Apple arrebenta nesse quesito. Depois de assistir apresentações que foram verdadeiros shows na Apple WWDC decidí ler o livro e tentar aprender alguma coisa sobre o que eles fazem.

Quando eu estava lendo o livro, um trecho de um capítulo que fala sobre os princípios de design acendeu uma lâmpada na minha cabeça e me fez atentar para uma coisa que acontece diariamente no desenvolvimento de software:

“Design can make things easier for the viewer or the user. Design is not decoration. If anything, design is more about subtraction than addition. Visually, we do not want to include too much, nor do we want to exclude too much. Generally, people err on the side of including too much visual information, which often results in clutter and confusion.

É verdade. Existe uma tendência grande das pessoas acharem que mais funcionalidades e complexidade é sempre melhor. As pessoas pensam exatamente como descreve o livro Getting Real da 37 Signals:

“Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they’re spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It’s an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can’t think ahead, they can only think behind. They don’t lead, they follow.

Transportando para o mundo do desenvolvimento de software, eu vejo que muitos desenvolvedores adoram entulhar seus códigos com todos os design patterns que já ouviram falar, adoram usar EJBs em qualquer coisa, adoram inventar seus frameworks malucos… Enfim, adoram fazer tudo que é complexo e trabalhoso. Assim como no design, entulhar o código com essas coisas só fazem ele ficar muito mais difícil de ser mantido e entendido!

Talvez um dos motivos disso acontecer seja que nem sempre o desenvolvedor tem senso de urgência e visão do negócio. Nem sempre ele entende que não dá para perder 3 dias fazendo um menu JavaScript que abre e fecha, ou passar 80% do tempo tentando encaixar design patterns no código, ou criar uma arquitetura com 36 camadas para diminuir o acoplamento. Essas coisas podem ser extremamente prejudiciais para o projeto, porque o cliente está esperando triplicar o faturamento e o número de visitantes do seu site e essas coisas não vão ajudar em absolutamente nada. A oportunidade de usar design patterns, criar camadas no software ou qualquer outra coisa surgirá naturalmente no decorrer do projeto. Se isso não acontecer, então simplesmente não os use.

Uma dica para descobrir se você ou alguém está fazendo uma coisa útil ou não é tentar responder a seguinte pergunta: “Qual problema será resolvido com isso?”. Ultimamente tenho feito essa pergunta para todo mundo e percebí que muito mais da metade das coisas não são justificáveis. É incrível como as pessoas criam coisas sem nenhum motivo, que só deixam o software mais complexo sem necessidade, tanto internamente (código) quanto externamente (interface).

Por isso eu gosto e recomendo trabalhar sempre com uma das regras básicas do XP. Independente de usar XP ou não, a simplicidade é uma ótima regra:

“A simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work. If you find something that is complex replace it with something simple. It’s always faster and cheaper to replace complex code now, before you waste a lot more time on it. Keep things as simple as possible as long as possible by never adding functionality before it is scheduled. Beware though, keeping a design simple is hard work.”

Se você é desenvolvedor e adora complicar tudo, pare de brincar de professor pardal e pense simples, ou é isso que vai acontecer com a sua empresa:

[Agile 2008 Conference] Henrik Kniberg: 10 ways to screw up with Scrum and XP

Thursday, August 7th, 2008

Gostei muito da apresentação do Henrik Kniberg “ensinando” 10 maneiras para arruinar seus projetos mesmo usando XP e Scrum. É óbvio que eu não quero acabar com os meus projetos, mas é legal debater sobre os erros mais comuns nas adoções de metodologias ágeis e seus motivos para poder evitá-los.

Uma coisa interessante é que o Henrik costuma usar com sucesso a mesma combinação de XP e Scrum que usamos na Globo.com. Não por acaso, tanto o seu livro Scrum and XP from the Trenches quanto a apresentação (mesmo quando ainda não tinha assistido) e o seu blog sempre foram boas fontes de referência para mim.

Resumidamente, as 10 maneiras mais comuns de arruinar projetos com XP e Scrum são:

  • Futilidades: debates homéricos sobre coisas como “vamos usar cartões ou post-its” quando o time sequer tem um P.O.! Os problemas devem ser atacados em ordem de importância. Além disso, a aplicação do processo não precisa ser perfeita desde o início. Good enough is good enough.
  • Definition of Done: muitos times não tem uma definição de pronto ou não respeitam essa definição. Isso não só é essencial como também é preciso que o cumprimento desta definição esteja dentro do controle do time.
  • Velocidade: não é conhecida, usada ou é muito variável ao longo das iterações.
  • Retrospectivas: não há retrospectivas e o time não evolui suas práticas ao longo do tempo aproveitando-se dos aprendizados obtidos nas iterações.
  • Comprometimento do time: time é cobrado e sempre culpado por erros em estimativas. Isso faz com que eles sempre se comprometam com menos do que podem fazer, com medo de serem culpados novamente.
  • Débito técnico: é totalmente ignorado e só cresce ao longo das iterações.
  • Trabalho em equipe: não há trabalho em equipe e existem tarefas fixas para determinadas pessoas, o que faz com que várias histórias sejam implementadas em paralelo.
  • Product Backlog: não existe ou não está priorizado corretamente.
  • Integrações da base de código: não existe um branch onde o código pode ser lançado em produção a qualquer momento e a gerência da base de código não é agil.
  • Sprint Backlog/quadro de tarefas: não existe, está longe do time, é muito complicado ou não é usado durante o Daily Scrum e atualizado diariamente.

É óbvio que essas não são as únicas maneiras de fazer besteiras em projetos com XP e Scrum e pode até ser também que tenham algumas maneiras mais “eficazes” que essas. No entanto esses problemas são muito comuns e acho que por isso mereceram destaque na apresentação.

Você pode encontrar os slides da apresentação no site do Henrik Kniberg. Esses slides são de uma apresentação um pouco mais antiga mas não há muitas diferenças.

[Agile 2008 Conference] Mary Poppendieck: The five dimensions of a system

Wednesday, August 6th, 2008

Agile 2008 - Mary PoppendieckPela primeira vez tive a oportunidade de assistir uma apresentação da Mary Poppendieck, e devo dizer que fiquei impressionado pela qualidade da apresentação… A mulher é simplesmente uma enciclopédia humana!

A Mary começou falando sobre histórias de “plank roads” (estradas de tábuas de madeira). Há muito tempo, quando todas as estradas eram de terra e cheia de buracos, alguém teve a idéia de fazer estradas de tábuas de madeira. Os benefícios foram muitos e enormes para a época: os transportes ficaram muito mais rápidos, o desgaste dos carros ficou muito menor, e por aí vai. Como essas estradas tinham um custo muito alto para serem produzidas, estimou-se que seriam necessários dez anos para que elas se pagassem. No entanto, quando as estradas ficaram com cinco ou seis anos começaram a se deteriorar, e era seria necessário fazer uma grande reforma para que elas voltassem a ser usáveis. Desta forma as estradas de tábuas se mostraram um péssimo negócio, pois com esse ciclo de implementação e manutenção jamais se pagariam. E aí a Mary levantou uma questão: assim como acreditava-se que as estradas de tábuas de madeira resolveriam todos os problemas do mundo até que os pontos negativos foram percebidos, será que o desenvolvimento ágil também não é uma estrada de tábuas e a qualquer momento vamos achar seus problemas?

Isso foi o gancho para ela mostrar várias histórias de estradas de tábuas, ou seja, histórias de coisas que acreditava-se que eram excelentes mas que depois foram mostrando seus problemas. Ela citou vários exemplos desde o waterfall até as ferramentas RAD, e levantou vários pontos sobre porque essas idéias fracassaram.

O que estamos tentando fazer hoje com desenvolvimento ágil é uma tentativa de resolver vários desses fracassos que tivemos em experiências passadas. A experiência com esses problemas e o entendimento das suas causas fez com que nascessem várias das linhas de desenvolvimento ágil que temos hoje como o XP, Lean Software Development e Scrum. Ainda acredita-se que o desenvolvimento ágil está no caminho de resolver vários problemas, portanto, respondendo à pergunta inicial, na opinião da Mary ainda não existem evidências de que o desenvolvimento ágil é uma “estrada de tábuas”.

Para encerrar, a Mary falou das cinco dimensões de um sistema e algumas questões sobre essas dimensões. Se você responder sim para todas essas perguntas (ou pelo menos a maioria), você está no caminho certo para desenvolver software de qualidade, de forma eficiente e que atende aos seus clientes.

Motivo/Razão do sistema

  • Os especialistas técnicos estão sempre atualizados com o objetivo geral do sistema?
  • Os técnicos do time vão checar por sí mesmos qual é o verdadeiro problema que o sistema deverá resolver?
  • Existe um líder técnico que é responsável por atingir o objetivo do sistema e que guia o time tecnicamente caso necessário?
  • Existem ciclos de aprendizado para descobrir se o sistema está servindo para o que se propõe e melhorá-lo de acordo com os objetivos?

Estrutura

  • O time tem uma boa visão do todo sobre o que eles estão produzindo, sobre a empresa e sobre como o seu trabalho se encaixa no todo?
  • Existem ciclos de aprendizado que munem os desenvolvedores com feedback sobre o uso do sistema?
  • Os desenvolvedores menos experientes são treinados e supervisionados para garantir que eles produzirão código de boa qualidade que incorpora a aprendizagem de erros cometidos anteriormente?
  • O trabalho é revisado por alguém apropriado?

Integridade do sistema

  • A integridade do sistema é parte integrante do desenvolvimento, e quando ele é finalizado pode-se assumir que o sistema já está completamente testado?
  • O sistema é desenvolvido de tal forma que é necessário um tempo desprezível para merges e testes no final?
  • As falhas são raras e são investigadas a fundo para descobrir padrões que podem servir para resolver e previnir problemas similares no futuro?
  • Esse conhecimento é capturado, consolidado e disseminado de uma maneira efetiva?

Tempo de vida do sistema

  • O tempo de vida e possíveis futuras modificações são considerados no projeto e desenvolvimento do sistema?
  • As pessoas que vão operar o sistema estão envolvidas no seu projeto?
  • O time de desenvolvimento permanece envolvido com o sistema a longo prazo?
  • As recompensas estão estruturadas de forma que desenvolver um sistema robusto que funcione bem ao longo dos anos é o comportamento mais encorajado?

Resultados do sistema

  • O sistema atinge muito bem o seu objetivo e os clientes conseguem antecipar algum retorno sobre o investimento?
  • O sistema atinge seus objetivos financeiros, dentro do seu custo e prazo planejados?
  • O sistema funciona sem falhas e há confiança que ele continuará assim?
  • O sistema atende plenamento àqueles que o operam, usam, suportam, mantém e criam algum valor com ele?

Você pode encontrar os slides da apresentação no site da Mary Poppendieck.

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.

[FISL 9.0] Desenvolvimento Ágil com XP e Scrum

Sunday, April 20th, 2008

Scrum no FISLOntem, no último dia do Fórum Internacional de Softwre Livre, fiz minha apresentação sobre Desenvolvimento Ágil com XP e Scrum, um assunto muito interessante que está se tornando cada vez mais popular nos últimos meses. A sala estava lotada, muita gente nem conseguiu entrar (fotos no Flickr)!

Infelizmente os 40 minutos não foram suficientes para falar tudo que eu queria/deveria e a apresentação ficou meio corrida… Então, como prometí, estou disponibilizando os slides da apresentação sob a licensa Creative Commons 2.5 para quem quiser dar uma olhada com mais calma.

Desenvolvimento Ágil com XP e Scrum
View SlideShare presentation or Upload your own. (tags: xp scrum)

Além disso, seguem alguns ponteiros para quem quiser estudar mais sobre o assunto:

Livros recomendados

Blogs sobre “Agile”, Scrum e XP

Links

XP complementa o Scrum

Monday, March 31st, 2008

As metodologias que conhecemos hoje em dia como “metodologias ágeis” se baseiam nos mesmos princípios e no manifesto ágil. Talvez seja por isso que muitas práticas dessas metodologias são muito parecidas ou até mesmo iguais, só mudando seu nome.

Estou falando mais especificamente de Scrum e eXtreme Programming (XP). O Scrum, particularmente, é um framework focado principalmente em planejamento e gerência. Já o XP é mais focado em práticas de desenvolvimento. Mesmo assim, várias práticas são coincidentes entre Scrum/XP como sprint/desenvolvimento iterativo, daily scrum/daily meeting, sprint planning/planning game, e por aí vai.

A principal diferença que vejo entre as duas é que Scrum não te diz nada sobre práticas de desenvolvimento de software ágil, até porque você pode usar Scrum não só para fazer sistemas, como também para fazer carros, aviões ou bolos.

Minha visão é que as práticas de XP complementam o Scrum. Certas práticas de desenvolvimento, que vejo como essenciais para o bom andamento de um projeto de software, não fazem parte do escopo do Scrum mas fazem parte do XP, como desenvolvimento guiado por testes, integração contínua, build de 10 minutos, design incremental, metáforas, código coletivo, programação em par, refatoração e por aí vai. Por isso, não só acho que é bom fazer essa combinação, como acho que é bastante recomendável.

Mas para fazer isso não seria melhor usar XP puro ou invés de Scrum? Não vejo dessa forma. Scrum tem algumas diferenças que acho interessantes, como a retrospectiva fazendo parte do processo, uma grande ênfase na gerência do backlog (e em quem é o “responsável” por cada backlog: o P.O. pelo backlog do produto e o time pelo Sprint backlog) e a forma de planejamento e acompanhamento dos Sprints.

10 livros recomendados para desenvolvedores

Thursday, March 27th, 2008

No início do ano escreví um post sobre a importância de nós, desenvolvedores de software, lermos livros, que rendeu boas discussões. Depois disso recebí algumas mensagens perguntando quais são os livros que considero mais importantes para um desenvolvedor.

Bom, essa pergunta é complicada de responder. Primeiro porque eu ainda não lí todos os livros que deveria, e segundo porque cada pessoa tem seu gosto particular por tecnologias, processos, frutas e etc.

Então, resolví criar a lista dos 10 livros que eu particularmente mais gosto e que recomendo fortemente para qualquer desenvolvedor. Estes livros são alguns dos que mais me influenciaram a melhorar minha forma de trabalhar e programar. Além disso, coloquei link para os sites, blogs ou páginas de informações dos autores, caso alguém ainda não tenha:

Agile Software Development, Principles, Patterns, and Practices Agile Software Development, Principles, Patterns, and Practices
Robert C. Martin
Agile Software Development with SCRUM Agile Software Development with SCRUM
Ken Schwaber e Mike Beedle
Design Patterns: Elements of Reusable Object-Oriented Software Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson e John M. Vlissides
Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans
Extreme Programming Explained: Embrace Change (2nd Edition) Extreme Programming Explained: Embrace Change (2nd Edition)
Kent Beck e Cynthia Andres
Introduction to Algorithms Introduction to Algorithms
Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest e Clifford Stein
The Mythical Man-Month: Essays on Software Engineering The Mythical Man-Month: Essays on Software Engineering
Frederick P. Brooks
Patterns of Enterprise Application Architecture Patterns of Enterprise Application Architecture
Martin Fowler
Peopleware: Productive Projects and Teams Peopleware: Productive Projects and Teams
Tom DeMarco e Timothy Lister
The Pragmatic Programmer: From Journeyman to Master The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt e David Thomas

Infelizmente todos os livros são em inglês e nem sei se existe tradução. Se você não souber inglês, matricule-se urgentemente em algum curso porque saber inglês nesta área é muito importante!

Convido vocês a também fazerem suas listas e compatilharem seus livros preferidos :)

Você tem que ler os livros!

Tuesday, January 22nd, 2008

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert [...] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!

Cronogramas não funcionam

Tuesday, December 4th, 2007

Gantt ChartUma vez participei de um projeto que tinha um cronograma gigantesco tentando prever alguns meses de trabalho. Como de costume esses mega-projetos estão descritos em um também gigantesco Gantt Chart (se você não sabe do que eu estou falando veja a imagem ao lado).

O software que estávamos desenvolvendo era super específico e estavamos lidando com uma série de variáveis desconhecidas. Por exemplo, uma das partes do projeto era fazer integração com um sistema em C utilizando um protocolo não muito bem documentado baseado em HTTP. Para esta tarefa o gerente de projeto estimou “5 dias”. Quando eu perguntei como ele fez para estimar 5 dias sem nem mesmo saber exatamente como funciona o protocolo HTTP, a resposta foi a tradicional: “ah, eu chutei o valor pra cima porque não tinha muita certeza”. Como assim chutou pra cima? De onde ele tirou que isso é “para cima”? (só de curiosidade, no fim das contas a integração levou 3 semanas…)

Assumir que coisas deste tipo levarão tempos pré-determinados não funciona. O que esse gerente fez é tão tosco quanto um exemplo que tem no livro do Ken Schwaber: “para cada 4 classes, 3.5 designers completarão uma tarefa em 16 horas”. Acredite, esse é o tipo de “técnica” que os gerentes de projeto CMM Level 5 Certified utilizam para definir esses cronogramas malucos.

Além disso para poder fazer esse tipo de cálculo considera-se que as pessoas conseguem fazer uma determinada quantidade de trabalho por dia. Aí eu pergunto: isso leva em conta um dia de trabalho de um profissional bem treinado, bem qualificado, bem supervisionado, totalmente consciente, sem problemas pessoais, começando de manhã após um copo de café expresso? Ou seria um dia de trabalho de uma pessoa qualquer?

É por isso tudo que esses projetos sempre atrasam!

O que é preciso enxergar é que o processo de desenvolvimento de software não é uma linha de produção, não é executado por robôs e por isso não se pode determinar exatamente o que acontecerá durante um longo período de tempo. Além disso o processo envolve muita criação e não se pode garantir que os produtos finais sempre serão os mesmos ainda que aplicado o mesmo método de trabalho. Veja, produzir um carro, por exemplo, envolve uma série de atividades encadeadas e repetidas. Se você produzir 8.000 carros todos passarão pelo mesmo processo de fabricação e no fim do processo você terá 8.000 carros idênticos fabricados na mesma quantidade de tempo. Mas se você entregar o mesmo projeto de software para 8.000 programadores diferentes é totalmente possível que no final você tenha o mesmo problema resolvido de 8.000 formas diferentes e em prazos totalmente diferentes dependendo do nível de conhecimento, linguagem/tecnologias adotadas e etc.

No projeto que estou trabalhando atualmente fazemos diferente. Não definimos um prazo de entrega para o projeto inteiro mas sim a data de entrega dos Sprints (as iterações do Scrum). Fazendo análise e desenvolvimento de forma incremental os riscos são bem menores e é muito difícil alguém não levantar uma bandeira amarela antecipadamente caso uma estimativa esteja totalmente fora da realidade como a que eu citei. Mesmo não tendo muita flexibilidade nas datas de entrega acho que as pessoas se sentem mais confortáveis assim porque sempre estamos entregando alguma coisa e não atrasamos. O máximo que já aconteceu foi cortar a última história do Sprint (que voltou para o backlog e acabou nem entrando no Sprint seguinte), mas mesmo assim eu sinto que as pessoas ficam mais satisfeitas.

Sempre que esse papo vem á tona alguém pergunta: e como eu controlo o projeto? Quer ver um exemplo: sabendo que a nossa equipe faz Sprints de 15 dias nossos clientes decidiram que nós deviamos desenvolver determinadas funcionalidades chave para que agora no fim do segundo Sprint possamos fazer um release em produção de um software novo. Além disso eles participam ativamente das reuniões de planejamento dos Sprints e decidem quais tarefas serão feitas por nós. Quer mais controle que isso?!?

Por isso tudo que eu acredito que os cronogramas não são eficientes. Em alguns casos já é difícil planejar um Sprint de 15 dias, imagina projetos de meses ou anos? Fico me perguntando se esse projeto desse Gantt Chart (aquela imagem do início – achei no Google Images) foi entregue na data certinha que está especificada alí… Eu duvido!

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!