Definindo histórias de usuário e desenvolvimento ágil
Um princípio fundamental dos processos de desenvolvimento modernos é o desenvolvimento ágil . Essa metodologia de desenvolvimento enfatiza o uso de pequenas histórias de usuários para definir o que um sistema faz da perspectiva do usuário, não técnica. Um usuário se preocupa se um produto é rápido, fácil de usar e se resolve seu problema. Eles não se importam se segue uma arquitetura de 3 camadas, tem Mongo DB ou se está usando Rails ou Asp.net.
Histórias de usuários:
- São fáceis de entender e qualquer pessoa pode participar
- Trabalhe iterativamente; eles podem e devem ser alterados ou alterados com frequência
- Alinhe desenvolvedores, usuários e especialistas de negócios em torno de metas e expectativas comuns
- São muito mais fáceis de ler do que documentos de requisitos de 400 páginas
Storyboard That fornece uma plataforma ideal para criar histórias de usuários ágeis e iniciar conversas em um formato que é muito menos desgastante do que uma parede de texto.
Épico
No contexto das histórias de usuários, um “épico” é simplesmente uma história muito ampla que mais tarde será dividida em muitas histórias de usuários específicas. Começar com um épico alinha todos com uma visão única e de alto nível. A história épica ancora um projeto de cima para baixo, e se não faz sentido construir uma epopéia, o trabalho de apoio também será um desperdício de esforço.
Nesta história, fica muito claro o que é a visão de longo prazo e como deve ser o sucesso. Uma boa história épica deve incluir:
- Ambiente ou Contexto
- Atores ou usuários
- Metas e objetivos
- Atividades e eventos
Definindo Usuários
Especialmente ao projetar software, é importante ter uma boa visão de como serão os usuários. Nem todo usuário corresponderá a essa visão com precisão, e pode haver várias categorias de usuário, mas essas visões distintas precisam de articulação. Pensar primeiro nos usuários protege contra o excesso de engenharia e complicação, evitando que um novo produto tenha algo para todos e não seja útil para ninguém.
Criando uma história
Uma vez que uma epopéia foi estabelecida e os usuários definidos, histórias menores e mais específicas podem ser construídas sobre experiências de usuário específicas. As histórias a seguir dividem o descrito acima em duas narrativas: consultar um pedido e reordenar um produto.
Essas narrativas não contêm informações técnicas; os usuários não se importam com a forma como os resultados são alcançados, desde que execute as tarefas desejadas. Da mesma forma, a UX é descrita genericamente, para evitar sufocar a inovação ou forçar um caminho. Em geral, as histórias devem ser:
- Pequeno - menos de 10 dias de trabalho
- Valiosos - Depois de concluídos, eles devem entregar algo utilizável
- Estimable - Capaz de criar uma estimativa aproximada de quanto esforço está envolvido
Procurando um pedido
Executando um Reordenamento
Conversa e planejamento para testes
Essas histórias devem convidar conversas e perguntas, como:
- Essas são as histórias certas para combinar com nosso épico?
- Que outras histórias devem ser criadas?
- Essas histórias são consistentes com o que sabemos sobre nossos usuários?
É perfeitamente razoável criar muitas histórias; na verdade, deve ser encorajado. Algumas dessas histórias nunca serão usadas, mas é importante ver o caminho que elas traçaram. Esta coleção de histórias eliminará requisitos adicionais e influenciará os testes.
As histórias devem provocar e informar a discussão sobre como o software será testado e quais regras de negócios precisam ser definidas explicitamente. Por exemplo:
- Quão rápida uma pesquisa precisa ser?
- Existe um limite de tempo para novos pedidos?
- O que o sistema deve fazer se for o segundo pedido? Quinto?
- Quais testes e perguntas de acompanhamento você teria?
© 2024 - Clever Prototypes, LLC - Todos os direitos reservados.
StoryboardThat é uma marca registrada da Clever Prototypes , LLC e registrada no Escritório de Marcas e Patentes dos EUA