Articles « Info » : Chef de projet

L'itératif, ça apporte quoi, au juste ?
    Certainement pas moins de travail, en terme de gestion, mais plus de précision sur les délais et les fonctionnalités qui y seront présentes à chaque étape intermédiaire. Le but reste le même : rendre à une date finale fixe de livraison toutes les fonctionnalités attendues par le client. Les étapes intermédiaires sont là préciser et affiner ces-dites fonctionnalités, évitant ainsi les "mauvaises surprises" des recettes finales.

Il faut tout planifier, chaque étape, dès le début ?
    Non, malheureux! Ce serait un vaste gâchis. La planification initiale consiste en :
- une estimation du délai global (souvent fixée en collaboration avec le commercial de l'affaire),
- une liste de fonctionnalités classées par risques décroissants (risque = techno mal maîtrisée et fonctions dont dépendent toutes les autres).
    Vous ne pouvez donner aucunes dates intermédiaires précises tant que la phase d'analyse (celle où vous déterminer l'architecture du programme) est validée et où les risques ont été évalués (en général après une ou deux itération).

Donc, au début, on peut s'lancer sans trop savoir où on va ?
    Mais re-non, re-malheureux! On ne va pas commencer à faire de la conception et du codage juste pour occuper l'équipe tout en espérant que des objectifs clairs vont apparaître! Mais d'un autre côté, toutes les exigences fonctionnelles n'ont pas, en effet, à être présentes dès le début du projet.
    L'essence même de l'itératif, c'est de reconnaître "officiellement" une pratique courante "non-officielle" : le "rework" (en anglais), soit le fait que l'on doit "re-travailler" sur ce que l'on a déjà analysé ou conçu ou même codé.
Cette façon de travailler peut facilement vous amener à vous faire tomber dans 2 pièges :
- divergence,
- manque de priorités.

Divergence... ? Ha oui, la fameuse Loi n°8 sur le taux de changement
    Exactement! Travailler en cycle itératif ne doit pas signifier d'introduire une nouvelle technologie ou un nouvel algo ou que sais-je encore à chaque nouvelle itération. Un élément qui marche ne doit pas être retravaillé juste pour le fun. Cela n'a plus rien à voir avec le "rework" et risque d'engendrer plus d'effets de bords désastreux qu'autre chose.
    2 types de personnes peuvent vous amener dans cette mauvaise situation :
