Découvrez les différentes manières pour apprendre à gérer plusieurs projets au sein d'une petite équipe de développement.

Avant de rentrer dans le vif du sujet, commençons par poser le contexte dans lequel cet article a été rédigé. Vous gérez l’attribution de tâches dans une équipe informatique de 5 personnes. Votre équipe réalise des projets de développement de site web, d’application métier ou mobile, de création de contenu multimédia ou encore de réalisation graphique. Les projets sont de taille variable, ils varient entre quelques semaines jusqu’à plusieurs mois, voire des années.

Ce postulat étant défini la question qui se pose est : comment aborder efficacement le planning de chacun, autrement dit, comment gérer les ressources afin que les projets soient livrés en temps et en heures, veiller à ce que les ressources ne soient pas en surmenage ou en manque de travail. En bref que le projet se déroule bien et que les membres de l’équipe soient satisfaits de leurs conditions de travail.

Si l’on attribue des tâches aux personnes sans vraiment définir une stratégie au préalable, il y a de fortes chances de se retrouver avec un cas tel que décrit dans le schéma ci-dessous.

Figure 1 Exemple d’une mauvaise répartition de projet au sein d’une petite équipe

Voici quelques observations sur le schéma présenté :

• Certaines personnes sont clairement à la tête de certains projets alors que d’autres errent entre différents projets.
• Certaines personnes ne participent pas du tout à certains projets, ce qui limite les connaissances métier à un nombre limité de personne.
• On constate que la mise en route tardive du projet 3 a provoqué l’arrêt de tous les autres projets afin de tenir les délais.
• L’exemple montré est simple, mais nous constatons déjà que cela peut rapidement être ingérable si le nombre de ressources et/ou de projet venait à augmenter.
• On constate que le projet 1 a essentiellement concerné une seule personne, si cette dernière venait à être malade ou à quitter l’équipe, aucune autre ressource ne serait à même de reprendre le travail.
• Ce genre de planification encourage les membres de l’équipe à travailler de manière individuelle et non pas en équipe.

Sur la base de ces observations, voici les principaux problèmes qui surgissent :

• Égalité de traitement entre les membres de l’équipe certains membres ont le « luxe » de travailler sur un seul projet alors que certains changent régulièrement de contexte.
• Pas ou peu d’esprit d’équipe, éventuellement la création de binômes.
• La connaissance des produits est limitée à une ou deux personnes et non pas à l’ensemble de l’équipe.
• Certaines personnes sont surmenées alors que d’autres sont en manque de travail.
• Il est difficile de savoir qui travaille sur quoi et d’avoir une vision globale de chaque projet.

Passons en revue les différentes solutions qui s’offrent à vous

1. Chaque personne travaille sur un projet spécifique

Dans cette option, tous les projets avancent parallèlement avec une ressource attribuée à chaque projet. Il sera possible de présenter régulièrement une avancée au client, en contrepartie la date de livraison sera longue pour chaque projet. Ce qui implique que pour chaque projet il faut gérer en parallèle les éléments suivants :

• La livraison de produits intermédiaires
• Facturation
• Séance client
• La mise en production finale

D’autre part, les ressources travaillent de manière individuelle, il n’y a donc pas d’esprit d’équipe ni de critiques/propositions d’améliorations sur le travail des autres. Finalement, la personne qui aura réalisé le projet sera experte dans son projet, elle sera donc plus productive et décèlera rapidement les causes des bugs, en revanche si cette même personne tombait malade ou venait à quitter votre équipe, il faudra qu’une autre personne acquière toutes ses connaissances.

• – Délais de livraison maximums pour chaque projet
• – Pas de travail collaboratif, pas d’esprit d’équipe
• – Une seule personne possède tout le savoir du projet
• + Pas de perte de temps pour les changements de contexte
• + Avancée régulière sur le projet, planification de versions simplifiée

2. Un sprint par projet, alternance de projet

Cette seconde alternative propose de traiter un projet différent dans chaque sprint. Le point fort de cette méthode est que la connaissance du projet est répartie sur l’ensemble de l’équipe. Vous ne dépendrez pas d’une seule personne pour la réalisation d’un projet, n’importe quel membre de l’équipe aura les connaissances sur le fonctionnement de vos produits. De plus, cette stratégie demande une bonne cohésion d’équipe et donc une ambiance de travail agréable. Le fait que tout le monde soit concentré sur un même produit permet d’obtenir plus d’idées, d’avis, de points de vue sur le produit, ce qui résulte sur un résultat de meilleure qualité.

