Igor Macaubas — blog

Backlog ready: gerenciando o risco do seu planejamento

Tue, 29 Nov 2011 00:00:00 GMT

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.

Falhe cedo, aprenda rápido: porquê utilizar métodos ágeis para criar excelentes produtos

Mon, 05 Jul 2010 00:00:00 GMT

Artigo acadêmico de 2010, publicado sob a licença Creative Commons BY-NC-SA 3.0 BR. Baixe o artigo completo em PDF (13 páginas).

Resumo

Criar produtos de sucesso não é um trabalho fácil, principalmente quando se fala em software. O mercado está cada vez mais agressivo, e é extremamente difícil conciliar as necessidades de inovação, criação e excelência dentro de orçamentos e prazos apertados que regulam a indústria de desenvolvimento. Neste mundo cada vez mais intolerante à falhas, é contra-intuitivo afirmar que falhar, e saber lidar com as falhas, pode muitas vezes ser uma vantagem competitiva imensa.

Palavras chave: desenvolvimento, metodologias, inovação, gestão, agile, waterfall, comparação

Abstract

Create successful products is not an easy job, and even tougher when we talk about successful software. The market is more aggressive every day, itʼs very hard to conciliate the needs of innovation and creativity with the tight schedules and budgets that rules the development industry. In a world where failure is not an option, itʼs counter-intuitive to say that failure, and knowing how to handle it, creates indeed a huge competitive advantage.

Keywords: software, development, methodology innovation, management, agile, waterfall, comparison

Scrum é efetivo, e não eficiente

Tue, 03 Mar 2009 00:00:00 GMT

Li há um tempo atrás um post do Dan Rawsthorne (CSM, CSP, CST) no blog da Danube Technologies, falando sobre como ele se sentia desconfortável com algumas afirmações ou concepções incorretas a respeito do que é efetividade (effective) e o que é eficiência (efficient). Como o post foi na época de festas, terminei perdendo o timing e não consegui traduzir nem fazer nenhum tipo de comentário no blog, mas tinha deixado o post gravado aqui para depois escrever sobre ele. Fiz uma tradução abaixo (para ver o texto na íntegra, em inglês, clique aqui):

Eu gostaria de falar um pouco sobre uma situação recorrente que encontro nos times que faço coaching e nas classes que ensino. Quando falo com as pessoas sobre Scrum (e agilidade em geral), eu invariavelmente escuto coisas como “Eu gostaria que os meus times fossem mais eficientes”, ou “Estamos usando Scrum então poderemos ser mais eficientes”, e, é claro “nós seremos mais eficientes com esse processo e economizaremos algum dinheiro, certo?”

A resposta é “não”, ou “não imediatamente”, e isso normalmente nos leva a uma conversa sobre efetividade versus eficiência. Por definição, efetividade é “produzir um forte efeito”, que em software siginifica que nós entregaremos algo usável para o negócio. Eficiência, por outro lado, é “produzir resultados com pouco desperdício de esforço”, o que é uma coisa completamente diferente, e é um conceito totalmente não-agile.

Agora, vamos olhar para o que as empresas normalmente fazem (lembre-se que você é o que você realmente faz, e não o que você diz que faz). Em minha experiência, muitas empresas estão no negócio de “deixar as pessoas ocupadas” ao invés de estar no negócio de “produzir um produto”. Isto é, gerentes entram em mais apuros por suas pessoas “desperdiçarem tempo” do que por sua organização não produzir o produto correto. Isso é uma vergonha.

Agilidade é sobre ciclos de “verificação e adaptação”, ou seja, feedback. Quanto mais feedback você recebe, mais efetivo você será, mas mais esforço será também gasto. Isso é inerentemente ineficiente — estamos sacrificando efetividade de propósito. Para poder ser eficiente com agile, você precisaria de loops de feedback que te fornecessem as respostas que você precisa o mais rápido possível, e ter o quanto mais loops de feedback como possível. E nós não sabemos como fazer isso, sabemos?

Aqui é quando aparecem frases como “falhe rápido, falhe cedo”, que é uma forma de dizer que nós gostamos de ser eficientemente ágeis, aprendendo nossas lições o mais rápido possível. Okay, e não me importaria em ser eficientemente ágil, preferiria ao invés disso ser efetivo do que eficiente. E, na minha visão, não traz nenhum bem tentar ser eficiente até que você já saiba como ser efetivo. Isto é, se você pnão consegue produzir o produto certo todas as vezes (ou virtualmente todas as vezes) então não tente adicionar eficiências ao seu processo.

Para colocar de maneira bem simples, “Waterfall é eficiente — agilidade é efetiva”, e quando nós tentamos ser eficientemente ágeis, nós terminamos por introduzir uma falsa previsibilidade no nosso processo, que no final, termina nos ferindo.

É isso por agora, meus dois centavos, Dan.

