Não é novidade para ninguém que desenvolver produtos envolve diversas pessoas, etapas e investimentos. Quando falamos então de desenvolvimento de produto através da metodologia ágil, é indispensável pensarmos no uso de algum método (como o Scrum) na gestão de backlog.
Pensando nisso, e sabendo que em um cenário desses é necessário realizar a manutenção de um product backlog – ou seja, de uma lista priorizada de atividades a serem desenvolvidas – aqui veremos um pouco sobre como essa gestão é feita no dia a dia.
O trabalho de Product Owner
Em uma equipe que aplica o Scrum, temos a realização de ciclos de desenvolvimento sucessivos que chamamos de sprints. Quando uma sprint termina, a próxima se inicia automaticamente, e assim seguem-se as iterações, com suas diversas cerimônias. Dessa forma tão contínua, como a equipe sabe o que deve desenvolver e em que momento? Como garantir que a equipe tenha informação suficiente sobre o que ela deve desenvolver?
A resposta dessa pergunta gira em torno do trabalho exercido pelo Product Owner, em manter o product backlog atualizado e priorizado. O PO é a pessoa que fará a ponte entre a equipe de desenvolvimento e todos os stakeholders do produto. Além de estabelecer uma boa comunicação, o PO deve colher e lapidar as ideias dessas partes junto ao time de Produto e Design. Dessa atividade contínua, surgem as tarefas que o time vai desenvolver para agregar o máximo valor possível ao produto a cada entrega.
Refinamento de backlog
Cada sprint se inicia logo após a outra, sucessivamente. Isso significa que, ainda durante o ciclo de uma sprint, o PO deve estar trabalhando para definir o que vai entrar na próxima. Isso é possível por meio do que chamamos de product refinement.
Embora não seja uma cerimônia regrada pelo Scrum, ela ocorre quando o PO está ali, durante a sprint, organizando e deixando claro para toda a equipe o que deve vir em seguida. Não é uma atividade unilateral: o PO deve estar em contato com a equipe, validando o entendimento e a viabilidade de cada tarefa em conjunto.
Mas é certo que algumas decisões, principalmente as mais técnicas, não vão ser de competência do Product Owner. Isso cabe aos tech leads envolvidos no debate. Esse é apenas um exemplo de como o PO deve manter a comunicação e o alinhamento com sua equipe, visando a entrega de valor a cada ciclo. Assim, é possível refinar o backlog antes da próxima cerimônia de planejamento.
Vale ressaltar que não importa a forma como a comunicação se desdobra. Há equipes que preferem realizar reuniões de refinamento, enquanto outras optam pelo modelo assíncrono. O importante é fazer o que for o melhor para todos, garantindo que os itens da a próxima sprint estejam listados antes de seu início.
User Stories
Uma ferramenta muito usada no desenvolvimento de produto é a User Story (ou “história do usuário”), por meio da qual podemos fazer uma descrição da funcionalidade a ser desenvolvida, partindo da perspectiva do usuário/persona. User Stories se tornaram muito famosas a partir do uso do framework ágil Extreme Programing (XP), pois conseguem fazer com que qualquer pessoa organize suas ideias para, de forma direta e resumida, se colocar na visão de um usuário, exprimindo uma vontade que revela um valor agregado ao negócio. Essa é a forma correta de se escrever uma User Story:
Refinar o backlog é, portanto, trabalhar nos seus itens para que fiquem totalmente claros e concisos, prontos para desenvolvimento. Vale ressaltar ainda que User Stories podem ser itens de backlog, mas os itens de backlog não precisam ser, necessariamente, User Stories.
Definition of Ready (DoR)
Seguindo essa linha de pensamento, o que significa deixar os itens prontos para sprint? A Definition of Ready (DoR) ou definição de “pronto para desenvolvimento” varia de acordo com cada equipe. Mas, basicamente, seria uma lista de requisitos a cumprir para que aquela User Story seja considerada apta a fazer parte da sprint.
É muito comum que os refinamentos ocorram ao longo de várias reuniões com a equipe, com os líderes, e as demais pessoas envolvidas. Até chegar ao “ready”, a equipe tem que passar por todo um processo de entendimento sobre o contexto de negócio, trazido pelo Product Owner, que deve explicar por que tomou a decisão de conduzir o backlog daquela forma.
Quando a equipe entende o contexto do negócio, fica muito mais fácil propor soluções. Como eu gosto de dizer e ressaltar, não existe uma hierarquia entre o PO e as pessoas desenvolvedoras. Meu trabalho não é dizer como os engenheiros e designers devem desenvolver o produto – pelo contrário, eles têm muito mais expertise técnica para propor as soluções..
Critério de aceite
Já vimos como definir que um item está pronto para entrar em uma sprint, mas como saber se aquele item está completo? Da mesma forma que definimos requisitos que atestam se um item está pronto para ir para desenvolvimento, definimos critérios mínimos para considerar aquele item como apto ao final, ou seja, critérios para testar se o que foi proposto foi realmente alcançado naquela funcionalidade.
Estimativas
Com os itens já definidos e refinados para nova sprint, durante a cerimônia de planejamento eles costumam ser esmiuçados em tarefas menores e estimativas. É importante usar as estimativas não apenas para garantir que o escopo da sprint não ultrapassará sua duração, mas para que toda equipe tenha um entendimento compartilhado daquela tarefa, fazendo com que cada pessoa estime de forma parecida.
Com esse tipo de gestão de backlog e alinhamento, a equipe é capaz de amadurecer seu entendimento em relação aos itens. Consequentemente, consegue chegar num nível de estimativa através de story points, ou seja, definir quantas pendências a equipe consegue desenvolver a cada sprint. Em equipes menos maduras no agile, essas estimativas costumam levar horas.
Conclusão
A gestão de backlog é um trabalho contínuo que requer proatividade e cuidado especial do Product Owner, pois você vai desenvolver o produto a partir dessa atividade.
A qualidade do produto desenvolvido está estritamente ligada à performance da equipe em trabalhar conjuntamente, propondo soluções. As ferramentas e definições que listadas aqui partem dos meus estudos e da minha experiência pessoal, mas vale lembrar que frameworks são apenas um ponto de apoio. Ou seja, as equipes devem usar de forma a conseguir tirar deles o melhor proveito possível, considerando que não há um jeito certo ou errado.
Leia também:
