Planejamento

Ao contrário do que muitos acham utilizar Scrum não significa anarquia no projeto. Bem pelo contrário. Scrum exige que tudo seja planejado com antecedência. A diferença para o método tradicional é que Scrum não exige como se vai executar o plano, apenas o plano em si mesmo tem que ser documentado.

Acontece  que a documentação do plano é apenas um conjunto de listas de histórias ordenadas por Prioridade. O Product Backlog , respetivos Release Backlogs e respetivos Sprint Backlogs.

Usar Scrum significa planejar e rever o planejamento a cada passo. É pelo constante replanejamento que o Projeto é guiado até ao sucesso. A mecânica do Scrum resume-se portanto a um ciclo de fases de planejamento e execução que são alternadas até o produto ser entregue. Planejamento – Execução – Planejamento – Execução – …

O Scrum começa com um planejamento “macro” e depois inicia o ciclo com execuções e re-planejamentos periódicos ( os sprints)

Planejamento inicial : Brainstorming

O planejamento inicial do projeto é realizado para descobrir o que o Produto será. Ainda não existe uma visão do que o Produto será apenas ideias soltas sobre algumas propriedades que ele deve ter. O Dono do Produto como interessado principal no Produto e suas caracteristicas reune uma equipa que o ajude a entregar esse produto.

Pessoas com várias capacidades são chamadas a participar. Desde desenvolvedores , arquitetos e programadores até advogados, vendedores, analistas de mercado, pessoas do marketing, usuários, … enfim todos os que podem contribuir para incluir valor no Produto.

Uma ou mais reuniões do tipo brainstorm são realizadas para jogar as ideias na mesa. Se existe um cliente por detrás que encomendou o software ele terá muitas das principais ideias que correspondem a necessidades do dia a dia. Isso será complementado com preocupações legais, de segurança, técnicas , etc.. até ter uma lista da funcionalidades ideais do Produto.

Neste ponto a lista pode conter grandes aberrações e contradições. O Dono do Produto conduz este processo no sentido de ter uma lista o mais abranjente possível e depois, sozinho, assume a responsabilidade de enxugar esta lista para as funcionalidades que realmente irão constituir o produto.

Algumas funcionalidades serão necessárias ao funcionamento ( como ter uma interface agradável) algumas à construção ( como utilizar a plataforma Java ) e algumas ao uso ( como ter um mecanismo de segurança por senha). Outras serão vitais para o sucesso do produto e o destinguirão da concorrencia e são essencias que sejam incluidas. E outras são interessantes se poderem ser incluidas, mas ainda não sabemos se valem o esforço.

O artefacto final da fase brainstorm do planejamento é o Product Backlog com todas as histórias mais ainda sem estimativas de tamanho ou prioridade.

Planejamento de Lançamento (Release Planning)

Com o Product Backlog em mãos o Dono do Produto priorida as histórias com base no valor do produto e a necessidade das funcionalidades.

Durante esta analise é provável que o Dono do Produto veja que muitas funcionalidades não assim tão importantes e podem ser adicionadas depois a uam versão minima. Assim, o segundo passo no planejamento é agrupar as funcionalidades no Product Backlog em pacotes que possam ser utilizados e em particular um pacote que possa ser lançado com o nome e a cara do Produto, mas onde ainda faltam algumas funcionalidades que serão acrescentadas em lançaments futuros.

Todo este planejamento é realmente estratégico do ponto de vista do negócio que usará o produto e para quem está se responsabilizando pela entrega do Produto. Contudo para que as decisões possam ser tomadas em consciencia é necessário que todas as histórias candidatas para o primeiro lançamento tenham seu tamanho avaliado.

Idealmente avaliariamos o tamanho de todas as historias no backlog, mas na prática avaliar as historias para os dois primeiros lançamentos é suficiente. É claro que uma historia que não foi avaliada pode ser avaliada a qualquer momento e introduzida no backlog se for necessário.

Estimando o tamanho

Estimar o tamanho de uma história não é avaliar o tempo que demora a ser implementada. Contudo existem os seguintes principios seguidos durante a avaliação:

1. O tamanho da história aufere o que é necessário fazer para a historia estar completa.
2. Os tamanhos das historias são proporcionais umas às outras.
3. Os tamanhos das historias são adicionáveis.
4. Estamos apenas estimando

