29
Nov 11

Backlog ready: gerenciando o risco do seu planejamento

Recebi o Juan Bernabó na Globo.com, para dar uma volta no nosso ambiente de desenvolvimento. O Juan se surpreendeu com um indicador que temos usado há algum tempo para gerir os riscos do planejamento (ou da falta dele), o Backlog Ready. Esse indicador foi criado dentro da Globo.com, pelo Danilo Bardusco, e não estava documentado em lugar nenhum fora da Globo.com – então espero que esse post sirva para esse propósito.

Motivação

Um problema comum em organizações ágeis é o fenômeno de esvaziamento do product backlog. Isso pode acontecer porque o PO entrou de férias, licença médica, ou porque o mesmo estava muito ocupado fazendo outras coisas (esse é um sintoma de um outro problema, assunto para outro post!). Quando isso acontece, o time normalmente fica ‘faminto’ por histórias. Vão para o planning sem histórias definidas, e o processo de planning fica realmente sofrido.

Além disso, é saudável que o time conheça o seu terreno alguns sprints à frente – mesmo que o backlog mude. Evita o FUD (fear, uncertainty & doubt – medo, incertezas e dúvidas) que normalente se instala quando o time não conhece o seu futuro de curto prazo, minando a motivação e o ambiente de trabalho.

O conceito de ready

Há algum tempo atrás, o Serge Beaumont criou o conceito de READY, em conjunto com o Jeff Sutherland. É basicamente um checklist que serve para identificar itens de backlog que estão prontos para entrarem no sprint. O Serge criou esse conceito para garantir que as histórias que vão para o sprint planning tiveram três perguntas respondidas: Why? (porque), What? (o que) e How? (como), e além disso são pequenas o suficiente e foram estimadas. Nas palavras dele:

 READY is when the team says: ‘Ah, we get it’ ”. […] In the end a User Story is READY if a team can implement it, and a Product Owner can prioritize it.

