O Jogo do Planejamento, Parte II

(Caso não se lembre, leia O Jogo do Planejamento, Parte I)

Juntando uma pilha de cartões sobre a mesa, João diz:

- Nosso objetivo agora é ordenar as estórias na ordem em que serão realizadas. Primeiro em um nível macro, agrupadas em torno de temas, e encaixadas em períodos de um mês, ou seja, o que faremos no primeiro mês, depois no segundo, no terceiro e por aí vai…

Cláudio meneia a cabeça, entendendo onde o pequeno quer chegar. Ele pega um cartão e percebe que em todos eles, além da prioridade que ele assinalou, foram marcados pela equipe de Sérgio números que iam de 2 a 13, seguindo uma ordem que ele achou ser a dos fatoriais. Franziu o cenho sem entender, principalmente ao ver a unidade que acompanhava cada número: Joule. Percebendo a inquietação, João prossegue:

- Esses valores representam o “custo” de implementação de cada estória, os desenvolvedores ordenaram cada estória da mais fácil à mais difícil, então escolheram a mais fácil para valer 2 joules. Isso é arbitrário, estamos assinalando um valor mínimo que escolhemos para representar o esforço da estória mais fácil. A partir daí assinalaram o esforço de cada estória em relação à mais fácil, em termos de 2 vezes, 3 vezes mais difíceis, usando números fatoriais para marcar essa progressão. A escolha desses números também é arbitrária e é a que mais se mostrou coerente de acordo com a experiência de nossa equipe, ou seja, pode variar de equipe para equipe.

- E para que serve esse custo, se é tudo arbitrário? – Perguntou Cláudio, com descrença na voz.

- Nem tudo, esses números significam a relação de dificuldade das estórias entre si. Veremos como isso é utilizado: Sérgio, quanto tempo vocês acham que levam para realizar a estória de 2 joules?

- Um dia.

- Então temos uma relação de um joule para meio dia. – Continuou João.

- Por que vocês não anotaram em dias desde o começo? – Interrompe Cláudio.

- Porque a quantidade de tempo que levamos para desenvolver uma estória depende de diversos fatores que não conhecemos ainda, como por exemplo a experiência do desenvolvedor que ficará com ela, seu humor no momento em que estiver trabalhando nela, disponibilidade de recursos necessários a sua implementação e por aí vai. Se estimássemos cada estória em termos de tempo, seria difícil chegar a um consenso rapidamente, o que pode ser fácil para um pode não o ser para outro. Por isso nós estimamos em dificuldade relativa, uma tarefa pode não parecer fácil para vários membros da equipe, mas todos concordam, por exemplo, que ela é mais fácil que outra.

- Entendi… e a questão do tempo?

- Então, a questão do tempo é resolvida num primeiro momento por essa estimativa da relação “tempo real”/joule. Como a dificuldade relativa de cada estória não mudará, ou seja, no geral uma sempre será mais difícil do que outra. Tudo que precisamos fazer é manter nota da relação “tempo real”/joule na medida em que o projeto for ocorrendo, para ir ajustando as estimativas com a realidade.

- Faz sentido…

- Bem… continuando, nós trabalharemos com iterações de uma semana, isso quer dizer que toda semana estaremos fazendo isso que estamos fazendo agora…

- O quê? Toda semana? – Fala Cláudio assustado.

- Sim, sim. E não será bom? Toda semana você poderá mudar a ordem em que as coisas serão feitas, inserir novas estórias, tirar outras que você descubra que não sirva mais. O que você acha?

- Parece ser interessante. Continue.

- Então, como temos 8 desenvolvedores para o EasyStuff com 5 dias úteis de trabalho, temos um total de 40 vezes 2, 80 joules de esforço total por semana. Mas como cada desenvolvedor é responsável por uma estória por inteiro, então a maior estória possível dentro de uma semana inicialmente deve ter no máximo 10 joules.

- Mas eu vejo aqui duas estórias com esforço de 13 joules…

- É verdade, então vamos ver se essa estória não pode ser quebrada em outras menores. Sérgio você poderia ver isso?

Sérgio pega as duas estórias e senta com a sua equipe e Vera. Na primeira estória está claro que eles deixaram passar uma estória muito grande, e conseguiram dividir em 2 menores. Mas a segunda mostrou-se indivisível, Vera explicou que aquela funcionalidade era a mais simples possível. Preocupado, um dos desenvolvedores tem uma idéia e diz:

- Vamos fazer o seguinte! A gente implementa toda a lógica de negócio em uma estória e em outra estória a gente implementa a interface. Certamente cabe em uma semana!

- Mas tem um problema, toda estória tem que agregar valor direto ao usuário. Ou seja, não adianta implementarmos a camada de negócio se não vai ter interface para o usuário utilizá-la. – Comenta Sérgio.

- Por quê?

- Porque se não conseguirmos verificar a estória, então estaremos potencialmente desperdiçando nosso esforço construindo algo que não vai ser verificado pelo usuário. Estaremos atrasando o feedback do que fizemos até um momento indefinido quando o resto da funcionalidade será implementado.

- Entendi, então vamos fazer o quê?

Sérgio retorna com seu grupo para mesa de João com as duas novas estórias e a antiga. Após ouvir a explicação, João pensa um pouco e diz:

- Temos duas soluções possíveis, uma é estender a iteração para caber integralmente a maior estória que é essa. A outra é, já que essa estória tem baixa prioridade e não vai ser implementada tão cedo, podemos colocá-la de lado e verificar se a velocidade da equipe aumenta a ponto de abranger essa estória em uma semana. Eu, particularmente, vejo mais vantagem nessa segunda abordagem já que é possível que a gente descubra mais tarde que ela não vai ser nem necessária. O que você acha, Cláudio?

- Por mim tudo bem, essa estória não tem muita importância pra mim agora. Eu quero saber de produto novo nas prateleiras logo! Estou ansioso para saber o que vocês vão me entregar em Abril!

- Muito bem, para saber isso precisamos continuar com o jogo do planejamento, o objetivo agora é maximizar a vazão de valor para o cliente, no caso, para você.

(Continua no próximo post)