Histórias de usuário como forma de documentar a especificação point-in-time do produto

Question

Histórias de usuário como forma de documentar a especificação point-in-time do produto

#1 resposta do (1 votos)
#2 resposta do (0 votos)

5

Temos um produto de software existente que está sendo transferido para um processo ágil.

Novos requisitos serão capturados como histórias de usuários, mas isso inspirou a pergunta sobre o que fazer com os requisitos existentes e qual é a relação entre as histórias do usuário e a especificação / documentação do produto.

Eu vejo valor na captura de todos os atualmente implementados e novos requisitos como histórias de usuários como uma maneira de responder à pergunta: "O que exatamente os usuários podem fazer com o produto neste momento?" .

Eu não tenho especificamente uma necessidade para isso agora, mas posso ver que é útil poder mostrar a um cliente: "Aqui: é exatamente isso que o produto faz". Essa pode ser uma boa maneira de rastrear nossos compromissos contratuais ou até mesmo uma lista de verificação de compra.

Em geral, as histórias de usuário são usadas como uma ferramenta para capturar e implementar novos requisitos - e, até onde eu sei, as pessoas raramente excluem uma história de usuário quando o requisito se torna obsoleto ou não é necessário não mais. E sem fazer essa "poda", você não tem mais uma especificação completa da funcionalidade do seu produto em um determinado momento.

Suponho que a outra maneira de capturar essa especificação é por meio de testes de aceitação (tese de Executable Specification ). Com algo como maxixe, você tem um strong acoplamento entre história, teste de aceitação e especificação.

TL; DR: Se eu quisesse capturar uma lista pontual de funcionalidade ou "especificação" do meu produto de software, como você faria isso? Histórias de usuários através de uma ferramenta de rastreamento apropriada parecem nos dar o poder de fazer isso, mas eu nunca as vi usadas para isso.

Observação: a equipe já está bastante familiarizada com o ágil, portanto, essa pergunta não é sobre como eles se familiarizam com o processo.

agile

por Schneider 22.02.2017 / 01:43

fonte

2 respostas

Tags agile

Acione a chave primária em vez da identidade Núcleo funcional para projeto de sistema de elevador

score 1 · Answer 1

Pessoalmente, eu não alocaria recursos para criar histórias de usuário de engenharia reversa em um aplicativo existente, tudo de uma só vez.

Comece com as novas solicitações para desenvolver boas práticas com esse processo (obtendo feedback de clientes, gerando histórias de usuários, usando-as para desenvolvimento e finalmente tendo recursos testados e aprovados.). Todos devem se tornar fluentes e eficientes.

Quando todos os envolvidos estiverem proficientes no processo de história do usuário, colete histórias adicionais sobre recursos ou seções do aplicativo relacionadas aos novos recursos. O objetivo aqui é identificar o que os usuários realmente querem (talvez um recurso possa ser removido?), Então ninguém acidentalmente tira algo necessário. Eu acho que este é um método mais eficiente porque o desenvolvedor está se familiarizando com uma certa parte da base de código já. Use esse conhecimento para desenvolver mais especificações.

Lembre-se de que as histórias dos usuários são o que o usuário quer do ponto de vista dele. Não há nada sobre como isso é feito. Um conjunto de testes pode ajudar a realizar isso ou a documentação de requisitos adicionais, mas você precisa ter uma equipe com alguma fluência nessa área. Equipes que lutam com testes de escrita, assim como escrever histórias de usuários, não serão capazes de criar algo muito útil. Eles estão lutando para apenas fazer funcionar.

A chave é garantir que a adoção desses novos processos (histórias de usuário e testes) seja bem-sucedida. Leva tempo. Se você ainda está praticando essas coisas, não é provável que você tire o máximo proveito delas. Todos ficarão frustrados com o processo e isso acabará sendo um desperdício.

score 0 · Answer 2

As histórias de usuários também podem ajudar a definir expectativas sobre o que esperamos dos usuários e como eles devem lidar com as limitações do sistema / estados de erro. [1]

Se você tiver especificações do sistema (estou pensando nelas como limitações pré-acordadas) que não podem ser descritas diretamente nas histórias do usuário, tente descrever o que acontecerá quando o usuário estiver no limite do sistema e o que acontece quando além disso.

[1]: isso é apenas documentação. Não force os usuários a seguir as histórias do usuário. Se houver uma lacuna entre o que os usuários estão fazendo e o que você espera que eles façam, os requisitos não foram bons o suficiente na primeira vez e precisam ser revisitados.