User Stories No contexto de XP

Uma história... Uma história não é mais do que a descrição de uma pequena funcionalidade que o cliente pretende ver desenvolvida no sistema.

Uma user story é constituída por: Uma pequena descrição, utilizada como lembrete e para as atividades de planejamento. Conversações sobre a história, entre clientes e programadores, de modo a detalhar a história e esclarecer dúvidas. Um conjunto de testes de aceitação

Analisemos cada um dos pontos com base numa funcionalidade muito comum: "Um potencial cliente do nosso site deve poder registrar-se de modo a receber notícias, ofertas, entre outros tipos de contactos."

Pequena Descrição DEVE SER CONCLUÍDA EM ATÉ 5 DIAS IDEAIS Uma história é uma pequena descrição e deve ser apresentada em uma ou duas frases de forma simples. Assim, devemos extrair várias histórias do exemplo: "O cliente deve receber um e-mail de confirmação do registro." "O cliente só fica devidamente registrado depois de responder ao e-mail de confirmação." "O cliente deve poder fornecer dados adicionais, como morada, telefone ou idade."

Conversações sobre a história Estimar o tempo de construção da história "O cliente deve receber um e-mail de confirmação do registro" O cliente (o nosso, não o do site) deve poder alterar o conteúdo do e-mail sem intervenção da equipa de desenvolvimento? O e-mail deve ser personalizado? Deve ser enviado em texto puro, RTF, HTML? Todas estas questões devem ser debatidas e esclarecidas entre cliente e equipe de desenvolvimento antes e durante a construção da história.

Testes de aceitação Os testes de aceitação têm uma finalidade confirmar que o sistema funciona de acordo com a especificação. A cada história estão associados um conjunto de testes de aceitação, que devem ser definidos pelo cliente, antes da construção da história.   O nome, testes de aceitação, tem como objetivo indicar que estes são os testes que o cliente definiu como sendo necessários o sistema passar de modo a que a história possa ser dada como concluída.

Exemplo “Um cliente deve-se registrar indicando como código de utilizador o e-mail e escolhendo uma palavra-chave alfa-numérica." Que testes de aceitação podemos definir? "Uma palavra-chave não deve aceitar caracteres que não os A-Z, a-z e 0-9." "Depois de registrado, o cliente deve receber uma confirmação provisória do registro." "Se o código de utilizador estiver errado, o cliente deve ser informado do motivo."

Como estimar a duração de uma história? Estimar com toda a equipe( cliente + equipe técnica) Primeiro, cada elemento da equipe técnica escreve secretamente num papel a sua estimativa Haverá disparidades quando todos as apresentarem Todos justificam suas estimativas Repetem o ciclo pelo menos mais uma vez

Triangularização Com o conhecimento adquirido nas estimativas das histórias passadas podemos estimar as próximas.

Exemplo de User Story US06 Incluir funcionalidade de autenticação(restrição de acesso) TA6.1 - Acessar sistema a partir de um login válido (autenticação feita com sucesso) TA6.2 - Acessar sistema a partir de um login inválido (mensagem de erro deve ser exibida) Estimativa inicial: 6h

Referências Contra a Corrente. User Stories. Acessado em 22/10/2007. Disponível em: http://weblogs.pontonetpt.com/contracorrente/posts/7120.aspx. Contra a Corrente. Estimando User Stories. Acessado em 22/10/2007. Disponível em: http://weblogs.pontonetpt.com/contracorrente/posts/7253.aspx USER STORIES E TESTES DE ACEITAÇÃO. Acessado em 22/10/2007. Disponível em: http://dsc.ufcg.edu.br/~yp/Exemplos/06_UserStoriesETestesDeAceitacao.htm User Stories e Planeamento – Estimativas. Acessado em 22/10/2007. Disponível em: http://weblogs.pontonetpt.com/contracorrente/posts/7324.aspx Mais sobre as User Stories (Histórias) . Acessado em 22/10/2007. Disponível em: http://weblogs.pontonetpt.com/contracorrente/posts/7142.aspx XP1: Um Processo de Desenvolvimento. Acessado em 22/10/2007. Disponível em: http://www.dsc.ufcg.edu.br/~jacques/cursos/2002.2/projii/xp1/xp1.html#userstories Mike Cohn. User Stories Applied - for Agile Software Development. Addisson-Wesley; 2004.