Acabou sendo mais longo do que eu havia planejado (tinha começado como um comentário), mas espero que o comprimento / detalhes adicionados sejam úteis e você os encontre justificados.
O Agile não é específico para aplicativos CRUD
A maior parte da literatura sobre ágil parece ter tendência para aplicativos de negócios do tipo CRUD, nos quais o usuário está ciente do que está acontecendo nos bastidores. (Tudo bem, porque a maior parte do código que está sendo escrito provavelmente pertence a essa classe.)
Eu acho que isso ocorre porque é mais fácil criar exemplos fáceis de seguir desse tipo, não porque a metodologia é direcionada a esses tipos de sistemas. Se você criar um exemplo não tão fácil de seguir, corre o risco de ficar com o leitor preso ao tentar entender o exemplo quando seu argumento era ensinar ao leitor sobre conceitos ágeis.
Histórias de usuários! = Requisitos
Para esse tipo de aplicativo, o relacionamento entre as histórias do usuário (requisitos) e as tarefas de desenvolvimento é mais direto: basta dividir a história do usuário em algumas tarefas.
Uma história de usuário não é a mesma que um requisito. É verdade que pode haver alguma sobreposição, dependendo de quão alto é o requisito, mas geralmente não é o mesmo. Tenho a impressão de que você está enfrentando a mesma armadilha que muitos de meus ex-gerentes caíram: pensando nas histórias de usuários simplesmente como sinônimos de "requisitos", que é semelhante a quando os usuários do SVN tentam fazer a transição para o Git, mas continuem pensando em termos de SVN. (Eles então enfrentam problemas devido às suposições iniciais ruins.)
IMHO, a principal diferença entre requisitos e histórias de usuários é que os requisitos especificam, em detalhes, como certos componentes do sistema devem se comportar; são especificações que incluem entradas, saídas, premissas / condições prévias, possíveis exceções levantadas etc. Eles se concentram no que o sistema faz.
OTOH, as histórias de usuários concentram-se no resultado esperado para o usuário final sem tentar criar uma especificação comportamental detalhada para os componentes do sistema. Eles se concentram na experiência esperada do usuário .
O que eu costumava fazer, e essa era uma prática adotada por minha equipe, era dividir as histórias dos usuários em tarefas. Suas tarefas podem ser tão específicas ou vagas quanto você queria / precisava delas, mas elas deveriam ser seus indicadores de progresso para o trabalho real realizado no sentido de levar a história a um estado concluído.
Exemplo
Lembro-me aproximadamente dos EUA em que trabalhei anos atrás, nos quais os usuários precisavam designar casos de teste para que todos na equipe estivessem cientes de quais TCs estavam trabalhando para evitar esforços duplicados; a interface do usuário era um aplicativo da web (interno). O usuário viu apenas um botão, mas a história foi dividida em várias tarefas que incluíam alguns detalhes técnicos de implementação etc.
Visibilidade do Usuário
Mas há outro tipo de aplicativo em que a maior parte do código tem que lidar com processamento complexo que não é diretamente visível para o usuário.
É possível torná-lo visível para o usuário de alguma forma?
Considere um GPS. Quando você perdeu a sua vez, não verá o processo real de recálculo da rota, mas o usuário recebe algum feedback útil (por exemplo, "Recalculando ...").
Os compiladores podem exibir avisos ou erros ou incluir novas configurações / opções na GUI para que os usuários vejam que algo novo foi adicionado. Eu acho que os usuários dos compiladores seriam programadores, certo? Eles não veriam o suporte a um novo padrão adicionado?
Embora o suporte a um novo padrão provavelmente esteja no nível do recurso e precise ser dividido em histórias do usuário, você se certificou de que, pelo menos em alguns casos, não está tentando usar histórias quando deveria usar os recursos ?
A análise de imagem em um carro pode ser formulada de maneira a permitir que o usuário saiba que as chances de acabar em um acidente de carro foram reduzidas. Por exemplo:
Como passageiro em um carro autônomo, preciso que a probabilidade de o veículo causar um acidente colidir com um objeto não reconhecido seja o mais próximo possível de zero, para que eu possa viajar com mais segurança.
Que os EUA capturam, em alto nível, coisas que você normalmente precisaria especificar usando uma combinação de requisitos funcionais e não funcionais - incluindo segurança, proteção etc.
No entanto, um requisito pode ser mais sobre o sistema; por exemplo:
A função abcno componente Adeve ter o valor do limite de tolerância diminuído no algoritmo de comparação de imagens para detectar melhor os objetos que se movem lentamente.
Para mim, isso seria facilmente uma tarefa na história do usuário que mencionei acima, intitulada algo como: Diminuir a tolerância na funçãoA.abc e incluir outros detalhes relevantes nela.
Para um sistema de simulação de fluidos, você pode até ter uma barra de progresso que fornece feedback sobre as tarefas em segundo plano que o sistema está executando, se isso faz sentido. (Sempre há uma maneira de informar o usuário sobre algo, embora você queira evitar spam.)
Não conheço o suficiente sobre os domínios específicos que você mencionou para criar exemplos melhores e / ou mais realistas, mas se houver uma diferença aqui, você poderá usar diferentes maneiras de fornecer feedback ao usuário sobre algo menos visível que o sistema pode estar funcionando, ou seja, pode haver maneiras de tornar as coisas invisíveis um pouco mais visíveis. (Mesmo que tudo se resume a escrever um conjunto de notas de versão que documenta quanto mais rápido o desempenho do sistema é devido aos seus esforços, etc.)
Relação entre histórias e tarefas
Aqui pode ser realmente difícil relacionar tarefas e histórias de usuários.
Nossa abordagem foi manter as histórias dos usuários focadas no que era a solicitação, por que ela foi feita e no que as coisas precisavam ser verdadeiras para considerar os EUA "concluídos". O how sempre foi deixado de fora dos EUA e deixado para o (s) desenvolvedor (es).
O (s) desenvolvedor (es) dividiriam o problema descrito nos EUA em um conjunto de tarefas nas quais eles trabalhariam.
Estou dizendo isso como alguém que, na maioria das vezes, fez a programação no servidor de back-end, que provavelmente é tão "invisível" quanto possível para o usuário final.
Dependendo do que eu precisava fazer, às vezes eu usava o AJAX para mostrar uma animação / gif "carregando ..." simples, para que o usuário soubesse que precisava esperar um pouco para que algo mais fosse concluído, sem ter a impressão errada. Às vezes era tão simples assim. Uma tarefa para isso seria apropriada.
Paradigma, prática e experiência diferentes
Existem técnicas para superar esse problema ou é apenas algo que temos que aceitar e tirar o melhor proveito dele?
Além de aceitar a mudança de paradigma, praticar e acumular experiência, provavelmente não há muito mais a dizer. Eu sempre vi pessoas tentando usar atalhos durante o processo. Eu aconselho isso, especialmente se você está começando. À medida que obtém mais experiência, você pode permitir alguma flexibilidade, mas evite prejudicar a si mesmo.
Dada a sua redação anterior, você ainda pensa nas histórias como se fossem "requisitos renomeados", o que eu acho que é uma suposição falsa. Penso que este é um sintoma de uma questão mais profunda sobre as diferenças fundamentais entre abordagens ágeis e não-ágeis.
Em segundo lugar, acho que você deve aceitar que o ágil é uma mudança de paradigma em comparação à cascata, o que significa que, embora o processo tenha objetivos semelhantes, eles o fazem de maneiras muito diferentes. (Pense em SVN vs Git, se isso ajudar.)
Tente melhorar sua compreensão atual das diferenças conceituais entre requisitos e histórias de usuários e aceite que elas não são a mesma coisa.
Aprendendo com seus Sprints - Retrospectivas
O que não posso enfatizar o suficiente é a retrospectiva entre Scrum Master e Desenvolvedores no final de cada sprint. É nesse lugar que eles discutem coisas que "deram certo" ou "não deram certo" de maneira honesta / transparente, e que mudanças factíveis serão implementadas para o próximo sprint para abordar os pontos "não deram certo" .
Isso nos permitiu adaptar e até aprender com as experiências uns dos outros e, antes que percebêssemos, tínhamos melhorado significativamente conforme medido pela consistência geral da velocidade de nossa equipe.