De nos jours, il existe plusieurs méthodes de gestion de projet, mais quelles sont celles qui sont réputées pour mener à bien un projet numérique ? Il existe beaucoup de modèles, on a donc sélectionné les plus courantes. L’idée de cet article n’est pas de détailler chaque méthode précisément, mais de faire un bref aperçu et d’en tirer quelques avantages et inconvénients. Nous fonctionnerons en mode client / prestataire, où le client sera une entreprise qui exprime un besoin à travers un projet, et où le prestataire sera l’entreprise qui réalisera son projet.
Méthodes traditionnelles ou Méthodes agiles ?
Dans la gestion de projet informatique, on distingue deux approches très importantes et différentes l’une de l’autre :
- Les méthodes dites traditionnelles
- Les méthodes dites agiles
Pour faire simple, dans les méthodes dites traditionnelles, on va se trouver dans un principe de projet non-itératif. Le client fournira un cahier des charges qui détaille le projet qu’il souhaite mettre en place. Après plusieurs échanges avec le client pour être certain que le besoin est clair, le prestataire va pouvoir intervenir, réaliser le projet et le livrer au client à la toute fin. Et si le besoin du client a changé pendant cette phase de réalisation du projet, c’est compliqué de faire machine arrière : le prestataire s’engage sur un périmètre défini (une liste de fonctionnalités bien détaillée), c’est donc plus difficile quand il s’agit d’enlever une brique complète ou bien de la refaire autrement.
Pour les méthodes dites agiles, on va au contraire se trouver dans un principe de projet itératif, c’est-à-dire qu’on va construire l’application au fur et à mesure et créer des livraisons intermédiaires. Pour ce genre de méthode, il faut évidemment que le client soit bien présent. En travaillant en parallèle avec le prestataire, il aura beaucoup plus de libertés s’il souhaite changer une fonctionnalité ou demander une évolution non pensée au début du projet. > L’idée globale de l’agilité sur un projet informatique c’est de développer de manière itérative un produit, en créant des lots qui sont fonctionnels et qui ont un intérêt.
On va donc parler dans la suite de cet article de deux méthodes traditionnelles (Cascade, Cycle en V) et de trois méthodes agiles (Scrum, Kanban, eXtreme Programming).
Méthode traditionnelle – Cascade
C’est la méthode traditionnelle la plus linéaire possible. On va retrouver plusieurs phases dans cette méthode, et chaque phase dépend de la phase précédente, et nécessite d’être claire et validée. En effet, un changement de conception en plein milieu du développement pourrait avoir un coût élevé et un impact assez fort.
On va donc retrouver les phases suivantes :
- Exigences : phase d’ateliers, réunions, analyse des besoins afin de présenter le projet
- Analyse : phase de spécifications, où le prestataire va rédiger des documents qui vont détailler l’application, fonctionnellement et techniquement.
- Conception : définition et mise en place de l’architecture par le prestataire
- Mise en oeuvre : implémentation de l’application (phase de développement)
- Validation : phase de test de l’application par le client avec éventuellement des correctifs à apporter (on appelle cela la phase de recette)
- Mise en service : mise à disposition de l’outil au client afin d’effectuer la mise en production pour les utilisateurs finaux
Dans cette méthode, il n’y a donc pas vraiment de retour en arrière possible, car on valide une phase avant de passer à la phase suivante. L’inconvénient principal est que le produit est visible par le client que vers la fin du projet (on parle d’effet tunnel) et que le produit est très rigide : si le client souhaite changer d’avis sur une fonctionnalité en pleine phase de développement, c’est compliqué (principalement au niveau contractuel). L’avantage est que le projet bénéficie d’une documentation claire et précise, et que l’on valide chaque étape avant de passer à la suivante (ça a un côté plus rassurant).
La méthode en Cascade fonctionne bien pour des petits projets, où le client est certain du produit final qu’il souhaite.
Méthode traditionnelle – Cycle en V
Cette méthode est utilisée pour pallier aux problèmes du modèle en Cascade, car elle autorise des retours en arrière. On retrouve donc à peu près les différentes phases de la méthode en Cascade (Analyse, Spécifications, Conception, Implémentation, Tests), mais on peut autoriser des changements qui engendreront un nouveau passage par les phases précédentes.
Par exemple, si lors de la phase de recette le client pense à une nouvelle fonctionnalité, ou bien à l’évolution d’une fonctionnalité livrée, on va pouvoir faire un retour en arrière afin de spécifier ces changements, en adaptant si besoin l’architecture, en développant cette partie et en effectuant des nouveaux tests.
Avec cette méthode, on va globalement retrouver les mêmes inconvénients qu’avec la méthode en cascade, c’est-à-dire cet effet tunnel, avec en plus un temps supplémentaire de rédaction de documentations. Mais à contrario, le projet sera clairement bien défini et il peut être intéressant d’avoir une bonne documentation sur le projet, surtout si on veut faire de la maintenance à long terme dessus.
Cette méthode fonctionnera donc bien pour les petits/moyens projets, avec un client qui a une vision assez claire de son projet
Méthode agile – Scrum
La méthode Scrum est l’une des méthodes les plus populaire dans le monde de l’agile.
Nous ne rentrerons pas dans tous les détails, comme tous les termes que l’on peut retrouver dans cette méthode, car on pourrait en faire un article dédié et qu’il y a beaucoup à dire sur le Scrum. Il est nécessaire de juste garder le principe en tête : développer un produit de manière itérative, en réalisant des cycles pouvant aller d’une à quatre semaines. En moyenne, un cycle (ou sprint) dure deux semaines.
Au début du cycle, on va définir une liste de tâches au travers d’une réunion de planification de sprint. Ensuite, l’équipe développe les tâches sur le périmètre défini, pour une date précise de livraison. A la fin du sprint, les acteurs se réunissent pour faire une retrospective, afin de discuter des difficultés rencontrées, ou de la charge des tâches dans le sprint, afin d’ajuster pour le cycle suivant.
L’avantage premier dans cette méthode, c’est que les livraisons se font de manière continue, sur des petites périodes. Si le client change d’avis, l’équipe en discute au prochain sprint et les tâches sont adaptées pour le nouveau besoin. L’autre avantage, c’est la communication entre tous les acteurs. Dans la méthode Scrum, l’équipe réalise ce qu’on appelle une mêlée quotidienne (ou daily meeting en Anglais). Ce point quotidien qui doit durer 15 min en moyenne permet d’avoir une vision claire de l’état d’avancement du produit et des problèmes rencontrés.
Vous vous en doutez surement, mais dans la méthode Scrum, si le client n’est pas présent, ça ne va pas pouvoir bien fonctionner !
Effectivement, définir des petits lots est un avantage, mais cela implique que le client doit être présent pour pouvoir définir les tâches à venir, les détailler, suivre le produit et voir s’il correspond toujours à son besoin. Un autre inconvénient, c’est qu’il y a généralement peu de documentation sur ce genre de projets.
Méthode agile – Kanban
La méthode Kanban est une méthode souvent utilisée et assez réputée car elle permet d’avoir une vision claire de l’état d’avancement d’un projet.
Elle est très visuelle car l’objectif est de créer des colonnes pour y mettre des post-it, qui correspondent aux tâches d’un projet. On peut définir quelques colonnes de base afin de rester simple, comme on peut très bien définir beaucoup de colonne afin d’avoir beaucoup de statuts différents. L’objectif, c’est de faire avancer son post-it sur la colonne suivante, en évitant les retours en arrière. Chaque entreprise, chaque équipe projet va définir ses colonnes à sa manière, mais on va retrouver souvent quelques colonnes similaires :
- ToDo : liste des tâches à faire
- Doing : liste des tâches en cours
- Done : liste des tâches terminées
Après ça, on peut imaginer énormément de colonnes, qui correspondraient à d’autres statuts : à respécifier, à tester, à livrer en recette, à livrer en production, en attente, à jeter (celle la on va éviter..).
Kanban est une méthode qui est assez personnalisable selon le contexte.
Elle peut être aussi très utile en complément d’une autre méthode. On pourrait très bien coupler la méthode Kanban à la méthode Scrum. On remplira en début de sprint notre colonne ToDo avec les tâches à réaliser, en espérant voir toutes ces tâches dans la colonne Done à la fin du sprint.
L’avantage de cette méthode, c’est qu’elle est rapide à mettre en place, simple à adapter et elle est très visuelle pour avoir une vue globale du projet.
L’inconvénient est qu’il est difficile d’avoir une visibilité sur les dates de livrables, surtout si on utilise seulement cette méthode. L’autre inconvénient, c’est qu’on dispose de peu de documentation, et on a tout intérêt à avoir un client présent pour bien expliquer les tâches, car avoir quelques mots sur un post-it ne suffiront pas.
En tout cas, cette méthode est très bien pour être utilisée avec des outils comme Redmine, Jira, Mantis ou même Trello, où l’on va définir (et bien détailler) des tâches avec un système de workflow et de statuts.
Méthode agile – eXtreme Programming (XP)
XP, ou eXtreme Programming n’est pas directement une méthode mais plutôt une liste de concepts pour rendre son projet agile. Au total, on retrouve 13 concepts dans l’extreme programming, dont :
- L’intégration continue : permet de déployer et livrer automatiquement le projet (en utilisant Jenkins par exemple), dans le but d’effectuer des petites livraisons
- Le travail en binôme (pair-programming) : très utile pour la montée en compétence ou l’intégration d’une nouvelle personne dans une équipe
- Le développement dirigé par les tests (Test Driven Development) : pratique visant à développer les tests avant les features
- La revue de code (code review) : principe permettant de faire relire et valider son code par un autre développeur avant de merger des changements
- Le refactoring : bonne pratique permettant de repasser sur du code existant pour l’améliorer, le rendre plus lisible, en suivant des conventions de code sur le projet
L’avantage des concepts de l’eXtreme Programming, c’est qu’ils permettent d’avoir vraiment un produit de qualité, et une bonne connaissance du projet par tous les acteurs. En revanche, l’inconvénient de ces concepts, c’est qu’ils ont un coût non négligeable. Par exemple, certains clients pourront très bien dire : pourquoi je paierai 2 développeurs sur une seule tâche, alors qu’ils pourraient faire 2 tâches en parallèle ? Evidemment ce point est discutable, on pourrait faire un article dédié sur le pair-programming !
Les concepts de l’eXtreme Programming ont l’avantage de pouvoir être mixés avec des méthodes traditionnelles ou d’autres méthodes agiles.
Méthodes traditionnelles VS méthodes agiles : le match !
Nous avons vu plusieurs méthodes traditionnelles et agiles, avec des philosophies différentes, mais il est important de retenir ces principes :
- Dans les méthodes traditionnelles, le client n’est pas obligé d’être très présent. On va bénéficier d’une documentation importante, afin de bien cadrer et spécifier le projet. En revanche, on va avoir un effet tunnel pour le client, qui n’aura son produit qu’à la fin du cycle du projet.
- Dans les méthodes agiles, le client doit être fortement présent. On va faire des livraisons itératives, sous forme de petits lots. La communication est un point essentiel dans ces méthodes, alors qu’en revanche on négligera l’écriture d’une documentation claire et précise.
Attention cependant à ne pas tomber dans le piège de vouloir appliquer une méthode particulière car elle est populaire. Une méthode, ça s’apprend, ça se travaille, et surtout ça s’adapte selon le contexte. Essayez de faire du Scrum avec un client très peu disponible par exemple : vous vous en mordrez les doigts !
Vous vous en douterez donc, mais il n’y a pas de méthode parfaite. Il n’y a pas de recette magique qui dit qu’en appliquant cette méthode sur ce projet, ça fera un carton ! Chaque méthode dépend du client, de son implication, de la façon dont il souhaite travailler avec le prestataire, des développeurs et de leur niveau, ou encore des contrats et de la partie commerciale.
Ce qu’il faut retenir, c’est qu’on va souvent utiliser différents concepts des méthodes vues dans cet article. On va pouvoir les adapter, les mixer en se posant toujours la question : est-ce que ça sera adapté pour mon projet ?
Il faut également savoir que tout a un coût, et qu’on ne pourra jamais mettre tous les meilleurs principes en place : votre client aura toujours un budget limité 😉
Bonus – La méthode La R.A.C.H.E.
D’accord, il n’y a pas de méthode parfaite, mais s’il vous plait, essayons de mettre en place un miminum de concepts de gestion de projet, évitons tous ensemble la gestion de projet à la R.A.C.H.E. !
La méthode R.A.C.H.E signifie : Rapid Application Conception and Heuristic Extreme-programming et s’appuie sur deux concepts aussi important l’un que l’autre.
D’une part la «Rapid Application Conception » correspond conceptuellement à une accélération importante dans la phase de conception de l’application par rapport aux méthodes classiques. Pour bien débuter avec La RACHE il faut soigner la phase d’étude et la rédaction du cahier des charges. Il faut ici produire un travail de synthèse important en résumant le cahier de charges en un post-it de 8 mots maximum. Puis la mission est d’extrapoler de ce post-it un sujet de développement vaseux, mais pas trop. À partir de là, en règle générale, la multiplication du nombre de mots sur le post-it par un chiffre tiré au sort entre 20 et 200 donne la durée du projet en jours/homme. On prendra soin de ne rien planifier dans cette phase.
D’autre part « L’extrême programming heuristique » est un concept assez prometteur. En effet l’heuristique est une technique consistant à apprendre petit à petit, en tenant compte de ce que l’on a fait précédemment pour tendre vers la solution d’un problème. Opposé à l’algorithmique, l’heuristique ne garantit pas du tout qu’on arrive à une solution quelconque en un temps fini. Ceci sous-entend d’une part une démarche pédagogique globale d’apprentissage et de capitalisation des acquis, mais aussi que les échéances annoncées le sont dans une pure optique de déconnade symbolique. Et c’est précisément le plus ‘produit’ de la méthode RACHE.
On vous laisse aller voir par vous même le détail de cette méthode sur son site Internet dédié
