Quelle méthode de gestion de projet choisir ?

La situation

La méthode classique de gestion de projet utilisée en informatique est issue du bâtiment. Elle suit le cycle en V dans lequel on définit un cahier des charges, on rédige des spécifications, puis on définit l'architecture, on fait le développement, les tests, la validation, on fait la recette et le client dit ainsi  si cela lui convient ou pas. Il existe une variante, le cycle en Y qui dissocie le fonctionnel du technique, mais fondamentalement on reste sur un fonctionnement où une fois que le client et son fournisseur se sont mis d'accord sur le cahier des charges avec le coût et les délais correspondants, le projet est lancé et ces bases ne sont plus censées varier.

Le Standish group publie depuis plus de 20 ans une étude appelée « Chaos computer » qui indique le pourcentage de projets réussis, en échec ou en dérive. Un projet réussi est un projet où les fonctions et caractéristiques attendues, ainsi que les délais et le coût répondent aux attentes initiales du client et du fournisseur. On constate que la proportion de projets réussis oscille entre 25 et 33 % et que les projets stratégiques ont encore moins de chance d'être réussis car beaucoup sont interrompus avant la fin (http://rapportsalzman.blogspot.fr/2012/05/la-gestion-de-projet-peut-mieux-faire.html).

Les raisons de ces échecs sont multiples : incompréhensions, retards, besoin du client qui évolue, changements de spécifications diverses, risques techniques et humains, manque d'outils de suivi adaptés, études amont insuffisantes... Certains projets connaissent le redouté effet tunnel:  des quantités importantes de développements restent à réaliser, et les échéances ne cessent d'être repoussées, jusque parfois à ne plus donner de date de sortie du tout.

Si l'on décide longtemps à l'avance les services, les fonctions que l'on veut offrir, il se peut bien qu'à la mise sur le marché, cela ne corresponde pas ou plus aux attentes des consommateurs / utilisateurs. Il se peut aussi que l'on n'ait pas une vision totalement claire de ce qui doit être fait dès le début. Souvent certains points ne seront affinés que durant le projet. Hors avec l'accélération de l'évolution des marchés, particulièrement depuis l'arrivée d'Internet, une grande réactivité et une bonne vitesse d'exécution des projets sont encore plus nécessaires.

Lorsqu'un changement, une décision qui en remet en cause d'autres, intervient tard dans le processus de développement d'un logiciel, son coût s'accroît de façon exponentielle. En effet, non seulement une partie du cycle devra être re-parcourue (architecture, développement, tests, validation,...), mais en plus le nombre de personnes impliquées sera d'autant plus grand que ce chemin sera long. Il en va de même pour tout bug trouvé.

Hors les méthodes de gestion de projet classiques sont peu ouvertes au changement et elles n'empêchent pas l'effet tunnel. Le Processus Unifié tente de résoudre le problème avec les itérations et les incréments. L'itération est la possibilité de reparcourir une partie du processus: par exemple en mettant à jour l'architecture alors que l'on était dans le développement proprement dit. De même, le projet peut être découpé en sous-projets qui conduisent à autant d'itérations exécutées les unes après les autres, et qui cette fois-ci parcourent chacune tout le cycle. On fait donc des livraisons successives incrémentales qui correspondent à l'ajout d'un sous-projet à chaque fois. Enfin le Processus Unifié, en se centrant sur l'architecture et la réutilisabilité, entend réduire les coûts.

Ces méthodes restent toutefois assez rigides et ne permettent pas de réduire les coûts de façon significative en particulier lors d'un changement de spécification qui intervient tard, ou de bug rencontré.

Quelques méthodes agiles

Face à ce constat, Kent Beck a créé une méthode appelée eXtreme Programming (XP) qu'il a appliquée dès 1996. L'idée est d'accueillir le changement, de permettre des prises de décision tardives, mais aussi, de reprendre toutes les bonnes pratiques du métier qui ont pu être expérimentées, et de les appliquer dans un développement informatique. Cela a donné en particulier:

• le jeu du planning pour évaluer et planifier les tâches à réaliser pour une itération.
• la recherche constante de la simplicité (analyse de la valeur).
• la programmation en binômes.
• le refactoring: afin de favoriser la simplicité, la maintenabilité et la fiabilité, on n'hésite pas à refaire une partie du logiciel, à revoir l'architecture, à supprimer le code mort ou redondant.
• l'automatisation des tests pour contrôler la qualité et maîtriser toute dérive.
• l'intégration continue pour éviter les intégrations qui n'en finissent plus mais aussi pour permettre le test régulier de la livraison complète, et ainsi contrôler toute régression.
• la mise en production le plus tôt possible pour valider le logiciel et avoir des retours.
• le stand-up meeting, qui est la réunion quotidienne d'avancement de l'équipe. Celle-ci se fait le matin et dure 15' maximum!

