Le développement logiciel agile pour une plateforme en ligne réussie, partie 1

Le développement agile repose entièrement sur une condition : que toutes les personnes impliquées aient la même vision du produit. Chez nous, quatre outils maintiennent cette vision à jour : deux interviennent au début de chaque projet, deux accompagnent la réalisation et l’exploitation. Cet article porte sur les deux premiers.

Étape 1 : structurer les exigences avec la story map

La user story map est une méthode issue du design de produit agile. Elle rend les exigences visibles et les organise de manière à créer une compréhension commune du produit. Nous la tenons dans StoriesOnBoard. Vous y avez accès pendant toute la durée du projet et voyez à tout moment où en sont les choses.

Niveau 1 : par quelles grandes étapes de processus passent les personnes utilisatrices ?

Nous décomposons d’abord le système en grandes étapes de processus, les activities. Dans le logiciel final, elles correspondent généralement à des modules entiers.

Niveau 2 : quelles étapes font partie de chaque étape de processus ?

Chaque étape de processus est divisée en autant de sous-étapes que nécessaire, les tasks. Dans la solution, elles correspondent généralement à des fonctions individuelles.

Niveau 3 : de quoi une étape a-t-elle besoin pour fonctionner ?

Sous chaque étape se trouvent les user stories. Elles décrivent les niveaux d’extension d’une fonction et peuvent être priorisées entre elles : pour la fonction « Login », la connexion par nom d’utilisateur et mot de passe est une story, la connexion via un compte Google une deuxième. Les cartes les plus importantes figurent en haut de la colonne, les moins importantes en dessous.

Niveau 4 : dans quel ordre la réalisation se fait-elle ?

Nous regroupons les stories de même priorité en étapes de réalisation, les epics. Comme un epic ne contient que des stories de même priorité, les epics peuvent eux aussi être priorisés entre eux et d’un projet à l’autre.

Nous développons ainsi par niveaux d’extension plutôt que fonction par fonction. La différence se voit tôt : au lieu d’une fonction parfaitement aboutie entourée de lacunes, vous disposez après quelques semaines d’un processus complet que vous pouvez tester. Sur ce premier niveau, nous ajoutons peu à peu les cas particuliers, jusqu’à ce que l’effort d’une optimisation supplémentaire dépasse son utilité.

Les post-it numériques restent mobiles : étapes et stories peuvent être ajoutées, déplacées ou supprimées à tout moment. La priorisation se fait par la position dans la map : de l’important au moins important, du simple au spécifique, sans perdre de vue l’ensemble.

Cette vue d’ensemble est la condition d’une architecture capable de porter aussi des exigences ultérieures. Et comme vous avez tôt sous les yeux un logiciel qui fonctionne, les exigences manquantes ou mal comprises apparaissent tant qu’elles sont encore peu coûteuses à modifier.

Étape 2 : visualiser les idées avec des mockups

Un mockup montre comment le produit va se comporter : une esquisse sommaire des éléments de commande, pas un design abouti. Nous élaborons avec vous les fonctions identifiées dans la story map, et vous voyez en peu de temps un premier concept.

Nous utilisons pour cela Moqups. L’outil relie les écrans entre eux, ce qui permet de parcourir le fonctionnement en cliquant, et les commentaires sont placés directement sur l’élément concerné plutôt que dans un échange d’e-mails séparé.

Les mockups ont donc deux fonctions : ils valident les exigences avec vous et servent à l’équipe de développement d’ébauche pour l’interface utilisateur.

Story map et mockup couvrent la phase de conception et de démarrage. La partie 2 présente les deux outils de planification, de réalisation et de documentation.