Na última semana, participei de um painel na Campus Party Brasil 2016, intitulado “A Televisão na era do Streaming: como emissoras e novos players estão se adaptando”.
O painel contou com a participação de representantes de várias empresas de mídia do Brasil, onde discutimos a mudança de hábito, as possibilidades que as novas tecnologias abriram, e as estratégias e movimentos do mercado de streaming e mídia online.
Participaram do painel:
Igor Macaubas – product manager da Globo.com
Carlos Queiroz – original Content Manager da Fox
Luiz Bannitz – diretor de business affairs da Looke Filmes
Cassiano Fróes – gerente de tecnologias de novas mídias da Globosat
Na semana passada, fiz uma palestra falando um pouco do “beyond the basics” do Scrum na Globo.com. Gostaria de registrar os meus parabéns ao pessoal da comunidade Ágil de São Paulo, pois o evento esse ano foi show, muito bem organizado e com um excelente programa. A Globo.com, como não poderia deixar de ser, marcou forte presença!
Gravei a palestra em vídeo, mas como o auditório estava super cheio (ainda bem!) a filmagem não ficou legal :-(! Vou tentar salvar pelo menos o áudio e publico um podCast!
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:
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 é:
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:
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:
Não seja escravo delas. As métricas devem trabalhar pra você, e não o contrário;
Use o bom senso;
Questione sempre a validade da medição. Porque e para que estou medindo?
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.
Finalmente consegui organizar o post inteiro. Agora está completo, com vídeo, slides e fotos. A palestra foi ministrada no dia 25/11/2011 no Agilidade na Prática/Agile Tour Recife 2011, no auditório do Porto Digital:
Voltei hoje da Python Brasil [7] e confesso que fiquei positivamente impressionado com o evento. Apesar dos problemas com a Internet (nada é perfeito), o evento foi um sucesso! Foi muito bom ver que a comunidade Python está crescendo, com pessoas de todos os lugares do Brasil participando ativamente. Tive a oportunidade de reencontrar alguns velhos conhecidos, e conhecer novos rostos. O espaço da Globo.com (que foi um dos principais patrocinadores) no evento estava muito movimentado, principalmente durante os breaks quando organizamos um circuito de Lightning Talks no segundo e terceiro dias.
E que venha a próxima! O próximo evento que a Globo.com está patrocinando é a RubyConf, que também será em São Paulo nos dias 3 e 4 de Novembro, e também estarei por lá!
