As user stories são a mesma coisa que casos de uso?

[abalad]

Abro este Topico para discutirmos opiniões para pessoas que trabalham com métodos ágeis no desenvolvimento FrontEnd, como sugestão pode-se utilizar o seguinte esquema:

• [ O que é User Stories para você e Quando utilizar ] : Resposta [Exemplos]

• [ O que é um Caso de Uso para você e Quando utilizar ] : Resposta [Exemplos]

• [ Conclusão ] : Resposta

[RatoX]

tudo isso aqui são minhas opiniões baseada numa cacetada de livros e experiências mas isso não quer dizer que elas são melhores ou piores do que a sua experiência meu caro leitor <3

O que é User Stories para você e Quando utilizar:

• São necessidades especificas de um usuário/client/persona. Geralmente são tratadas como épicos e depois são quebradas pelo time de tecnologia ( nas IPM iteration planning meeting) junto com o P.O ou stackholders.

• É muito bom para times ágeis que trabalham com sistemas que mudam, e aceitam mudanças, toda a hora.

• Um formato muito bom para que a tecnologia se torne um pouco do porco no produto.

Ex.:

UserStory: O persona Felipe precisa agendar aulas na aplicação.

Na IPM:

• Os pontos técnicos são levantados: TimeZone e outras coisas que já sabemos que dar problema quando trabalhamos com datas.
• Os débitos técnicos sobre aquela parte do código são relembrados.
• Histórias menores são criadas:
• Criar mockup baseada nos dados sobre o persona Felipe
• Adicionar endpoint para listar as aulas baseado em uma data especifica
• Adicionar endpoint para salvar uma ou mais aulas para um usuário
• Implementar mockup criado para Felipe
• Estimativas são feitas ( aqui é onde entra o rage da comunidade )

*lembrando que detalhes sobre as histórias menores vão ser detalhadas também

O que é Caso de Uso para você e Quando utilizar:

• É uma descrição detalhada sobre um modulo/funcionalidade de um sistema. Geralmente são tratadas como fonte da verdade e inalteráveis, existem processos que alterações em casos de usos necessitam de duas assinaturas de gerentes.

• É criado, na sua maioria, por um(a) Analista de Negócios junto com os clientes ou gerentes, ele vem bem detalhado, as vezes com pseudo-código dentro.

• O caso de uso é designado para um par ou uma pessoa especifica

• Prazos fixos são comuns, existem até modelos de caso de uso que tem o campo de data de conclusão é obrigatório.

Ex.:

Uma regra para medição de quantidade de aço no concreto

Na fase de analise:

• A(o) analista de negocio senta com o(a) engenheiro(a) para entender e determinar com essa regra funciona
• Mais de uma reunião é feita para que todos os detalhes sejam levantados
• Uma segunda pessoa revisa o Caso de Uso
• O analista conclui o documento
• Os(as) engenheiros(as) chefes assinam

Na fase de desenvolvimento:

• O analista entrega o caso de uso para o(a) desenvolvedor(a)
• O(a) desenvolvedor entrega no prazo previsto
• O analista testa todo o produto baseado nas regras que o engenheiro descreveu

Conclusão

Eu acho os Casos de Usos muito mais burocráticos porém eu acredito que cada casa é um caso. Coloquei duas situações bem distintas onde eu não me sentiria bem trabalhando em um projeto de engenharia, onde vidas estão em jogo, usando User Stories do jeito que eu descrevi acima e vice-versa.

[chicoalff]

Ótima discussão! A pouco escrevi um artigo com dicas sobre como escrever uma user story considerando o conceito das sete dimensões de um produto, se quiser conferir: http://www.analisederequisitos.com.br/disciplinas/engenharia-de-requisitos/