A grande pergunta de todo projeto: Quando vai terminar?

É comum as partes interessadas quererem saber quando o projeto vai terminar, por isso constroem-se cronogramas nas metodologias tradicionais.

Sabe-se, no entanto, que a maioria dos projetos não cumpre os prazos e isso se dá a várias “doenças” e erros que os projetos trazem consigo, geralmente ligados ao comportamento ou a estrutura (Leia mais no livro 21 erros clássicos da gestão de projetos).

O Scrum, no entanto, se atém ao que é realmente possível fazer, sem sambarilove. Se não é possível calcular com exatidão a data final de um projeto, por que tentar? Por isso, o Scrum usa o conceito de timebox, em que o tempo é fixo e o escopo é variável.

Esse conceito tem a ver com o estudo que mostra que, no mundo dos softwares, apenas 20% das funcionalidades são realmente utilizadas. O cliente pede sempre muitas coisas, mas no final utiliza somente algumas.

Cabe a nós, como Scrum Masters, auxiliarmos nossos clientes na priorização do que é mais importante para seu negócio, ao invés de apenas cumprir prazos (e sofrer pressões) para criar coisas que sequer serão utilizadas.

Doenças do prazo

Alguns diriam que têm metas a cumprir, datas de lançamento de produtos, que os projetos já estão começando atrasados e que, por isso, é necessário ter um controle rígido de prazo. Mas todos sabemos que um recurso sob pressão sempre colocará “gordura” no prazo quando estimar e, quanto mais pressionarmos, mais gordura colocará.

Lei de Parkinson

Sabe-se, pela lei de parkinson, que o esforço sempre se enquadra ao tempo disponível. De modo que se um programador estimar 3 dias para fazer um trabalho, o fará em, no mínimo, 3 dias, ainda que pudesse fazer em menos tempo.

Em contrapartida, se for pressionado a assumir uma estimativa de 1,5 dia (metade do tempo), ainda que pudesse fazer em 1 dia, levará, no mínimo, o tempo que foi obrigado a estimar.

E como se não bastasse isso tudo, na próxima estimativa, sabendo que será pressionado a cortar o tempo pela metade, estimará 6 dias (o dobro) para que você – “espertalhão” – possa pedir a redução sem tirá-lo da zona de conforto.

É um jogo de gato e rato que mais lembra os desenhos do Tom e Jerry.

Por isso, as metodologias ágeis usam escalas não-lineares para calcular o tamanho do projeto e, a partir dele, seu prazo. Em outras palavras, o prazo se calcula pela velocidade média do time, livre das pressões que modificam os comportamentos de forma nociva.

É o que chamo de “liberdade no cercadinho”, a “criança” pode brincar com o que quiser, desde que seja dentro do espaço que lhe foi delimitado. Em outras palavras, o programador poderá determinar a ordem de complexidade, mas a gestão do tempo se dará diariamente, sem que ele fique no controle.

Calculando o prazo de um projeto ágil

Estimando o tamanho do projeto

Uma das técnicas para cálculo dos story points é o Planning Wall. Nela, você deve primeiramente listar as estórias de usuário, geralmente numa parede usando post-its.

Em seguida, devem ordená-las por complexidade, ignorando-se o fator tempo (não se atenha se os itens que escolhi são realmente mais complexos, é apenas um modelo ilustrativo).

Por último, deve usar uma escala não-linear para pontuar cada estória, como a sequência de Fibonacci, por exemplo.

Com isso, você terá o tamanho do projeto: 1+2+5+8+13+21+34 = 84. Este número será utilizado para medir o progresso.

Progresso x Velocidade

Mede-se o tamanho do projeto e não o prazo, pois, no Scrum, não importa quanto tempo passou e sim o quanto foi concluído (Leia mais em Como saber se a entrega está pronta mesmo).

Daqui nasce a diferença entre progresso e velocidade:

• Quanto mais estórias o time terminar, mais o projeto PROGREDIU. Ou seja, mais próximo está de terminar todas as estórias.
• Quanto mais rápido o time terminar, mais VELOCIDADE ele está alcançando.

Calculando a Velocidade do time e o Prazo do projeto

