C’est en 2001 qu’a été élaboré aux États-Unis le manifeste du développement agile par un groupe de dix-sept spécialistes du développement logiciel, parmi lesquels figuraient notamment Kent Beck, Ward Cunningham, Martin Fowler ou encore Robert C. Martin. Ils ont posé les fondations de nouvelles approches de gestion de projet, particulièrement adaptées aux projets informatiques. La méthodologie Scrum fait partie de ces approches de gestion de projet. Toutefois, plus qu’une simple « méthode », il est plus juste de parler de philosophie, d’approche ou encore d’état d’esprit agile, tant elle se distingue des méthodes classiques. Scrum propose également un cadre structuré facilitant la gestion de projet agile. Nous allons vous présenter les éléments essentiels pour comprendre la méthode agile Scrum.
Qu’est-ce qu’une méthode agile ?
Comment définir une méthode agile ? Pour répondre à cette question, examinons d’abord le fonctionnement de la gestion classique de type « Waterfall », puis voyons en quoi l’approche agile s’en différencie.
La gestion Waterfall ou cycle en V
Dans une gestion de projet traditionnelle basée sur un cycle en V, on débute systématiquement par l’analyse des besoins du client et la rédaction d’un cahier des charges. Une fois les différentes parties alignées, les spécifications fonctionnelles puis techniques sont définies et validées. L’ensemble des fonctionnalités de l’application ainsi que les modalités de réalisation (notamment les choix techniques) sont décrits avant même le début du développement.
Le projet est ensuite segmenté en tâches, qui sont estimées, hiérarchisées et planifiées. Cette organisation permet d’établir un calendrier indiquant les dates de début et de fin de chaque tâche, ainsi que la date de livraison prévue du projet. Il ne reste plus qu’à assigner ces tâches aux membres de l’équipe. Un tableau de suivi, mis à jour régulièrement, permet de contrôler l’avancement.
Tout retard dans l’exécution d’une tâche impacte directement la date finale du projet. Ce n’est qu’une fois les développements terminés que le produit est présenté au client pour validation. Le client n’a donc une vision concrète du produit qu’à la fin. Si des ajustements sont nécessaires, cela engendre des pertes de temps. Même si le client peut parfois voir des éléments en cours de développement, la méthode reste rigide car elle suit un plan prédéfini, et toute modification en cours de projet devient complexe à gérer. Il est très difficile d’anticiper tous les besoins dès le départ. Il arrive fréquemment que certaines fonctionnalités jugées essentielles au départ ne le soient plus, tandis que de nouveaux besoins apparaissent trop tard pour être intégrés.
L’effet tunnel généré peut nuire fortement au projet. Si, lors de la phase de validation, un écart important apparaît entre les attentes du client et le produit livré, ce sont les spécifications et le contrat qui font foi. Dans la plupart des cas, aucune des parties n’en sort gagnante, et la relation peut être durablement dégradée.
La gestion agile
L’approche agile adopte une logique totalement différente. Plutôt que de tout définir dès le départ et de suivre un cadre rigide, le projet est structuré en cycles de développement itératifs et incrémentaux, dans lesquels le client et l’utilisateur final sont pleinement impliqués. Le centre d’attention n’est plus le projet en lui-même, mais le produit. L’objectif n’est plus seulement de terminer le projet, mais de créer un produit qui répond parfaitement aux besoins.
Un principe fondamental de l’agilité est que le besoin évolue. Grâce à des règles simples, il devient possible de s’adapter à ces évolutions et de limiter, voire supprimer, l’effet tunnel responsable de nombreux échecs.
Dans un projet agile, il n’est pas nécessaire de tout planifier dès le départ. Un premier objectif à court terme est défini et immédiatement mis en œuvre. Une fois atteint, on fait un bilan, on identifie les améliorations possibles, on définit un nouvel objectif, puis on recommence. Ce processus se répète jusqu’à l’obtention du produit final. Concrètement, le client exprime sa vision et les fonctionnalités souhaitées. L’équipe de développement estime ensuite le coût de réalisation de chaque fonctionnalité. Dès cette étape, les échanges entre le client et l’équipe permettent de clarifier les besoins. À partir de ces estimations, un budget global peut être établi.
L’équipe sélectionne ensuite, en accord avec le client, certaines fonctionnalités à développer durant une itération, généralement courte (quelques semaines). Pendant cette période, les activités couvrent les spécifications, le développement et les tests. À la fin, une démonstration du produit partiel mais fonctionnel est présentée. Le client peut alors valider la conformité avec ses attentes, tandis que l’utilisateur vérifie l’utilisabilité. Ces retours permettent d’ajuster rapidement le produit.
Le client définit les priorités des fonctionnalités. Il peut ainsi disposer d’un produit incomplet mais utilisable, sans attendre la fin du projet. Il peut également modifier les priorités en cours de route. Une fonctionnalité peut être reportée ou remplacée selon son importance. Les méthodes agiles offrent donc une grande flexibilité, tout en permettant de maîtriser les délais et les coûts.
Lire aussi : Triangle d’or en gestion de projet
Le Manifeste Agile
Bien que l’agilité semble récente, ses origines remontent plus loin. Le développement itératif apparaît dès 1986, et Scrum est utilisé dès 1993.
Cependant, le véritable tournant a lieu en 2001 avec la création du Manifeste Agile par dix-sept experts. Ce document définit une nouvelle manière de concevoir les logiciels.
Le Manifeste Agile met en avant une philosophie centrée sur :
- L’humain, plutôt que sur les outils.
- Les individus et leurs interactions plutôt que les processus et les outils,
- Un logiciel fonctionnel plutôt qu’une documentation exhaustive,
- La collaboration avec le client plutôt que la négociation contractuelle,
- L’adaptation au changement plutôt que le respect strict d’un plan.
Cela ne signifie pas que les éléments secondaires sont supprimés, mais qu’ils sont moins prioritaires. L’objectif est de développer un produit fonctionnel, amélioré progressivement à chaque itération.
La priorité reste la satisfaction du client. Pour cela, les livraisons sont fréquentes afin de permettre un suivi régulier et des tests continus. Les changements sont acceptés, même tardivement. La collaboration est constante entre les parties prenantes. Un processus d’amélioration continue permet également d’optimiser l’efficacité de l’équipe.
L’agilité apporte donc une grande souplesse par rapport aux méthodes traditionnelles. Cela ne signifie pas que tout est permis. Un cadre reste nécessaire pour éviter les dérives. Les cycles courts et les validations régulières facilitent l’intégration des ajustements.
Lire aussi : Coaching gestion de projet, est-ce important ?
Les différentes méthodes agiles de développement informatique
Il existe plusieurs approches agiles de gestion de projet. Les trois plus répandues sont « RAD » (Rapid Application Development ou Développement Rapide d’Applications), « XP » (eXtreme Programming) et bien entendu « Scrum ». Toutes ont pour but de raccourcir le cycle de développement d’un logiciel ou d’une application, tout en intégrant les évolutions des besoins du client tout au long du projet.
La méthode RAD est l’une des plus anciennes et a été introduite en 1991 par James Martin. Elle repose sur une approche semi-itérative, un processus structuré d’organisation des développements ainsi qu’une technique de modélisation adaptée à l’application à concevoir (UML, Merise…). Un projet RAD se divise en cinq étapes : l’initialisation (mise en place des équipes, définition du périmètre…), le cadrage (objectifs, solutions, ressources), la conception (modélisation de la solution), la construction (prototypage avec validation continue) et enfin la finalisation (contrôle qualité final avec déploiement sur un site pilote).
eXtreme Programming est une méthode particulièrement adaptée aux projets informatiques. Son principe fondamental repose sur la participation active du client dans le processus de développement. Les développeurs doivent produire un code aussi simple que possible, clair et compréhensible. Pour améliorer la qualité du code, ils travaillent en binôme. Des cycles très courts permettent de livrer rapidement des versions fonctionnelles et de valider chaque étape du projet.
Enfin, Scrum est sans doute la méthodologie agile la plus utilisée. Employée depuis 1993, elle propose un cadre de gestion de projet structuré incluant des rôles, des réunions, des artefacts, des règles de fonctionnement et un cycle de développement itératif. Le cadre Scrum est à la fois simple, transparent et pragmatique. Concrètement, on définit le contenu d’une itération (appelée « sprint ») en termes de fonctionnalités, celles-ci sont développées puis validées à la fin du sprint. Une analyse du sprint écoulé est ensuite réalisée avant de démarrer le suivant.
Entrons maintenant plus en détail dans la méthodologie Scrum.
La méthodologie Scrum, un cadre de travail agile pour des projets complexes
Comme mentionné précédemment, Scrum se définit davantage comme un cadre de travail que comme une méthode complète de gestion de projet. Elle permet toutefois de piloter le développement d’applications complexes. Le projet est structuré autour de « sprints » (itérations) dont la durée varie généralement entre deux et quatre semaines. Un cas d’usage typique de Scrum est un projet informatique dans lequel le client n’a pas encore identifié l’ensemble des fonctionnalités attendues et où une certaine flexibilité organisationnelle est donc nécessaire.
Le projet commence par un « sprint 0 », consacré à l’ensemble des travaux préparatoires et de mise en place : conception et architecture, environnements de développement, outils de suivi et d’intégration…
Les fonctionnalités attendues sont listées et décrites sous forme de « user stories », puis intégrées dans le backlog produit. Au début de chaque sprint, l’équipe (développeurs et client) se réunit afin de déterminer quelles user stories seront développées. Elles sont estimées lors d’une réunion appelée « poker planning » puis priorisées. L’ensemble des user stories retenues constitue le « sprint backlog ». Le planning du sprint ainsi que les objectifs à atteindre sont alors définis. Par exemple, pour un logiciel de messagerie, un product backlog pourrait inclure les user stories « Se connecter au serveur de messagerie », « consulter la liste des messages », « rédiger un message », « envoyer un message »…
Pendant toute la durée du sprint, des réunions quotidiennes, appelées « daily meetings », sont organisées. Elles se tiennent généralement le matin et rassemblent toute l’équipe. Pour rester efficaces, elles durent environ 15 minutes et se déroulent debout afin d’éviter qu’elles ne s’éternisent. L’objectif est d’aligner l’équipe pour que chacun dispose du même niveau d’information. Chaque développeur prend la parole à tour de rôle pour expliquer ce qu’il a réalisé la veille, les objectifs atteints, ce qu’il prévoit de faire dans la journée ainsi que les éventuels obstacles rencontrés. Cela permet d’identifier rapidement qui peut intervenir pour aider à résoudre les blocages et permettre à chacun de progresser. À la fin de la réunion, l’équipe valide avec le Scrum Master sa capacité à respecter les délais et à réaliser l’ensemble du sprint backlog.
À la fin du sprint, une démonstration de l’application dans son état actuel est présentée au client. Le client ainsi que l’utilisateur final peuvent manipuler le produit et vérifier que les développements réalisés correspondent aux attentes. Des retours peuvent être formulés ainsi que des demandes d’ajustement. Elles pourront être prises en compte, ou non, lors du sprint suivant.
Le dernier jour de l’itération, une réunion appelée « revue de sprint » est également organisée. Elle permet à toute l’équipe de rappeler les objectifs fixés et les fonctionnalités effectivement développées et livrées.
Enfin, l’équipe projet se réunit une dernière fois pour la rétrospective. C’est l’occasion d’identifier les pratiques qui ont bien fonctionné durant le sprint ainsi que celles qui doivent être améliorées. Chaque membre peut s’exprimer librement. L’objectif est de mettre en évidence les points forts et les axes d’amélioration dans une logique d’amélioration continue, puis d’intégrer ces enseignements dans les prochains sprints. Un plan d’amélioration est alors défini, et le sprint suivant peut commencer immédiatement.