Vous avec un projet d’appli mobile et vous avez choisi un développement Agile. C’est bien !
Le souci c’est que le jargon du développement Agile regorge de termes anglais.
Si vous n’êtes pas trop anglophone, cela peut vous paraître contraignant mais ne vous inquiétez pas, nous allons tout vous expliquer dans la langue de Molière.
Comme on l’a vu précédemment [cf les premiers articles de cette série consacrée au développement agile d’applications mobiles], la méthode Agile Scrum est centrée sur la collaboration entre les parties prenantes d’un projet (équipes de développement internes ou externes, client à l’origine de la demande).
Alors commençons par parler des hommes.
Développement Agile : le jargon pour nommer les acteurs de votre projet d’appli mobile
La conception de votre appli mobile est réalisée par l’équipe de développement, aussi appelée la Dev Team dans la méthode Agile.
Cette équipe est menée par le scrum master.
Le scrum master
Il s’agit le plus souvent d’un Chef de projet, bien que la méthode Agile n’utilise pas ce terme (elle s’attache plus à la notion de produit qu’à celle de projet).
Son rôle est de faciliter et d’animer le travail de l’équipe de développement.
Concrètement, le scrum master fait en sorte quotidiennement que l’équipe puisse travailler au mieux sur les tâches qu’elle s’est engagée à réaliser, notamment en la protégeant des demandes extérieures inattendues et en assumant les problématiques administratives.
Le product Owner
Son interlocuteur chez le client (à l’origine de la demande) est le product owner (terme dont la traduction littérale pourrait être « Propriétaire du produit », ou « Chef de Produit »).
Son rôle est d’établir les spécifications fonctionnelles du produit qui répondront au mieux aux attentes des utilisateurs dans le cadre budgétaire et le temps imparti au projet. (La suite, c’est en dessous de l’infographie !)
Développement agile : les mots clés de la description des besoins
Le backlog
La responsabilité du product owner est notamment de :
- Préciser le product backlog ; on pourrait traduire cela comme « carnet de produit » en référence au « carnet de commandes » ; ou, si vous préférez une expression plus triviale « la liste de courses ». Dans un développement Agile, ce backlog liste donc l’ensemble des fonctionnalités attendues du produit (c’est-à-dire l’appli mobile !)
- Prioriser les items de cette liste les uns par rapport aux autres ; c’est-à-dire indiquer dans quel ordre les fonctionnalités du produit devront être livrées, ce qui peut permettre de prévoir plusieurs versions du produit pour tenir compte des contraintes budgétaires et de planning). Le backlog est donc une liste ordonnancée des besoins du projet.
- Mettre à jour cette liste, si nécessaire, en cours de développement (nous verrons dans quel cadre, par la suite).
Les User stories
Nous venons de voir que le backlog est constitué d’une liste de fonctionnalités, mais ce n’est pas tout à fait vrai.
Il est constitué en réalité de “user stories” (histoires utilisateurs).
La différence entre une fonctionnalité et une histoire utilisateur est assez simple.
Lorsqu’un futur utilisateur de la solution décrit son besoin, il le fait en termes d’usage et non en termes techniques, par exemple : « En tant qu’utilisateur de l’application, je souhaite créer mon compte personnel pour pouvoir accéder en tout lieu à mon espace privé de manière sécurisée ».
Derrière cette phrase qui paraît toute simple, un certain nombre de fonctionnalités peuvent se cacher, liées aux aspects techniques qui sont induits.
Le vocabulaire du développement agile proprement dit
Les sprints
Pour mettre en œuvre l’appli mobile, la méthode de développement Agile Scrum s’appuie sur des sprints : il s’agit de périodes de développement de courte durée (2 à 3 semaines) s’apparentant à une course de vitesse, pendant lesquelles l’équipe va concevoir, réaliser et tester une portion des exigences initiales exprimées dans le backlog.
Les scrums
Des scrums quotidiens (réunions de courte durée qui tiennent leur nom des mêlées au rugby) permettent de mesurer l’avancement du sprint.
La recette
À la fin de chaque sprint, une version de ce qui a été développé est fournie au donneur d’ordre à des fins de test et de validation, et une recette est réalisée.
À ce stade, le product owner peut demander à compléter ou modifier le backlog, ce qui donne lieu à une négociation avec le scrum master (et ne modifie en aucun cas le sprint en cours).
La rétrospective
Entre chaque sprint, a lieu également une rétrospective, réunissant les développeurs, le product owner et le scrum master.
Cette réunion entre dans le cadre d’une approche d’amélioration continue et a pour objectif d’analyser le déroulement du sprint qui vient de se terminer en invitant les participants à répondre aux questions suivantes :
- si nous pouvions refaire le sprint qui vient de se terminer, que referions-nous à l’identique ?
- que ferions-nous différemment ?
Cette rétrospective donne aussi l’opportunité aux participants d’émettre des idées d’améliorations pour les futurs sprints.
Pour aller plus loin :
- [ Article ] Développement d’applications mobiles : l’indispensable collaboration !
- [ Article ] Projet d’appli mobile : l’expression de besoins, un casse-tête insoluble ?
Vous souhaitez réagir ou en savoir plus ?
On vous offre un café et, en bonus, notre glossaire mobile, pour vous aider à décrypter le jargon de la mobilité.
Vous êtes partant(e) ?