Como escrever histórias eficazes em Desenvolvimento ágil 2.0

Histórias bem escritas são fáceis de entender por todos os desenvolvedores e membros da equipe, como Testes ou Documentação.

As histórias permitem que o grupo de atribuição estime com precisão o esforço necessário para implementar o trabalho de acordo com a definição de concluído. A definição de concluído são os critérios de saída acordados pelo grupo, que determina quando uma história está concluída.

Uma história tem as seguintes condições básicas:

• Descrição: a descrição da história está relacionada a uma persona de usuário, como administrador, e descreve um valor comercial ou trata de uma dívida técnica.
• Critérios de aceitação: os critérios de aceitação da história são mensuráveis e testáveis.

Descrições da história

Uma boa descrição de história de usuário identifica o seguinte para atender ao requisito declarado:

• a função da persona do usuário no sistema
• a necessidade expressa pela persona do usuário
• o benefício para todas as partes interessadas, como desenvolvedores, usuários e outros

Normalmente, a descrição de uma história é expressa como: "Como um<role> , eu quero<goal or need> , para que<benefit> ".

Exemplos de boas descrições de história

• Descrição: como desenvolvedor, quero publicar o estado atual da minha aplicação em um conjunto de atualizações para que eu possa implantá-la em um sistema de produção.
• Descrição: como cliente, quero receber notificações quando forem inseridos comentários em um incidente para que eu seja atualizado sobre o status.
• Descrição: como gerente de mudanças, quero habilitar a avaliação de risco para qualquer mudança, estabelecendo uma lista de perguntas com respostas de múltipla escolha.

Exemplo de descrição de história incorreta

Descrição: as notificações são enviadas quando os incidentes são criados.

Esta descrição é ruim porque:

• A descrição não indica quem ou o que está enviando as notificações, nem a forma que a notificação assume, como e-mail.
• A descrição não inclui nenhuma informação de benefício, portanto, o valor comercial não está claro.

Poderia ser melhor escrito como:

Descrição: como criador de incidentes, quero que notificações por e-mail sejam enviadas para um conjunto predefinido de partes interessadas quando eu criar um incidente, para que elas possam ser informadas quando um incidente que as afetar for criado.

Critérios de aceitação da história

Os critérios de aceitação definem os limites de uma história de usuário e são usados para confirmar quando o software está funcionando conforme o esperado, o que significa que a história está concluída. Os critérios de aceitação são uma parte essencial da "Definição de Concluído" de uma história.

Bom critério de aceitação

Os bons critérios de aceitação devem incluir o seguinte, quando relevante:

• Usabilidade: certifique-se de incluir medidas de usabilidade nos critérios de aceitação. Indique como responder à pergunta: é fácil de usar? A chave é identificar as medições corretas e garantir que cada uma seja quantificável.
• Funcionalidade: identifique tarefas de usuário, processos de negócios ou funções específicas que devem estar em vigor no final do projeto. Um requisito funcional pode ser: O usuário pode escolher entre vários tamanhos.
• Manipulação de erros: enumere os casos de erro e como cada um deve ser tratado. Por exemplo, se um usuário executar as etapas na ordem errada, como o software lidará com isso?
• Desempenho: teste o desempenho do sistema da perspectiva de um usuário individual. Por exemplo: a IU é dinâmica?
• Testes de estresse: descreva como o sistema responde quando está sob estresse porque há muitos usuários, transações ou consultas. Os critérios de aceitação devem definir limites aceitáveis para testes de estresse. Por exemplo: o sistema responde dentro de um limite de 250 milissegundos quando 100 usuários enviam consultas simultaneamente?

Exemplo de critérios de boa aceitação

Descrição: como cliente, quero solicitar e pagar o livro por meio de um formulário seguro baseado na Web, para que as informações do meu cartão de crédito estejam seguras.

Critérios de aceitação:

• Todos os campos obrigatórios devem ser preenchidos antes que um cliente possa enviar um formulário.
• As informações do formulário são armazenadas no banco de dados de pedidos do cliente.
• O pagamento pode ser feito via Amex, Master Card ou cartão de crédito Visa.
• O sistema deve calcular e aplicar com precisão o imposto sobre vendas.
• O sistema deve calcular e aplicar com precisão as taxas de envio.
• O cliente deve ser capaz de verificar a precisão do pedido.
• Um e-mail de confirmação é enviado ao cliente que envia o formulário.
• A proteção contra spam está funcionando.

Exemplo de critérios de aceitação incorretos

Descrição: como cliente, quero receber notificações quando um incidente for comentado, para que eu seja atualizado sobre o status.

Critérios de aceitação: as pessoas apropriadas são notificadas quando os incidentes são comentados.

Os critérios de aceitação são ruins porque não fornecem detalhes suficientes para testar, por exemplo, não está claro quem são as pessoas apropriadas.

Os critérios de aceitação podem ser melhor escritos como:

1. Como um usuário ESS, crie um incidente.
2. Selecione Notificar partes interessadas.
3. Salve o incidente.
4. Faça login como parte interessada.
5. Verifique se você recebeu um e-mail para o incidente registrado.