Então, digamos que foi definida uma duração de 2 semanas para cada sprint e que é provável que o time faça as 2 primeiras estórias na sprint 1, mas que, se sobrar tempo, podem começar a trabalhar na terceira estória.

As duas primeiras estórias são, portanto, a meta da sprint e devem cumprir o objetivo traçado para a primeira sprint. A terceira estória é desejável, se der tempo, o projeto avançará (terá progresso) mais rapidamente.

Usando o tempo como medida

No planejamento da sprint, o time desdobra as atividades necessárias para finalizar cada estória. O quadro (sprint backlog) fica mais ou menos assim.

Aqui temos um primeiro insight: Duas semanas têm 40 horas por pessoa. Se consideramos 3 pessoas no projeto, já começou a sobrar tempo.

Simulando sprint 1

Então, duas semanas depois, chega-se ao seguinte sprint burndown:

Pergunto: Terá o time avançado na velocidade esperada? Houve dificuldades no meio do caminho? O que fez com que a primeira semana fosse mais rápida que a segunda?

Pois é, na prática as coisas são um pouco diferentes.

Nesse projeto, já se conhecia um fornecedor de móveis, então as etapas de seleção de fornecedor e contrato foram mais rápidas. As aprovações da sala de espera (segunda estória) demoraram mais que o previsto, pois o Product Owner não havia passado informações detalhadas do que gostaria de fazer. Por isso é importante o conceito de definition of ready, para que só se aceitem estórias que já tenham suas definições bem planejadas. Passar o trabalho do PO para o time reduz a produtividade.

Qual foi a velocidade do time?

3 story points (das duas estórias) por sprint. Sendo assim, o projeto terminará em:

• 84 sp / (3sp/sprint) = 28 sprints
• Como cada sprint leva duas semanas => 56 semanas ou 14 meses.

Pergunto: Mas, será que a velocidade será constante nas demais sprints? Será que as atividades mais demoradas já não foram cumpridas? Será que a integração do time melhorará nas próximas rodadas?

Não se sabe.

Por isso, é importante acompanhar algumas sprints para se ter uma ideia mais concreta de qual será a velocidade média. Vamos simular?

Simulando as sprints 2 e 3

Digamos que na segunda sprint, o time tenha concluído a estória “Sala de reunião” e na terceira tenha concluído a estória “elevador”. Como ficaria a velocidade média?

• Sprint 1 = 3 story points
• Sprint 2 = 5 story points
• Sprint 3 = 8 story points
• Média = (3+5+8)/3 = 5,33 sp/sprint

Perceba como é mais coerente considerar a variação de produtividade ao longo de várias sprints, por isso se considera sempre a média (ou média móvel, se preferir) para estimar o projeto.

Como ficaria o prazo do projeto considerando a perspectiva da velocidade média?

• Quantidade total de story points = 84
• Quantidade de story points já realizados = (3+5+8) = 16
• Quantidade restante de story points = (84-16) = 68
• Tempo total do projeto, após a revisão = 68 / 5,33 = 12 sprints
• Em termos de prazo, ficaria em = (12 sprints * 2 semanas para cada) / 4 semanas por mês = 24 semanas ou 6 meses.

Pois é, num ambiente convencional, ao término da primeira sprint já se estariam fazendo reuniões de melhoria, o time teria levado muitas broncas e provavelmente alguém acabaria saindo da equipe, o que derrubaria ainda mais a produtividade.

Como acompanhar a velocidade do time?

A velocidade do time é medida por quantos story points aquela equipe conseguiu fazer num período fixo. Os story points, no entanto, são medidas comparativas entre estórias de usuário, que usam escalas não-lineares.

Deste modo, ao comparar uma estória de usuário com outra, o time é obrigado a escolher, por exemplo, entre 8 e 13, de modo que uma estória que valha 8 story points pode acabar levar mais tempo que outra com o mesmo valor. Isso serve para que o time “perca a noção do tempo exato” para fazer uma estória e acabe focando-se nos resultados.

Esse é um dos grandes segredos do acompanhamento ágil, foco nos resultados.

Para acompanhar a velocidade, deve-se usar um gráfico de controle, como o exemplo a seguir.

