Approche Lean Agile en action

Exemple de portail étudiant

Un collège communautaire souhaite développer un portail étudiant pour offrir des services en ligne aux étudiants. Ils ont invité un représentant étudiant, du personnel du département et les membres de l’équipe d’administration du portail afin de former une équipe pour participer au projet de développement du portail étudiant. Voici les comptes rendus extraits de la première réunion.

Réunion des parties prenantes

Ordre du jour

• Proposer des fonctionnalités pour le portail étudiant
• Discuter de la faisabilité de la liste des fonctionnalités proposées
• Prioriser les fonctionnalités à implémenter comme essentielles, prochaine livraison, souhaitables…

Steve (équipe de développement) : Bienvenue… Nous souhaitons rendre cette réunion plus productive et fructueuse. Lorsque vous proposez des fonctionnalités que vous souhaitez avoir, nous pouvons utiliser le format suivant comme méthode standard d’expression : qui (vous êtes), quelle fonctionnalité (vous voulez), et pourquoi (vous la voulez)… Ces fonctionnalités seront enregistrées sous forme de « user stories » comme outil de communication tout au long de ce projet.

Nous avons ensuite fait une séance de cerveau-vent de propositions de « user stories » provenant de différentes parties prenantes :

Représentant étudiant : s’inscrire à des cours, payer les frais de scolarité, consulter l’horaire, modifier l’horaire, consulter la fiche de notes, abandonner des cours…

Représentant académique : ajouter des informations sur les cours, modifier les informations sur les cours, supprimer les informations sur les cours…

Administrateur du portail : sauvegarder les informations sur les cours, modifier l’état du compte étudiant

Maintenant, nous avons un ensemble de cartes pouvant être organisées en lignes et colonnes

Prioriser les fonctionnalités proposées

Représentant développeur : Nous disposons d’une liste de « user stories » prioritaires à implémenter dans l’itération suivante. Pour cela, nous devons approfondir chaque « user story » afin de mieux comprendre et obtenir davantage d’informations. Examinons ensemble la première fonctionnalité essentielle « s’inscrire à un cours »

Nous avons obtenu des informations supplémentaires suivantes des utilisateurs finaux lors de la réunion :

• Académique : l’étudiant doit être inscrit à temps plein
• Administrateur : l’étudiant doit fournir des identifiants de compte corrects pour se connecter
• Académique : le cours n’est pas complet
• Académique : les prérequis du cours doivent être remplis
• Administrateur : un cours sélectionné pour être ajouté au planning ne doit pas entrer en conflit avec l’horaires d’un autre cours
• Développeur : quelles autres fonctionnalités souhaitez-vous regrouper en liste avec cette fonctionnalité dans le système cible ?
• Étudiant : abandonner des cours, consulter l’horaire, modifier l’horaire.

Les 3C de la « user story »

De bonnes « user stories » sont bien plus que de simples énoncés. Une « user story » standard se compose de trois parties, communément appelées les trois C. Le premier « C » de chaque « user story » doit suivre le format standard : « En tant que [rôle], je veux [faire quelque chose], afin de [bénéfice] », qui constitue le contenu minimal d’une « user story » à inscrire sur la carte. La « Conversation » est le contenu du deuxième « C », qui représente les échanges entre les utilisateurs finaux, le propriétaire du projet et l’équipe de développement. Ces échanges enregistrent les discussions orales ou d’autres informations utiles telles que des courriels, des maquettes ou tout autre contenu connexe au projet. Le dernier « C » d’une « user story » est la « confirmation », qui correspond aux critères d’acceptation utilisés pour vérifier que la « user story » a été correctement implémentée et livrée avec succès.

Permettez-moi d’approfondir un peu plus la manière de développer la partie de confirmation d’une histoire utilisateur. Ici, nous utilisons le modèle le plus connu appelé Gherkin, qui adopte la formule Given-When-Then pour guider la rédaction des tests d’acceptation pour une histoire utilisateur :

