o número de pontos que considera que a história consumirá.
Quando houver grandes diferenças, as pessoas que jogaram as cartas de maior e
menor valor explicam suas razões para escolher aquele valor e, então, com base nas
explicações, as cartas são jogadas novamente até que um consenso seja encontrado
e a estimativa seja definida.
Na realidade, não importa qual técnica sua equipe utiliza, o importante é que
todos os membros da equipe participem e que seja definido um valor de esforço
ou custo para que seja possível medir a velocidade da equipe para fundamentar
o planejamento de releases e dar uma certa previsibilidade para os interessados
(stakeholders).
3.10
Definindo Entregas com o Planejamento de Re-
leases
O objetivo das reuniões de planejamento de releases é definir quando novos incre-
mentos do projeto serão, finalmente, instalados em produção. Assim como os outros
procedimentos, esta reunião também deve possuir uma cadência; geralmente, a cada
duas semanas ou mensal.
Todos os interessados do projeto podem participar da reunião. Especialistas de
integração, especialistas de redes, desenvolvedores, testadores, designers e todos que estiverem relacionados ao processo de entrega (deployment) devem estar presentes.
O importante é que a reunião seja composta pelas pessoas capazes de tomar decisões
técnicas, de negócio e gerenciais.
Quando o processo de release é muito complexo, pode ser interessante ter uma
pessoa responsável por
coordená-lo. É comum que um gerente de projetos assuma
esse papel, liderando a reunião, além de coordenar os releases.
Durante a reunião de planejamento de releases deve-se deliberar sobre que itens
irão compor o próximo release. Este é um momento oportuno para se levantar e con-
siderar os ricos, pensar sobre planos de contingência e treinamentos, analisar quanto tempo o processo de deploy deverá levar, quem deverá estar presente no momento
do deploy e quando ele será realizado.
57
3.10. Definindo Entregas com o Planejamento de Releases
Casa do Código
Para que os releases sejam curtos é necessário tentar dividir as histórias das itera-
ções em grupos que representem o mínimo possível de funcionalidade que agregue
algum valor. Dessa forma o cliente não precisará esperar muito tempo para receber
retorno de seu investimento, e receberá esse retorno frequentemente em funcionali-
dades que seriam adicionadas pouco a pouco ao produto, agregando assim cada vez
mais valor ao software.
O planejamento de releases oferece um mapa para alcançar o objetivo do projeto.
Imagine um projeto de seis meses para um supermercado. Poderíamos dividi-lo em
seis releases de um mês cada. No primeiro release poderíamos entregar o módulo
de gerenciamento de preços, no segundo release o módulo de pedido de compra,
no terceiro os relatórios gerenciais, e assim por diante. Assim, a cada mês o cliente poderia resgatar um pouco de seu investimento em forma de software.
É importante buscar entregar o máximo de valor agregado ao cliente a cada rele-
ase, mas isso não significa o mesmo que entregar o maior número de funcionalida-
des. É preciso entender o que agregará mais valor.
Muitas vezes uma única funcionalidade pode agregar mais valor do que dezenas
de outras juntas. No Scrum, por exemplo, fala-se do conceito de valor de negócio
ou business value, que pode ser representado por um intervalo numérico, como por
exemplo de 0 a 100. O valor de negócio é definido pelo PO, e é através dele que
a prioridade das funcionalidades a serem desenvolvidas é determinada. Esse valor
pode mudar ao longo do tempo, por isso é importante estar preparado para adaptar
o planejamento.
Outro fator importante em se tratando de priorização é detalhar e quebrar apenas
os requisitos de maior importância para que seja mais simples se manter as histórias priorizadas e organizadas. Por exemplo, se você está desenvolvendo um sistema financeiro, e sabe que não fará o calculo de financiamento nos próximos 5 releases, é
melhor manter apenas um épico Financiamento do que já quebrar em histórias es-
pecíficas Calcular Financiamento com Sistema SAC, Calcular Financiamento com
Sistema Price etc.
58
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
Mantenha o Backlog Pequeno
Para se ter uma ideia de como a complexidade de priorizar histó-
rias aumenta à medida que se adiciona histórias no backlog: se você
tiver 3 estórias no backlog (A, B, C), você pode ter 6 ordens de prio-
ridade diferentes (A, B, C), (B, A, C), (B, C, A), (A, C, B), (C, A, B) e
(C, B, A). Agora, se você tiver 5 itens, poderá ter 120 ordenações dife-
rentes, se tiver 10 itens poderá ter 3.628.800 e se tiver 20 itens poderá
ter 2.432.902.010.000.000.000 ordenações diferentes. Isso mesmo, é um
calculo fatorial, como nas corridas de cavalos.
Um dos principais benefícios dos métodos ágeis e do desenvolvimento em ite-
rações é a redução do tempo das entregas para o cliente. Durante o planejamento
de releases é importante procurar potencializar o time-to-market, por isso devemos