Notas sobre o “User Stories Applied: For Agile…”

Olá, pessoal

for-agile-software16750_fHá pouco tempo terminei de ler o livro “User Stories Applied: For Agile Software Development” (Mike Cohn), um dos livros mais conhecidos sobre o assunto.

Neste artigo, separei alguns pontos do livro, vindos de diferentes capítulos, os quais achei interessantes compartilhar por serem dicas úteis ao se trabalhar com user stories. Portanto, este não é um artigo introdutório sobre o assunto e sim um apanhado de práticas/ideias tiradas do livro.

Vamos ao conteúdo:

IDENTIFICANDO PAPÉIS DE USUÁRIOS (USER ROLES)

Ao escrever user stories deve-se evitar um usuário genérico (o “usuário” deve…”) e pensar em QUAL usuário será efetivamente beneficiado pela user story. Por exemplo, quando estamos desenvolvendo um software que controle as notas dos alunos de uma escola, temos alguns papéis que surgem rapidamente em mente: aluno, professor e pai/responsável.

Para identificar esses papéis, desenvolvedores e clientes devem reunir-se em sessões para tal propósito, que seguem os seguintes passos:

1. Brainstorm: onde cada presente identifica o maior número de papéis de usuários, anotando-os em cartões.

2. Organizar a lista:  cartões com os mesmos papéis ou papéis similares são agrupados, formando-se pilhas separadas de cartões.

3. Consolidar papéis: o grupo discute sobre os papéis parecidos, descartando papéis ou fundindo papéis em um só.

4. Refinamento: para cada papel de usuário restante, são descritos detalhes como a frequência de uso do software, a habilidade desse tipo de usuário com computadores, o nível de conhecimento sobre o domínio do software e seus objetivos com o software.

PESCANDO REQUISITOS

O livro utiliza a metáfora de pesca com rede (“trawling for requirements”) para descrever o processo de levantamento de requisitos. Segundo Cohn, esta metáfora, que ele tirou de outro livro, funciona bem para o levantamento de requisitos por 4 motivos:

1. Para cada tamanho de requisito, é usado um tamanho diferente de rede de pesca. Em uma primeira “leva”, são pescados os peixes maiores, que são as user stories maiores, de maior valor de negócio e que transmitem uma ideia geral do que o software é. Com outros tamanhos de rede são pescados os médios e os menores.

2. Peixes crescem e morrem. Isso significa que certos requisitos, ao longo do projeto, podem ganhar importância (crescem) ou tornarem-se desnecessários (morrem).

3. Você não conseguirá pescar todos os peixes de uma área com a rede, assim como não conseguirá obter todos os requisitos.

4. Por fim, entra a habilidade. Um pescador habilidoso conhece as melhores técnicas e os melhores lugares para pescar. O mesmo vale para o levantamento dos requisitos.

Embora essa metáfora não tenha me fisgado (*) muito, talvez por eu ser um completo ignorante de pescaria, a ideia é mostrar que os requisitos não são “coisas prontas” e definitivas, que é só ir buscar em algum lugar. Ao contrário, eles devem ser capturados, eles podem emergir ou perder sentido no decorrer do projeto e é importante dar foco naqueles que realmente tem valor de negócio.

(*) costumo usar trocadilhos no dia-a-dia (não sei se alguém consegue achar graça em algum deles), mas este é o primeiro trocadilho que escrevo neste blog. Meio forçado, mas foi.

TESTES DE ACEITAÇÃO

São escritos para expressar detalhes das user stories, provenientes das conversas entre clientes e desenvolvedores. Garantem que a user story esteja definitivamente pronta de acordo com as expectativas do cliente.

Podem ser escritos:
– Sempre que clientes e desenvolvedores se reunirem
– No planejamento da iteração
– Sempre que forem descobertos – durante ou após a implementação

FATIANDO O BOLO

Entrando em boas práticas relacionadas a user stories, quando decidimos quebrar uma user story muito grande, é melhor quebrá-las de forma que cada uma vá de ponta-a-ponta no software. No livro, é usado o termo “slice the cake” (fatiar o bolo) para se referir a uma user story que tem um pouco de cada camada do software.

As vantagens disso: (1) acabamos exercitando a arquitetura do software; (2) damos ao cliente a possibilidade de escolha de colocar a funcionalidade em produção, mesmo que sem todos os recursos desejados por ele.

USER STORIES FECHADAS

User stories fechadas são aquelas concluídas transmitindo a ideia de que um determinado objetivo foi cumprido. Portanto, não é recomendado criar uma user story do tipo “O candidato a vaga pode gerenciar seu currículo”, pois ela transmite uma ideia de continuidade. Quando “poder gerenciar seu currículo” estará pronta? Quando o candidato atingiu o objetivo de “gerenciar o currículo”?

O mais adequado, então, é construir essa user story como um grupo de user stories fechadas, como “O candidato pode alterar o currículo”, “O candidato pode remover o currículo”, “O candidato pode criar uma versão em inglês do currículo”, etc.

CRIANDO RESTRIÇÕES

Algumas vezes um requisito não pode ser escrito como uma user story, pois não é algo que vá ser implementado e sim atendido por todo o software. Nesses casos, usa-se o conceito de restrição (constraint) para identificá-lo.

Normalmente, restrições são uma forma de especificar requisitos não-funcionais. Alguns exemplos:

– O software deve suportar 100 usuários concorrentes
– A interface web deve funcionar corretamente no IE9 (eca!)

CONCLUSÃO

Neste artigo, ao invés de uma resenha, procurei apresentar o livro “User Stories Applied: For Agile Software Development” mostrando alguns pontos do mesmo.

O livro ainda trata de estimativas com user stories (story points, velocidade, planejamento de iterações e releases), mostra um exemplo completo desde a identificação dos papéis de usuários até o planejamento da release, entre outras coisas.

Recomendo a todos que trabalham com user stories e, principalmente, àqueles que querem começar a aprender.

Por hoje, é isso!

[]s

Anúncios

6 comentários em “Notas sobre o “User Stories Applied: For Agile…”

  1. Muito bom o seu post Robson. Tenho achado cada vez melhor trabalhar com user story. Acredito que uma user story bem escrita é aquela que consegue descrever com poucas palavras o valor da solicitação realizada. E também compartilho com a ideia que uma user story pode estar em uma evolução contínua, muitas vezes escrevemos uma story e com o passar do tempo ela pode ter sofrido alterações conforme a necessidade do negócio do cliente. Estarei lendo o livro sugerido. Obrigada pela dica.

    1. De nada, moça!

      O legal é que ela é mais um ‘lembrete’ do que um documento formal, concebida assim para que todos (cliente e time) estejam sempre se comunicando.

      A comunicação verbal é muito mais eficiente do que texto, que gera confusão além de muitas vezes ser extenso demais.

      É uma mudança de pensamento. Antes muita documentação, agora mais comunicação. 🙂

  2. Robson, ótima síntese do livro. Despertou meu interesse em ler ele logo, pena que é em inglês e vou ter que fazer um certo esforço pra entender as coisas com clareza.
    Abs !

Participe! Vamos trocar uma ideia sobre desenvolvimento de software!

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s