Aprenda a cobrar pelo valor e o ingrediente secreto do Scrum

Fri, 06 Feb 2009 00:00:00 GMT

Há algum tempo atrás, em uma das discussões da lista Scrum-Brasil do Yahoo! Groups, escrevi uma mensagem que terminou virando post em um blog. Encontrei o post por acaso, em uma pesquisa pelo Google… e mensagem me chamou atenção, pois é uma das coisas mais difíceis que enfrento no meu dia-a-dia às voltas com desenvolvimento ágil de software: cobrar pelo valor, ao invés de horas. Interessante, hoje mesmo troquei idéias com um dos nossos consultores sobre isso: o mercado de desenvolvimento de software precisa mudar. Nós, desenvolvedores, não podemos cobrar pelo nosso trabalho como um trabalhador manual. Gosto de ilustrar com a seguinte estória:

Era uma vez uma empresa transportadora de cargas. Trabalhava transportando cargas bilionárias, petróleo e toda essa espécie de coisas. A menina dos olhos da empresa era um grande e novíssimo navio, que fora fabricado ao custo de 2 bilhões de dólares.

Um dia de serviço desse navio custava à empresa US$ 100.000 dolares. Após somente 6 meses de serviço, o navio simplesmente parou de funcionar. Foram chamados técnicos e mais engenheiros e mais mecânicos do fabricante, que ao término de 1 mês não conseguiram resolver o problema de jeito nenhum. 30 dias com esse navio parado siginificava um prejuízo de 3 milhões de dólares para a empresa, e seus donos estavam à beira de um colapso nervoso quando foi dada a idéia de chamar um especialista independente, que já tinha enfrentado problemas semelhantes e se saído muito bem, devido à sua experiência imensa com a complexa mecânica naval.

Eis que no dia seguinte, chega o especialista. Senta-se em frente a uma das partes do motor, tenta ligar, pressiona alguns botoes, balança a cabeça, murmura algo para si mesmo… e puxa uma chave de fenda da sua caixa de ferramentas. Desaparece por entre os motores por alguns instantes, e ao retornar diz: “problema resolvido”. Apenas ao toque de um botão, o motor responde e o navio começa a funcionar.

O presidente da empresa ficou impressionado, e perguntou ao especialista quanto ele lhe devia. O especialista respondeu:

– A conta é US$ 1 milhão, por favor.

O presidente da empresa ficou indignado, e falou:

– US$ 1 milhão por apenas alguns minutos de trabalho? Para apertar um parafuso? Eu sei que o meu navio é um navio de 2 bilhões de dólares, mas 1 milhão é absurdo! Pagarei somente se receber demonstrativo com todos os detalhes que justifiquem esse valor!

O especialista simplesmente balançou a cabeça afirmativamente e saiu.
Na manhã seguinte, o presidente recebe o demonstrativo com o detalhamento do serviço. Ao terminar a leitura, não hesitou e mandou que fosse paga no ato.
A nota fiscal dizia:

“Serviços realizados:
Visita técnica – cortesia
Apertar um parafuso – US$ 0,10
Saber qual parafuso apertar – US$ 999.999,90“

Em suma, um problema que era remexido há um mês e sem solução foi resolvido em poucos minutos. Um erro comum é querer fazer comparações entre complexidade x tempo. Isso é errado. Quando estimamos utilizando planning poker, levamos em consideração o tamanho de uma história, relativo à sua complexidade – esqueça as horas. Mesmo. Trabalhamos com processos empíricos, lembram?

E no final, uma estimativa é somente uma estimativa – não é uma previsão, não está gravado em pedra, e não precisam ser certas. A definição da palavra “estimativa” comprova isso, procure no Google. Obviamente, quando atingimos uma certa regularidade e melhoramos nossa exatidão das estimativas, ganhamos mais previsibilidade e temos melhores condições de nos planejar para o futuro. Mas isso é uma coisa que vem naturalmente, assim como a velocidade do time, e não pode ser forçada.

O ingrediente secreto do Scrum

E por falar em coisas que não podem ser forçadas, me lembrei de uma coisa que gosto de evidenciar em minhas conversas sobre Scrum e Agilidade: Em um âmbito mais abrangente, desenvolvimento de software é um processo criativo.

Você não pode forçar pessoas a terem idéias. O que podemos fazer é criar um ambiente propenso à boas idéias – como um terreno fértil. E esse é um dos vários ingredientes “secretos” para o sucesso, coisas que não estão escritas em nenhum manual – e que nenhuma ferramenta vai ajudar você à obter.

Melhore suas reuniões diárias: levante suas mãos!

Fri, 30 Jan 2009 00:00:00 GMT

