Histórias de usuários para requisitos funcionais [fechado]

Question

Como somos uma empresa pequena, atuo tanto como gerente de projetos quanto como desenvolvedor.As especificações que crio para os clientes contêm uma série de elementos usados ​​para descrever e definir o projeto, incluindo histórias de usuários juntamente com quaisquer outros elementos que considero necessários para definir o projeto (por exemplo,wireframes, fluxos de usuários, mapas de sites etc.) para o cliente.

Se uma especificação funcional “descreve como um produto funcionará inteiramente da perspectiva do usuário.Não importa como a coisa é implementada.Ele fala sobre recursos.“.Então alguém vê algum problema em usar histórias de usuários para definir uma especificação funcional para um site?Alguém realmente faz especificações funcionais dessa maneira?

Na verdade, estou tentando melhorar um pouco o meu jogo e me perguntando se essa abordagem funcionaria para clientes maiores que talvez tenham ideias mais rigorosas sobre o que uma especificação funcional deve conter, pelo que uma abordagem formal pode ser necessária.Definitivamente neste momento os nossos clientes respondem bem ao nosso método de produção de documentação.

Estou interessado em ouvir o que as pessoas que trabalham profissionalmente em gerenciamento de projetos pensam sobre isso.

Answer 1

Estou em desacordo com o que algumas outras pessoas disseram.

Em primeiro lugar, concordo: as histórias são uma ótima maneira de declarar requisitos funcionais.Para mim, eles são uma das melhores maneiras de realmente comunicar os requisitos de uma forma que os usuários finais realmente entendam.Já vi muitas especificações que foram assinadas sem nunca terem sido lidas.

A única coisa que eu diria que você gostaria de acrescentar a eles são os requisitos não funcionais - cobrindo desempenho, segurança, volumes de dados, auditoria, arquivamento e assim por diante.Embora possam ser abordados em histórias, às vezes são melhor abordados de uma forma que cruze todas as histórias.

Em termos de ser adequado para grandes empresas, é aqui que discordo.Na minha experiência (e já fiz projetos para a Shell, American Express, alguns bancos multinacionais e outros), muitas vezes eles não são mais formais do que empresas menores, então ficarão bem com histórias.A realidade é que um usuário em uma grande empresa não está mais bem equipado (ou interessado) na leitura de diagramas de classes e sequências do que em qualquer outro lugar.

O tamanho e a complexidade do projeto podem exigir requisitos mais detalhados, mas é o tamanho do projeto, e não o tamanho da empresa, que importa quando você determina como documentar os requisitos.

Para mim, a melhor documentação de requisitos é a documentação adequada ao seu público, e para mim as histórias de usuários acertam em cheio na maioria das vezes - elas são curtas e claras o suficiente para que, quando assinadas, signifiquem algo porque ' eu os li e entendi (em oposição à aprovação de uma especificação de 100 páginas, o que invariavelmente significa que eles realmente não a leram), mas é bom o suficiente para os desenvolvedores trabalharem também.

Answer 2

Sim, você pode usar histórias de usuários para suas necessidades funcionais.Faço isso o tempo todo, e já faço isso há anos.Na minha opinião, funciona muito bem e melhor do que outros sistemas que usei.

Essa abordagem funcionaria para clientes maiores?Para fazer uma generalização grosseira, não.Eles terão algum sistema usado para definir requisitos e provavelmente não serão histórias de usuários.Se você vier com histórias de usuários, haverá uma desconexão com as práticas atuais, que você terá que superar.

Tenho tido sucesso ao usar histórias de usuários em organizações maiores, mas é necessário um esforço conjunto, com o qual ambas as partes precisam estar comprometidas.

Answer 3

O que você está descrevendo são os cenários de casos de uso que definem os recursos, é isso que é necessário do ponto de vista da usabilidade e é exatamente o que o cliente entenderá e concordará.Maquetes de tela e diagramas de fluxo certamente ajudarão tanto o cliente quanto os desenvolvedores.

Uma especificação de implementação pode então ser necessária para instruir os desenvolvedores sobre o que precisa ser incluído na construção real. A profundidade disso será determinada pelas capacidades de seus desenvolvedores, que incluem seu conhecimento da arquitetura/estrutura da casa e metodologias/convenções e podem incluir detalhes específicos sobre o que afeta várias partes do aplicativo.

Também trabalhamos em equipes pequenas (às vezes um ou dois desenvolvedores) e acreditamos que o que foi dito acima é tudo o que é necessário neste caso.

Empresas maiores com equipes muito maiores podem usar Software de Modelagem, diagramas UML e outras especificações mais detalhadas.No caso de você ser o desenvolvedor principal, você ainda deve gastar tempo projetando seu aplicativo, mas se ninguém for revisar os designs e insistir em todas as formalidades, é melhor gastar seu tempo implementando o software.