C’est en 2001 qu’a été créé aux Etats-Unis le manifeste du développement agile par un groupe de dix-sept passionnés du développement logiciel, dont faisaient notamment partie Kent Beck, Ward Cunningham, Martin Fowler ou encore Robert C. Martin. Ils ont jeté les bases de nouvelles méthodes de gestion de projet, particulièrement adaptées aux projets de développements informatiques. La méthodologie Scrum est l’une de ces méthodes de gestion de projet. Mais plus qu’une simple « méthode », il faut parler de philosophie, d’approche ou encore d’état d’esprit agile, tant la différence est grande avec les méthodes de gestion de projet classiques. Scrum apporte en plus un cadre de travail permettant une gestion de projet agile. Nous allons vous donner toutes les clés nécessaires à la compréhension de la méthode agile Scrum.
Qu’est-ce qu’une méthode agile ?
Quelle peut être la définition d’une méthode agile ? Pour répondre à cette question, voyons d’abord en quoi consiste la gestion classique de type « Waterfall », et nous verrons ensuite en quoi la gestion agile est différente.
La gestion Waterfall ou cycle en V
Avec une méthode de gestion de projet classique, utilisant un cycle en V, on commence toujours par l’analyse des besoins du client et la rédaction du cahier des charges. Une fois les différents partis d’accords, les spécifications fonctionnelles, puis techniques de l’application sont rédigées et validées. L’ensemble des fonctionnalités du logiciel ou de l’application et les modalités de leur réalisation (choix techniques notamment) est décrit avant que la moindre ligne de code ne soit écrite.
Le projet est ensuite découpé en tâches qui sont chiffrées, priorisées et ordonnancées. De cette organisation résulte un planning permettant de connaître les dates de début et de fin de chaque tâche, ainsi naturellement que la date de fin prévisionnelle du projet. Il ne reste plus qu’à attribuer la réalisation des différentes tâches aux membres de l’équipe. Le tableau de bord du projet, mis à jour très régulièrement, permet de suivre l’avancement.
Tout retard pris lors de la réalisation d’une tâche aura des répercussions immédiates sur la date de fin du projet. Enfin, lorsque les développements sont terminés, le produit peut enfin être livré au client pour validation. Ce n’est donc qu’à la fin des développements que le client aura une vision du produit final. Si quelque-chose ne lui convient pas, s’il faut reprendre une partie des développements, c’est autant de temps perdu. Même si dans les faits, le client peut avoir une vue partielle du produit durant les développements, il n’en reste pas moins que la méthode est relativement rigide parce que le projet doit suivre une trajectoire bien définie (tout est spécifié à l’avance) et que la prise en compte d’une modification en cours de projet peut rapidement devenir un vrai casse-tête. Il est très difficile, voire impossible, de prévoir tout ce dont on aura besoin. Au final, il n’est pas rare de se rendre compte qu’une fonctionnalité qui paraissait vitale au début du projet ne le soit pas tant que ça, et que d’autres besoins finalement identifiés comme importants en cours de route ne puissent pas être pris en compte.
L’effet tunnel induit peut être dévastateur pour le projet. Si l’on constate au moment de la recette une trop grande différence entre ce qui est attendu par le client et ce qui a été produit, ce sont les spécifications et le contrat signé qui trancheront. Généralement, ni le prestataire ni le client n’en ressortent gagnants, et la relation entre les deux peut être altérée à jamais.
La gestion agile
L’approche agile est radicalement différente. Plutôt que de tout spécifier dès le début du projet et de s’en tenir à un cadre très rigide, un projet agile sera organisé en cycles de développements itératifs et incrémentaux, auxquels le client final et l’utilisateur seront intégrés et participeront de façon active. Le centre de gravité n’est donc plus le projet en lui-même, mais bel et bien le produit. L’objectif n’est plus de mener le projet à bien, mais de donner naissance à un produit fini, correspondant parfaitement au besoin du client.
La principale considération de la philosophie agile est que le besoin ne peut pas être figé et qu’il va sans doute évoluer au fil du projet. Grâce à des règles simples et claires, il est possible de s’adapter à ces changements et de réduire au minimum, voire de faire disparaître l’effet tunnel à l’origine de l’échec de bon nombre de projets informatiques.
Dans un projet agile, inutile donc de spécifier et planifier l’intégralité du produit cible. Un premier objectif est fixé à court terme, et sa réalisation débute immédiatement. Lorsque ce premier objectif est atteint, on s’arrête, on fait le point, on note les améliorations possibles, on fixe l’objectif suivant et on repart dans une phase de réalisation… et ainsi de suite jusqu’à l’obtention du produit final. Concrètement, avec une méthode agile de gestion de projet, le client décrit sa vision du produit et les fonctionnalités qu’il souhaite y voir figurer. Cette liste de fonctionnalités est soumise à l’équipe de développement qui fournit une estimation du coût de réalisation de chacune d’elles. A ce stade, l’équipe de développement et le client communiquent déjà directement afin que la compréhension des demandes soit juste. A partir de l’ensemble de ces estimations, il est possible de déduire un budget global pour le projet.
L’équipe de développement sélectionne ensuite en accord avec le client une partie des exigences exprimées et chiffrées. Ces fonctionnalités devront être réalisées durant une itération, qui correspond à une période de temps relativement courte, quelques semaines tout au plus. Durant cette itération, les travaux effectués iront des spécifications fonctionnelles et techniques jusqu’aux développements et aux tests. A l’issue de cette itération, une démonstration du produit partiel mais opérationnel est faite au client et à l’utilisateur final. Le client peut alors se rendre compte du travail effectué et vérifier qu’il correspond bien à son besoin. L’utilisateur final peut vérifier que le produit est utilisable et correspond à son métier. Grâce à cette visibilité, l’équipe de développement peut avoir des retours directs, et modifier rapidement le code déjà produit, afin que les fonctionnalités réalisées correspondent bien aux besoins décrits.
C’est le client qui définit la priorité des fonctionnalités qu’il souhaite voir réalisées. Il a ainsi la possibilité d’obtenir un produit incomplet, mais opérationnel, qu’il peut mettre en production s’il le souhaite. Plutôt que de devoir attendre la fin du projet, il peut donc déjà utiliser le produit existant en l’état, en attendant que d’autres fonctionnalités soient intégrées. Il a également la possibilité de modifier les priorités de fonctionnalités non encore développées qu’il avait auparavant définies. Une fonctionnalité nécessitant une réflexion plus approfondie peut être reportée à une itération ultérieure, une fonctionnalité vitale, mais identifiée trop tard, peut venir en remplacer une autre jugée moins importante… Les méthodes agiles apportent une souplesse incomparable tant pour le client que pour le prestataire, tout en permettant de contrôler et respecter les délais et le budget du projet.
Le Manifeste Agile
Même si l’approche agile semble être « à la mode » depuis quelques années seulement, il faut remonter bien plus loin pour en retrouver les fondements. La gestion de projet de développement itératif fait son apparition en 1986, tandis que la première utilisation de Scrum date de 1993.
Mais l’événement déclencheur qui a permis à la philosophie agile de faire son chemin au sein des entreprises a été la création du Manifeste Agile en 2001 par dix-sept experts du développement logiciel. Il s’agissait alors de définir une nouvelle façon de développer des applications.
Le Manifeste Agile décrit la philosophie de cette nouvelle approche, et amorce un véritable changement culturel. L’humain est remis au centre des préoccupations en lieu et place des outils.
L’agilité amène donc à privilégier :
- Les individus et leurs interactions plutôt que les processus et les outils,
- Des logiciels opérationnels plutôt qu’une documentation exhaustive,
- La collaboration avec les clients plutôt que la négociation contractuelle,
- L’adaptation au changement plutôt que le suivi d’un plan.
Attention cependant, si les premiers éléments des phrases ci-dessus sont privilégiés, les seconds ne sont pas pour autant abandonnés. Ce n’est pas parce qu’il est indiqué dans le Manifeste Agile que l’on préfèrera un logiciel scrum opérationnel à une documentation exhaustive qu’il n’y a pas de spécifications par exemple. Privilégier un élément ne signifie pas faire disparaître totalement un autre. Mais plutôt que de décrire le produit fini de façon très précise dès le début, on préfèrera développer une application qui fonctionne et qui va être perfectionnée au fur et à mesure des itérations.
La priorité va donc être la satisfaction du client. Pour cela, les livraisons seront rapides et régulières de façon à ce qu’il puisse d’une part vérifier l’avancement du projet, et d’autre part contrôler et tester qualitativement le produit au fur et à mesure du processus de création. Les demandes de changements seront accueillies positivement, même tard dans le projet. Clients, utilisateurs finaux et développeurs travaillent ensembles tout au long du projet, avec une communication transparente. Un processus d’amélioration continue est également mis en place afin que l’équipe devienne de plus en plus efficace au fil du temps.
L’agilité apporte donc beaucoup de souplesse par rapport à une gestion de projet classique. Cela ne signifie pas que le client va piloter le projet et qu’il faut intégrer tout ce qu’il demande. Cela représenterait naturellement un risque non négligeable de dérapage pour le projet. La mise en place de cycles de développement courts ponctués de phases de validation du travail par le client facilite la gestion du changement et la prise en compte des corrections et ajustements demandés.
Les différentes méthodes agiles de développement informatique
Il existe plusieurs méthodes de gestion de projet agiles. Les trois méthodes les plus connues sont « RAD » (pour Rapid Application Development ou Développement d’Application Rapide), « XP » (pour eXtreme Programming) et bien sûr « Scrum ». Toutes ont pour objectif de réduire le cycle de développement d’un logiciel ou d’une application, tout en tenant compte des évolutions des besoins du client tout au long du projet.
La méthode RAD est l’une des plus anciennes et a été créée en 1991 par James Martin. Elle s’appuie sur une méthode semi-itérative, un processus d’ordonnancement des développements et une technique de modélisation adaptée au l’application à développer (UML, Merise…). Un projet RAD se découpe en cinq phases : initialisation (organisation des équipes, périmètre…), cadrage (objectifs, solutions, moyens), design (modélisation de la solution), construction (prototypage et validation permanente) et enfin finalisation (contrôle final de qualité avec la mise en place d’un site pilote).
eXtreme Programming est une méthode particulièrement adaptée aux projets informatiques. La règle fondamentale de la méthode est que le client participe au développement. Ensuite, les développeurs doivent produire un code le plus simple possible et facilement lisible. Pour les aider, ils travaillent en binôme afin d’améliorer la qualité du code produit. Des itérations très courtes permettent de livrer rapidement des prototypes opérationnels et de faire valider chaque étape du projet.
Enfin, Scrum est certainement la plus connue des méthodologies agiles. Utilisée depuis 1993, elle fournit un cadre de gestion de projet avec des rôles, des réunions, des artefacts, des règles de gestion et un cycle itératif de développement. Le cadre de travail Scrum est simple, transparent et pragmatique. Pour résumer simplement, on définit le contenu d’une itération (ou « sprint scrum ») en termes de fonctionnalités, elles sont développées, puis validées à l’issue du sprint. Un bilan du sprint écoulé est réalisé avant de continuer sur le sprint suivant.
Entrons maintenant en détails dans la méthodologie Scrum.
La méthodologie Scrum, un cadre de travail agile pour des projets complexes
Comme nous l’avons vu, la définition de Scrum tient plus d’un cadre de travail que d’une méthode de gestion de projet complète. Elle permet néanmoins la gestion du développement d’applications complexes. Le projet est organisé autour de « sprints » de développement (les itérations) d’une durée allant généralement de deux à quatre semaines. Un exemple typique d’utilisation de Scrum est un projet de développement informatique où le client n’a pas encore défini toutes les fonctionnalités dont il a besoin et où une certaine souplesse d’organisation est donc nécessaire.
Le projet débute par le « sprint 0 », dédié à la réalisation de tous les travaux de préparation et de mise en place : conception et architecture, environnements de développement, outils de suivi et d’intégration…
Les fonctionnalités demandées sont listées et décrites sous la forme de « user stories » et placées dans le backlog produit. Au début d’un sprint l’équipe est réunie (développeurs et client) afin de déterminer quelles user stories vont être développées. Elles sont chiffrées lors d’une réunion intitulée « poker planning » et priorisées. L’ensemble des user stories sélectionnées constitue le « sprint backlog ». Le planning sprint et les objectifs à atteindre sont alors fixés. Pour un logiciel de messagerie, un exemple de product backlog pourrait contenir les user stories « Se connecter au serveur de messagerie », « consulter la liste des messages », « créer un message », « envoyer un message »…
Durant toute la durée du sprint, des réunions quotidiennes ou « daily meetings » sont organisées. Elles ont généralement lieu le matin et réunissent l’ensemble de l’équipe. Pour être efficace, une réunion quotidienne ne dure que 15 minutes et tous les participants restent debouts. C’est un moyen particulièrement efficace pour s’assurer qu’elle ne s’éternise pas. L’objectif de cette réunion est de synchroniser l’équipe de façon à ce que chacun ait le même niveau d’information. Chaque développeur prend la parole à tour de rôle et décrit au reste de l’équipe ce qu’il a fait la veille, les objectifs qui ont été atteints, ce qu’il prévoit de faire aujourd’hui avec les nouveaux objectifs à atteindre, et les éventuels problèmes ou blocages qu’il rencontre. De cette façon, il est facile de savoir qui peut lui venir en aide et comment, afin de résoudre ses problèmes et de lui permettre d’avancer de nouveau. A la fin de la réunion, l’équipe valide avec le Scrum Master la possibilité de tenir les délais et de réaliser l’intégralité du sprint backlog.
A la fin du sprint, une démonstration de l’application dans son état actuel est faite au client. Le client comme l’utilisateur final peuvent manipuler l’application et vérifier que les développements effectués lors du sprint sont bien conformes à ce qui était attendu. Des remarques peuvent être émises et des demandes de modifications formulées. Elles pourront être ou non prises en compte dans le prochain sprint.
Lors du dernier jour de l’itération, une réunion appelée « revue de sprint » est également organisée. C’est le moment pour toute l’équipe de rappeler les objectifs qui avaient été fixés et les fonctionnalités qui ont été réalisées et livrées.
Enfin, l’équipe projet se réunit une dernière fois durant le sprint pour la rétrospective. C’est l’occasion de faire la liste des processus qui ont bien fonctionné durant le sprint et de ceux qui nécessitent d’être améliorés. Tout le monde a la possibilité de s’exprimer librement. L’objectif est d’identifier les points forts et les points faibles du sprint dans un souci d’amélioration continue et de prendre en compte les différentes remarques lors des prochains sprints. Un plan d’amélioration est alors mis en place et le sprint suivant peut démarrer dans la foulée.
Les différents rôles de la méthodologie Scrum
Scrum définit trois rôles Scrum dans l’organisation d’un projet agile :
- Le « Product Owner » ou « PO » : il porte la vision du produit à réaliser et il s’agit donc généralement d’un expert métier. Il travaille en collaboration directe avec l’équipe de développement et a notamment la charge de remplir le backlog produit et de déterminer la priorité des user stories à réaliser. Il peut être interne ou externe, même s’il s’agit généralement du client.
- Le « Scrum Master » ou « SM » : Il s’agit d’un membre à part entière de l’équipe projet, et il doit maîtriser Scrum car il est chargé de s’assurer que la méthodologie est correctement appliquée. Il ne faut surtout pas le confondre avec un chef de projet. Son rôle n’est pas de diriger, mais de faciliter le dialogue et le travail entre les différents intervenants, de façon à ce que l’équipe soit pleinement productive. Il agit donc plutôt comme un coach, aussi bien auprès du product owner que de l’équipe de développement. Il doit être un bon communiquant et faire preuve de pédagogie, afin de pouvoir résoudre les éventuels conflits qui pourraient apparaître durant le projet. Il anime généralement les différentes réunions, qu’il s’agisse du scrum daily meeting, de la revue de sprint ou encore de la rétrospective. Généralement, le rôle de Scrum Master change régulièrement au sein de l’équipe projet, chacun pouvant le devenir à tour de rôle.
- L’équipe de développement : généralement composée de 4 à 6 personnes, elle est chargée de transformer les besoins exprimés par le product owner sous la forme de user stories en fonctionnalités réelles, opérationnelles et utilisables. L’équipe est généralement composée de plusieurs profils, ne se limitant pas à des développeurs, et peut intégrer des architectes, un DBA, un graphiste, un ergonome ou encore un ingénieur système ou réseau, en fonction des besoins.
Les outils Scrum
Différents outils de suivi et de calcul d’indicateurs peuvent être utilisés avec la méthode Scrum pour contrôler le déroulement du projet. Nous vous présentons ici les principaux.
- Le Burndown Chart : il s’agit d’un graphique simple permettant de visualiser le degré d’avancement de chacune des tâches. Il permet de fournir à l’ensemble de l’équipe une vision claire et actualisée de l’état d’avancement des travaux et de la quantité de travail restante. Il est généralement mis à jour lors de la réunion quotidienne.
- Le task board : outil central du sprint scrum, ce tableau de bord projet permet de suivre en temps réel la progression de la réalisation des différentes tâches. Il est composé de trois colonnes comportant les tâches à faire, les tâches en cours et les tâches terminées. Il est généralement situé dans un endroit visible de l’ensemble de l’équipe (un tableau accroché au mur ou affiché sur un grand écran) et est actualisé directement par les développeurs dès que l’activité sur laquelle ils travaillent évolue.
- La learning matrix : cette « matrice d’apprentissage » a pour objectif d’aider les membres de l’équipe projet à identifier les points positifs du projet et ceux qui nécessitent une amélioration. Utilisée notamment lors de la rétrospective scrum agile, elle fait partie du processus d’amélioration continue du projet. La matrice est divisée en quatre quadrants : ce qui ne va pas et doit être changé, ce qui va bien et qui doit être répété, les nouvelles idées à essayer et les personnes appréciées. Chaque participant peut coller un post-it avec leurs idées dans les différents quadrants, puis chacun peut ensuite voter pour les suggestions proposées. Cela permet au final de dégager des priorités en termes d’organisation notamment pour le sprint suivant et d’améliorer les conditions de travail et la productivité de l’équipe.
- Le storyboard : il s’agit d’un outil graphique permettant d’illustrer les différentes étapes permettant d’atteindre un objectif. Le storyboard ressemble à une bande dessinée, chaque case représentant une étape, et donne un exemple de ce qui est attendu. Cet outil est destiné à la description de l’aspect fonctionnel et non à la conception ou à la démonstration de l’interface graphique.
- Le graphique Sunset : ce graphique permet de suivre la progression de l’équipe ainsi que l’avancement du projet plus généralement. Il fournit une vue globale du contenu du backlog produit avec un classement par importance des fonctionnalités attendues. Ainsi, la vélocité de l’équipe apparaît clairement et il est possible d’anticiper d’éventuelles modifications des dates de livraison. Il est également possible de suivre la consommation du budget et de prévenir les risques de dérapage. Le graphique Sunset est mis à jour à la fin de chaque scrum sprint.
Les différents types de rétrospectives agiles
La rétrospective scrum permet à la fin de chaque sprint d’identifier les points forts et les points à améliorer sur le projet. Il existe plusieurs types de rétrospectives en fonction des objectifs à atteindre et de l’équipe projet en place. Les sujets abordés diffèrent en fonction des besoins. En voici quelques exemples :
- Reconnaissance : l’objectif est ici de mettre l’accent sur ce qui a été bien fait plutôt que sur les aspects négatifs.
- Points forts : permet d’identifier les principaux points forts de l’équipe et de définir des actions permettant de les utiliser au mieux.
- Top 5 : les cinq plus gros problèmes rencontrés durant le projet sont listés afin que les participants puissent en discuter et proposer des actions pour y remédier.
- Plan d’action : permet de décider d’actions à réaliser à court terme qui auront une action à long terme sur le projet.
- Complexité : permet de déterminer la meilleure façon de gérer la complexité au sein de l’équipe projet.
- Valeurs Scrum : l’objectif est de mieux comprendre les valeurs portées par Scrum et d’évaluer le taux d’adhésion de l’équipe à ces valeurs en toute transparence.
Pour conclure sur la méthodologie Scrum
Scrum est sans aucun doute la méthodologie de gestion de projet agile la plus en vogue actuellement pour les projets de développements informatiques. N’hésitez pas à télécharger le scrum guide pdf depuis le site officiel, facile et rapide à lire, qui pourra vous aider à mettre en place Scrum. Si vous souhaitez aller plus loin, sachez qu’il est possible de passer une certification agile scrum attestant de vos compétences dans ce domaine. Actuellement, trois certifications existent : PSM (Professional Scrum Master), PSPO (Professional Scrum Product Owner) et PSD (Professional Scrum Developer).
Avant de vous lancer, vous pouvez également vous inspirer d’un exemple de projet avec Scrum ayant déjà eu lieu au sein de l’entreprise.
Enfin, Nutcache met à votre disposition l’intégralité des outils nécessaires à la gestion de projet scrum agile. Profitez d’une version gratuite durant 14 jours pour essayer la solution complète.