• (Étant donné.. et) un contexte
• (Lorsque.. et) une action est effectuée
• (Alors.. et) Effectuer certaines actions

Des outils tels que Cucumber et les frameworks de test Jbehave encouragent l’utilisation du modèle Given/Then/Then pour effectuer des tests automatisés, bien qu’il puisse également être utilisé uniquement comme une heuristique, indépendamment de l’outil utilisé.

Regroupons toutes les informations concernant l’histoire utilisateur « s’inscrire à un cours » et plaçons-les au format 3Cs :

Maintenant, mettons ces informations dans UeXceler, qui inclut la conversion et la confirmation que nous avons développées précédemment.

Division d’un épisode en histoires utilisateur

Si nous examinons plus en détail l’histoire utilisateur « s’inscrire à un cours », nous pouvons constater qu’elle est trop grande pour être incluse dans un sprint. Nous pouvons la considérer comme un épisode (une histoire utilisateur plus grande), qui peut être divisée en un groupe d’histoires utilisateur plus petites et liées. Nous pouvons diviser un épisode en tâches, que j’appellerais une division horizontale, ou, à la place, diviser l’épisode en scénarios, ce que nous appellerions une division verticale.

Division horizontale

L’approche traditionnelle pour construire une grande fonctionnalité consistait à la décomposer en travaux à réaliser au niveau des couches architecturales. Par exemple, modèle-vue-contrôle (MVC) ou architecture client-serveur, afin de garantir une séparation des préoccupations dans l’architecture du système, puis de la peaufiner en une architecture à n niveaux, telle que l’interface utilisateur (GUI), la logique de contrôle, le modèle d’objets, le mappage objet-relationnel, les couches de base de données, etc. Il existe de nombreuses couches dans une architecture à n niveaux, et je vais simplement en lister quelques-unes ci-dessous :

• Permet de développer une expertise élevée dans l’une des couches architecturales
• D’autres applications pourront réutiliser la fonctionnalité exposée par vos couches.
• Vous pourrez répartir vos couches sur plusieurs niveaux physiques. Cela peut avoir un impact très positif sur votre application en améliorant les performances (parfois), la scalabilité et la tolérance aux pannes.
• La maintenance de votre application est plus facile en raison de la faible couplage entre les couches.
• Ajouter plus de fonctionnalités à votre application devient plus facile.
• Les couches rendent votre application plus testable.

Il existe un grand nombre de réalisations réussies basées sur l’architecture à n niveaux, telles que Ruby on Rails et les architectures basées sur les services web.

Histoires utilisateur et division horizontale

Bien que l’architecture à n niveaux apporte des avantages à notre système, elle présente certains inconvénients lorsqu’elle est utilisée avec l’approche des histoires utilisateur. Elle tend à entraîner un cycle de retour très lent, en fonction de la taille de la fonctionnalité, car nous devons attendre que chacun termine sa partie pour l’intégrer et s’assurer qu’elle fonctionne. Le terme « découpage horizontal » fait référence à l’utilisation de cette approche par couches architecturales comme méthode principale de décomposition des grandes fonctionnalités.

Division verticale

Afin d’accélérer le cycle de retour, nous pouvons prendre un épisode et le diviser en plusieurs scénarios utilisateur qui traversent chacune des couches architecturales. Nous pouvons décomposer presque toute fonctionnalité en tranches, de sorte qu’il ne prenne au plus quelques jours pour construire, intégrer et tester toutes les pièces. Chaque tranche comprend tout le travail nécessaire à effectuer au niveau d’une couche architecturale, ainsi que tout test et intégration nécessaires pour la rendre prête à être livrée.

