Atualizado em 29/12/2019 com os slides e vídeo!
Quem trabalha comigo há algum tempo sabe o quanto eu repito a frase “agile não é bagunça” e quando o assunto é o backlog do time, isso não pode ser menos verdade. Existe uma má interpretação do Manifesto Ágil e da própria cultura Lean-Agile em geral que entende que não se precisa ter documentação em projetos rodando sobre frameworks ágeis.
Pura mentira!
A grande mudança de mindset nos métodos ágeis é criar a documentação estritamente necessária e somente quando for necessária, ao invés de gastar meses escrevendo documentos de Visão do Produto, Especificações Funcionais e Não-Funcionais e por aí vai. Isso não quer dizer, no entanto, que jamais vamos ter este tipo de documentação ou algo próximo à elas, mas que vamos distribuir a sua produção ao longo de várias sprints conforme nosso entendimento for aumentando e a necessidade se torne emergente.
E por que eu falo que agile não é bagunça?
Porque justamente em um ambiente auto-gerenciável e sem metodologias prescritivas é que precisamos do mais alto grau de organização e isso começa com nosso requisitos ágeis. No artigo de hoje falarei sobre três acrônimos bem populares para ajudar na organização dos requisitos ágeis:
É importante ressaltar que estes acrônimos são norteadores para a criação e organização destes artefatos e de que não devem se tornar uma “religião” nem criar fanáticos que impeçam os projetos de prosseguirem apenas porque alguma demanda não atende 100% a todos requisitos do acrônimo. Use-os como guias e não como grilhões.
No final deste artigo você encontra este material em forma de slides e nesse link você vê o vídeo da minha palestra sobre este assunto.
Vamos começar?
Backlog DEEP
DEEP é um acrônimo para Detalhado, Estimado, Emergente e Priorizado e são as características que o Product Owner deve buscar sempre em seu backlog.
Detalhado quer dizer que o backlog deve ter os detalhes suficientes para garantir clareza que propicie execução, mas não detalhado em demasia que gere desperdício. Entenda que a necessidade de profundidade no detalhamento é proporcional à emergência de uso do backlog, ou seja, os itens que vão entrar na próxima sprints (mais emergentes) devem estar melhor detalhados, enquanto que os itens que vão entrar daqui a várias sprints, podem estar bem menos detalhados.
Estimado quer dizer que todo item quando chega a um nível de detalhamento suficiente deve ter uma estimativa de esforço associada a ele, uma vez que o backlog não é apenas uma ferramenta de trabalho, mas e planejamento. Essa estimativa pode ser em horas, em pontos, em t-shirt size, em E/EE/EEE ou o que você possa imaginar e que faça sentido para seu time. Essa estimativa inclusive lhe auxilia a entender se o nível de detalhes está bom o suficiente, pois via de regra itens de backlog com uma estimativa muito alta deveriam ser quebrados em itens menores (a técnica de Planning Poker ou de Nivelamento de Features ajuda nisso).
Emergente quer dizer que o backlog evolui conforme o Product Owner vai aprendendo sobre o produto e o mercado vai lhe dando feedback sobre seus lançamentos (seu MVP, por exemplo), ele não é estático. O constante refinamento do backlog permite que o produto reaja bem a mudanças de estratégia e de escopo, ao invés de se apegar a um planejamento waterfall. O segredo aqui é rever todo o backlog a cada ciclo construir-medir-aprender do Lean Startup.
Priorizado quer dizer que a ordem em que os elementos estão dispostos no backlog importa. Os itens mais prioritários devem estar ao topo, enquanto que os menos prioritários devem estar mais embaixo. Os critérios e técnicas utilizados para priorização variam muito de Product Owner para Product Owner, de produto para produto e de mercado para mercado. Para o Scrum, não importa qual é a sua técnica, mas sim que o resultado deve gerar valor para os clientes e para a empresa.
Histórias INVEST
O acrônimo INVEST é um trocadilho para dizer que devemos “investir” tempo na escrita de boas histórias de usuário, tema de outro artigo aqui do blog. INVEST significa Independente, Negociável, Valiosa, Estimável, Small (Pequena) e Testável.
Independente significa que uma boa história de usuário não depende de outras e que outras não dependem dela. Que qualquer história deveria poder ser desenvolvida em qualquer ordem, conforme a prioridade que o Product Owner determinar. Sabemos que isso não é lá muito fácil de se alcançar, mas é sempre bom chegar o mais próximo possível disso.
Negociável significa que toda boa história é uma co-criação, uma negociação entre profissionais de negócio e profissionais técnicos. Uma história deve capturar a essência de um requisito, mas não os seus detalhes, que devem ser criados de forma colaborativa e emergente. Ao longo do tempo, mais detalhes serão adicionados a cada história conforme o produto evolui e os usuários demonstram novos comportamentos. Aqui entram os 3C’s necessários em todas histórias: Card, Conversation e Confirmation.
Valiosa quer dizer que toda história deve agregar valor ao produto e principalmente, ao usuário-chave da mesma. Uma historia jamais deveria agregar valor apenas ao desenvolvedor ou apenas ao negócio, e sim sempre centrada no cliente. O Product Owner sempre se deve perguntar se ele tornará melhor a vida do cliente ao colocar aquela historia em produção. A técnica de Nivelamento de Features pode ajudar a determinar o quão valiosa é cada história.
Estimável é semelhante ao que já falamos no DEEP sobre o backlog. Para entregar um backlog estimado que me permita planejar meu roadmap de produto, é necessário ter histórias estimadas primeiro. E para conseguir estimar as histórias elas precisam ser pequenas e claras, com detalhes suficientes e bom nível de entendimento entre negócio e técnicos. Esta estimativa não precisa ser precisa, mas deve dar noções de grandeza que ajudem na tomada de decisão, priorização, etc.
Small (Pequena) para que seja possível entregá-la em no máximo uma sprint, caso contrário ela será um épico. O grande desafio obviamente é o equilíbrio entre histórias pequenas o suficiente para que seja possível estimar, mas não tão pequenas que não entreguem valor algum para o cliente. Na verdade esse é o desafio de todo o INVEST, conciliar todas as características desejáveis em uma história. Via de regra, uma história não deveria levar mais do que alguns dias de um par de programadores trabalhando nela, se está levando mais de uma semana é uma dica de que deveríamos pensar em quebrá-la.
Testável indica que toda história deve poder ser coberta de testes para validar se seus requisitos funcionais e não-funcionais foram atendidos, geralmente abordados nos critérios de aceitação da história. Uma história que não podemos testar para garantir seu funcionamento não é uma boa história, pois ou não está Independente ou é pequena demais e não entrega valor algum.
Tarefas SMART
E para terminar, o acrônimo SMART é o mais famoso dentro e fora da computação uma vez que é usado para definir muito mais do que tarefas de qualidade, mas boas métricas, bons objetivos e por aí vai. Isso porque SMART é um acrônimo para Specific (Específica), Mensurável, Alcançável, Relevante e Temporal.
Specific (Específica) indica que toda tarefa deve ter uma responsabilidade única, ser coesa com seu objetivo e entregar apenas uma parte de uma história de usuário. Para quem é programador, é o mesmo que aplicar o princípio SRP (Single Responsibility Principle) do SOLID para tarefas. Ser específica ajuda a história ser Alcançável, Mensurável e Temporal, além de garantir o entendimento de todos no time.
Mensurável é uma característica desejável para apoiar o planejamento da sprint. Se eu não tenho como medir uma tarefa, como sei se entregaremos ela a tempo? Aqui não importa a unidade de medida, embora o ágil encoraje muito mais o uso de pontos do que de horas, desde que a unidade faça sentido para todos no time e gere informação valiosa para o time e para a empresa.
Alcançável é um requisito básico para toda tarefa. O time tem que ter as competências e recursos necessários para conseguir entregar a tarefa. Simplesmente não adianta definir como prioridade uma tarefa que ninguém sabe fazer ou que vai levar tanto tempo que ela por si só deveria ser uma história ou épico. Definir tarefas inalcançáveis para o time é o primeiro passo para perder o time, até mesmo por isso que geralmente a atividade de quebra de histórias em tarefas e feitas pelo Dev Team e não pelo PO.
Relevante tem a ver com o valor que esta tarefa agrega ao todo da história. Se a tarefa não agrega em nada, ou seja, é irrelevante para a história, ela não deveria ser feita. Tarefas são quebradas para ajudar os desenvolvedores a organizarem seu trabalho, mas cada uma deveria poder ser explicada em como contribui para a história principal.
Temporal quer dizer que toda tarefa tem um tempo para ser realizada, ela tem de estar delimitada a uma timebox específica, previamente combinada entre os membros do time e utilizada para ajudar na priorização e planejamento da sprint.
Claro, nenhum desses acrônimos é bala de prata e usar todos eles juntos, todos os dias, é um desafio imenso. Mas não desista, é justamente esta busca pela perfeição no trabalho com backlog, histórias e tarefas que cria maturidade em times ágeis.
E você, conhece algum outro acrônimo que eu não citei aqui? Deixe nos comentários!
* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!
