Product Backlog é a relação de
requisitos do produto a ser desenvolvido. Neste momento eu estou
tomando como premissa que já foi realizado os trabalhos de criação
do Backlog.
Um backlog deve ser organizado com
os desejos do cliente de maior prioridade na parte de cima e os
desejos do cliente de menor prioridade a baixo.
O backlog deve ter cada desejo
estimado conforme o seu esforço, existem técnicas de Pontos de
História, Dias Ideais, ou qualquer técnica de estimativa que a
equipe ou empresa tenha desejo de utilizar.
Figura 1: Backlog organizado do mais
importante a cima e menor importante a baixo, bem como o tamanho de
esforço para fazer cada item do backlog
Uma técnica de medir a qualidade do
backlog é a DEEP, que determina que um backlog possua um
detalhamento apropriado dos desejos pelo Product Owner, que este
detalhamento permita uma estimativa pela equipe, que exista a
consciência de todos que o backlog não é estático e com isso pode
ser mudado no decorrer do projeto e que ela seja priorizado para
entregar valor de negocio ao nosso cliente.
Figura 2: Backlog DEEP
Figura 3: Exemplo de Backlog
O backlog não tem necessidade de
ter todos os seus desejos especificados para o inicio do
desenvolvimento. Um trabalho de especificar todos os desejos para
depois iniciar o desenvolvimento de software vai promover um tempo
muito grande, o que pode gerar desperdício pelas mudanças de
desejo ou mudanças de interpretação dos desejos.
Figura 4: Backlog e Sprints
Devemos ter um detalhamento dos
desejos apenas referente a sprint que vai ser desenvolvida ou algumas
sprints a mais. Conforme o desenvolvimento vai sendo realizado, mais
detalhamento dos desejos são realizados em paralelo, mantendo a
distancia de tempo entre o detalhamento do desejo do cliente e a
entrada para a equipe de desenvolvimento sempre curta.
Figura 5: Desenvolvimento do Time e
Detalhamento dos Desejos em Paralelo
Figura 6: Não detalhe todos os
desejos do projeto, apenas os que vão ser desenvolvidos
Nem sempre todas as pessoas
conseguem ter uma visão do backlog organizado em uma planilha. Para
isso podemos utilizar o conceito de FBS (Feature Breakdown
Structure), onde podemos mostrar graficamente os desejos nos seus
tamanhos e decomposições.
Figura 7: FBS
Conclusão
Ter um backlog vivo onde desejos
podem entrar ou sair a qualquer momento, mesmo nos últimos momentos
do projeto, não é fácil de ser aceito para quem esta iniciando em
metodologias ágeis. Também não é fácil quebrar o paradigma de
especificar, isso é, entender todos os desejos do cliente, deixando
o detalhamento próximo da etapa de desenvolvimento de software.
Esses paradigmas são difíceis de
ser quebrados, mas eles são possíveis pela mudança cultural que é
a entrada do Product Owner no projeto. Devemos lembrar que ele é o
responsável pela definição de desejos que permita o projeto ser
bem sucedido ou não com relação ao seu retorno de investimento
(ROI).
Cabe a responsabilidade dele,
Product Owner, junto com a equipe ter a visão de grandeza do que é
possível ser feito ou não de desejos conforme o tempo que o projeto
possui.
O Product Owner é o único que pode
autorizar o desenvolvimento de um desejo e ter a sua presença no
projeto de maneira comprometida é um dos segredos de sucesso das
técnicas ágeis.
Abraços,
Abu
Este post faz parte do material
"Pensamentos Ágeis: Uma Coletânea de ideias de como penso sobre Ágil"
Postagens