É muito importante que fique claro que o tamanho da historia não representa o tempo que será necessário consumir para completar a historia. Ou seja,  uma historia com o dobro do tamanho de outra não necessáriamente demora o dobro a ser executada. O tempo que a historia demora a ser implementada é porpocional ao tamanho mas depende da equipa que a irá implementar.

Portanto, ao estimar o tamanho da historia temos que abstrair quem irá implementar a historia e concentrarmo-nos no que é necessário fazer para que a historia seja dada como completa. Para isso precisamos do saber o que “completo” significa e em que escala avaliar o tamanho das historias.

Definição de Pronto

Uma história é dada como completa, ou pronta, quando um certo objetivo pré-determinado é alcançado. Este é objetivo é chamado “Condição de Pronto”. Cada história tem a sua condição de pronto. Ela faz parte da informação da historia contida no backlog.

Todas as historias têm uma condição que define se a implementação da historia está completa ou não. Muitas vezes esta condição assume a forma de um teste – automatizado, ou não – que pode ser verificado empiricamente.

Escala de Tamanho

Precisamos de uma escala numérica na qual o tamanho das nossas historias possa ser avaliado. Precisamos que seja numérica para que os valores possam ser adicionados e ordenados e precisamos que a escala denote que se trata apenas de uma estimativa.

Este vasta literatura sobre como estimar com incertezas e tudo o mais. Aqui vamos no básico.

A escala de avaliação é um dos seguintes numeros: 0 , 1 , 2 , 3 , 5 , 8 e 13. Esta escala é propositalmente não continua. Estamos apenas estimando. É muito improvável que saibamos destinguir um 5 de um 6 ou 7 durante uma estimativa. Os numeros são afastados o suficiente para que seja clara a relação de grandeza relativa.

O numero zero indica historias que são demasiado pequenas. Elas devem ser agrupadas em historias maiores. Normalmente indica afazeres que estão na escala de tarefa e não de historia. Numeros maiores que 13 indicam historias grandes demais.  Essas historias devem ser divididas em historias menores. No inicio do planejamento podemos utilizar os zeros e os numeros maiores que 13 mas eles devem ser eliminados até ao fim da fase de planejamento de lançamento.

O que os numeros representam ?

Os numeros representam o tamanho da história e a quantidades em causa é o Ponto de Historia (Story Point, abreviado para SP). Um Ponto de Historia não é uma medidade de tempo e sim de tamanho. Lembre-se que tempo não é tamanho porque depende de fatores externos e outros diferentes do tamanho.

Existem duas abordagem para como estabelecer a relação entre os numeros e o tamanho das historias.

A primeira e mais simples é estabelecer que um 1 significa:  “O tamanho de um historia que um Desenvolvedor Sênior poderia completar em até 1 dia util se não fosse importunado para nada durante esse tempo”. Podemos escolher Desenvolvedor Junior ou qualquer outro nivel. O importante é que se escolha um.

Assim, 2 significa “O tamanho de um historia que um Desenvolvedor Sênior poderia completar até 2 dias uteis se não fosse importunado para nada durante esse tempo”… e assim por diante.

Esta forma de avaliação do tamanho da historia é conhecida como Estimativa em Dia Ideais e é a forma mais intuitiva para os desenvolvedores.

Insight

A este ponto você deve estar pensando : ” mas não tinha dito que não podemos medir tamanho em tempo ?!”. Sim, disse.

Acontece que o tempo que uma historia demora a ser completada depende da equipa que a desenvolve e a equipa, por definição, nunca é uma pessoa singular. Vejamos. Se a história tem um tamanho T e a equipe demora t dias a implementá-la então a velocidade da equipa é de V = T/ t ( SP/ dia)  invertendo tempos que o tempo é uma função da velocidade. t = T/ V.  Ora em Scrum a velocidade da equipa é uma constante para o projeto se a equipa não for importunada nem existirem obtáculos no seu caminho ( mais o menos como um maratonista que terá velocidade constante se não existirem obstáculos caminho nem for importunado pelo publico, o clima ou a condição da estrada).

