Quando falamos sobre os avanços tecnológicos, não podemos esquecer de mencionar o desenvolvimento de metodologias e técnicas para ajudar a entender o ponto de vista dos clientes de forma eficaz. Nesse sentido, o “User Story”, ou o histórico do usuário, é uma descrição informal de um ou mais recursos do sistema de software no desenvolvimento de software e gerenciamento de produtos que podem ajudar a sua empresa a entender melhor as necessidades dos usuários.
Assim, em um mundo cada vez mais rápido, é preciso conhecer as técnicas de otimização processual para alcançar resultados mais positivos. Portanto, se você quiser entender melhor como funciona o User Story, é só continuar lendo este artigo.
O que é User Story?
O User Story, nada mais é do que uma ferramenta usada no desenvolvimento de software Agile para capturar uma descrição de um recurso de software do ponto de vista do usuário pretendido. A história de um usuário descreve os vários tipos de usuários, o que eles querem e por quê. O relato de um usuário sobre sua experiência pode ajudar a criar uma descrição concisa de um requisito.
Portanto, de forma geral podemos dizer que esta técnica é aplicada para capturar uma necessidade do produto. Em contraste com outros métodos de especificação granular de requisitos (como casos de uso), em um User Story é preciso apenas conter as informações necessárias para iniciar uma conversa entre a equipe de desenvolvimento e o proprietário do produto.
Como funciona?
Como Martin Fowler explica em seu artigo “Use Cases and User Stories”, Usage Cases e User Stories estão relacionados, afinal, ambos são usados ​​para organizar os requisitos. No entanto, o User Story enfatiza mais os objetivos do usuário e como o sistema atinge essas metas, enquanto os Casos de Uso descrevem as interações do usuário de acordo com uma narrativa impessoal entre o usuário e o sistema.
Os requisitos são divididos em User Stories para que seja possível (e mais fácil) estimar o esforço necessário para concluir esse objetivo. Sendo assim, o User Story funciona como uma descrição direta de uma função, e é aconselhável que sejam escritas a partir da perspectiva do usuário.
Além disso, os User Story devem ser breves, diretas e claras. Sendo capazes de escrevê-los em um pedaço de papel breve e direto (conhecidos como User Index Cards). Se não há espaço para escrevê-lo em uma única letra, é por isso que precisamos refiná-lo mais e dividi-lo em mais histórias de usuário.
Como construir um User Story?
Existe um conceito conhecido como "3 C's", que descreve como construir sua história de usuário. Confira mais sobre os principais.
Cartão
Embora atualmente não utilizemos um cartão propriamente dito, utilizamos ferramentas desenvolvidas para esse fim. Portanto, podemos dizer que o conceito de cartão ainda se mantém, indicando que a descrição de uma história deve ser sucinta e objetiva. Como vimos anteriormente, se ela não couber no espaço de um cartão, significa que talvez ela deva ser dividida novamente.
Nesse sentido, o cartão representa duas ou três frases que são usadas para expressar a intenção da história e podem ser vistas como um convite ao diálogo. O cartão funciona como um token memorável que resume a intenção e representa um requisito mais específico, cujos detalhes devem ser decididos.
Conversas
São discussões (ou "reuniões") nas quais o PO, a equipe de desenvolvimento e talvez um QA (se houver) falam sobre como lidar com as solicitações feitas no cartão. É hora de decidir que tipo de solução será desenvolvida. Além disso, este é um bom momento para esclarecer quaisquer dúvidas.
Sendo assim, a conversa representa uma discussão entre os usuários-alvo, equipe, proprietário do produto e outras partes interessadas, que é necessária para determinar o comportamento mais específico necessário para realizar a intenção. Em outras palavras, essa fase também funciona como uma "promessa de conversa" sobre o resultado pretendido.
Confirmação
É necessário ter critérios para julgar se uma história está terminada para fazer essa determinação. São cenários que, se produzirem os resultados esperados, são satisfatórios, caso contrário, eles serão devolvidos à equipe de desenvolvimento para correções de problemas.
A confirmação serve como o "Teste de Aceitação", no qual o cliente ou product owner atesta que o histórico foi realizado a contento. Em outras palavras, a confirmação refere-se aos critérios que serão utilizados para determinar se a história cumpre ou não o propósito pretendido, bem como os requisitos mais específicos.
Conclusão
Neste artigo, falamos um pouco sobre o User Story, sua importância e quais são as suas principais características. No entanto, não podemos dizer que o tema se encerra aqui, ao contrário, este artigo serve apenas como referência geral para auxiliar quem precisa. Assim, você poderá entender o básico de forma eficiente para continuar os seus estudos na área.
Se você gostou desse conteúdo e quer conhecer mais sobre esse tema, é só continuar navegando no nosso site. Dessa forma, você poderá se aprofundar ainda mais no mundo tecnológico e nos seus avanços.
09/09/2022 Autor: DevSkin