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 especí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
descobrir qual escopo necessário para agregar algum valor ao cliente e, então, definir um release para entrega. Quanto menores forem os ciclos de release, mais rápido o
cliente poderá se beneficiar do produto, e oferecer feedback para que ele possa ser melhorado.
Para traçar um planejamento de releases é preciso estabelecer períodos fixos de