Assim sendo idealmente a velocidade constante, idealmente podemos pensar que ao aumentar o tamanho por uma constante, o tempo aumenta da mesma constante:

k t = (k T) / V = k (T/V)

Então, em condições ideais o tempo é uma função linear do tamanho. Assim, se podermos estimar o tempo, indirectamente estaremos estimando o tamanho. Contudo na realidade nada é ideal. A equipa sim será importunada e obstáculos sim aprecerão. A velocidade real depende fortemente dos membros da equipa, dos canais de comunicação entre eles, e dos impedimentos que lhes retiram o foco. Ao definir um único elemento para equipa com capacidades bem definidas ( Desenvolvedor Sênior) que, sendo sozinho, não comunica com ninguem, e mantendo o idealismo de zero impedimentos chegamos a uma estimativa ainda mais próxima da realidade.

Assim, o método da Estimativa por Dias Ideias estima os Story Points de uma Historia fazendo algumas restrições razoáveis que permitem a qualquer desenvolvedor estimar baseado no tempo que demoria a implementar a Historia.

É preciso mencionar que mesmo assim, a unidade da estimativa são Pontos de Historia e nao dias. Isto porque os dias são apenas uma ponte para chegar nos pontosde historia e não a unidade em si mesma. É como estimar a capacidade em litro de um frasco estimando o numero de botões de camisa que cabem dentro dele. O resultado seria em litros, não em botões.

Repare no “até” colocado na frase. O numero significa que o desenvolvedor poderia até demorar menos mas sempre mais que o numero anterior da escala. Por exemplo, na sua cabeça o desenvolvedor estima que 4 dias seria o ideal para a completar a historia, mas a escala não tem o 4. Assim ele seria forçado a escolher 5 para a sua estimativa já que sendo que é verdade que “O Desenvolvedor Sênior poderia completar a historia em até 5 dias uteis se não fosse importunado para nada durante esse tempo” é mentira que “O Desenvolvedor Sênior poderia completar a historia em até 3 dias uteis se não fosse importunado para nada durante esse tempo”.

Esta escolha dos valores dentro da escala forma uma compreensão partilhada entre todos os membros do que a escala significa e evita falsa exatidão nas estimativas.

Uma outra forma de estimar os Pontos de História é encontrar a historia mais simples do backlog. Esta será a história de referencia e seu tamanho é por definição 1. As outras histórias serão comparadas com esta e os numeros serão escolhidos de acordo com o tamanho relativo sempre tendo em atenção que os tamanhos das historias são proporcionais.

Durante o processo existirão historias que são menores que a historia de referencia e maiores que uma simples tarefa de uma pessoa. Assim, essa historia encontrada será a nova referencia e seu tamanho será 1.  A antiga historia de referencia é comparada com essa e um novo valor do seu tamanho é atribuido ( digamos 3). Todas as historias já estimadas anteriormente têm seus valores multiplicados por tamanho da historia de referencia antiga na nova escala ( 3, no caso). Os resultados são então arredondados para o numero na escala mais próximo conforme discussão entre a equipa. Por exemplo, uma historia cotada em 2 SP agora vale 3×2 = 6SP Os numeros mais proximos seriam 5 ou 8. A equipa tem que decidir se a historia se aproxima mais de um 5 ou de um 8.

Este esquema é chamado Estimativa por Tamanho Relativo e é o mais correto porque não introduz nenhum conceito de tempo, isolando assim, totalmente as duas coisas. Contudo é um sistema complexo de utilizar na prática, sobretudo com equipes Scrum novatas.

Seja pelo sistema de Tamanho Relativo, seja pelo de Dias Ideias, as historias têm o seu tamanho estimado. O Dono do Produto pode agora, em consciencia, trabalhar com essas estimativas para escolher quais historias vai incluir em quais releases.

No fim da fase de planejamento de lançamento os artefactos que temos são um Product backlog e um ou mais Release Backlogs.  É agora hora de executar o plano. Que começem os sprints.

Planejamento de Sprint

Durante o planejamento do Release é necessário estimar quantos sprints serão necessários para completar o Release. Para saber isto é preciso definir vários parametros do Sprint e conhecer a Velocidade da Equipa.  Mais sobre isto na seção dedicada ao Sprint.