Produto e Projeto

O objetivo de um projeto gerenciado com Scrum é entregar o Produto. Mas o que é o Produto ?

O Produto é um conjunto de funcionalidades devidamente agrupadas. As funcionalidades que constituem o Produto são ditadas pela Equipe e filtradas pelo Dono do Produto  durante um brainstorm no inicio do Projeto. O Dono do Produto fará alguns cortes e alterações nessas funcionalidades imaginadas até que, com a ajuda de todos e num processo criativo, se possa chegar numa lista de funcionalidades que formarão o Produto.

A palavra “funcionalidade” é um termo do mundo do software. A palavra genérica do Scrum para isto é Historia. O termo em inglês é story (estória – conto) e não history (história – relato de fatos), contudo em português, pelo uso e costume, o termo historia já tomou os dois significados que em inglês permanecem separados. Falaremos então em Historias para traduzir o termo Story. E Pontos de Historia para traduzir Story Points.

Assim, um Projeto tem como objetivo entregar um Produto. E um Produto é um conjunto de Histórias. No caso de um projeto de software Historias são funcionalidades que a aplicação quem que ter.

Historias são equivalentes a requisitos. A diferença é que se escrevem em um formato mais util.  Cada historia é caracterizada por:

• um pequeno texto que a descreve;
• um nome;
• e um numero que a identificam. O numero é para poder manter rastreabilidade caso venhamos a decidir mudar o nome e/ou a descrição.

Desde ponto de vista uma historia é muito semelhante a um requisito.Além disso a historia contém:

• Uma estimativa do tamanho;  (ver Estimando Histórias)
• Uma descrição de quando se considera a historia pronta (ver Definição de Pronto)
• Uma prioridade. A prioridade é um numero inteiro maior que zero  que ordena a lista. Numero maiores significam maior prioridade. Não existe escala limite para os números. Duas histórias não podem ter numero de prioridade igual.

A estimativa do tamanho é dado pela equipa e a prioridade pelo Dono do Produto. Pela repetida interação entre estes dois polos a lista é reordenada periodicamente de forma que sempre as histórias no topo da lista serão aqueleas passiveis de serem implementadas pela Equipa e têm maior valor para o Produto, na visão do Dono do Produto.

A decrições, nomes, etc.. das histórias são mantidas juntas em uma lista ordenada por prioridade e formam o que o Scrum chama de Product Backlog.

Product Backlog

O Product Backlog é a lista de história que formam o Produto. Mudar o produto significa mudar a lista de histórias ou as histórias em si, e , mudar as histórias ou a lista significa mudar o produto. Esta correspondência simples entre o Produto – que é uma entidade abstrata ainda não perfeitamente compreendida – e uma lista simples de descrições de funcionalidades é que permite que a gerencia do projeto seja simples, clara e agil.

A Lista de Historias – o backlog – expressa diretamente o resultado do brainstrom da equipa e do Dono do Produto. Nem todas as historias na lista serão implementadas, isto porque a visão do Dono do Produto irá mudar. Ela muda por muitos fatores. Pressão dos investidores, posicionamentos do mercado, expectativas dos compradores, etc… o ponto é que a lista de histórias irá mudar. Isto é um fato que deve ser abraçado e não refreado. Tentar lutar contra este fato é como tentar conter uma explosão. Impossível.

Portanto temos uma lista dinâmica. O dinamismo vêm de várias formas:

• Adição de novas historias e/ou remoção de antigas
• Reformulação da mesma historia. Mudando do nome ou a descrição para que tudo fique mais claro.
• Alterando a prioridade da historia em relação às outras (mudar a posição que a historia ocupa na lista)
• Alterando a estimativa do tamanho da historia.

Release Backlog

Depois da definição do produto precisamos montar um sub-conjunto de funcionalidades que já possa ser encarado como uma versão aceitável do produto. Normalmente partimos de uma versão simples para uma mais rica.

Estes “pedaços” do produto que entregaremos como se fossem o produto final são chamados relases.  Em português traduziríamos por versão ou entrega, mas nenhuma desses conceito é equivalente. Release é um “pedaço” do produto que já pode ser utilizado como sendo o Produto e é lançado antes do Produto completo para gerar retorno o mais cedo possível. Não é uma demo, nem uma versão beta. É um produto completo em si mesmo, mas não é o Produto que antevimos no ínicio do projeto. A tradução literal de “release” é “liberação” que podemos adaptar para “lançamento”.  O Produto é constituído de vários Lançamentos. Cada lançamento pode ter várias versões ( de correção de bugs, por exemplo).

Para deixar claro, o objetivo do projeto é entregar o Produto. O Produto só está pronto no fim do projeto. Contudo, durante o projeto podemos entregar “pacotes” de funcionalidades que já atuam como o Produto. Ou seja, pode ser comercializado, utilizado e terá funcionalidades que o Produto oferecerá.

Outra forma de pensar é que o Projeto tem como objetivo entregar vários Lançamentos. Sendo o ultimo deles equivalente ao Produto que antevimos no inicio do projeto. Ou seja, o ultimo Lançamento terá todas as funcionalidades do product backlog e será portanto o Produto ele mesmo.

Sendo que visamos vários Lançamentos  precisamos tratar cada um como um Produto em si próprio:  completo, funcional e com valor de mercado. Assim sendo o Dono do Produto é responsável por definir quantos Lançamentos o Produto terá. É possível que seja definido apenas um Lançamento ou vinte. Não importa. Cabe ao Dono do Produto estipular isso.

Simultaneamente o Dono do Produto precisa estabelecer quais histórias farão parte de qual Lançamento. Muitas vezes isso implica em partir algumas histórias em histórias menores para que as mais simples ou necessárias sejam incluídas em Lançamentos anteriores.

O product backlog, a listagem principal que define o Produto é assim dividida em N listagens menores chamadas Release Backlog, onde N é o numero de lançamentos que serão feitos.

Se só um release for feito (N=1) isso significa que o Produto será entregue de um só vez. Isto é possivel se a lista de historias for curta o suficiente, mas normalmente este é um cenário irreal. Forçá-lo pode ser a causa do Projeto ter que ser abortado pois pode passar muito tempo até que tenhamos uma versão funcional com valor de mercado.

O Produto é, portanto, entregue em vários lançamentos (releases). O Product Backlog é dividido em vários Release Backlogs.

O Lançamento (release) é realmente o que a equipa vai entregar. O planejamento está agora completo e resta apenas a execução.