Escrever histórias eficazes no 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 é o critério de saída acordado 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 aborda 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 da história do 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

Uma descrição de história é expressa como: "As a <role>, I want "Goal or Need>, so that <benefit>".

Exemplos de boa descrição da 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á-lo em um sistema de produção.
• Descrição: Como cliente, quero receber notificações quando forem inseridos comentários para 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, não de que forma a notificação assume, como e-mail.
• A descrição não inclui informações de benefício, portanto, o valor comercial não é claro.

Poderia ser melhor escrito como:

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

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

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

Bons critérios de aceitação

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 específicas do usuário, processos de negócios ou funções que devem estar em vigor no final do projeto. Um requisito funcional pode ser: O usuário pode escolher entre vários tamanhos.
• Tratamento de erros: Enumere 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 processará isso?
• Desempenho: Teste o desempenho do sistema da perspectiva de um usuário individual. Por exemplo: A IU é responsiva?
• 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 bons critérios de 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 por cartão de crédito Amex, Master Card ou 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 exatidão da encomenda.
• Um e-mail de confirmação é enviado para o 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 é 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 eles não dão detalhes suficientes para testar, por exemplo, não está claro quem são as pessoas apropriadas.

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

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