Comment l'agilité peut-elle être appliquée aux applications impliquant un traitement complexe?

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.)

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.

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. Des exemples seraient:

• Compilateurs
• Systèmes d'analyse d'images de voitures autonomes
• Systèmes de simulation d'écoulement de fluide

Ici, il peut être très difficile de relier les tâches et les histoires d'utilisateurs. 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?

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.

Les principes agiles peuvent certainement être appliqués dans ces cas. Comment?

• Les compilateurs peuvent avoir de nouvelles fonctionnalités linguistiques ajoutées ultérieurement dans des user stories distinctes
• Les systèmes d'analyse d'images peuvent avoir de nouvelles fonctionnalités ajoutées en tant que différentes classifications d'images
• Les systèmes de simulation d'écoulement de fluide peuvent prendre en compte différents aspects du modèle dans leurs simulations

Vous n'avez pas à manger l'éléphant entier en une seule bouchée. Agile vous demande simplement de montrer que vous avez nettoyé votre assiette avant la prochaine portion d'éléphant.

Je trouve que les personnes qui adhèrent strictement aux histoires d'utilisateurs se livreront simplement à un exercice très stupide de trouver des moyens farfelus dans lesquels les changements techniques d'arrière-plan affectent l'utilisateur (à l'insu de l'utilisateur, bien sûr, car ils ne sont que naïfs) utilisateur et vous parlez de changements complexes dans votre pipeline d'analyse de données ou quelque chose de ce genre) ou ils seront tout simplement perdus pour "comment pouvons-nous organiser ce travail!?!"

Je pense que la solution évidente est d'être plus pragmatique. Si le travail est de nature très technique et n'a pas d'impact particulièrement notable sur l'utilisateur, ne perdez pas de temps à essayer d'expliquer comment il fonctionne. Il suffit de choisir une manière évidente et simple dont elle peut bénéficier aux utilisateurs, puis d'orienter l'histoire autour des détails nécessaires aux développeurs pour faire leur travail. Je trouve cela extrêmement frustrant lorsqu'un PO insiste pour ne pas avoir d'informations techniques dans l'histoire alors que c'est absolument nécessaire. Ce n'est tout simplement pas une vue très holistique de ce qu'est réellement cet artefact (l'histoire). Comme ils pensent que cela existe juste pour eux, dans la plupart des cas, c'est aussi important pour les ingénieurs.

Pour la plupart de ces tâches techniques, il y a quelques fruits faibles en ce qui concerne l'impact sur l'utilisateur, que ce soit pour améliorer l'efficacité afin que les livraisons futures soient plus rapides, améliorant les performances, la fiabilité, etc. Ce n'est pas vraiment ce à quoi les gens ont tendance à penser lorsqu'ils pensent à des `` user stories '', mais si l'entreprise veut comprendre pourquoi vous contractez une dette technique ou quelque chose à cet effet, ces explications sont généralement les plus simples à fournir.

tl; dr ne laissez pas un scrumnazi vous compliquer la vie simplement parce qu'il est trop carré pour s'adapter. Être adaptatif est un concept fondamental de l'agilité après tout. Une stricte adhésion à Scrum ou Agile va généralement à l'encontre du visage ou du pragmatisme et de la praticité (ce qui fonctionne le mieux).

Je pense que le problème est de donner aux user stories un sens qu'elles n'ont pas. Scrum utilise le terme PBI, ou Product Backlog Item, qui, je pense, est infiniment meilleur. Les PBI suivront souvent un format de user story, par exemple, vous pourriez avoir un PBI comme "Les abonnés devraient pouvoir voir les détails de leur abonnement", mais vous pourriez également avoir tout aussi facilement un PBI comme "Créer une procédure stockée pour obtenir les détails de l'abonné" ".

Les user stories sont un outil . Ils vous aident à créer des descriptions de fonctionnalités et des exigences basées sur la mise à la place d'un utilisateur. Mais, tout comme une clé est inutile lorsque vous devez accrocher une photo, il y a des moments où vous n'avez peut-être pas besoin d'une histoire d'utilisateur.

Cela dit, de nombreuses équipes jouent en fait rapidement et librement avec la partie "utilisateur". Ils peuvent avoir des "user stories" comme "En tant que développeur, je dois pouvoir appeler une procédure stockée pour obtenir les détails de l'abonné", essentiellement une "histoire de développeur" pour ainsi dire. C'est une option tout aussi valable, mais personnellement, je dis que tant que vous pouvez décrire ce qui doit être fait et proposer un ensemble de critères d'acceptation, peu importe si vous avez une véritable histoire d'utilisateur derrière ou non.

Ces types d'applications sont exactement ceux où une expertise différente est présente et se développeront davantage. Les membres de l'équipe auront en raison de formations différentes, de différents projets de passe-temps et de différentes expériences professionnelles passées des compétences différentes. De plus, si quelqu'un développe un morceau de code particulier, le développeur peut être censé être celui qui connaît le mieux le code. Il peut donc être judicieux de confier d'autres tâches de développement impliquant le même morceau de code au même développeur.

Dans le processus agile le plus populaire, Scrum, il y a la planification du poker où chaque tâche est assignée un niveau de difficulté. Le niveau de difficulté ne dépend pas de la personne qui effectue cette tâche selon le processus. Ensuite, pendant le sprint, les gens sont considérés comme homogènes de sorte que chaque personne devrait pouvoir choisir chaque tâche et la mettre en œuvre. Dans les projets similaires à CRUD, cette hypothèse est valable. Mais dans les projets très complexes et difficiles, ce n'est certainement pas le cas.

Je n'utiliserais pas un processus agile pour ce genre de projets. Votre meilleur choix est d'éviter tout processus formel et d'utiliser simplement une bonne gestion de projet. Lorsque vous décidez qui implémente une fonctionnalité particulière, déterminez qui possède les meilleures compétences nécessaires pour cette fonctionnalité et la meilleure connaissance du code existant. Aucun processus n'est nécessaire pour cela. Vous voudrez probablement rédiger de bons documents de conception pour toutes les fonctionnalités et les tenir à jour. Notez que je ne fais pas la promotion d'un modèle de type cascade ici: les documents de conception ne seront pas tous écrits au début du projet; vous allez plutôt écrire de nouveaux documents de conception car de nouvelles fonctionnalités sont nécessaires.