custo/benefício.
Através dessa colaboração entre a equipe de desenvolvimento e o cliente é pos-
sível traçar um plano para atingir sucesso no projeto. O jogo do planejamento é
dividido em duas fases: o planejamento de releases e o planejamento de iterações.
Um dos principais benefícios do planejamento iterativo é a eliminação do des-
perdício de uma longa análise prematura, que é considerado um dos maiores des-
perdícios no desenvolvimento de software [49]. É comum em projetos waterfall que
a análise de todos os requisitos seja feita de antemão, de forma que no momento
do desenvolvimento os requisitos já mudaram e da maneira que foram analisados já
não podem mais agregar valor ao cliente. Essa prática de levantamento prematuro
de requisitos é conhecida como Big Requirements Up Front (BRUP).
36
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
Backlogs DEEP
Para ajudar Product Owners a não caírem no erro do levantamento
prematuro de requisitos, Mike Cohn, criou o acrônimo DEEP [20] que
representa 4 qualidades de um bom backlog:
1) D - Detalhado Apropriadamente: Os itens de maior prioridade devem
ser mais detalhados e os itens de menor prioridade não precisam de
muitos detalhes.
2) E - Estimado: Se todos os itens do Backlog estiverem estimados pela
equipe, o PO terá mais facilidade em priorizar o backlog e terá melhor
previsibilidade do projeto.
3) E - Emergente: O Product Backlog é um artefato vivo, isto é, deve mu-
dar frequentemente de acordo com as mudanças de negócio. Novos
itens são incluídos, itens antigos são removidos ou modificados.
4) P - Priorizado: Os itens do backlog devem estar priorizados do maior
valor de negócio para o menor valor de negócio para que os itens mais
importantes sejam detalhados e implementados antes dos menos im-
portantes.
Além disso, em abordagens tradicionais, era muito comum que os requisitos fos-
sem transmitidos ao desenvolver apenas por escrito através de um documento. Em
contrapartida, a essência da comunicação nos métodos ágeis é a comunicação face
a face.
De acordo com Alistair Cockburn, a comunicação através de papel é fria e pobre,
porque não há oportunidade para perguntas e respostas, a comunicação entre pes-
soas face a face é quente e muito mais rica porque oferece a oportunidade de iteração entre as partes [17].
É claro que isso não torna, de forma alguma, a comunicação escrita irrelevante,
pelo contrário, ela também é importante, mas não é suficiente, e nem mais eficiente
em todos os cenários.
É por isso que muitos métodos ágeis defendem a ideia de uma reunião de pla-
nejamento em que a equipe e o Product Owner participem juntos, e que, através de
37
3.3. Planejando uma Iteração
Casa do Código
uma conversa, criem histórias de usuário que representam as funcionalidades a se-
rem implementadas no software.
Ao decorrer deste capítulo, o conceito de histórias de usuário será mais ampla-
mente explorado, mas, antes disso, explicaremos um pouco mais o que se faz em um
planejamento de iteração.
3.3
Planejando uma Iteração
O planejamento de iterações permite estruturar as atividades do dia a dia da equipe.
Um release pode conter várias iterações (figura 3.1), de forma que as histórias que
precisam ser entregues no release são incluídas em uma ou mais iterações. Durante
a iteração as histórias são desenvolvidas e no final se tem um software desenvolvido e testado e, ao terminar uma iteração, uma nova iteração
é iniciada.
Figura 3.1: Releases e Iterações
As iterações geralmente têm periodicidade semanal, porém, tanto o tempo das
iterações como dos releases podem ser definidos de acordo com a necessidade de
cada organização. O tamanho ideal para uma iteração é o menor tempo possível que
seja necessário para que a equipe consiga entregar algo de valor com qualidade para
o cliente.
Ao planejar uma nova iteração, é importante ter em mãos o resultado da iteração
passada, isto é, a soma das estimativas das histórias que foram desenvolvidas. Esse é o número de pontos de estimativa que se pode esperar para a próxima iteração. Essa
soma de pontos é conhecida como velocidade da equipe. Há quem utilize uma média
das velocidades das iterações passadas para definir quantos pontos de complexidade
serão inseridos na nova iteração e há quem prefira utilizar apenas a velocidade da
última iteração.
Para inserir as histórias na iteração é preciso que elas estejam estimadas em com-
plexidade e priorizadas segundo o valor de negócio, o que provavelmente já terá sido 38
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
feito no planejamento de release. Dessa forma, selecionar as histórias para a iteração, geralmente, é algo rápido. O cliente verifica história por história, e as inclui na nova iteração de acordo com a prioridade. A somatória de pontos das histórias selecionadas, idealmente, não deve ser maior do que a definida, seja com base na iteração
passada ou na média das anteriores.
Depois de selecionadas quais histórias serão implementadas na nova iteração, é