
Sua história é uma hipótese… e ai?
Por Anselmo Eduardo Martelini JuniorAlgo que recentemente tem ficado claro para mim é que as abordagens padronizadas de desenvolvimento de software ágil parecem partir do princípio que o PO, ou o representante do cliente, tem conhecimento do mercado suficiente para priorizar as histórias e direcionar o desenvolvimento.
Em decorrência disso, as histórias são escritas de forma a atender somente o desenvolvimento, ou seja, elas não apoiam o aprendizado validado real e, por consequência, não propiciam a retroalimentação do backlog com as lições aprendidas.
Com a popularização das abordagens de aprendizado rápido, principalmente influenciadas pelo famoso livro Lean Startup, de Eric Ries, o PO onisciente parece, para mim, muito longe da realidade.
Abaixo descrevo como as histórias são escritas comumente e, na sequência, como poderiam ser descritas para direcionar a validação do real sucesso (ou não), potencializando o aprendizado.
A escrita das histórias
Existem muitas formas de se escrever os requisitos de um sistema, mas nos times de desenvolvimento que adotam Agile ou Lean é muito comum o uso de histórias.
Histórias são uma forma simples de expressar o que o solicitante deseja do sistema, e normalmente têm a perspectiva de quem vai utilizar aquela funcionalidade. Usando o clássico exemplo:
Como <tipo de usuário>,
Quero <objetivo>
Para <esta razão>
Temos como exemplo:
Como analista de crédito,
Quero ter acesso ao cadastro de um cliente no Serasa,
Para poder avaliar se o cliente é um bom pagador
O objetivo principal de uma história é servir como o ponto inicial de discussão [um convite à conversa] entre os envolvidos. Sendo “suficientemente incompleta” a história faz com que haja comunicação constante entre negócio e desenvolvimento com objetivo de concluí-la com êxito. Não busca, todavia, ser completa e ter todos os requisitos mapeados e detalhados desde o início.
Uma história também pode conter critérios de aceite, que detalham alguns comportamentos esperados que o solicitante deseja para a funcionalidade, como:
- Garantir o mesmo comportamento no IE e no Safari
- Abrir o calendário sempre no formato americano
- Exibir o gingerbread zumbi como easter egg 🙂
Algumas equipes vão além e capturam nos critérios de aceite o comportamento esperado para o sistema de uma forma que é facilmente transportado para ferramentas de testes automatizados, criando uma comunicação direta e consistente entre negócio e time (BDD):
Critério: Navega para a página de concursos culturais
Dado que a mensagem de limite de cupons excedido é exibida
Quando o usuário tenta navegar para a página de concursos culturais
Então ele é direcionado para a página de concursos culturais
Todos esses critérios e detalhes apresentados acima, entretanto, levam uma história somente ao estado em que está pronta para ser lançada, mas faltaria verificar ainda se as hipóteses que levaram ao seu desenvolvimento foram validadas, e se o critério de sucesso foi atingido.
Validando as hipóteses das histórias
Cada história carrega consigo um conjunto de hipóteses, muito mais que certezas, e por isso cada uma deve ser encarada como uma oportunidade única de aprendizado e validação de conceitos. Desta forma, creio que a própria escrita deva ser revista, deixando claro quais as hipóteses por detrás e quais os critérios de sucesso.
Pesquisando na internet encontrei um ótimo exemplo de como escrever histórias com este objetivo em mente:
Nós acreditamos que:
construindo a funcionalidade <nome da funcionalidade>
para o público <público alvo proposto>
atingiremos <resultados esperados>Saberemos que fomos bem sucedidos quando tivermos <sinal do mercado esperado>
Este exemplo foi escrito por Jeff Gothelf, autor do muito aguardado e recém lançado Lean UX: Applying Lean Principles to Improve User Experience.
Obviamente mudar a escrita da história, por sí só, não altera a forma de pensar e trabalhar de uma equipe, mas esta maneira de escrita abre muitas possibilidades para que todo o time de desenvolvimento participe ativamente e profundamente do processo de entendimento do negócio. O foco se afasta do desenvolvimento de histórias para o desenvolvimento de um produto, e PO se força a pensar em cada história não apenas como uma nova funcionalidade.
Como ainda não li o livro, paro por aqui, e espero em breve poder escrever mais sobre o assunto.
E no seu time, como os requisitos são passados para o desenvolvimento? Você acredita que todas as histórias são oportunidades de aprendizado e validação de hipóteses?
Anselmo,
Um post excelente e muito bem escrito. Fazia muito tempo que não via algo novo nesse assunto e foi com muito prazer que vi o casamento da ideia do Lean Startup com as User Stories (Histórias de Usuário). Parabéns!
Oi Leo.
Obrigado, Méritos também para o Buzon, que fez uma ótima revisão.
Abraço
Muito bom mesmo!!! Anselmo tocou num ponto que acho crucial em desenvolvimento de produto: não se trata primordialmente do desenvolvimento, mas do produto! Se a história deve ser “suficientemente incompleta” (adorei essa expressão!), entendo que é justamente para descobrir se aquela melhoria no sistema se reflete em um ganho para os objetivos do produto. Em seguida, essa mesma história deveria retroalimentar o backlog em uma mentalidade de “aprendi isso, então devo fazer/refazer aquilo”. O que percebo que ocorre é o foco total no backlog pré-definido, uma espécie de “depois eu vejo se aprendi algo”. Falha grotesca, mas muito comum no gerenciamento de produtos hoje em dia, sem contar que acaba virando escopo fechado e não aproveita as iterações do mundo Ágil.
Anselmo, ótimo post!
Como fazer para medir o sucesso das histórias? Seria após a entrega no sprint, ou durante o tempo de sprint ainda? Teria uma outra coluna no quadro, para SUCESSO? 🙂
Abs
Grande Buzon.
Rapaz, isso é tema pra outro post, mas se considerarmos que a história só entrega todo valor quando você aprende com ela, melhor aumentar o acompanhamento do seu fluxo incluindo a etapa de validação do critério de sucesso, não?
Abraço
Sim. E você acredita que isso seja uma atividade para todo o time e não somente para o PO… é isso?
Pingback: Escalando o papel do Product Owner | Kudoos
Pingback: #SomosTodosPOs | Kudoos