Como rascunho histórias de usuário como desenvolvedor?

10

Estou escrevendo um sistema em que eu e o proprietário do sistema somos desenvolvedores e atualmente somos a única fonte de 'solicitações' ou requisitos para o sistema, que eu gostaria de capturar em histórias de usuários vinculadas aos recursos {1}. Minha prioridade urgente agora é obter um backlog managaeble capturado. Como devo capturar o nível de especificação técnica com que estou acostumado a trabalhar nas histórias dos usuários, que não deveriam ser muito técnicas.

{1} Estou avaliando o serviço de gerenciamento de projetos ágil TargetProcess , e cada história de usuário deve estar vinculada a um recurso pai. O sistema parece ser adequado, portanto, essa pequena restrição é algo com o qual eu preferiria trabalhar do que contornar.

project-management agile scrum ProfK
fonte

Respostas:

14

O modelo de história típico é muito fácil de visualizar:

As a [ROLE] I need to [WHAT] so that/because [WHY].

O interessante é que a importância dos componentes é invertida.

POR QUE é mais importante que O QUE e mais importante que o ROLE

Exemplo usando esta pergunta

Como desenvolvedor de software, preciso aprender a escrever histórias de usuários para poder preencher a lista de pendências com rascunhos para iniciar as discussões sobre os recursos e obter pontos atribuídos a eles.

Mais alguma coisa acabou complicando a intenção e a implementação das histórias de usuário.

Ferramentas adicionais (a integração é melhor)

As ferramentas podem ser usadas para capturar informações detalhadas adicionais sobre as histórias capturadas ao discuti-las para atribuir pontos / estimativas, mas esses detalhes não devem fazer parte da própria história. Algo tão simples quanto um Wiki com 1 página por história para colocar detalhes / transcrições de discussões é uma solução suficientemente boa. A planilha do Excel é uma solução terrível.


fonte
5

Concentre-se no que é e no porquê e evite o como está ao escrever as histórias dos usuários.

O que você enfrenta é realmente um exercício muito bom para todos os desenvolvedores. Ser capaz de expressar o requisito em termos simples e comerciais é uma habilidade importante.

Você deve se concentrar no requisito geral como "precisa ser capaz de fazer uma única seleção em uma lista suspensa de objetos para que o usuário possa ativar a ação Foo" em vez de especificar usando uma caixa de combinação ou caixa de listagem ou o que desencadeie uma rotina específica .

Outra maneira de abordar isso é fingir que a base / estrutura de código subjacente é uma caixa preta quase completa. Sempre que você estiver dizendo "use o objeto XYZ", poderá verificar automaticamente perguntando se você saberia disso em um sistema de caixa preta.

Atualização:
IMO, não há problema em colocar detalhes em um caso de uso que indique o nível de detalhe necessário para obter informações. Por exemplo, com um sistema de inscrição, é justo especificar
- sobrenome; campo obrigatório
- primeiro nome; campo obrigatório
- ID da conta; sistema gerado sem entrada necessária
- signo astrológico; campo opcional - (sugestão) fornece pesquisa para inserir a data de nascimento?
- etc ....

A chave é que você não está especificando o técnico como para essa informação. Se você estiver dizendo "use uma classe String / matriz de caracteres / ou campo varchar" para o sobrenome, saberá que está especificando demais.

Se você é multilíngue, use dois idiomas diferentes como teste decisivo. Por exemplo, strings em C são geralmente matrizes char (acter), enquanto C ++, Java e C # (ok, e quase todo mundo ...) têm um objeto String como real. Se você achar que sua especificação está invalidada usando um desses idiomas, você saberá que especificou demais.

Vale a pena notar que estou usando especificamente o termo Caso de Uso em oposição à História do Usuário , embora a variante que acabo usando seja um híbrido de ambos. Meu objetivo de um caso de uso é fornecer uma visão geral do que está acontecendo (uma história do usuário no sentido mais estrito), mas depois trabalhar com os atores, sistemas e funcionalidades gerais necessárias. Minha abordagem está mais próxima do que Fowler está sugerindo naquele artigo da Wikipedia, em oposição à abordagem de Cockburn.

Portanto, terei um único caso de uso (ou mais) para o cenário de inscrição ou item de trabalho. Se é realmente complexo, eu o dividiria em múltiplos, mas isso não é grande coisa. O caso de uso pode ser dividido em tarefas individuais, conforme necessário. O que é lançado em um scrum específico depende de muitas variáveis, mas não há nada nessa abordagem que impeça que você tenha um componente demonstrável no final do scrum.


fonte
3
Mesmo dizendo "lista suspensa" pode ser uma especificação excessiva.
Donal Fellows
@DonalFellows - Esse é um bom argumento, e ponderei um pouco sobre isso. Fui com ele desde que uma lista suspensa é um elemento genérico da interface do usuário bastante padrão que você verá com wireframes. Caixa de listagem e Combobox são construções de idioma específicas para listas suspensas. +1 no comentário.
@ GlenH7 Entendo isso, mas meu problema é que não sei onde capturar o material técnico. Se determinados campos são obrigatórios para, por exemplo, um novo funcionário, não quero usar uma história para cada campo, mas "como usuário, preciso capturar os campos x e y" e "pode ​​escolher capturar os campos q e z "tipo coisa. Se meus exemplos rápidos aqui forem a direção certa, tentarei fazer mais exercícios dessa maneira.
ProfK 17/07/12
@ProfK Como administrador de RH, preciso inserir informações sobre novos funcionários para poder registrá-los nos sistemas de folha de pagamento, 401K e benefícios de seguro. Esta deve ser uma boa história, os detalhes sobre todo o resto são apenas os detalhes que devem ser documentados em uma página da wiki ou em algum outro documento. Se for necessário adicionar o caso de outros novos recursos a essa história, novas Histórias com os requisitos específicos perdidos se tornariam novas histórias no sistema. A História é feita quando essa atividade pode ser concluída pelo ROLE para a aprovação dos clientes.
2
@ProfK - atualizei minha resposta em resposta à sua pergunta. OMI, acho que você está no caminho certo. Eu trabalhei em muitas metodologias diferentes, e o aspecto crítico a lembrar é fazê-lo funcionar para a sua situação. Parece que você precisa de um pouco mais do que o que uma história de usuário formal fornece. Portanto, adapte como você gera suas histórias de usuário e siga em frente. Alguns provavelmente me chamam a atenção pelo comentário, mas honestamente, o ponto principal é obter o código escrito e manter o projeto avançando.