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

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ó:

chocolates no taskboard
Estimar em chocolates é legal, comê-los é ainda melhor… Imagine juntar as duas práticas :)))

Ensinando e Aprendendo

cold fluUm 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:

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. Com certeza aprendi outras coisas, mas agora já escrevi demais… Até a próxima!

Novo Scrum User Group e Genchi Genbutsu

scrum user group recife
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

product ownerSempre 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.