Encolha suas estórias
Muitos times que tentam implementar processos ágeis reportam não colher os benefícios prometidos. Isso pode ter inúmeras causas, mas uma que passa frequentemente desapercebida é que e as estórias vão inflando a medida que pressões do dia a dia começam a aparecer. Não estou falando da estimativa em pontos, mas sim do escopo esperado de uma estória. Tentar fazer demais em uma estória compromete o fluxo, aumenta o ciclo (tempo de provisionamento) e gera frustração no time. Uma equipe ágil que busca entrega contínua e iterativa deve tentar reverter essa tendência.
Normalmente consideramos a sigla I.N.V.E.S.T., cunhada por Bill Wake, como o instrumento de medida padrão para boas estórias. Vamos ver o que ela significa:
Independente (Independent) – Realiza valor incremental imediatamente
Negociável (Negotiable) – Não é um contrato, pode ser alterada por uma conversa
Valor (Valuable) – Torna a experiência melhor para alguém
Estimável (Estimable) – Pode ser comparada relativamente com outras estórias
Sucinta (Small) – O menor incremento possível
Testável (Testable) – Você sabe quando está pronto
Apesar de útil, esse acrônimo pode fazer um desserviço para times iniciando em ágil, pois ele sacrifica a ordem de importância para compor uma palavra em inglês. Por exemplo, é importante que uma estória seja independente, mas isso não é mais importante do que ela ter valor (e provavelmente é menos). Assim, quem começa a avaliar suas estórias de cima para baixo, vai primeiro verificar se ela é independente, e sacrificar a qualidade da estória antes mesmo de verificar se ela tem valor. eu considero mais importante me perguntar se uma estória tem valor e se ela é testável. O time pode até insistir em fazer o esforço, mas deve se perguntar por que isso é tão importante ou como vai saber quando pode considerá-la pronta. A próxima etapa é tentar balancear sua independência com o seu tamanho (sucinta) – para ser sincero, eu raramente olho para as outras duas características (negociável e estimável).
Por que estórias grandes são ruins
Maior risco de erro
Além dos prejuízos óbvios para o fluxo (estórias maiores levam mais tempo para terminar), estórias grandes demais também causam outros problemas. É mais provável que detalhes importantes acabem se perdendo se a estória for grande demais. Na verdade, é comum reduzir o número de critérios de aceite totais quando se divide uma estória grande em múltiplas, porque a complexidade é acrescentada iterativamente (para entender por que isso acontece, imagine, por exemplo, tentar descrever todas as raças de cachorro em prosa ao invés de em uma hierarquia). Isso impacta até mesmo os desenvolvedores que estão codificando a estória. Se uma estória tem dezenas de critérios de aceite. É muito mais provável de um ser esquecido do que se ela tem meia-dúzia.
Dependências fora de controle
O controle de escopo e a priorização são muito mais fáceis com estórias pequenas. Se eu tenho uma estória que exibe “nome”, “foto” e “descrição”, eu só posso retirá-la do escopo se eu não preciso mais de algum dos três elementos. Caso eles estejam em três estórias separadas, eu posso preferir fazer dois deles agora e adiar outro ou removê-lo do escopo completamente. Claro que ao escrever a estória, somos tentados a agrupar coisas simples para “facilitar”, mas isso traz a premissa implícita de que todos são igualmente simples e o custo de fazer os três ao mesmo tempo é o mesmo. Se isso não for verdade, pode se perder muito tempo até perceber que isso está nos segurando. É muito melhor entregar três estórias breves em sequência do que ficar bloqueado com uma estória grande. Se essa estória grande (ou mais provavelmente uma pequena parte dela) bloquear muitas outras, isso pode ter consequências ainda piores!
Previsões ruins
Além disso, por causa da regressão a média, estimativas de diversas estórias pequenas são muito mais precisas, para o mesmo prazo total. Da mesma forma que quando jogamos um dado cem vezes podemos esperar que a distribuição de resultados seja mais homogênea do que quando lançamos 10 vezes, quando se estima cem estórias, é natural haver um erro aleatório, em algumas para mais, em outras para menos, mas quanto maior o número de estórias, mais provável é que a média seja mais próxima da realidade. Além disso, é naturalmente mais fácil de estimar estórias pequenas, aonde os detalhes podem ser todos considerados ao mesmo tempo, do que estórias grandes que certamente apresentarão casos mais complexos.
Em suma, estórias menores tendem a ser mais precisas, permitem um melhor acompanhamento do progresso, permitem que o time mude de ideia rapidamente e aumenta a confiança do time na entrega.
Fazendo estórias ainda menores
Para escrevermos estórias menores, podemos utilizar alguns truques que diminuem a ansiedade de ter coisas “pequenas demais para ter importância”:
- Lembre que em desenvolvimento ágil com entrega contínua, ir para produção é uma decisão de negócio – não uma decisão técnica – portanto o negócio pode decidir lançar algo em produção apenas quando todas as estórias pertinentes estejam prontas (ou pode mudar de ideia e não esperar todas estarem prontas!)
- Divida as estórias em pedaços pequenos e verticais atravessando todas as camadas (como se fosse um bolo). Mesmo que possa parecer mais trabalhoso, na prática a independência que estórias divididas dessa forma traz permite que futuras estórias semelhantes melhorem iterativamente a implementação, diminuindo a pressão por “fazer tudo certo da primeira vez”
- Não descreva a implementação, mas sim o valor esperado. Normalmente, um problema bem entendido acaba sendo mais fácil de resolver do que a solução imaginada a priori. Lembre de buscar identificar o mínimo valor incremental que pode ser testado, por mais insignificante que ele pareça
- Não se preocupe se no começo do projeto as estórias forem grandes. É nessa hora que – para diminuir o risco – se implementam funcionalidades cruciais. O importante é garantir que à medida que o projeto avança, as estórias ficam cada vez menores
Agora é só olhar para o seu backlog e se perguntar quais estórias poderiam ser menores. Não tem por que não tentar imediatamente!
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.