Story-Splitting-B-agile

portanto, é mais ou menos uma questão de gosto se você prefere um diagrama de caso de Uso gráfico ou uma lista de histórias de usuários (textuais).

deixe-me resumir a discussão sobre a estruturação de requisitos em geral: independente da notação, uma decomposição de um grande problema em um processo acionado externamente é a maneira mais neutra de alcançar esse detalhamento. Não se baseia em nenhuma estrutura interna dos sistemas (nem em suas funções, nem em seus subsistemas, nem em seus objetos).,,) mas puramente sobre as necessidades do meio ambiente.Isso não quer dizer que as outras estratégias de decomposição mencionadas acima não funcionem, mas apenas uma sugestão para não ficar preso em discussões estruturais internas.

Dividindo-se em pequenos

Como você pode ver no exemplo simples de sistema de navegação acima deste processo (independente da notação você preferir) ainda parece ser muito complexo para ser implementado em uma iteração. Você definitivamente precisa dividi-lo em pedaços menores. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) sugeriu muitas maneiras de lidar com pedaços maiores e dividi-los em histórias que são pequenas o suficiente para uma iteração.

Enquanto métodos clássicos sugeridos, principalmente, para compreender um processo complexo, melhor examinando a sua sequência de passos, estamos agora enfrentando um problema adicional no agile mundo: queremos criar valor em cada iteração, isto é, venha com potencialmente entregável do produto incrementos. Não é bom o suficiente apenas decompor um grande processo (um caso de uso ou uma grande história) para entendê-lo melhor. Após a decomposição, cada parte ainda deve entregar algum valor ao usuário independente das outras partes.Isso inibe Divisões Técnicas, como dividir em suas camadas técnicas, como interface de usuário, funcionalidade de domínio e camada de persistência, uma vez que implementar a camada de persistência primeiro (ou seja, criar algumas tabelas de banco de dados) não fornece nenhum valor comercial até que você possa preenchê-las e exibi-las. O mesmo é frequentemente verdadeiro para a decomposição pura do processo de negócios em suas etapas: implementar apenas a única etapa 7 de um processo complexo pode não fornecer nenhum valor, desde que as etapas predecessoras e sucessoras não estejam lá.

(apenas uma observação histórica interessante sobre guerras terminológicas entre metodologistas: Mike Cohn reclamou que as histórias de usuários não são casos de uso simplesmente usando o argumento: elas podem ser grandes demais para implementá-las em uma iteração. Ivar Jacobson aceitou esse argumento sobre o tamanho, mas recuou alegando que as “fatias de casos de uso” são uma maneira muito melhor de pensar do que trabalhar com histórias de usuário pequenas o suficiente, já que as fatias de casos de uso fornecem valor de ponta a ponta.)