sexta-feira, 12 de fevereiro de 2010

Cartão de História

Cartões de história é uma técnica de captura de requisitos de sistemas, esta técnica surgiu com a metodologia de desenvolvimento chamada de XP (extreme programming), porém podemos utilizar esta técnica com qualquer metodologia de desenvolvimento de sistemas ágeis.

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 história 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 negócio. Um cartão deve ser escrito com a linguagem no negócio, para que seja compreendido por todos.

Exemplo de Cartão de Historia
Como um professor, eu 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, eu 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 negócio e buscando as necessidades do sistema (em nível de negócio – o que tem que ser feito), mas em nenhum dos exemplos entramos em uma linguagem técnica e nem falamos “como vamos fazer”.

Template de Cartão de Historia
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 nós buscamos identificar os cartões no início 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.

Organizando Cartões de Historia
Um cartão de história 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 história, um número de referencia, estimativa, etc.

Conversas são anotações (lembretes) da história 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 história tem que possuir uma única responsabilidade, ter cartões de história 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.


Observe que o desenho que representa a frente do cartão tem os dados de identificação do cartão de história. Estes dados são: o numero (0001), o titulo (User Login), a história do cartão (As a [register user]...) e ainda dados das conversas com o usuário, onde temos um esboço de como deve funcionar a tela e anotações do comportamento esperado.

Na segunda imagem nós temos as informações dos testes (confirmação), mostrando os cenários possíveis e esperados pelo usuário.



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
http://kw-agiledevelopment.blogspot.com/2008/01/example-of-user-story.html



Abraço a todos,

Abu

Um comentário:

Wendell disse...

Gostei muito deste artigo. Vou utilizar em minhas aulas. Parabéns!