menu

Sua história é uma hipótese… e ai?

Por

Algo 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?

8 comments

  1. Leonardo Campos

    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!

    Posted on março 20, 2013
    • Anselmo Martelini Júnior

      Oi Leo.

      Obrigado, Méritos também para o Buzon, que fez uma ótima revisão.

      Abraço

      Posted on março 22, 2013
    • Guilherme Massa

      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.

      Posted on março 28, 2013
  2. Rafael Buzon

    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

    Posted on março 21, 2013
    • Anselmo Martelini Júnior

      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

      Posted on março 22, 2013
      • Rafael Buzon

        Sim. E você acredita que isso seja uma atividade para todo o time e não somente para o PO… é isso?

        Posted on março 23, 2013
  3. Pingback: Escalando o papel do Product Owner | Kudoos

  4. Pingback: #SomosTodosPOs | Kudoos

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top