Histórias de usuários para integração de API
Como escrever uma história de usuário melhor para integração. Este é um dos vários artigos curtos sobre como escrever melhores histórias de usuários com o ScopeMaster®.
Uma grande quantidade de software hoje em dia envolve a integração de diferentes componentes-aplicativos para criar um novo sistema. Consequentemente, os requisitos de software referir-se-ão frequentemente a um sistema ligado a outro. Esse tipo de integração geralmente envolve o compartilhamento de dados entre os aplicativos de software. Às vezes é uma verdadeira troca bidirecional, mas geralmente envolve o envio de dados de um aplicativo para outro ou a pesquisa de dados de um sistema externo. Essa integração de software normalmente é feita por meio de APIs, como APIs RESTful e, muitas vezes, usando microsserviços.
Então, vamos voltar nossa atenção para como escrever uma história de usuário melhor para esse tipo de integração. Esta é uma área em que gosto bastante dos exemplos de Mike Cohn. Aqui está um exemplo simples: um usuário em um aplicativo de comércio eletrônico chega à seção de entrada de endereço. Eles podem inserir seu código postal e uma consulta a um serviço externo é realizada. Então, como podemos escrever melhor esse tipo de história de usuário?
Em primeiro lugar, precisamos de reconhecer que um sistema conectado é geralmente outro utilizador funcional. Também precisamos manter nossa linguagem simples e clara. Existem centenas, senão milhares de maneiras de escrever isso. Aqui está apenas uma sugestão de frase:
Como um comprador EU querer para adicionar meu envio endereço, usando o Posctode_lookup_api para recuperar o endereço completo de um código postal
Neste caso, geramos duas etapas funcionais na história do usuário. Um para criar o endereço e outro que realiza o externo olho para cima. O ScopeMaster é capaz de identificar essas duas etapas funcionais, determinar a intenção funcional e, portanto, criar uma boa estimativa do tamanho funcional.
A troca de dados com uma API RESTful normalmente segue um padrão CRUD (criar, ler, atualizar, excluir) ou (colocar, obter, postar, excluir). É importante reconhecer, ao definir e dimensionar uma história de usuário, que reconhecemos que estamos enviando dados e obtendo uma resposta de um “corpo” externo (ou vice-versa). O “corpo” externo, embora possa ser uma API, é na verdade um tipo de usuário, ou usuário funcional, para ser mais específico.
Saiba mais em como escrever histórias de usuários de qualidade para integração
Redação Alternativa
Existem muitas maneiras de escrever a mesma história de usuário, talvez centenas de maneiras. Portanto, o que descrevemos aqui são apenas exemplos. Você pode, por exemplo, escrever a história da perspectiva do sistema externo (com o qual estamos integrando) como usuário de nossa aplicação, por exemplo
Como serviço de código postal posso responder a pedidos e enviar dados de morada mediante recepção de um código postal.
ou podemos escrever o mesmo do ponto de vista do usuário de nossa aplicação.
Como comprador, posso recuperar meu endereço do serviço de código postal externo quando insiro um código postal.
Ambas são abordagens válidas. Recomendamos este último por dois motivos:
- Ele se concentra no real Usuários experiência.
- Ele foi escrito da perspectiva de nosso aplicativo, não do aplicativo externo.
Lembre-se de que, ao escrever uma integração entre dois aplicativos, talvez seja necessário desenvolver código em ambos os locais e testá-lo de forma independente e como um sistema.
Escrevendo histórias de usuários de integração
