Os elefantes não são girafas e as histórias de usuários não são requisitos. Eles têm características comuns e um contexto comum, mas isso não os iguala. No entanto, muitas pessoas acreditam que as histórias de usuário são uma espécie de nova leitura do que é tradicionalmente chamado de requisitos de software - afinal, deve haver requisitos em um projeto, certo? Então, vou responder - não, e novamente não . Em primeiro lugar, estes não são requisitos e, em segundo lugar, os requisitos não são o que realmente precisamos. As histórias de usuário são, antes de tudo, uma chance de ver diferentes opções de implementação para que você possa aproveitar as oportunidades que se abrem. E os requisitos ... é resolver tudo com antecedência, para que depois você se prenda a isso.
Há algum sentido em escrever tal artigo? Isso não parece óbvio? Não, acredito que declarações frequentes como “requisitos no backlog” sinalizam que o paradigma de pensamento permanece o mesmo, apenas os sinais mudaram. O documento de requisitos passou a se chamar backlog, os próprios requisitos - user stories, e agora somos "ágeis" ...
Outro sinal de possível mal-entendido é a prática generalizada de armazenar user stories no banco de dados com a atribuição de um ID único. É possível que isso seja feito apenas por uma questão de conveniência, mas é possível que seja o resultado de uma tendência persistente de pensar em termos de requisitos.
Mas a prática de incluir histórias de usuários em um contrato já é um sinal 100% de que as histórias de usuários são consideradas requisitos. O problema aqui é que uma história de usuário, por definição, não pode ser tão inequívoca quanto um requisito e isso desvaloriza o contrato. Claro, às vezes os requisitos também podem ser interpretados com bastante liberdade, mas a própria técnica de escrevê-los implica inicialmente na eliminação da ambigüidade, o que não pode ser dito sobre as histórias de usuário. Além disso, os requisitos são resilientes a mudanças à medida que são incluídos nos contratos do projeto. Para alterar ou adicionar novos requisitos, eles devem ser repassados pelo CCB . Em outras palavras, as partes interessadas devem primeiro concordar e aprovar. Veja abaixo mais detalhes sobre os contratos.
Então, o que são histórias de usuários? Considere-os uma ferramenta de planejamento. Com a ajuda de user stories, priorizamos, avaliamos e decidimos em qual sprint a funcionalidade correspondente será implementada. Todos esses são recursos típicos de uma ferramenta de planejamento, portanto, não tente transformá-los em outra coisa.
O poder das histórias de usuários é que elas dão origem ao diálogo. Em vez de apenas pegar e passar para colegas uma especificação, que é interpretada primeiro pelos desenvolvedores e depois pelos testadores, iniciamos uma discussão. Incluímos funcionários com diferentes habilidades de comunicação. E assim - para cada novo recurso.
Como a história do usuário, como tal, não carrega muito significado, podemos simplesmente descartá-la após a implementação da funcionalidade correspondente. Se desejar, você pode manter cuidadosamente as estatísticas sobre o número de histórias realizadas, mas isso pode ser bastante limitado.
Acontece que não precisamos de requisitos? Na verdade, isso não é verdade. Afinal, de uma forma ou de outra, existem restrições. Por exemplo, o equipamento médico deve estar em conformidade com os regulamentos da FDA . Então, vamos chamá-los de restrições!
E ainda, os requisitos descrevem o Sistema em detalhes, talvez haja algum valor em tal descrição para nós? Por exemplo, como determinar se algum comportamento do sistema é um bug ou não, se não temos requisitos formais apresentados de uma forma ou de outra? A técnica "Especificação por Exemplo" nos ajudará aqui. Portanto, foi decidido que alguma funcionalidade deveria ser implementada. Você escreve regras de negócios e uma série de exemplos de forma que sejam: a) fáceis de ler; b) realizável. A partir desta descrição, deve ficar claro o que o sistema deve fazer. E também, se algo der errado como resultado de mudanças - a violação de qual regra de negócios foi a causa dessa disfunção.
Como escrevi anteriormente, a descrição do bug deve ser simples e clara. Bugs são coisas que destroem informações e são ruins, independentemente de termos ou não uma descrição de requisito que cubra um determinado caso.
Contrato
(por Matthias Skarin)
Então, o que vamos usar em vez da especificação de requisitos? Afinal, precisamos entender se implementamos exatamente o que era necessário? Estaremos usando contratos ágeis. Ágil - os contratos são uma oportunidade de ver a floresta pelas árvores, permitem focar na essência do projeto e atingir em conjunto o objetivo, cuja implementação irá satisfazer as necessidades dos usuários.
Lembre-se, quando você pensa no contrato durante o projeto para verificar se o seu parceiro violou alguma coisa, isso já significa que algo está errado. O contrato deve construir confiança entre as partes para que seja possível ir além dos detalhes, e não se prender a eles.
Resumo
- Apesar do elefante e da girafa terem quatro patas, são animais diferentes.
- As histórias de usuário não são requisitos, mas uma ferramenta de planejamento.
- A coisa mais próxima dos requisitos é a Especificação por Exemplo.