Une des grandes forces d'XP est que l'ensemble de ces pratiques se renforcent. Par exemple, une conception simple simplifie les tests, l'intégration, les livraisons, les retours. Le logiciel est décrit en scénarios (user stories) de petite taille plutôt qu'en fonctionnalités. Ainsi le parcours du cycle de développement est rapide, et on contrôle l'évolution du logiciel. Par conséquent le coût de tout changement de spécification est réduit.

La présence du client est requise au sein de l'équipe ! Ainsi il peut répondre à toutes les questions, clarifier ses demandes. Le client pilote davantage le projet, car on lui fait clarifier au fur à mesure ce qui doit être développé, on le fait choisir ce qui est prioritaire pour lui, ce qui donne le plus de valeur au produit à ses yeux. Le client voit ce qui est réalisable et réalisé par l'équipe à chaque itération. Tout cela contribue à construire une véritable relation de confiance avec lui.

Scrum est une méthode née officiellement en 2001. Cette méthode est faite pour tout projet technologique et donc pas seulement logiciel. 3 rôles principaux sont décrits: le Product Owner qui dit ce qu'il souhaite voir implémenter, l'équipe de développement, et le ScrumMaster qui agit pour améliorer le processus, le produit, le fonctionnement et le niveau de l'équipe.

Comme dans XP, on travaille à optimiser la prise en compte de tout changement afin d'en réduire le coût et de maximiser la valeur du produit. Les livraisons se font régulièrement à l'issue de chaque itération appelée sprint, ce qui contribue à éviter l'effet tunnel. Scrum intègre des pratiques du Lean et d'XP. Par exemple:

• La mêlée quotidienne correspond au "stand-up meeting" d'XP.
• Le tableau kanban qui permet de visualiser l'étape dans laquelle se trouve un scénario utilisateur où user story (A faire/En cours/Terminé), vient du Lean. 

De plus, en informatique, il est recommandé de reprendre des pratiques d'XP comme l'automatisation des tests et l'intégration continue.

Kanban est une méthode qui date des années 50, qui fait partie des pratiques du Lean. Si elle a été utilisée en premier lieu dans l'industrie automobile, elle est aujourd'hui mise en œuvre dans l'informatique. Cette méthode se concentre sur la gestion du système de production, afin d'en optimiser la capacité et de livrer en continu des éléments de travail (fonction, bug fix,...). Cela commence par formaliser le processus de production. Kanban utilise le management visuel notamment en mettant en place dans la salle de l'équipe, le tableau kanban visible de tous, qui indique ce qui est planifié, en cours et réalisé.

Un des changements les plus radicaux est le passage au flux tiré : désormais l'équipe ne prendra une nouvelle tâche que si elle en a la capacité, le but étant de faire des livraisons régulières et d'optimiser l'efficacité de l'équipe. Il n'y a pas d'itération planifiée comme avec Scrum. Kanban s'adapte bien aux projets en maintenance ou aux longs projets de développement. On peut envisager son utilisation pour une activité de support.

Enfin Scrumban est une combinaison de Scrum et de Kanban : on utilise Kanban pour la gestion des user stories et pour fluidifier la production. On garde la gestion par itérations/sprints, mais on détaille les différentes étapes par lesquelles chaque user story passera. On dessine donc un tableau, avec une colonne par étape, par exemple avec les colonnes: A faire, Développement, Intégration, Validation, Fait. Cela permet de détailler le processus de production, parfois même de le formaliser! C'est aussi très utile pour détecter et prévenir des situations de famines ou de surcharge dans une étape.

Scrumban est recommandé par rapport à Scrum, si l'équipe contient des personnes spécialisées dans des domaines particuliers (3D, tests, par exemple). Le logiciel peut aussi imposer que certaines étapes soient gérées par un nombre très restreint de personnes à la fois, comme pour l'intégration par exemple.

Conclusion

De plus en plus d'entreprises optent pour une méthode agile pour éviter l'effet tunnel, et améliorer les chances de rentabiliser leurs projets. Cela nécessite des compétences: les équipes doivent être formées, et les rôles définis par la méthode choisie, doivent être respectés. En effet les rôles et les processus diffèrent de ceux auxquels on est habitué.

Les méthodes agiles sont adaptées dans un contexte changeant où certaines décisions peuvent être prises tardivement et peuvent éventuellement en contredire d'autres. La méthode choisie peut ne pas être adaptée, par exemple à cause de la taille de l'équipe: avec XP l'équipe de développement ne dépasse pas les 10 personnes.

Il s'agit de rester pragmatique avant tout. Certaines pratiques peuvent être mises en place très rapidement. Mais il y a un réel changement culturel à opérer, et la migration vers une méthode agile n'est pas instantanée, ni semée d'embûches, aussi il vaut mieux être accompagné dans cette démarche.