Como “Cartões” têm o objetivo de capturar os requisitos eles se concentram em “quem, o quê e porquê de um recurso, e não como”. Neste ponto ele é igual a varias técnicas de levantamento de requisitos, onde tentamos identificar o que tem que ser feito e não como será feito.
O cartão de historia tem que ser escrito a partir de uma perspectiva do usuário. Desta maneira o cartão não deve possuir jargões técnicos ou informações de design, ou qualquer outra coisa que não seja informações de negocio. Um cartão deve ser escrito com a linguagem no negocio, para que seja compreendido por todos.
Um exemplo de cartão de historias pode ser:
Como um professor gostaria de lançar as notas de meus alunos, para que os alunos possam saber como estão indo na minha matéria.
Como um aluno gostaria de visualizar as minhas notas de modo que eu possa saber o meu desempenho nas disciplinas.
Observe que em ambos os casos estamos buscando um linguajar de negocio e buscando o as necessidades do sistema (em nível de negocio – o que tem que ser feito), mas em nenhum dos exemplos entramos em uma linguagem técnica e nem falamos “como vamos fazer”.
Um bom template de como escrever cartões é:
Como um [usuário papel], quero [meta], para que eu possa [motivo].
A primeira vista podemos achar que a parte do [motivo] não é necessária, mas a utilização do [motivo] nos leva a um entendimento melhor do objetivo pelo qual o cartão é útil. Ele nos ajuda a entender melhor como o requisito funciona e nos da uma idéia melhor para outras características do sistema.
Em Scrum nos buscamos identificar os cartões no inicio do projeto, para que ele de origem ao “Procuct Backlog”. Com os cartões identificados podemos dar origem a priorização e a estimativa dos mesmos.
Uma vez os cartões priorizados para execução em uma sprint eles devem ter os seus detalhes (tarefas) identificados. Não devemos identificar os detalhes de cartões que não fazem parte da sprint, desta maneira evitamos o gasto de energia na sprint corrente em trabalhos que fazem parte de outro momento temporal.
Mas como podemos organizar nossos cartões de historia?
Um cartão de historia deveria ter pelo menos três itens: Informações do cartão, dados de conversa com o usuário e testes de validação do cartão.
Informações do cartão são: nome, descrição da historia, um numero de referencia, estimativa, etc.
Conversas são anotações (lembretes) da historia e não uma especificação completa. Estas anotações servem de apoio para a obtenção de mais detalhes no momento de desenvolvimento, identificando como o software deve funcionar. Tudo que ajude a explicar a funcionalidade deve ser colocado como um item de conversa. É como um conjunto de palavras chaves, mas não tem a necessidade de ficar restrito a uma palavra, pode ser colocada (escrito) como uma frase.
Confirmação (Testes) são os casos de testes no verso do cartão. Os testes possibilitam o entendimento melhor do cartão, ajuda na busca de cenários que os usuários, desenvolvedores / analistas podem não ter pensado. Um cartão (requisito) tem que ser possível de ser testado.
Um cartão de historia tem que possuir uma única responsabilidade, ter cartões de historia com mais de uma responsabilidade dificulta o entendimento, a estimativa e a priorização. Cartões pequenos nos ajudam a realizar uma administração (gestão) do projeto.
Link de Referencia:
http://kw-agiledevelopment.blogspot.com/2008/01/user-stories-answers-on-postcard-please.html
http://kw-agiledevelopment.blogspot.com/2008/01/user-stories.html
Abraços a Todos,
Abu
Postagens
Nenhum comentário:
Postar um comentário