Cela s'est avéré plus long que ce que j'avais prévu (cela avait commencé comme un commentaire), mais j'espère que la longueur / les détails ajoutés sont utiles et que vous les trouvez justifiés.
Agile n'est pas spécifique aux applications CRUD
La plupart de la littérature sur l'agile semble être orientée vers les applications métier de type CRUD où l'utilisateur est à peu près au courant de ce qui se passe en coulisses. (C'est bien parce que la plupart du code en cours d'écriture appartient probablement à cette classe.)
Je pense que c'est parce qu'il est plus facile de créer des exemples faciles à suivre de ce type, pas vraiment parce que la méthodologie vise ces types de systèmes. Si vous créez un exemple pas si facile à suivre, vous risquez de coincer le lecteur en essayant de comprendre l'exemple alors que votre point était censé enseigner au lecteur des concepts agiles.
User Stories! = Exigences
Pour ce type d'application, la relation entre les user stories (exigences) et les tâches de développement est généralement simple: il suffit de diviser la user story en quelques tâches.
Une user story n'est pas la même chose qu'une exigence. Certes, il peut y avoir un certain chevauchement selon le niveau de «haut niveau» de l'exigence, mais généralement pas la même. J'ai l'impression que vous rencontrez le même écueil que beaucoup de mes anciens managers sont tombés: penser aux user stories simplement comme synonymes de "requirements", ce qui est similaire au moment où les utilisateurs SVN tentent de passer à Git, mais gardez penser en termes de SVN. (Ils rencontrent ensuite des problèmes en raison des mauvaises hypothèses de départ.)
À mon humble avis, une différence clé entre les exigences et les histoires d'utilisateurs est que les exigences spécifient, en détail, comment certains composants du système doivent se comporter; ce sont des spécifications qui incluent les entrées, les sorties, les hypothèses / conditions préalables, les exceptions possibles soulevées, etc. Elles se concentrent sur ce que fait le système .
OTOH, les user stories se concentrent sur le résultat attendu pour l'utilisateur final sans essayer de créer une spécification comportementale détaillée pour les composants du système. Ils se concentrent sur l' expérience utilisateur attendue .
Ce que j'avais l'habitude de faire, et c'était une pratique adoptée par mon équipe, était de décomposer les user stories en tâches. Vos tâches peuvent être aussi précises ou vagues que vous le souhaitez / en avez besoin, mais elles sont censées être vos indicateurs de progrès pour le travail réel accompli pour amener l'histoire à un état terminé.
Exemple
Je me souviens à peu près des États-Unis sur lesquels j'ai travaillé il y a des années où les utilisateurs devaient auto-assigner des cas de test afin que tout le monde dans l'équipe sache sur quels TC ils travaillaient pour éviter les efforts en double; l'interface utilisateur était une application Web (n interne). L'utilisateur n'a vu qu'un bouton, mais l'histoire a été divisée en plusieurs tâches qui comprenaient des détails de mise en œuvre technique, etc.
Visibilité utilisateur
Mais il existe un autre type d'application où la majeure partie du code doit traiter des traitements complexes qui ne sont pas directement visibles par l'utilisateur.
Est-il possible de le rendre visible d'une manière ou d'une autre pour l'utilisateur?
Prenons un GPS. Lorsque vous avez manqué votre tour, vous ne verrez pas le processus de recalcul de l'itinéraire réel, mais l'utilisateur reçoit des commentaires utiles (par exemple, "Recalculer ...").
Les compilateurs peuvent afficher des avertissements ou des erreurs, ou inclure de nouveaux paramètres / options dans l'interface graphique pour que les utilisateurs voient que quelque chose de nouveau a été ajouté. Je pense que les utilisateurs des compilateurs seraient des programmeurs, non? Ne verraient-ils pas le soutien d'une nouvelle norme ajoutée?
Bien que la prise en charge d'une nouvelle norme soit probablement au niveau des fonctionnalités et devrait être décomposée en user stories, vous êtes-vous assuré qu'au moins dans certains cas, vous n'essayez pas d'utiliser des stories alors que vous devriez plutôt utiliser des fonctionnalités ?
L'analyse d'image dans une voiture pourrait être formulée de manière à permettre à l'utilisateur de savoir que les chances de se retrouver dans un accident de voiture ont été réduites. Par exemple:
En tant que passager dans une voiture autonome, j'ai besoin que la probabilité que le véhicule provoque un accident en s'écrasant sur un objet non reconnu soit aussi proche de zéro que possible, afin de pouvoir voyager plus en toute sécurité.
Que les États-Unis capturent, à un niveau élevé, des choses que vous devriez normalement spécifier en utilisant une combinaison d'exigences fonctionnelles et non fonctionnelles, y compris la sécurité, la sûreté, etc.
Cependant, une exigence pourrait concerner davantage le système; par exemple:
La fonction abcdu composant Adoit avoir la valeur du seuil de tolérance diminuée dans l'algorithme de comparaison d'images pour mieux détecter les objets se déplaçant lentement.
Pour moi, ce serait facilement une tâche dans l'histoire de l' utilisateur je l' ai mentionné ci - dessus, intitulé quelque chose comme: Diminution de la tolérance en fonctionA.abc et inclure d' autres détails pertinents en elle.
Pour un système de simulation fluide, vous pouvez même avoir une barre de progression qui fournit des informations sur les tâches d'arrière-plan que le système effectue, si cela est logique. (Il existe toujours un moyen d'informer l'utilisateur de quelque chose, bien que vous souhaitiez peut-être éviter le spam.)
Je ne connais pas assez les domaines particuliers que vous avez mentionnés pour trouver des exemples meilleurs et / ou plus réalistes, mais s'il y a un point à retenir ici, c'est que vous pouvez utiliser différentes façons de fournir aux utilisateurs des commentaires sur quelque chose de moins visible que le système pourrait faire, c'est-à-dire qu'il pourrait y avoir des moyens de rendre les choses invisibles un peu plus visibles. (Même si cela se résume à la rédaction d'un ensemble de notes de publication qui documente à quel point les performances du système sont désormais plus rapides grâce à vos efforts, etc.)
Relation entre les histoires et les tâches
Ici, il peut être très difficile de relier les tâches et les histoires d'utilisateurs.
Notre approche était de garder les histoires d'utilisateurs concentrées sur ce qu'était la demande, pourquoi elle avait été faite et ce qui devait être vrai pour considérer que les États-Unis étaient «terminés». Le comment a toujours été exclu des États-Unis et laissé au (x) développeur (s).
Le ou les développeurs décomposeraient le problème décrit aux États-Unis en un ensemble de tâches sur lesquelles ils travailleraient.
Je dis cela comme quelqu'un qui, pour la plupart, a fait de la programmation côté serveur, qui est probablement aussi "invisible" que vous pouvez obtenir pour l'utilisateur final.
En fonction de ce que je devais faire, j'utilisais parfois AJAX pour afficher une animation / gif de "chargement ..." simple afin que l'utilisateur sache qu'il devait attendre un peu avant que quelque chose d'autre se termine, sans avoir la mauvaise impression. Parfois, c'était aussi simple que cela. Une tâche pour cela serait appropriée.
Paradigme, pratique et expérience différents
Existe-t-il des techniques pour surmonter ce problème ou s'agit-il simplement de quelque chose que nous devons accepter et en tirer le meilleur parti?
Au-delà de l'acceptation du changement de paradigme, de la pratique et de l'expérience accumulée, probablement pas grand-chose de plus à dire. J'ai souvent vu des gens essayer de prendre des raccourcis tout au long du processus. Je déconseille cela, surtout si vous commencez. À mesure que vous obtenez plus d'expérience, vous pouvez permettre une certaine flexibilité, mais évitez de vous affaiblir.
Compte tenu de votre formulation précédente, vous pensez toujours aux histoires comme si elles étaient des «exigences renommées», ce qui, je pense, est une fausse hypothèse. Je pense que c'est le symptôme d'un problème plus profond concernant les différences fondamentales entre les approches Agile et non Agile.
Deuxièmement, je pense que vous devez accepter que l'agilité est un changement de paradigme par rapport à la cascade, ce qui signifie que, si le processus a des objectifs similaires, ils s'y prennent de manières très différentes. (Pensez SVN vs Git, si cela aide.)
Essayez d'améliorer votre compréhension actuelle des différences conceptuelles entre les exigences et les user stories et acceptez que ce n'est pas la même chose.
Tirer des leçons de vos sprints - Rétrospectives
Ce que je ne saurais trop insister, c'est la rétrospective entre Scrum Master et Developers à la fin de chaque sprint. C'est l'endroit où ils discutent des choses qui "se sont bien passées" ou "qui ne se sont pas bien passées" d'une manière honnête / transparente, et quels changements réalisables seront mis en œuvre pour le prochain sprint afin de résoudre les points "qui ne se sont pas bien passés" .
Cela nous a permis de nous adapter et même d'apprendre des expériences des uns et des autres, et avant que nous le sachions, nous nous étions considérablement améliorés, mesurés par la cohérence générale de la vitesse de notre équipe.