Typiquement, la division horizontale divise les fonctionnalités en histoires utilisateur ou tâches au niveau des composants architecturaux. Exemple : interface utilisateur front-end, bases de données ou services backend. En revanche, une tranche verticale produit un logiciel fonctionnel et démontrable qui ajoute de la valeur métier. Ainsi, la division verticale améliore la capacité de l’équipe à livrer un incrément de produit potentiellement livrable à chaque sprint. Imaginez couper un gâteau composé de couches de crème, de chocolat, de fruits et de gâteau. Si vous coupez le gâteau horizontalement, votre ami ne recevra qu’une tranche de gâteau, de chocolat, de crème ou de fruits. Je suis sûr que vos amis préféreraient un morceau contenant un peu de chaque couche. Obtenir simplement une seule couche ne leur permet pas de goûter le véritable goût de tout le gâteau. Une approche plus favorable pour vos amis consiste à créer des tranches verticales (la valeur souhaitée).

Division horizontale d’un épisode selon un objectif

Rappelez-vous que la conversion de l’histoire utilisateur « s’inscrire à un cours » que nous avons lors de la réunion avec les parties prenantes, la fonctionnalité a été initialement proposée par les étudiants (rôle principal) et soutenue par d’autres parties prenantes. Lorsque nous approfondissons les détails de l’histoire utilisateur, nous constatons qu’il y a une bonne quantité d’informations réservées par les autres parties prenantes qui participeront à l’histoire utilisateur en tant que rôles secondaires.

En réalité, certains étudiants peuvent ne pas s’intéresser ou même ne pas vouloir les contraintes imposées par les personnes en rôle secondaire. Par exemple, un étudiant oublie son mot de passe et l’a entré incorrectement trois fois, il/elle peut ne pas vouloir passer par le processus de réinitialisation du mot de passe, mais souhaite tout de même pouvoir réessayer plusieurs fois. Ou encore, un étudiant ne souhaite pas avoir de quota pour les livres de la bibliothèque ou une période d’emprunt, etc. Ceux qui souhaitent imposer des règles métier ou des contraintes aux fonctionnalités proposées en tant que leur objectif utilisateur sont précisément ceux qui participent en tant que rôles secondaires dans l’histoire utilisateur. La fonctionnalité ne devrait pas fonctionner du tout si les règles métier et l’objectif secondaire ne sont pas appliqués à la fonctionnalité proposée. Si nous divisons l’épisode horizontalement selon les objectifs des acteurs secondaires en un groupe d’histoires utilisateur, nous pouvons à la fois satisfaire les objectifs des acteurs secondaires, rendre l’histoire utilisateur testable et obtenir directement des retours de la personne concernée.

Examinons les informations provenant des sections de conversion et de confirmation pour voir comment nous pouvons diviser l’histoire plus grande « s’inscrire à un cours » en un groupe d’histoires utilisateur liées.

1. L’étudiant doit être un étudiant inscrit. Sinon, il/elle ne recevra pas les identifiants fournis par la notification destinée aux nouveaux étudiants. S’il a reçu la notification mais que le compte n’a pas encore été activé, il/elle doit s’inscrire au nouveau compte en ligne (marqué par un cercle rouge 1)
2. Si nous approfondissons un peu plus le processus de connexion, nous savons que si un étudiant fournit ses identifiants incorrectement trois fois, il doit alors entrer dans le « processus de réinitialisation du mot de passe » (marqué par les cercles rouges 2 et 3)

Compartiment général des histoires utilisateur

Créons ces histoires d’utilisateurs dans UeXceler :

L’histoire d’utilisateur « Connexion au compte » est créée dans le compartiment général des histoires d’utilisateurs. En plus des histoires d’utilisateurs liées à la connexion, deux autres histoires d’utilisateurs connexes sont également en cours de création dans le même compartiment général : « Réinitialiser le mot de passe » et « Créer un nouveau compte étudiant », pour les raisons suivantes :

• Si les identifiants du compte sont saisis incorrectement par l’étudiant à trois reprises, cela déclenchera l’histoire d’utilisateur « Réinitialiser le mot de passe » ;
• Et si un nouvel étudiant n’a pas encore enregistré de compte étudiant, il/elle peut déclencher l’histoire d’utilisateur « Créer un nouveau compte étudiant » depuis l’écran de connexion.