- les renforts (nouveaux développeurs intégrés dans l'équipe en cours de projet) : un nouveau a toujours de nouvelles idées... et le pire est qu'elles ne sont en général pas mauvaises! Il faut résister alors à la tentation de revenir sur une partie qui marche sous le seul prétexte que "l'on peut faire encore mieux",
- le client qui croit avoir compris votre démarche en cycle itératif que vous vous êtes tué à lui expliquer. Ils voudront faire passer tous leurs "changements" de spécif en tant que "nouvelle itération". Cet effet est connu sous la dénomination de "requirements creep" : le "décalage des spécifications". Le chef de projet doit se montrer intraitable : toute spécification qui n'a pas été prévue doit se retrouver sous forme d'un avenant, facturé en plus, avec un nouveau planning. Une nouvelle itération ne peut être le prétexte à intégrer quoi que ce soit de nouveau à la dernière minute.

Ok ok... Et le manque de priorités ? 
    Peu de chefs de projets en sont conscients (au moins les premières fois), mais chaque projet a un moment très spécial : le "flip" ou "retournement de situation" : ce moment où tout le monde se rend compte (l'équipe de développeurs comme le client) que « l'on va y arriver finalement, après tout !!! ». Vous savez, ce moment où le client passe de l'état d'esprit où il pense que rien ne sortira jamais de ce projet à celui où il est convaincu que le logiciel attendu va bien sortir dans les temps.
    Et bien, à ce moment là, il faut vraiment se méfier. Car vous allez vous trouver inondé de petites fonctionnalités secondaires que le client craint ne pas voir apparaître dans le produit à la livraison. Avant, il était content si les fonctionnalités majeures étaient bien présentes. Maintenant, chaque détails devient un enjeu essentiel...
Pire, de nouvelles exigences peuvent se glisser sous ce flot incessant de demandes-client où tout est soudainement "top-prioritaire".
    Certes, tout ce qui a été demandé doit être livré, mais la plus mauvaise manière d'y arriver est de céder à cette pression et de vouloir tout faire en même temps : il faut prio-ri-tai-ri-ser. Il faut le faire durant tout le projet, et il ne faut surtout pas oublier de continuer à le faire après le "flip".

Bon alors, qu'est-ce qui est le plus important, avec ce type de démarche ?
    Le logiciel!!! Il ne s'agit pas d'avoir la meilleur technique de management possible ou encore d'avoir les spécifs les plus blindées ou la meilleure conception. Il faut se concentrer sur le logiciel.
    Il est vrai que l'approche Waterfall est confortable : vous avez une tonne de papier sur laquelle vous appuyer. Vos testeurs ont pleins de temps pour peaufiner leurs plans de tests, en se basant sur des spécifications bien policées...
    En cycle itératif, il faut se concentrer sur les fonctionnalités à réaliser et vos testeurs doivent commencer très tôt leur travail, alors que tout est encore susceptible d'évoluer.

Heu... alors, par quoi on commence ?
    Par le plus dur ou le plus risqué en terme technique.
    Mais attention, aborder une difficulté entraîne souvent un réflexe qui se révèle très mauvais : se donner "plus de temps" ! Ca ne sert à rien de remettre "à plus tard" la résolution d'une difficulté, sous prétexte de "se donner plus de temps pour y réfléchir".
    Avec un cycle itératif, on ne peut pas se mentir très longtemps : si un projet est destiné à échouer, autant s'en apercevoir le plus tôt possible, et non passer une première phase confortable qui donne l'impression que tout avance bien, avant de se confronter à la difficulté qui fait tout effondrer. Cela permet de perdre le moins d'argent possible.
    Et, en en parlant de risques (techniques), il ne faut surtout pas oublier de surveiller l'apparition de nouveaux risques. La liste initiale de difficultés techniques, avec leurs dépendances, était une première ébauche qui vous a amené à établir une première suite d'itération.
Mais la résolution des premières difficultés vous amène ensuite à une analyse bien définie, avec une architecture qui saura répondre aux fonctionnalités attendues, mais qui peut aussi faire surgir d'autres points critiques. Il vous faudra les intégrer et revoir vos itérations.
    Enfin, ne mettez surtout pas trop de "difficultés techniques" dans votre première itération. N'oubliez pas que cette étape initiale recouvre d'autres problèmes : vos développeurs doivent potentiellement s'adapter à de nouveaux outils, de nouvelles techniques, un nouveau formalisme de codage, etc. La pire des chose est de se retrouver avec une première itération trop longue, que vous seriez obligé "artificiellement" de déclarer comme terminé alors que vous n'avez aucun premier prototype à sortir, donc que "rien ne marche" encore.
    Au début, il ne faut pas se braquer sur la complétion absolue des objectifs, mais plutôt sur une "non-complétion appropriée", qui vous laisse avec des développeurs bien initiés à ce nouveau projet, et un premier proto vous permettant de discuter avec le client. 

Ok, et pour les itérations suivantes, comment ça se passe ?
    D'abord, éviter de confondre une release hebdomadaire avec une itération! Le piège est d'avoir trop d'itérations. En général, cela va de 3 itérations (pour un projet de 2 ou 3 mois) à 9 itérations (pour de très long projets). Il faut tenir compte de la taille de votre (ou vos) équipe(s), de leur distribution géographique, de tous les intervenants impliqués.
    L'autre piège est de "se faire recouvrir les itérations" : oui, vous devez planifier l'itération suivante avant la complétion de celle en cours... mais la démarrer (en terme d'analyse et de conception) de suite peut vous mener à toutes sorte de problèmes :
- les collaborateurs qui travaillent sur une itération tout en analysant la suivante ne seront pas complètement concentrée sur l'itération en cours, au point de ne pas tout faire ou de ne pas "corriger" suffisamment vite les bugs en cours.
- certaines parties du logicielles ne seront pas encore prêtes (en terme de services et d'interface) à supporter ce qui a été analysé et conçu pour l'itération suivante,
- le "retour de connaissance" de l'itération en cours n'aura jamais eu l'opportunité de pouvoir inspirer et guider l'analyse et la conception de l'itération suivante.
    Bien sûr, vous pouvez dédier une partie de votre équipe sur la prochaine étape, mais le plus rarement possible : cela reste inévitable lorsque vous avez des collaborateur très spécialisés, comme un "analyste" qui ne veut faire que de l'analyse.

Mmmm... et vos itérations-truc, là, c'est bien perçu par le client ?
    Évidemment, c'est mal perçu, et par le client, et par votre direction informatique. Les 2 sont habitués à travailler en "milestones", sur des documents précis.
    C'est à vous de protéger votre équipe d'un côté, et de rendre chaque itération la plus claire possible en terme d'objectif. Pour cela :
- toute votre équipe doit travailler sur une même itération. Essayer de paralléliser est, au mieux, dangereux car le travail lié à la synchronisation des travaux de vos sous-équipe est souvent plus coûteux qu'on ne le pense,
- il faut réussir à fixer des délais intermédiaires précis pas trop tôt. Il faut "résister" pendant une ou deux itérations (les 2 premières) le temps d'analyser les risques, proposer un premier proto, intégrer les remarques clients et proposer une architecture valable. Des délais précis pour les itérations suivantes peuvent alors être fixés avec précision. Pas avant.
    Évidemment, l'avantage de ce type d'approche est que vous pouvez montrer très tôt "quelque chose qui marche", ce qui vous permet de prendre en compte les remarques clients avant même d'avoir commencer à tout documenter de façon formelle. C'est l'esprit « démontrer d'abord, documenter après ». En effet, la documentation vous permet de montrer "comment cela devrait marcher"... alors que les ingénieurs préfèrent voir "comment cela marche".

Bon, en clair, comment mesurer le degré d'avancement précis ?
    D'un côté, vous avez, après une ou deux itérations, complètement analysé le projet. Vous avez donc à votre disposition une liste de "use-case" ("cas d'utilisation") à réaliser.
    Le problème ? Il ne faut pas croire que chaque itération va permettre de réaliser un cas d'utilisation. En général, il permet de faire partiellement plusieurs cas d'utilisation. De l'état d'avancement partiel de ces cas, vous pouvez alors en tirer un état d'avancement global du projet... et pourtant, ce n'est pas cela que vous devriez surveiller le plus.

Allons bon, qu'est-ce qui pourrait être plus important que le degré d'avancement ?
    Le taux de changements ! Changements dans les spécifications, la conception ou le codage. Et aussi (encore plus dur à détecter), le taux de bouclage ("churn" en anglais, soit le fait de tourner le lait pour en faire du beurre!). Vous savez, ces changement répétés qui vous ramène à la solution initiale! Ils sont souvent symptomatique d'un problème plus profond.
Cela rejoint la divergence évoquée plus haut.

Bigre... le chef de projet a intérêt a être bon, non ?
    Lui, et l'architecte ! La meilleure direction de projet possible ne mènera à rien sans un architecte qui, au bout d'une ou deux itérations, vous définira une architecture (et ses solutions techniques associées) qui tiendra la route. Inversement, la meilleure architecture du monde ne fait pas le poids face à une gestion de projet qui s'attaque à trop de sujets à la fois, dans le mauvais ordre, engendrant une "panique" en fin de projet.
    Bref, c'est la Loi n°5 sur le manager et le technicien.
    Utiliser la même personne pour faire les deux... serait pour le moins risqué. Cela peut marcher pour de petits projets, de 5 à 10 personnes. Au-delà, mieux vaut penser à séparer clairement les tâches, un peu pour les mêmes raisons qu'un producteur et un réalisateur seront deux personnes différentes pour produire le même film.

Pfff... ça l'air compliqué, tout ça. Pourquoi se compliquer la vie ?
    Au contraire, les principes qui sous-tendent cette démarches sont là pour vous simplifier la vie :
- s'attaquer aux risques techniques tôt dans le projet (avant que ces risques ne vous attaquent!),
- reconnaître la nécessité de revenir sur des points déjà étudiés, au travers du retour de connaissance entre itération,
- se concentrer sur le logiciel d'abord, en en produisant des versions intermédiaires régulières,
- intégrer les remarques du client tout au long du process afin de mieux veiller à l'évolution des spécifications (qui seront soit refusées, soit intégrées sous forme d'avenant, mais jamais étudiées à la dernière minute au moment de livrer).
    C'est vrai, c'est plus dur à manager qu'avec un cycle en V traditionnel. Mais lorsque vous en saisissez le principe, vous découvrez un style de management beaucoup plus fin, précis, maîtrisé.