Implantar o trabalho ágil nas equipes e organizações não é uma tarefa que pode ser realizada da noite para o dia. Quando as empresas e seus times começam a atuar sob as premissas do manifesto ágil, percebem quanta preparação é necessária para fazer com que atividades e processos fluam de maneira tranquila e eficiente. Não importa se o método utilizado é o Scrum, Kanban ou XP. Sem a compreensão do real significado destas duas palavras – trabalho ágil – há grandes chances de encontrar problemas pela frente, com alta possibilidade de ser necessário ajustar a rota no meio do caminho.
De maneira geral, quase todos os modelos ágeis têm em comum o backlog, um repositório de requisitos que são, essencialmente, uma lista de tarefas do projeto. É ali que ficam documentadas todas as histórias dos usuários, informações que fazem parte de um banco de dados colaborativo, controlado pelo proprietário do produto.
Para ter um sprint (nome dado a cada uma das etapas de um projeto desenvolvido) bem-sucedido, a equipe precisa refinar todas as histórias do backlog, garantindo que todos os processos estejam concluídos. Inserir tarefas inacabadas ou não editadas no sprint final pode causar problemas durante o ciclo de implementação do produto.
Identificando a Definition of Ready (DoR)
O Scrum Guide tem um capítulo sobre a Definition of Done (definição de feito, em português), mas não sobre a Definition of Ready (definição de pronto, em tradução literal). Por isso, em alguns casos, equipes e organizações têm dificuldade de criar sua própria DoR para itens no backlog.
Para evitar dúvidas ou problemas nesse processo, usualmente se estabelecem alguns padrões que possibilitam entender que um dos itens de backlog está pronto. Em outras palavras, a definição de pronto estabelece os critérios que uma história de usuário específica tem que cumprir antes de ser considerada para estimativas ou inclusão em um sprint.
O primeiro deles é a clareza. Uma história de usuário fica clara se todos os membros da equipe entendem o que ela significa. Escrever histórias de forma colaborativa e acrescentar critérios de aceitação para as de maior prioridade facilita a compreensão e, por consequência, a clareza. Outro ponto fundamental é ser factível. Uma história de usuário precisa ser passível de ser concluída em um sprint, de acordo com a definição de feito. Se isso não for possível, precisa ser dividida ainda mais. Também é preciso que ela seja testável. Um item pode ser testado caso haja uma forma efetiva de determinar se a funcionalidade age como o esperado.
Para criar a definição de pronto também é possível utilizar a metodologia INVEST, que ajuda a refinar histórias e gerar mais qualidade nas contribuições nos sprints. A técnica, cujas letras da sigla representam cada uma um critério a ser considerado, pode ser usada pela equipe como um guia para garantir que as histórias sejam independentes, negociáveis, valiosas, estimáveis, sucintas e testáveis. Na prática, isso significa que o trabalho precisa gerar valor sozinho; que conceitos como “por que” e “o que” precisam ser compreendidos por todos; e que o valor gerado para os stakeholders deve estar claro para o time. A complexidade e o esforço para fazer o trabalho precisam ser definidos e a equipe precisa ser capaz de mensurar isso.
A história também precisa ter o tamanho certo para não sobrar ou perder itens que deveriam ser entregues. Para isso, as equipes podem usar diferentes técnicas de medição (T-Shirt Sizing / Animals Sizing / Planing Poker) e deve ser possível escrever um teste para cada história. Os testes, muitas vezes, são usados como um critério de aceitação e, se não é possível pensar em um teste, talvez a história esteja imprecisa demais. A história precisa ser refinada o suficiente para que a equipe possa fazer seu trabalho de maneira assertiva e efetiva.
Construindo a Definição de Feito (DoD)
A DoD é um acordo dentro da equipe sobre os critérios que devem ser atingidos antes que uma história de usuário seja considerada “feita”, ou seja, devidamente concluída. Se uma história não atinge esses critérios, então normalmente será considerada inacabada e não será contada na velocidade do sprint. Embora isso possa variar significativamente em cada equipe, os membros devem ter um entendimento compartilhado do que significa um trabalho concluído, para garantir a transparência.
Um exemplo de lista de verificação para a definição de feito envolve construção de projetos sem erros, testes unitários escritos e aprovados, considerar se o projeto foi implantado no ambiente de testes, realização de questionário de garantia de qualidade e solução dos problemas encontrados. Também é preciso considerar se ferramenta foi testada em relação aos critérios de aceitação, se foi liberada pelo proprietário do produto e se a documentação/diagramas relevantes foram produzidos e/ou atualizados.
Esse processo pode ser comparado com o trabalho das equipes de Pit Stop na Fórmula 1. Altamente ágeis e precisas, elas resumem a importância do acompanhamento de todo o time para que nada de errado aconteça na ponta. Assim que o carro estaciona no box toda a equipe está pronta para começar o Sprint (no caso, a chegada do carro). Todos sabem suas posições e o que devem fazer para ser bem-sucedidos na entrega. O sprint (troca de pneus, conferência do carro etc) começa e cada um desempenha a sua função. O processo termina e o incremento do carro foi realmente feito e está pronto para ser entregue: o carro pode voltar para a pista e continuar a correr.
Se o líder notificar o proprietário do produto, neste caso o piloto, que o incremento está pronto antes da hora haverá um grande dano, que vai impactar a todos os envolvidos no processo, o processo em si e o produto final. É a mesma coisa que acontece dentro de qualquer equipe ágil, o que torna a DoD fundamental. Ela precisa ser seguida e o incremento realmente precisa estar feito, sem necessidade de ajustes, antes de passar para o próximo passo. Trabalho ágil, eficiente e consciente.
João José Silva, territory service manager na Red Hat.
