Choisir sa méthode

Une méthode se choisit, elle ne se décrète pas

Beaucoup d’organisations adoptent une méthode de gestion de projet parce qu’elle est en vogue, sans se demander si elle correspond à leur contexte. Résultat prévisible : une méthode agile plaquée sur un projet aux exigences figées par un cahier des charges contractuel, ou un cycle en V imposé à une équipe qui doit livrer vite et apprendre en marchant. Ce chapitre présente les grandes familles de méthodes, les critères de choix, puis s’attarde sur Scrum, la plus documentée, et sur ses dérives les plus fréquentes.

Le cycle en V

Le cycle en V organise le projet en phases séquentielles : expression du besoin, spécifications, conception, réalisation, puis tests et validation qui remontent symétriquement vers les phases de conception. Chaque étape se termine avant que la suivante ne commence, et chaque phase de vérification correspond à une phase de conception précise.

Cette approche convient quand les exigences sont stables et connues à l’avance, quand une contrainte réglementaire impose une validation formelle à chaque étape, ou quand un retour en arrière coûte très cher une fois la réalisation engagée. Elle devient un handicap dès que le besoin évolue en cours de route, car elle absorbe mal le changement une fois une phase validée.

Les approches agiles : Scrum et Kanban

Les méthodes agiles partent du postulat inverse : le besoin n’est jamais totalement connu à l’avance, mieux vaut livrer vite, observer l’usage réel et ajuster. Deux cadres dominent largement le paysage du digital.

Scrum structure le travail en itérations courtes et fixes, les sprints, à l’issue desquelles une version utilisable du produit est présentée. Il convient à un travail qui peut se découper en incréments livrables régulièrement, avec une équipe stable sur la durée.

Le Kanban visualise le flux de travail sur un tableau à colonnes et limite le nombre de tâches en cours à chaque étape, plutôt que de découper le temps en itérations fixes. Il convient particulièrement à une activité de flux continu, comme le support ou la maintenance, où les demandes arrivent en permanence et à un rythme irrégulier.

Choisir selon le contexte, pas selon la mode

Le choix se joue sur quelques critères concrets. La stabilité des exigences d’abord : plus elles sont susceptibles de changer, plus une approche itérative s’impose. Le cadre réglementaire ensuite : un projet soumis à des validations formelles obligatoires se prête mieux à un déroulement séquentiel documenté. La stabilité de l’équipe compte aussi : Scrum suppose une équipe qui reste ensemble sprint après sprint, plus difficile à garantir avec des ressources partagées entre plusieurs projets.

Une approche hybride, cadrage amont plus formel et exécution itérative, répond souvent mieux à la réalité des organisations que l’application stricte d’un seul modèle. Le bon signal n’est pas « sommes-nous agiles » mais « cette façon de travailler aide-t-elle à livrer ce qui compte, au bon rythme ».

Scrum en pratique

Le Guide Scrum, rédigé par Ken Schwaber et Jeff Sutherland, définit Scrum par trois rôles, cinq événements et trois artefacts, dans son édition de référence de 2020.

Les trois rôles forment la Scrum Team : le Product Owner, qui maximise la valeur du produit et priorise le travail, le Scrum Master, qui fait respecter le cadre et retire les obstacles, et les Developers, qui réalisent le travail. L’édition 2020 a fusionné l’ancienne « équipe de développement » dans un rôle unique de Developers, sans hiérarchie interne.

Les cinq événements rythment le sprint : le Sprint lui-même, période fixe de réalisation, la Sprint Planning qui l’ouvre en définissant ce qui sera fait, le Daily Scrum, court point quotidien de synchronisation, la Sprint Review qui présente l’incrément produit, et la Sprint Retrospective qui clôt le cycle en examinant comment l’équipe peut s’améliorer.

Les trois artefacts donnent la matière du travail : le Product Backlog, liste ordonnée de tout ce qui pourrait être fait, le Sprint Backlog, sous-ensemble retenu pour le sprint avec le plan pour le réaliser, et l’Increment, le résultat cumulé et utilisable à ce jour.

Les dérives à surveiller

Adopter le vocabulaire d’une méthode ne suffit pas à en tirer les bénéfices. L’agilité de façade consiste à organiser des daily meetings et des rétrospectives sans jamais changer la façon dont les décisions se prennent réellement : le comité de direction continue d’arbitrer en dehors du cadre, les priorités changent sans passer par le backlog, et les rituels deviennent des réunions vides de leur fonction d’origine.

Le culte de l’outil est la dérive symétrique : installer un logiciel de gestion agile et considérer que la méthode est appliquée, alors que l’outil n’est qu’un support. Un tableau Kanban numérique parfaitement configuré n’empêche pas une équipe de continuer à travailler comme avant si rien ne change réellement dans la façon de prioriser ou de discuter des blocages.

Ce qu’il faut retenir

Le cycle en V et les approches agiles répondent à des contextes différents : stabilité contre incertitude, validation formelle contre livraison itérative. Scrum structure le travail en sprints avec trois rôles, cinq événements et trois artefacts précisément définis. Aucune méthode ne produit ses effets par sa seule adoption formelle : sans changement réel des pratiques, elle reste un habillage. Le chapitre suivant montre comment, une fois la méthode choisie, mesurer si le projet avance réellement dans la bonne direction.