Cependant, le temps entre chaque sprint peut être trop long et donc il y aura toujours un temps de mise en route pour se replonger dans le projet, c’est donc du temps qui est perdu. Ensuite avec une forte charge de travail de manière ponctuelle il est difficile de définir un plan de délivrables intermédiaires. Finalement, au même titre que l’option numéro 1 tous les projets avanceront en parallèle et auront des dates de livraison qui seront temporellement proches, ce qui implique toutes les problématiques décrites précédemment.

• – Temps entre 2 sprints sur le même projet trop long, perte de temps pour se remettre dans le contexte
• – Difficile de planifier les versions de produit
• – Livraison retardée pour tous les produits
• + La connaissance du projet est répartie sur toute l’équipe
• + Esprit d’équipe

3. Tous les projets dans un sprint

Cette troisième possibilité est à l’opposé de ce qui est présenté dans la 1ère option. C’est-à-dire qu’au sein du même sprint on va avancer sur tous les projets. Un peu comme si chaque fois qu’une personne termine une tâche elle en piochait une autre aléatoirement dans le backlog. Le bon point de cette méthode est que tous les projets avancent en même temps il est donc possible de régulièrement présenter les avancées aux clients, malheureusement si la quantité de projets devient trop importante le travail accompli chaque semaine sur chaque projet est minime.

D’un point de vue de la spécification, vous devrez être irréprochable, étant donné qu’il faudra fractionner les projets de sorte qu’ils s’adaptent à la taille des sprints, les tâches seront beaucoup plus courtes et donc plus précises. Cela demande donc du travail en amont pour planifier le travail des ressources. Comme au point précédent, dans ce cas de figure la connaissance des projets sera répartie sur l’ensemble des membres de l’équipe. Pour clôturer ce chapitre, selon moi le plus grand défaut que vous allez rencontrer avec cette méthode est que les membres de votre équipe vont devoir alterner d’un projet à l’autre plusieurs fois durant le sprint et donc à chaque nouvelle tâche, il y aura un temps de mise en contexte qui peut faire diminuer la productivité du groupe.

• – Nécessite beaucoup de détails dans la spécification des tâches
• – Risque de confusion entre les projets
• – Avancée dans les différents projets minimes
• + Avancée régulière sur tous les projets
• + Esprit d’équipe
• + L’ensemble de l’équipe a les connaissances sur les différents projets

4. Sérialiser les projets, un projet à la fois

La dernière approche est selon moi la plus efficace, d’un point de vue de la gestion de ressources, il s’agit de traiter les projets les uns après les autres. Votre équipe s’investit entièrement dans un projet jusqu’à ce qu’il soit terminé, puis passe au projet suivant. On n’en retrouve pas les différents défauts mentionnés dans les alternatives précédentes, c’est-à-dire la perte de temps due au changement de contexte, la connaissance du produit limité à une partie de l’équipe, temps de livraison total long, etc. Une des conditions pour que le développement de vos solutions se déroule sans accroc est une bonne cohésion au sein de l’équipe, les conflits peuvent parasiter la productivité.

Malheureusement, cette solution n’est pas toujours aisée à mettre en place dans un environnement concret. En effet, dans la réalité il se peut que vous attendiez des informations d’un chef de produit externe qui pourrait bloquer votre équipe.

• – Requiert une bonne cohésion d’équipe
• – Difficilement applicable concrètement
• + Pas de perte de temps dû au changement de contexte
• + Connaissance répartie sur l’ensemble de l’équipe
• + Les projets sont livrés rapidement

Conclusion

Chacune des solutions citées a ses avantages et ses inconvénients, c’est à vous de définir laquelle est la plus adaptée à votre domaine d’activité et aux compétences de votre équipe. Évidemment dans la réalité rien n’est jamais soit blanc soit noir, il faut savoir trouver le juste milieu. En plus de ça, il y a toujours des évènements externes qui viendront perturber le déroulement de vos journées. Dans le cas où vous auriez des approches différentes, ou si vous avez tenté d’appliquer une des méthodes présentées c’est avec plaisir que nous accueillerons vos expériences dans les commentaires.