As linhas em vermelho mostram os limites superior e inferior, apenas como alerta para que o Scrum Master avalie se houve um potencial desvio. Basicamente, o gráfico de velocidade serve para dar uma noção do prazo do projeto, mas sem certezas, afinal, o Scrum foca em resultados não em estimativas.

Usando a quantidade de tarefas como medida

Uma outra forma de controlar o andamento da sprint é por quantidade de atividades. Ela é mais rápida e mantém as pessoas focadas no que deve ser feito e não em quanto tempo levará para fazer.

O burndown tem o mesmo formato do gráfico baseado em horas, mas, retrataapenas atividades concluídas.

Se lembrarmos da diferença entre progresso e velocidade, notaremos que “terminar uma atividade não significa finalizar o trabalho (a estória), afinal, a atividade pode não ter dado certo.

Talvez lhe incomode não saber as horas que o time gastou com cada tarefa, mas isso é realmente mais importante que o resultado?

O andamento do projeto é acompanhado na daily meeting e o tempo que se investe estimando horas é desperdiçado em relação ao tempo de execução.

Usando story points como medida

Para os mais radicais, nem mesmo estimar a quantidade de tarefas é justificável. Preferem apenas listar as estórias de usuário daquela sprint e seguir para a execução.

Quando se têm um grande número de estórias, o gráfico faz mais sentido. Mas, de qualquer forma, só haverá progresso quando uma estória for 100% concluída, ou seja, quando atender a definition of done.

Acompanhando o Progresso do projeto

Agora voltando ao product backlog: Como o Product Owner deve acompanhar o progresso do projeto?

Ao final de cada sprint, deve atualizar o gráfico de burndown, mostrando quantos story points foram finalizados, conforme o exemplo.

Replanejamento a cada sprint

Seria sensacional se os projetos seguissem uma linha reta, mas na prática, o PO (Product Owner) decidirá, a cada planejamento de sprint (sprint planning), quais estórias permanecem, quais serão simplificadas e quais serão adicionadas.

Em termos práticos, a estória “Negociação” poderia ser “repriorizada” para entrar na quarta sprint. Ela também poderia ser “simplificada”, reduzindo sua complexidade para caber no prazo. Tudo pode acontecer, afinal, é um projeto ágil!

Finalizando o projeto no Scrum

Então chegou o grande dia, o tempo do projeto acabou. Chegou 3/9/16 e na segunda-feira que vem será o lançamento do produto.

Mas, peraí… o escopo não foi totalmente concluído! Quem é responsável por isso? A quem vamos demitir?

Embora esse seja o pensamento tradicional, presume-se que no Scrum, o PO tenha colaborado com o time durante todo o projeto e teve a visão exata do que havia sido concluído a cada sprint. Foi ele quem decidiu, com base no seu conhecimento de negócio, quais estórias eram prioritárias e também foi ele quem avaliou cada entrega.

Deste modo, espera-seque esteja satisfeito com o resultado, ainda que o escopo inicial do projeto não tenha sido concluído. Pois, se não estivesse, teria apontado isso durante o projeto.

O mais comum é que o product burndown finalize com algumas estórias não implementadas, seja porque o prazo terminou ou porque não houve interesse em seguir com elas. Mas, não se preocupe, na segunda-feira tudo que foi produzido irá ao ar e não haverá surpresas no último dia.

Uma mudança de paradigma

Para que o Scrum funcione adequadamente é preciso, principalmente, a definição clara dos papéis atuantes no projeto e para que o resultado seja satisfatório é preciso um acompanhamento muito próximo do PO e muito realismo em relação ao que é possível ser feito. Isso é o que chamo de “parceria”.

Se qualquer dos papéis não se adaptar a esse novo modelo de trabalho, seja pela necessidade de microgerenciamento, seja pelo desejo de participar de todas as reuniões ou simplesmente pela atitude de fechar os olhos e buscar culpados quando o impossível não for concluído, é melhor não tentar usar o Scrum como bode expiatório.

Muitas e muitas empresas pelo mundo têm usado Scrum. Se nesta ou naquela não funcionou, está na hora de rever os conceitos e mudar o paradigma de trabalho. Quando houver foco em resultados e confiança mútua, certamente qualquer modelo de trabalho funcionará melhor.

Eli Rodrigues