As frases de efeitos que carregam a pregação do Scrum muitas vezes atrapalham mais do que ajudam a explicar certas cerimônias do Scrum. Isso acontece por exemplo com a reunião de planejamento, onde os membros do time precisam estimar o tamanho das histórias e o julgamento dos membros é enublado por referências como "não é possível dizer quanto uma tarefa é maior que outra devido a imprecisão inerente a estimativa".
Pretendo aqui fazer uma reflexão sobre a estimativa do Scrum que, em minha opinião, não rompe com as convenções usuais de estimativa e onde os valores atribuidos as tarefas expressam de fato o "tamanho" médio estimado para cada tarefa com relação ao tempo.
Para quem não sabe, durante a reunião de planejamento o Product Owner explica as histórias do "Backlog", o time precisa estimar o "esforço" necessário para concluir cada delas. A
ferramenta para auxiliar a estimativa é o pôquer do planejamento. No pôquer do planejamento, cada membro da equipe utiliza um baralho de cartas de uma pseudo-sequência de fibonacci (os baralhos mais comuns seguem a sequência 1,2,3,5,8,13,20,40, 100). Escolhe-se uma tarefa como referência a pontuação. Ex: uma aplicação simples de cadastro é a tarefa de valor 2.
A cada história, após o PO apresentar o problema e de uma discussão inicial dos membros da equipe, os membros da equipe iniciam o jogo. Simultaneamente apresentam a carta que melhor aproxima o valor que cada um considera representar o esforço (em relação a tarefa de referência) necessário para a realização da tarefa. Se ocorrerem divergências, jogadores que escolheram os valores mínimos ou máximos expõem o motivo porque acreditam que a pontuação deva ser maior ou menor apresentando facilidades e dificuldades que talvez outros membros não tenham percebido. Outras rodadas do pôquer se sucedem até
que os jogadores entrem em consenso.
Sterilis theoria, auream praxis. Na prática, muitas pessoas ficam confusas sobre o valores e a escala do pôquer do planejamento. Um colega meu defendia a ideia que os números não representam valores escalares, ou por exemplo uma atividade 2 não foi estimada 2,5 vezes mais fácil do que uma atividade 5 e que para justamente não levar ao erro dessa relação matemática entre as grandezas fora escolhida uma sequência estranha de progressão. Por esse raciocínio, 5 expressa apenas um esforço maior que 2 e 3 porém menor que 8.
Para a discussão ficar mais rica irei ilustrar o problema com 4 atividades para serem avaliadas: ler um exemplar da Revista Caras, ler um livro da série Harry Potter, ler Os Lusíadas e ler a teoria de Galois. Ao final, a equipe deve ser capaz de fazer um resumo ou apontar os pontos mais importantes da leitura. Esse exemplo foi inspirado num exemplo utilizado num “curso de Scrum”. Em nosso cenário imaginário, esse é o primeiro Sprint
e a equipe deve eleger uma história como referência. Vamos supor que a história de ler um exemplar da Revista Caras seja escolhido como referência (o esforço estimado é 2). Ainda por hipótese, ninguém da equipe leu a série Harry Potter nem o exemplar específico da Revista Caras em questão. Qual deveria ser o esforço estimado para a leitura de um Harry Potter???
Para ser mais específico, considerando que um livro da série Harry Potter tenha 700 páginas e que uma revista Caras tenha 50 páginas, imaginando que a linguagem utilizada no livro seja no máximo tão difícil quanto a linguagem utilizada na revista, seria errado assumir que o livro é no mínimo dez vezes mais difícil que a revista? Tudo leva a crer que sim....
Para compreender melhor isso é importante saber para que essas avaliações serão utilizadas. A avaliação não apenas torna possível ordenar as tarefas. Ela permite estimar o conjunto de tarefas que o grupo é capaz de realizar num Sprint. Primeiro porque a cada Sprint, um total de histórias é realizado. Cada história leva consigo sua pontuação. Logo, a cada Sprint tem-se a média de total de pontos que o time é capaz de entregar (entre outros estimadores como o mínimo de pontos entregues, mediana, etc). Esses valores balizam a quantidade de pontos que o time pode se comprometer a entregar. Na verdade, mesmo num primeiro Sprint, o time deveria ser capaz de imaginar qual valor seria razoável como esse limite.
Se a sequencia fosse apenas uma ordem (digamos A para a tarefa mais fácil e G para a tarefa mais difícil) não seria possível estimar a capacidade de produção do time. Além disso, após as estimativas, o PO tem a liberdade de escolher qualquer combinação de histórias cujo total seja menor ou igual a capacidade da equipe. Para isso, seria muito saudável que uma história 8 fosse 4 vezes “maior” que uma história 2.
Num segundo momento, essa capacidade média de produção será utilizada para que o PO possa estimar o tempo para a realização de histórias maiores, mesmo com incertezas grandes. Toda ideia de estimativa é essa, senão estaríamos falando de definição do tempo.
Voltamos ao exemplo dos livros... Ao invés da revista Caras vamos considerar que história básica seja ler “A Volta ao Mundo em Oitenta Dias” (com 256 páginas). Com todas as variáveis constante a menos do tamanho dos livros, Harry Potter teria nota 5,4.
Ocorre que qualquer estimativa leva consigo uma certa incerteza. O pôquer do planejamento resolve isso com uma relação implícita entre intervalos e valores ao limitar a escolha de valores intermediários. Dessa forma, ao estimar uma história com 2 seria uma forma de dizer que a história tem valor maior que 1 e menor que 3, logo de um intervalo de 2 pontos. Aliás, a série de Fibonacci serve justamente para isso, qualquer número da série (maior que 1) é igual a diferença entre o número que sucede e antecede.
Avaliar a leitura de um livro da série de Harry Potter, deveria considerar esse intervalo. E dessa forma 5 seria um valor que faria bastante sentindo. Agora, qual a dificuldade de ler (e entender ) a teoria de Galois que poderia ser escrita em 10 páginas. Os cursos de graduação em bacharelado de matemática dedicam um semestre ao estudo dessa teoria. Logo, questões como a complexidade ou incertezas podem ser fatores decisivos na estimativa. Assim como a experiência anterior dos membros da equipe (por exemplo, poderíamos ter matemáticos no time o que diminuiria bastante a dificuldade dessa história).
Para finalizar, qualquer metologia de estimativa descrita nos livros de engenharia de software das abordagens tradicionais apontam questões como extensão, complexidade, experiência da equipe e a incerteza. O Scrum não pormenoriza o processo de como estimar deixando isso a cargo do time, mas de qualquer forma trata de avaliar a seguinte grandeza: velocidade (ou trabalho sobre tempo) (lembrando que essa velocidade inclui incertezas inerentes ao processo de estimativa e a diferença entre o cenário especulado e o cenário real).
Pretendo aqui fazer uma reflexão sobre a estimativa do Scrum que, em minha opinião, não rompe com as convenções usuais de estimativa e onde os valores atribuidos as tarefas expressam de fato o "tamanho" médio estimado para cada tarefa com relação ao tempo.
Para quem não sabe, durante a reunião de planejamento o Product Owner explica as histórias do "Backlog", o time precisa estimar o "esforço" necessário para concluir cada delas. A
ferramenta para auxiliar a estimativa é o pôquer do planejamento. No pôquer do planejamento, cada membro da equipe utiliza um baralho de cartas de uma pseudo-sequência de fibonacci (os baralhos mais comuns seguem a sequência 1,2,3,5,8,13,20,40, 100). Escolhe-se uma tarefa como referência a pontuação. Ex: uma aplicação simples de cadastro é a tarefa de valor 2.
A cada história, após o PO apresentar o problema e de uma discussão inicial dos membros da equipe, os membros da equipe iniciam o jogo. Simultaneamente apresentam a carta que melhor aproxima o valor que cada um considera representar o esforço (em relação a tarefa de referência) necessário para a realização da tarefa. Se ocorrerem divergências, jogadores que escolheram os valores mínimos ou máximos expõem o motivo porque acreditam que a pontuação deva ser maior ou menor apresentando facilidades e dificuldades que talvez outros membros não tenham percebido. Outras rodadas do pôquer se sucedem até
que os jogadores entrem em consenso.
Sterilis theoria, auream praxis. Na prática, muitas pessoas ficam confusas sobre o valores e a escala do pôquer do planejamento. Um colega meu defendia a ideia que os números não representam valores escalares, ou por exemplo uma atividade 2 não foi estimada 2,5 vezes mais fácil do que uma atividade 5 e que para justamente não levar ao erro dessa relação matemática entre as grandezas fora escolhida uma sequência estranha de progressão. Por esse raciocínio, 5 expressa apenas um esforço maior que 2 e 3 porém menor que 8.
Para a discussão ficar mais rica irei ilustrar o problema com 4 atividades para serem avaliadas: ler um exemplar da Revista Caras, ler um livro da série Harry Potter, ler Os Lusíadas e ler a teoria de Galois. Ao final, a equipe deve ser capaz de fazer um resumo ou apontar os pontos mais importantes da leitura. Esse exemplo foi inspirado num exemplo utilizado num “curso de Scrum”. Em nosso cenário imaginário, esse é o primeiro Sprint
e a equipe deve eleger uma história como referência. Vamos supor que a história de ler um exemplar da Revista Caras seja escolhido como referência (o esforço estimado é 2). Ainda por hipótese, ninguém da equipe leu a série Harry Potter nem o exemplar específico da Revista Caras em questão. Qual deveria ser o esforço estimado para a leitura de um Harry Potter???
Para ser mais específico, considerando que um livro da série Harry Potter tenha 700 páginas e que uma revista Caras tenha 50 páginas, imaginando que a linguagem utilizada no livro seja no máximo tão difícil quanto a linguagem utilizada na revista, seria errado assumir que o livro é no mínimo dez vezes mais difícil que a revista? Tudo leva a crer que sim....
Para compreender melhor isso é importante saber para que essas avaliações serão utilizadas. A avaliação não apenas torna possível ordenar as tarefas. Ela permite estimar o conjunto de tarefas que o grupo é capaz de realizar num Sprint. Primeiro porque a cada Sprint, um total de histórias é realizado. Cada história leva consigo sua pontuação. Logo, a cada Sprint tem-se a média de total de pontos que o time é capaz de entregar (entre outros estimadores como o mínimo de pontos entregues, mediana, etc). Esses valores balizam a quantidade de pontos que o time pode se comprometer a entregar. Na verdade, mesmo num primeiro Sprint, o time deveria ser capaz de imaginar qual valor seria razoável como esse limite.
Se a sequencia fosse apenas uma ordem (digamos A para a tarefa mais fácil e G para a tarefa mais difícil) não seria possível estimar a capacidade de produção do time. Além disso, após as estimativas, o PO tem a liberdade de escolher qualquer combinação de histórias cujo total seja menor ou igual a capacidade da equipe. Para isso, seria muito saudável que uma história 8 fosse 4 vezes “maior” que uma história 2.
Num segundo momento, essa capacidade média de produção será utilizada para que o PO possa estimar o tempo para a realização de histórias maiores, mesmo com incertezas grandes. Toda ideia de estimativa é essa, senão estaríamos falando de definição do tempo.
Voltamos ao exemplo dos livros... Ao invés da revista Caras vamos considerar que história básica seja ler “A Volta ao Mundo em Oitenta Dias” (com 256 páginas). Com todas as variáveis constante a menos do tamanho dos livros, Harry Potter teria nota 5,4.
Ocorre que qualquer estimativa leva consigo uma certa incerteza. O pôquer do planejamento resolve isso com uma relação implícita entre intervalos e valores ao limitar a escolha de valores intermediários. Dessa forma, ao estimar uma história com 2 seria uma forma de dizer que a história tem valor maior que 1 e menor que 3, logo de um intervalo de 2 pontos. Aliás, a série de Fibonacci serve justamente para isso, qualquer número da série (maior que 1) é igual a diferença entre o número que sucede e antecede.
Avaliar a leitura de um livro da série de Harry Potter, deveria considerar esse intervalo. E dessa forma 5 seria um valor que faria bastante sentindo. Agora, qual a dificuldade de ler (e entender ) a teoria de Galois que poderia ser escrita em 10 páginas. Os cursos de graduação em bacharelado de matemática dedicam um semestre ao estudo dessa teoria. Logo, questões como a complexidade ou incertezas podem ser fatores decisivos na estimativa. Assim como a experiência anterior dos membros da equipe (por exemplo, poderíamos ter matemáticos no time o que diminuiria bastante a dificuldade dessa história).
Para finalizar, qualquer metologia de estimativa descrita nos livros de engenharia de software das abordagens tradicionais apontam questões como extensão, complexidade, experiência da equipe e a incerteza. O Scrum não pormenoriza o processo de como estimar deixando isso a cargo do time, mas de qualquer forma trata de avaliar a seguinte grandeza: velocidade (ou trabalho sobre tempo) (lembrando que essa velocidade inclui incertezas inerentes ao processo de estimativa e a diferença entre o cenário especulado e o cenário real).
Comentários