Baseado nessa definição, é possível criar o nosso próprio conceito de READY. Na Globo.com, uma história está READY quando:

  • Está escrita no formato de user-story (Como <ator> quero <funcionalidade> para <valor de negócio>
  • Foi estimadas pelo time utilizando planning poker
  • Possui valor de negócio
  • Está priorizada
  • Possui critérios de aceite

O objetivo é garantir o entendimento das histórias pelo time. Na definição do Serge, qualquer item de backlog que não se encaixa nessas características não é faz parte do Product Backlog – e sim de um Product Parking Lot, pois está esperando que time em conjunto com o PO terminem de entender e discutir a história. Esse conceito foi criado como um complemento da Definition of Done.

A mecânica

Eu estou sempre preocupado com o custo de coleta das métricas. É preciso ser o mais pragmático e crítico possível em relação à métricas, pois uma relação custo x benefício ruim pode minar completamente o propósito de uma medição – além de que os números podem ser manipulados (gamed).

Esta métrica tem um custo de coleta baixíssimo: é só contar a quantidade de pontos que estão no seu backlog no antes do planning de cada sprint (pois inclusive as histórias que vão para o Sprint Backlog ainda são backlog, pois ainda não foram entregues), registrar esse número, e seguir em frente. Tem o custo de alguns segundos de atenção ao quadro.

O backlog ready está acoplado à velocidade do time, então para que o mesmo funcione direito, você também precisa medir a velocidade do seu time. A velocidade do time é determinada pela média aritimética dos pontos entregues nos 3 últimos sprints. É uma métrica básica do Scrum, que você inclusive já deve coletar.

Por exemplo:

Sprint n: entregamos 43 pontos
Sprint n+1: entregamos 30 pontos
Sprint n+2: entregamos 45 pontos

Sua velocidade no Sprint n+2 será:
(43 + 30 + 45) / 3 = 39 pontos (desprezando os decimais).

O gráfico de velocidade desse time ficaria assim:

Gráfico da evolução da velocidade de um time

Considere que antes do planning de cada sprint, esse era o status do backlog desse time:

pré-Sprint n: 150 pontos
pré-Sprint n+1: 107 pontos
pré-Sprint n+2: 77 pontos

O Backlog READY é um indicador numérico, com uma escala percentual de 0% a 100%, indicando o volume de histórias que estão prontas para entrar no Sprint Backlog e serem desenvolvidas, onde:

  • 0% significa que não existe nenhuma estória em estado READY;
  • 100% significa que há um volume adequado de estórias bem conhecidas e entendidas pelo time;

Toda vez que o indicador está abaixo de 100%, é um sinal que o buffer de segurança está esvaziando e em breve o time pode ficar faminto, sem histórias para trabalhar. Hora de crescer o backlog!

Na Globo.com, convencionamos que 100% é o equivalente a 3 vezes a velocidade do time, ou seja, temos histórias bem escritas e conhecidas pelo time, suficientes para alimentar 3 Sprints. Menos que isso costuma gerar falta de visão de curto prazo, enquanto que mais do que isso costuma gerar desperdício e re-trabalho pelas mudanças inerentes ao negócio.

Portanto, é válido analisar o contexto do seu negócio e descobrir o número ótimo para o seu caso, de acordo com a sua realidade de planejamento, disponibilidade do PO, envolvimento do cliente etc.

A equação para cálculo desse indicador é:

equação para cálculo backlog ready

A fórmula acima definida é a que utilizamos na Globo.com. O número 3 destacado é o que define os três Sprints que convencionamos, e que define o mínimo do nosso backlog ready. Para o time utilizado no exemplo acima, essa seria a evolução do seu backlog ready:

evolução do indicador backlog ready ao longo de vários sprints

No exemplo acima, o backlog ainda estava num nível aceitável no Sprint 2, porém no Sprint 3 ele precisa ser urgentemente trabalhado.

O ministério da saude adverte: métricas podem causar estragos gigantes! Use com moderação!

Cuidado! Eu tenho quatro guias gerais a respeito de métricas que gostaria de compartilhar:

  1. Não seja escravo delas. As métricas devem trabalhar pra você, e não o contrário;
  2. Use o bom senso;
  3. Questione sempre a validade da medição. Porque e para que estou medindo?
  4. Números podem e sempre serão manipulados (gamed). Se vacine contra isso usando as regras anteriores.

Transformando isso num sistema pull

Uma forma simples de utilizar esse número é criar um sistema pull de manutenção de backlog. Nos times em que trabalhei, uma reunião de estimativa era disparada sempre que o número de backlog ready caia para abaixo de 90%.

E foi dessa forma que a métrica foi criada, e é assim que a utilizamos na Globo.com. Espero que seja útil para você também! Qualquer dúvida/sugestão ou comentário, por favor faça abaixo.


04
Sep 11

4o encontro Pernambucano de Gerenciamento de Projetos

Amanhã, dia 05 de Setembro de 2011, estarei palestranto no 4o encontro Pernambucano de Gerenciamento de Projetos, evento promovido pelo chapter do PMI de Pernambuco (PMI-PE). Fiquei surpreso e ao mesmo tempo feliz de ter sido convidado para palestrar neste evento – feliz pelo fato de ser Pernambucano (apesar de já morar há 2 anos no Rio), e surpreso por que nunca tinha me visto palestrando num evento do PMI, principalmente depois de 2005/2006, que enveredei minha carreira para a área de Gestão Ágil de Projetos.

O título da minha palestra será ‘Abraçe as incertezas: A Ilusão do Controle no Mundo Ágil’, falarei um pouco sobre o que realmente importa na gestão de projetos ágeis. A organização do evento me autorizou a gravar a palestra, então ela estará aqui no blog no mais tardar até quarta-feira, e os slides, no slideshare, como sempre!

Site do evento: http://www.scarduatec.com.br/pmipe2011/

Divulgação na mídia: http://ubas.us/qtVcxH

 


17
Mar 10

Desvendando o Scrum: Revista TI Digital

No ano passado, dei uma entrevista à Flávia Freire, da Revista TI Digital, sobre Scrum. Na época, eu ainda não estava trabalhando na Globo.com, mas o Guilherme Chapiewski, que estava na Globo.com a época, e o Danilo Bardusco, que é o nosso Gerente de Desenvolvimento, também foram entrevistados pela revista, juntamente com membros da comunidade Scrum Brasil, como  o Nelson Abu. Depois de alguns desencontros, finalmente consegui uma edição em papel da revista onde saiu esta matéria, mas até então não havia conseguido a matéria em formato digital – até que hoje pela manhã me deparei com o PDF da matéria, publicado no próprio site da revista. A matéria ficou muito rica, e acho que vale à pena utiliza-la como referência, principalmente para quem está começando e tentando entender do que se trata o Scrum.

Link alternativo para download: [download id=”5″ format=”1″]


02
Mar 09

Penalidades por atraso nas reuniões de Daily Scrum

Os maiores problemas quando falamos sobre as reuniões de Daily Scrum são assiduidade e pontualidade. Brasileiro, em geral, tem um problema incrível quando falamos em horários. É muito raro chegar à uma empresa e ter uma reunião marcada começando e terminando no horário certo. Na realidade, até retiro o que eu disse. Não só Brasileiro, mas em qualquer país é difícil conseguir fazer as coisas acontecerem no horário certo (ok, em alguns mais difícieis, em alguns menos…) – Mas em geral, o ser humano tem um “coeficiente” de procrastinação altíssimo…

Vendo este cenário, já rolaram na lista Scrum Development, do Yahoo! Groups, inúmeras discussões a respeito do tópico. O que fazer para garantir a realização das cerimônias no horário certo? Quais penalidades aplicar aos atrasados/ausentes?

O James Brett, do site ScrumMaster.com.au, escreveu um artigo bem interessante sobre essas penalidades para os atrasados – que traduzo aqui pois acredito que será de grande ajuda, pois pelo menos a mim o artigo ajudou bastante. Vamos lá:

Penalidades de atraso nas daily Scrums

Um componente chave do processo do Scrum é a reunião diária, o Daily Scrum. Esta reunião deve acontecer no mesmo local/horário todos os dias, de preferência próximo ao espaço onde o time trabalha, onde o taskboard do time fica. Cada membro do time responder à três perguntas nesta cerimônia:

  • O que você fez desde a última reunião?
  • O que você vai fazer até a próxima reunião?
  • Você tem algum impedimento?

O daily scrum permite que o time entenda o que cada membro está fazendo, e é essencial para o trabalho em equipe necessário para a entrega da Sprint. Eu já experienciei também um time que quis adicionar uma quarta questão à lista das três acimas, que era “Qual a sua confiança (nota de 1 a 10) de que o time irá entregar o objetivo da Sprint?”. Isso ajuda o ScrumMaster à identificar problemas escondidos no time.

Da mesma forma, é usual que o time escolha as penalidades por atraso para os membros que, ou chegaram atrasados na daily scrum, ou não compareceram à reunião. É essencial que o time decida a sua própria penalidade, e quais “desculpas” são aceitáveis para chegar atrasado (se houver). Um dos meus times passou por este processo recentemente, e como um time chegou a um acordo: qualquer um dos atrasados iria suprir o restante do time com Donuts no próximo dia, como uma forma de “punição”. Aí, um dos membros do time protestou: “eu não vou entrar nessa! E se eu ficar preso por causa de uma solicitação do suporte?”. Então o time debateu mais um pouco, e definiu o que era e o que não era admissível como desculpas por atrasos. Depois disso, todos concordaram que a penalidade deveria ser trazer donuts. Um acordo com 100% de adesão foi feito entre o time.

O ponto importante para lembrar é que o time é que deve chegar à penalidade, e que TODOS no time devem se comprometer com antecedência à obedecer às regras do time e pagar as penalidades por chegar atrasado. Pessoas de fora do time não devem forçar penalidades ou condições no time, pois dessa forma o time não terá mais o compromisso, um princípio-chave em tudo que é relacionado ao Scrum.

Para finalizar, eu estava interessado em ouvir quais penalidades haviam sido implementadas no mundo afora, apenas por diversão. Eu coloquei esta questão no user-group de Scrum do Yahoo! Grupos, e recebi diversas respostas, que combinei com as que eu presenciei e compilei a lista abaixo.

Várias penalidades por atraso

  • Cantar uma música de preferência do time (Noite feliz, My Way, Balão mágico, etc)
  • Donuts
  • Usar orelhas de coelho cor de rosa e brilhantes por 20 minutos
  • Usar um cartão “Eu me atrasei” por algumas horas
  • Pagar uma penalidade de R$ 2,00. Colocar numa caixa selada, e depois de alguns meses, ao abrir a caixa, o ScrumMaster dobra a quantia e o time gasta em conjunto. Se estiver vazia, o Scrum Master parabeniza o time, colocar R$ 100,00 na caixa, e o time decide como gastar a grana: sorvete, pizzas, ingressos para festas, cerveja, uma nova máquina de café, etc.
  • Encher o refrigerador do time com caixas de sorvete
  • Fazer a daily Scrum em um escritório vazio, e trancar a porta no horário combinado para início. A penalidade de perder a Daily Scrum e se sentir de fora do time é tão grande que as pessoas param de se atrasar.
  • Humilhação pública sem pena, com muita risada 🙂
  • Nossos desenvolvedores são muito anti-sociais, comparados ao restante da empresa. Então, quando eles se atrasam, nos forçamos que eles andem por aí e colham relatos de experiência ou melhoria com nossos usuários. Isso só aconteceu uma vez, desde então ninguém nunca mais se atrasou!

Um grande obrigado a todos que responderam a thread original no Yahoo Groups!

Brincadeiras à parte, vale à pena dar uma olhada nas penalidades, e usar esse artigo como um “guideline” sobre como ter sucesso nas suas Daily Scrums.

Boa sorte!

Para o artigo original, em inglês, clique aqui.


22
Feb 09

Daily Scrum Meetings – você sabe mesmo fazer?

O Daniel Wildt, do grupo de metodologias ágeis do Rio Grande do Sul, publicou no blog um artigo com um vídeo um pouco antigo, mas bem legal, onde vários CSTs (incluindo o Boris Gloger) simulam uma Daily Scrum ruim, fazendo um teatrinho. Confiram o vídeo abaixo (bem divertido, por sinal), e o post no blog do XP-RS aqui.