1. En tant qu’étudiant, je veux me connecter au portail étudiant, afin que…
2. En tant qu’administrateur du portail, je veux vérifier que la personne qui se connecte est un étudiant inscrit, afin que…
3. En tant que responsable de cours, je veux vérifier la pertinence avant d’autoriser l’ajout du cours sélectionné au planning de l’étudiant, afin que…

Nous pouvons considérer que ces trois histoires d’utilisateurs sont divisées horizontalement à partir de l’épique « s’inscrire à un cours », mais ces histoires d’utilisateurs permettront de réaliser les objectifs de certains acteurs secondaires auprès desquels vous pouvez obtenir des retours et confirmer. Sans que les préconditions soient remplies, l’histoire d’utilisateur principale n’aurait plus aucun sens.

Vous pouvez voir que nous avons placé toutes ces histoires d’utilisateurs dans le compartiment général des histoires d’utilisateurs, et la raison en est qu’elles partagent probablement la même précondition avec les autres fonctionnalités (histoires d’utilisateurs) liées sur la même page d’appel, telles que « visualiser le planning », « modifier le planning », « supprimer des cours », etc.

Compartiments des cas d’utilisation

Il reste trois éléments encerclés en rouge marqués 4, 5 et 6 sur la figure ci-dessus. Ce sont les scénarios alternatifs de l’épique « s’inscrire à un cours ». Si l’une de ces trois conditions est fausse, un scénario alternatif sera alors déclenché et peut être représenté comme une histoire d’utilisateur divisée. Peut-être pouvons-nous la diviser soit horizontalement, soit verticalement, mais n’est-ce pas toujours le découpage vertical qui est préférable ? Pas nécessairement, cela dépend vraiment du contexte. Il n’existe pas de solution universelle, nous devons considérer quelle approche convient le mieux à votre situation. Permettez-moi d’approfondir davantage.

Par exemple, si vous allez attribuer l’histoire d’utilisateur principale à un développeur et les trois histoires d’utilisateurs « connexion », « s’inscrire à un nouveau compte » et « réinitialiser le mot de passe » à un autre développeur. Vous pourriez préférer que le développeur chargé de l’histoire principale développe d’abord le scénario idéal durant le sprint en cours, puis développe progressivement les scénarios alternatifs lors des sprints suivants (si le délai le permet). Mais si le délai est court et que vous jugez que c’est trop lourd pour un seul développeur de gérer l’épique entier, vous pouvez alors le découper horizontalement en tâches pour les attribuer à plusieurs développeurs en parallèle.

Découpage de l’épique en scénarios

Si nous considérons les détails du scénario décrit dans la section de confirmation de l’épique, nous pouvons facilement identifier les tranches verticales pour un groupe d’histoires d’utilisateurs connexes.

1. En tant que responsable de cours, je veux vérifier les prérequis avant d’autoriser l’ajout du cours sélectionné au planning de l’étudiant, afin que…
2. En tant que responsable de cours, je veux vérifier la disponibilité du cours avant d’autoriser son ajout au planning de l’étudiant, afin que…
3. En tant que responsable de cours, je veux vérifier la disponibilité de l’horaire de l’étudiant avant d’autoriser l’ajout du cours sélectionné au planning de l’étudiant, afin que…

Découpage de l’épique en tâches

Si nous souhaitons décomposer l’épique en tâches plus petites pour un développement parallèle au sein du même sprint, comme suit :

1. Vérifier l’état du quota du cours
2. Vérifier les prérequis du cours
3. Vérifier l’horaire

Maintenant, c’est à vous de choisir comment découper l’épique en histoires d’utilisateurs pour le processus de développement agile. Vous pouvez voir que l’histoire d’utilisateur « S’inscrire à un cours » et ses histoires d’utilisateurs connexes sont placées dans un compartiment de cas d’utilisation (votre épique), également appelé « S’inscrire à un cours », qui sert de placeholder pour accueillir toutes les histoires d’utilisateurs principales ainsi que celles découpées à partir de celle-ci.