Ultimamente, alguns membros dos times com os quais eu trabalho começaram a questionar e até a reclamar um pouco sobre a efetividade das nossas reuniões de Daily Scrum. Eu também estava compartilhando deste sentimento, principalmente porque algumas vezes a reunião de Daily Scrum parecia mais uma reunião de status, onde os membros do time informavam a mim (ScrumMaster) do progresso do projeto.

Hoje, estou atuando como ScrumMaster em três times, sendo o menor de 3 pessoas e o maior de 4. Ou seja, os times não são grandes, e felizmente todos os membros dos times sentam juntos, e no mesmo ambiente – o que ajuda o pessoal a se comunicar, sem paredes nem distâncias a serem percorridas – basta virar sua cadeira para trás ou para o lado e falar com os demais membros.

Quando recebi a reclamação e os comentários, concordei de imediato, pois eu também compartilhava deste sentimento. Até então, as nossas reuniões de Daily Scrum eram realizadas da seguinte forma: Stand-up Meeting, diariamente mais ou menos no mesmo horário, na área do time, timebox de 15 minutos, onde cada membro do time respondia às três perguntas padrões (O que fiz desde a última reunião, O que farei até a próxima, Quais dificuldades estou enfrentando), utilizando a técnica do Talking Stick para controlar quem tinha a palavra.

Então começei a me perguntar sobre como ou o que eu poderia fazer para ajudar o time a tornar as reuniões diárias mais efetivas e úteis para o time. Tendo sempre em mente que o Scrum é feito para o time, e que o foco da daily scrum é justamente fazer o time conversar sobre seu progresso e seus problemas, além de ser um loop de feedback do time para o próprio time, saí à procura de soluções e sugestões.

Um artigo que me chamou bastante atenção, e que terminei encontrando nas minhas andanças pelo Google Reader, foi este artigo do Kevin E. Schalab. Neste artigo, Kevin comenta justamente sobre uma discussão que aconteceu num dos grupos do LinkedIn, que tinha como tópico a seguinte pergunta: “O quanto de discussão paralela (ou seja, fora do escopo das três perguntas do Daily) posso permitir acontecer numa reunião diária?”

Não vou traduzir o artigo desta vez, mas ao invés vou destacar os pontos que considero mais importantes:

“Telling people to stop talking after answering the 3 questions is going to turn the meeting into a status meeting” – ou seja, “Pedir para que as pessoas parem de falar depois de responder às três perguntas vai transformar sua reunião em uma reunião de status” – era isso que muitas vezes acontecia nas nossas Daily Scrum. Quando um membro do time começava uma discussão técnica (normalmente após a última pergunta), eu normalmente interrompia o mesmo e pedia para que ele conversasse com os demais membros do time após o término da Daily Scrum. O que acontecia? Raramente isso acontecia. O timing era perdido…
“No meu grupo, as pessoas também aproveitavam a Daily Meeting para contar sobre lições aprendidas do dia anterior ou de experiências anteriores – eu fiz algo de errado e aqui está o que você deve fazer para não repetir meu erro” – exatamente com o objetivo de promover o loop contínuo de feedback entre os membros do time!
“Parking lot: Discussões tangentes ou questões fora do escopo das três perguntas que durassem pouco mais de alguns segundos para serem finalizadas eram interrompidas pelo Scrum Master e escritas como itens de parking lot. Após o término da reunião, este Parking Lot era rapidamente priorizado pelo time, por ordem de urgência, e rapidamente resolvidos depois da daily Scrum.” – esta era a forma como eu vinha atuando, mas ainda não era o insight que eu estava à procura.
“Hand-raising (levantando as maõs): Aqui, a regra é simples. As pessoas dizem o que precisa ser dito na reunião de stand-up, sem se limitar ao escopo das três perguntas (mas ainda assim respondendo as mesmas). Se uma pessoa da equipe perceber ou achar que a discussão atual não está trazendo benefícios, a mesma levanta a sua mão. Quando a maioria das pessoas tiver com a mão levantada, a minoria que ainda está discutindo sobre o tópico irá deixar a discussão para depois, e vai voltar às 3 perguntas do daily scrum. Ao mesmo tempo, se eu sou a única pessoa com a mão levantada, eu rapidamente baixo a mesma, pois assim percebo que o time vê importância na discussão daquele tópico, e a maneira mais eficiente de se tratar daquele tópico é neste momento.” – bingo, está aí o insight que eu procurava! Uma forma de manter as conversas inoportunas fora da reunião, e transformar a mesma num encontro de feedback do time.

Após ler este artigo, apresentei o mesmo aos meus times, mas particularmente ao que estava reclamando mais da ineficiência dos encontros. O sucesso da adoção da prática foi instantâneo – todos ficaram satisfeitos, e o aproveitamento das reuniões de daily ficaram muito, mas muito melhores. Além disso, essa técnica de levantar as mãos cria também um sistema de pressão que torna as pessoas conscientes de que, se elas começarem a perder o foco, mãos serão levantadas.