TDD mais importante que tudo
No dia 18/09/2010 apresentei a palestra "TDD direto das trincheiras" em João Pessoa, no evento "Agilidade Paraíba" promovido pelo grupo Scrum-PB. O público era bastante jovem e poucos conheciam ou usavam TDD. Espero ter conseguido despertar a curiosidade de várias pessoas, mas na verdade eu ainda fico bastante chocado como tão poucas pessoas/empresas adotam TDD. Como eu coloco no último slide da minha apresentação, "TDD é mais importante que tudo".
A prática do TDD viabiliza economicamente o design evolutivo e em última instância o próprio desenvolvimento iterativo incremental. Através principalmente do TDD é que a curva de custo da mudança pode ser suavizada.
Usando TDD as pessoas perdem o medo de fazer refactoring para remover código duplicado ou para evoluir funcionalidades existentes. O uso do TDD induz ao programador ter um melhor entendimento do negócio. Além disso, usamos menos o debug (que toma um baita tempo), localizamos mais rapidamente os bugs e enfim, escrevemos um código de melhor qualidade.
Se você não usa TDD, sugiro que avalie melhor esta prática. Não é fácil fazer a transição. Leva tempo e esforço, mas quando a ficha cai, você não vai querer trabalhar de outra forma. Estude, se prepare bem. Se precisar de ajudar é só chamar 
Como brinde, deixo aqui um link com uma introdução ao TDD bastante legal. Boa Sorte!
Agilidade Paraíba 2010
No dia 18/09/2010 vai acontecer o evento "Agilidade na Paraíba 2010", organizado pelo Grupo de Usuários Scrum Paraíba. Vou participar deste evento apresentando "TDD direto das trincheiras".
Acho muito legal que TDD venha gerando cada vez mais interesse, especialmente em nossa região. Isso porque eu digo e não me canso de repetir que TDD é a prática relacionada com engenharia de software mais importante do universo ágil. Através de TDD que você consegue suporte para design evolutivo, simplicidade e consequentemente desenvolvimento iterativo e incremental que DÁ CERTO! Nos vemos lá...
Para inscrições e mais informações, acesse: http://scrumpb.org
Café Ágil
Sábado passado (dia 15/05/2010) participei do evento Café Ágil promovido pela ThoughtWorks Brasil no Centro de Informática da UFPE. Neste evento eu apresentei o trabalho "TDD Direto das Trincheiras", mesmo trabalho que já havia apresentado no evento Agilidade na Prática em Novembro de 2009. Naquela oportunidade, deixei pra fazer a apresentação em cima da hora e ficou bem nojentinha (veja aqui), desta vez pedi ajuda a Jinmi Lee, que deu uma reformulada no ppt. Vejam a diferença:
Para uma comunicação eficiente é necessário que tanto o contéudo quanto a apresentação sejam bem feitos. Apenas com a união desses dois fatores será possível passar a mensagem de forma eficaz.
Voltando ao evento, as apresentações de Paulo Caroli e Jim Webber foram ótimas e a participação do público foi bem legal. Bastante interessante também a mesa redonda (a mesa era retangular mesmo), que além da minha presença e a do Paulo, ainda contou com a participação de Luciano Felix (Provider Sistemas), Cristine Gusmão (UFPE) e Alexandre de Vasconcelos (UFPE). Parabéns a todos pela organização e espero que tenha mais eventos desse nível por aqui.
TDD direto das trincheiras
Essa foi a apresentação que fiz no evento "Agilidade na Prática" em 30/11/2009. Este evento foi promovido pelo SPIN Recife.
Sprint Planning Meeting II ou Sprint Design Meeting?
Qual o principal objetivo da reunião de Sprint Planning Meeting 2? 
Em muitos lugares você poderá encontrar uma resposta simplista para essa pergunta: O objetivo é dividir os itens do product backlog em tarefas de no máximo 8 horas (ou 16 em algumas fontes). Mas dividir como?
Durante a Sprint Planning Meeting 1, o time e o product owner selecionaram de comum acordo alguns itens para serem trabalhados durante o sprint em questão. Para chegar neste ponto, o time teve que discutir em mais detalhes cada item de backlog, tirar eventuais dúvidas e revisar algumas estimativas. Em função disso, podemos perceber claramente que se trata de uma reunião para discussão e esclarecimento dos requisitos. Até este momento estamos apenas trabalhando em cima do domínio do problema, ainda não entramos na solução.
No Sprint Planning Meeting 2 a cuíca muda o tom. Se pensarmos que o objetivo principal é apenas dividir os itens em tarefas, vamos estar na verdade apenas dividindo o problema, mas aqui precisamos na verdade é dividir a solução. Para chegar na solução o time vai ter que fazer design (análise & projeto), que é exatamente o objetivo desta reunião.
Agora, será que faz diferença? Será que dividir o problema é diferente de dividir a solução? Vejamos alguns exemplos:
Considere o item de backlog chamado Login do Usuário. Algumas possíveis tarefas para Sprint Planning Meeting 2 sem foco em design:
- Implementar tela de login
- Implementar serviço de autenticação
Muito bom, com esse conjunto de tarefas eu posso fazer o item de backlog, o problema é que agrega muito pouco e para efeito de planejamento é desastroso, afinal o time não sabe exatamente o que vai fazer em cada uma dessas tarefas. Tudo vai ser descoberto apenas na hora H. Neste cenário observamos que é muito comum a criação de diversas novas tarefas durante o sprint.
Vamos ver agora que tarefas eu poderia criar se tivesse realizado a reunião com foco em design:
- Criar tela de login
- Selecionar lib js para chamar serviço de autenticação via ajax (supondo que é ajax e uma lib ainda não foi selecionada)
- Criar serviço de autenticação
- Criar query com login=login e senha=senha
- Criar classe de Usuario (campos: login e senha)
- Criar método para criptografar a senha (escolher método)
- e por aí vai...
O que acontece no novo cenário é que a equipe se aprofundou na solução. Neste caso o time pôde definir melhor o escopo de cada tarefa, antecipar dúvidas e eliminar riscos. Mas afinal para que serve o planejamento?
Resumindo:
- Sprint Planning Meeting 1 = Requisitos
- Sprint Planning Meeting 2 = Design
E ainda assim: Sprint Planning Meetings = planejamento.
Entenda os príncipios por trás das práticas
Como todo mundo já percebeu, Scrum virou moda. A maioria das empresas dizem que usam Scrum, porém poucas são REALMENTE ágeis. A principal razão pela qual isso acontece é porque as pessoas dessas empresas ainda não assimilaram os príncipios que estão por trás dos métodos ágeis. O entendimento e a adoção desses príncipios são fundamentais para ter sucesso com Scrum. Acredito que esse fenômeno aconteceu de forma similar com a adoção do RUP. Aqui está o material de uma apresentação que fiz sobre esse assunto.
Chocolates e Scrum
Muito legal o post "Chocoholic Agile Adoption Strategy". Nesse post o autor fala sobre a experiência de criar uma nova escala para realizar estimativas das user stories. Para enfatizar o caráter abstrato da estimativa de tamanho, eles criaram uma escala de chocolates. Quanto maior a barra de chocolate escolhida (Furry Friends, Chunky, Half Block, Family Block, Half Slab ou Slab), maior o tamanho da estória.
Por aqui estamos utilizando story points mesmo, porém uma de nossas equipes inovou ao criar uma premiação para algumas das tarefas, veja só:
Estimar em chocolates é legal, comê-los é ainda melhor... Imagine juntar as duas práticas ))
Ensinando e Aprendendo
Um de nossos maiores clientes solicitou que houvesse um repasse de conhecimento sobre scrum. E lá fui eu para Brasília com meu treinamento scrum de 8 horas. Estive em Brasília poucas vezes, mas desta vez pude presenciar um fato histórico: na terça (28/10/08) foi dia mais quente da história. Que sorte Aqui em Recife faz calor, mas pelo menos temos um ventinho... lá foi diferente... nem uma brisa... foi duro de aguentar.... Foi difícil também ter que ministrar este treinamento para 4 turmas (foram 72 pessoas ao todo) em 4 dias consecutivos com esse calor e gripado. Foi um teste de resistência... Mas deixando isso de lado, vamos as lições que aprendi dessa aventura:
- Cada turma é diferente. Eu estava acostumado a treinar o pessoal aqui da empresa, onde é tudo mais homogeneo. O ambiente e as conversas do dia a dia fazem com que não tenha muita novidade e voce já possa antecipar as polemicas. Lá foi muito diferente. Cada turma era composta de pessoas com perfis diferentes, ocupando cargos diferentes, trabalhando em departamentos diferentes... Tive que me virar. Cada dia o pessoal debatia e criavam polemicas diferentes, e eu tinha que ajustar o treinamento a todo momento. Acho que quando alguém de uma turma for conversar com outro de outra turma, vão achar que assistiram treinamentos diferentes... hahaha... No final, deu tudo muito certo e acho que a mensagem foi bem passada e assimilada. Foi uma experiencia fascinante.
- Não existe exame anti-doping para instrutores. Ainda bem... estava lá a base de vitaminas, analgésicos, antitérmicos, antinflamatórios, anti-isso, anti-aquilo... se houvesse anti-doping eu ia ser suspenso.
- Conversei com algumas pessas em cargo de chefia, que não são necessariamente da área que me diziam que tinha alguma coisa muito errada em passar mais de 1 ano levantando e detalhando requisitos e na hora de implementar ainda surgem dúvidas e modificações toda hora. Preciso acrescentar alguma coisa?
- Muitas pessoas que não conhecem, acham que scrum é uma coisa muito exótica, algo que pode ser usado para brincadeiras mas não para projetos sérios... temos que estar preparados para dar a informação correta e completa, para que a ficha caia.
- Nada supera exemplos reais, especialmente exemplos conhecidos pela audiencia. Como trabalhamos para esse cliente há algum tempo, e temos alguns projetos onde só fazemos a implementação do sistema (CASCATA PURA), pude citar exemplos reais, que eles viveram e conhecem muito bem. Claro que neste processo voce vai criticar a forma que eles conduzem seus projetos, mas não devemos ter medo de ferir seus sentimentos. Estamos tentando fazer o bem.
- Para todo problema existe solução. Muitas pessoas passam a vida toda criando obstáculos para evitar a mudança. Nossa missão é remove-los.
- Com certeza aprendi outras coisas, mas agora já escrevi demais... Até a próxima!
Novo Scrum User Group e Genchi Genbutsu
Compareci ao kickoff da criação do grupo Scrum User Group Recife na quarta-feira passada. Acho muito interessante esse tipo de iniciativa, pois já é comum haver colaboração virtual através da internet, mas nada substitui uma oportunidade para discussões e troca de experiências cara a cara. O próximo encontro já está marcado para o dia 5 de novembro, e eu estarei lá colaborando.
Durante o evento, houve uma apresentação de Boris Gloger sobre as dificuldades de se adotar Scrum, e enquanto eu escutava, acabei por reviver os primeiros momentos da implantação aqui na empresa. Como já falei em post anterior, eu fui o responsável em implantar o scrum, e tudo começou com um projeto piloto e 1 equipe. Tudo tava indo muito bem, os conceitos estavam sendo bem assimilados e o trabalho ia de vento em popa, porém os bons resultados criaram uma imensa pressão nos outros projetos. De repente, todas as equipes queriam usar scrum. A pressão foi tão grande que não deu para conter a ansiedade do povo. Em um piscar de olhos tive que treinar quase 100 pessoas (não tínhamos orçamento para contratar Boris...) e todo mundo passou a usar scrum. Como eu só era um (ainda sou apenas um), não deu para acompanhar o dia a dia de todas as equipes e nem todas as equipes conseguiram experimentar o sucesso da equipe piloto.
Com esta situação, decidi adotar uma nova estratégia de acompanhamento utilizando um dos princípios do TPS (Toyota Production System) chamado "Genchi Genbutsu" que em tradução livre significa vá até lá e veja você mesmo. A minha idéia é entrar em cada uma das equipes, fazer parte dela por 1 ou 2 sprints e ajudar a fazer os ajustes necessários para transformar os insucessos em sucessos. Este processo vai ser bem demorado, mas acredito que vai deixar resultados mais sólidos. Já passei pela primeira equipe que estava com a moral nas canelas e juntos conseguimos virar o jogo. Estou agora na segunda equipe e estamos evoluindo bastante. O que eu aprendi com essa experiência é que cada equipe em cada projeto é um mundo novo. Não dá para ficar fazendo suposições ou criando boas práticas universais....
VÁ ATÉ LÁ E VEJA VOCÊ MESMO!
Entregue valor em todos os Sprints
Sempre fui fã das metodologias ágeis, sempre acreditei nos seus princípios. Passei um bom tempo tentando convencer as pessoas da minha empresa a adotar SCRUM, e só depois de muito esforço consegui sinal verde fazer o piloto. Depois dos bons resultados deste piloto, acabei sendo responsável pela implantação do SCRUM em toda a empresa. Com a experiência adquirida, passei a prestar consultoria para outras empresas. Hoje tive uma experiência interessante em uma dessas consultorias.
O cenário é o início do desenvolvimento de um novo produto. Como é o início, existe a necessidade de criar arquitetura e escrever um monte de código de infraestrutura. Todo esse trabalho ia levar pelo menos 2 sprints, mas sem entregar nada de palpável para o Product Owner. Mostrei a equipe a importância de entregar algo com valor de negócio desde o primeiro sprint, até porque não tem como provar que a infraestrutura está correta se não for construido nada em cima dela. Planejamos o primeiro sprint com uma parte de infra e algumas funcionalidades que utilizariam essa infra.
O início do sprint foi bem típico, a equipe bastante motivada pelas novidades e um Product Owner esperançoso, porém sem acreditar que receberia um pedaço do produto pronto em apenas 4 semanas. Hoje foi o dia do Sprint Review e ao ver que a equipe conseguiu fazer e entregou um pedaço do seu querido produto, o Product Owner falou todas as frases que a gente espera escutar no fim do sprint: "Era isso o que eu queria!", "Agora eu tenho algo para pegar, apertar e ver como vai ficar!", "Com isso eu posso dizer se vocês estão no caminho certo", "Agora eu posso trabalhar mais junto de vocês", "Quero ver o que vocês estão fazendo mesmo antes de acabar o sprint", ...
Missão cumprida. Product Owner engajado. Claro que não podemos deixar a bola cair, depois do primeiro sprint, temos que continuar a fazer entregas de forma contínua. Mas o Product Owner está engajado, tudo vai ser mais fácil.
Entregue valor de forma contínua e desde o primeiro sprint! Tenha fé!
In Scrum we trust.