Valtech Mag
Au fil des projets, le développement agile mis en œuvre selon les règles de l’art prouve qu’il permet de livrer des logiciels de qualité dans le respect des délais impartis et des budgets alloués. Ce succès a déchaîné l’enthousiasme et donné lieu à une rhétorique tout aussi débordante. L’agilité est souvent décrite comme si radicalement différente du développement en cascade qu’elle pourrait se passer de ses attributs naturels que sont, entre autres, les chefs de projet.

Cela n’est que partiellement vrai. Mais l’agilité est bel et bien en train de révolutionner le rôle du chef de projet. Le chef de projet est mort. Vive le chef de projet !

La réalisation de logiciels, c’est autre chose. Dans le cadre d’un projet en cascade classique, le chef de projet est chargé de livrer un système logiciel dans un contexte où sont donnés des ordres dont l’exécution doit ensuite être contrôlée. Il propose donc un plan élaboré à partir des délais et du budget alloués par le client. Il décide du nombre de collaborateurs et du temps qu’il lui faudra pour mener à bien le projet. Il assigne aux développeurs des tâches et s’assure que celles-ci sont effectuées dans les délais et en conformité avec le plan élaboré originellement. Si le plan commence à déraper — et dès que ce dérapage se produit —, il prend des mesures pour remettre le projet sur les rails. En d’autres termes, le chef de projet s’efforce d’exécuter un plan qui prévoit l’évolution du projet.
Avec l’approche agile, il ne s’agit pas de suivre un plan à la lettre.
Or, tous les projets logiciels ne se déroulent pas comme prévu. On attribue souvent l’échec des projets en cascade au manque de compétence supposé du chef de projet et/ou à la relative immaturité des méthodes de génie logiciel. Mais en réalité, la construction d’un système logiciel n’est pas un exercice de prévision. C’est un exercice d’adaptation.

Avec l’approche agile, il ne s’agit pas de suivre un plan à la lettre. Il s’agit d’arriver à destination : c’est-à-dire à la livraison du logiciel. Pour filer la métaphore du voyage, disons qu’un chef de projet agile est un guide chargé de cornaquer son équipe. La réussite ne se mesure pas au degré de soumission de l’équipe aux ordres donnés avant le départ, mais à sa capacité à éviter les écueils et à braver les intempéries pour atteindre le but de son périple.

En tant que guide, le chef de projet agile doit faire preuve de trois qualités majeures : le sens du leadership, la motivation et la vision.
De la gestion de projets à la direction d’équipes

Le chef de projet doit être un meneur d'hommes, pas un donneur d'ordres. Dans l’univers du développement agile, l’appellation « chef de projet » est peu appropriée. Il serait plus juste de parler de « chef d’équipe » ou de « coordinateur de projet ». Pourquoi ? Parce que les projets agiles obéissent à une logique totalement différente de celle qui est à l’œuvre dans les projets en cascade. Modestes ou ambitieux, tous les projets agiles fonctionnent selon un « cycle agile » : préparation, construction, retours, adaptation, dont le rythme est imprimé par le chef de projet.

Pendant la phase de préparation, le chef de projet aide l’équipe à définir son propre plan d’action. L’équipe décide de ce qui est faisable et de ce qui ne l’est pas. Elle décide qui va s’atteler à quelles tâches (ce n’est pas le chef de projet qui les affecte).
Le chef de projet n’est pas sur le dos de l’équipe.
Pendant la phase de construction, le chef de projet n’est pas sur le dos de l’équipe. Il ne fait pas de microgestion. En revanche, il s’assure que l’équipe dispose des ressources nécessaires à l’accomplissement des tâches qu’elle a prises en charge et il la protège de toute interférence avec l’extérieur.

Pendant la phase de feedback, l’équipe revient sur le déroulement de l’itération et identifie ce qui a marché et ce qui n’a pas marché. A ce stade, le chef de projet est là pour rappeler à l’équipe les points qu’elle a pu négliger et l'informer de tout changement externe susceptible d'affecter les itérations suivantes. Enfin, des changements sont effectués pour l’itération suivante, à partir des retours obtenus.
Je me plais ici

Le chef de projet doit créer un environnement de travail fondé sur la collaboration. Dans un projet agile, des rôles — et non des tâches — sont assignés aux membres de l’équipe. Chaque rôle est assorti de droits et de responsabilités. La mission du chef de projet consiste à délimiter les droits et les responsabilités de chaque rôle en collaboration avec la personne chargée de l’exécuter. Elle consiste également à vérifier que chacun respecte les droits des autres et assume ses propres responsabilités.

La même chose vaut pour les interactions de l’équipe avec les parties prenantes. L’une des caractéristiques des projets agiles est de ménager des voies de communication très ouvertes entre les développeurs et le client. Mais une communication excessive peut se révéler une source de distraction néfaste. C’est pourquoi le chef de projet doit agir comme « garde-fou », afin de prévenir tout déraillement au cours d’une itération.

Protéger l’équipe suppose également d’éviter qu’elle ne devienne trop dépendante d’une seule personne. Il est donc important d’encourager la collaboration et l’apprentissage. Plus les membres de l’équipe seront polyvalents, plus il sera facile de faire face au départ inopiné de l’un d’entre eux.
Un développeur qui aime son cadre de travail est un développeur qui travaille mieux.
Au bureau, le chef de projet doit faire en sorte que le cadre de travail favorise la productivité. Un développeur qui aime son cadre de travail est un développeur qui travaille mieux. Le chef de projet doit être ouvert aux suggestions d’amélioration de l’espace de travail.

Il doit, en outre, veiller à ce que les itérations ne sombrent pas dans la monotonie. Pour cela, il n’hésitera pas à injecter de temps à autre une itération de refactorisation pour briser la routine. De même, il ne devra pas craindre de redistribuer les rôles. Ce type d’initiative améliorera la communication et la compréhension au sein de l’équipe et favorisera le partage des connaissances. Enfin, il devra s’assurer que l’équipe effectue une semaine normale de travail. La progression doit se mesurer aux résultats que génère le projet et non au nombre d'heures qu'y consacre l'équipe. Il a été prouvé à de multiples reprises que de longues heures de travail n’aboutissent qu’à produire du code de mauvaise qualité, sans permettre de rattraper le temps perdu.
Je fais un rêve

Le chef de projet incarne la vision du projet. Les développeurs ne se lèvent pas chaque matin avec le désir ardent d’écrire du code. Ce qui les motive, c’est le défi intellectuel que représente le projet. Il incombe au chef de projet de stimuler son équipe en exprimant la vision du projet de telle sorte que chacun puisse la comprendre. La vision doit refléter à la fois la perspective du client et le point de vue technique. Au chef de projet de faire ressortir le point de convergence entre les deux : en quoi la valeur commerciale du projet profitera de l’excellence technique du logiciel livré. Tout au long du projet, le chef de projet intervient pour nourrir cette vision, afin que personne ne perde de vue la destination finale.
Les développeurs ne se lèvent pas chaque matin avec le désir ardent d’écrire du code.
Définir clairement la vision du projet nécessite également de l’expliquer aux utilisateurs et à toutes les parties prenantes. Il est important de faire un rêve, mais le chemin devant y mener peut parfois sembler obscur ou intimidant. Il revient au chef de projet de fragmenter ce voyage en étapes maîtrisables et accessibles. Enfin, si le chef de projet doit incarner la vision, il n’en est pas le seul inspirateur. La vision émane d’un effort collectif. Le chef de projet doit mettre en place un environnement qui laisse chaque membre de l’équipe contribuer à la formation de ce rêve.
Conclusion

Comme vous le voyez, le rôle d’un chef de projet agile évolue en fonction du stade du cycle agile auquel il se trouve :
  • Au début d’une itération, le chef de projet est un meneur qui guide l’équipe dans la bonne direction.
  • Au cours d’une itération, le chef de projet est un supporteur qui protège son équipe des éléments et s’assure qu’elle a tout ce qu'il lui faut pour travailler efficacement et dans de bonnes conditions.
  • À la fin d’une itération, le chef de projet est un facilitateur qui aide son équipe à tirer les leçons des retours obtenus et à mettre en œuvre les changements et les améliorations qui s’imposent
Le chef de projet agile ne ressemble guère à son homologue des projets en cascade. Mais son travail est tout aussi décisif et il promet d’être plus gratifiant.
Vos commentaires

19 déc. 2006 14:28 - dupont
Et l'approche agile pour construire un pont, une voiture ou une centrale nucléaire ?

rarement lu un tel amas de conneries, témoignant d'une incompetence et d'une irresponsabilité avérées.
19 déc. 2006 16:14 - pourquoi pas ?
La réponse est digne d'une fermeture d'esprit mais bon le troll existera toujours. L'agilité est un mode de fonctionnement qui a l'avantage de mettre en mouvement les acteurs et évite les postures de défense.

19 déc. 2006 17:12 - jean-marc
Méthode très intéressante, mais jamais vu appliquée dans la pratique.
20 déc. 2006 08:27 - maurice
L'approche agile se décline en une panoplie de méthodes dont la plus connue est XP (eXtreme Programming). Je pratique depuis qq semaines et nos commanditaires sont favorables à cause de la suppression de l'effet tunnel des cycles en cascades et en V. Quelques contraintes existent comme la taille des équipes par ex. L'agilité est à mon avis parfaitement adaptée pour les environnements changeant ou mal définis.
20 déc. 2006 11:15 - Fred
A la lecture des commentaires, je pense qu'il faudra encore un peu de temps pour que ces methodologies soient prisent au serieux par tous ;-)
Pour ma part, la methode SCRUM a donné d'excellents résultats sur mes derniers projets. Gardez en tête qu'il arrive souvent que les clients ne sachent pas exactement ce qu'ils veulent, d'où l'intéret de rester agile ...
20 déc. 2006 13:35 - Papa Furax
Il y a effectivement pas mal de baratin et de buzz autours des méthodes agiles, et je pense que c'est ce qui produit des réactions commes celles de dupont, qui semble-t-il ne s'est pas interessé à ce qu'il y a réelement dérrière, ou alors c'est du pur troll, d'ailleurs il ne semble pas avoir compris que cela s'adresse en premier lieu à l'industrie du *logiciel*

Je suis un peu dubitatif sur Scrum, car il me semble que ça ne matche pas vraiment avec le comportement social en France en tout cas.

En revanche, j'ai eu la chance de travailler pendant deux ans, avec un management s'en inspirant, et surtout en appliquant la majeure partie des principes d'XP, et le moins qu'on puisse dire, c'est que la productivité, mais surtout la *qualité* sont grandement améliorés.
21 déc. 2006 14:03 - Christophe
Interessant. Structure et exprime la realite d'une majorite de projets informatiques qui n'ont pas de contraintes de safety (embarques) et ou l'on evolue entre de la bricole controlee en cycle iteratifs et des process mettant en oeuvre de la qualite, quand le client la paie.

Ah, pour info, Mr Dupont (le 1er post) le seul amas de connerie c ton post justement. Il est bien dit en intro que ca ne concerne que des projets informatiques, et pas des projets industriels comme une centrale...
pis bon, derniere chose, personne t'oblige a appliquer une telle approche.....
21 déc. 2006 18:07 - Oaz
J'ai 2 réponses à cet article :
  • la longue que l'on peut lire à cette adresse : http://agilitateur.azeau.com/index.php?itemid=61
  • la courte qui est que l'auteur de cet article devrait un peu plus réfléchir à ce qu'est l'agilité et comment elle se pratique au lieu d'énoncer autant de contresens, voire de contre-vérités...
22 déc. 2006 21:08 - Stephane
Je me demande où l'auteur a vu qu'il fallait absolument garder un chef de projet intermediaire du client/utilisateur.
C'est au representant des utilisateurs/client (Onsite Customer / Product Owner) de guider l'effort de l'equipe dans la bonne direction..

Scrum et XP fonctionnent trés bien, et ce depuis près de dix ans.. Ce sont d'ailleurs des process empiriques, elaboré progessivement à partir de l'expérience (contrairement a d'autre process aux bases théoriques)
Mais attention, il n'y a rien de magique dans l'agilité.. au contraire, même si les principes agiles sont plutôt du bon sens, ce n'est généralement ni intuitif ni facile a mettre en pratique.. il faut du courage..

Une organisation incapable de promouvoir un climat de confiance de fera pas disparaitre ses dysfonctionnements avec ou sans process agile..

Je pense pas que ca soit une question de culture ou de secteur d'activité, mais juste d'habitudes.. et j'espère qu'il y quand même un grand nombre de boites francaises qui ont déjà de bonnes habitudes (voire agile sans le savoir)
23 déc. 2006 14:18 - Sébastien
La première agilité est la capacité de s'adapter à l'environnement et d'anticiper les réactions. Dans mon contexte, il aurait été impossible de faire adopter scrum ou xp tel quel ni à mon DI, ni à certain de mes développeurs. Mes projets sont généralement au niveau macroscopique placés dans un cycle en V ce qui rassure les MOAs puis découpés en sous tâches XP ou V selon les intervenants. En général j'essaye de placer les éléments spécifiques au projet en V, tout ce qui est framework ou composant réutilisable en XP.

m2p.

Seb
23 déc. 2006 23:21 - pascal
Les méthodes agiles telles que présentées dans cet article intéressant s'adressent à des "superman" de l'informatique. Croire que chacun des développeurs peut maitriser tous les outils nécessaires (uml, eclipse, jsf/struts/swing/ajax/validator, spring, hibernate, cvs, maven/ant/continuum, java, javascript), les middlewares (http, ws, rmi, ejb...), les modèles architecturaux (n couches, soa...), les bonnes pratiques (modéliser un processus, modèliser un domaine métier...), s'apparente à un voeux pieux.

Ces méthodes ont été inventées par des programmeurs brillants, souhaitant sauvegarder leur capacité créative face à des pratiques à la CMMI, en apparence plus coercitives puisque valorisant la capitalisation, cad la réutilisation (de pratiques, de patterns, de composants). Mais toutes les équipes informatiques ne sont pas composées de Beck, Cunningham, etc.
Dans la méthode pronée par l'article, on a l'impression d'être devant une équipe d'artistes créatifs, dont on se demande si elle a un objectif business ou un objectif de fun...

Par ailleurs, présenter le cycle en V des années 80 comme seule alternative à la méthode agile est un peu facile. Les démarches itératives liées à un cycle en Y sont sans doute moins fun mais plus intéressantes.

Enfin, je suis sceptique sur la "scalabilité" d'une telle démarche. Or, même s'il faut se méfier des méga projets, les grandes entreprises ont des grands besoins et ne peuvent échapper à la nécessité de faire de temps en temps de tels projets. La décomposition en sous-projets est certes nécessaires et possibles, mais quid de la synchronisation entre équipes ? de la nécessité de spécifier les besoins ? de la nécessité de mettre en place des architectures réutilisables ? de la nécessité de prévoir des phases d'intégration périodique ? Est-ce compatible avec les méthodes agiles ? Ce n'est pas clair...
27 déc. 2006 08:54 - Michel
Et s'il n'existaient pas vraiment vos supermen ? Peut-être que tout un chacun est un développeur brillant qui s'ignore, enfermé dans des méthodes rabaissant ses compétences.

Cela fait deux ans que je travaille avec ce mode de développement, pour la plupart nous sommes une equipe de jeunes développeurs (entre 1 et 3ans d'experience) et cela a bien fonctionné, tout le monde est monté en compétence pratiquement en meme temps. Evidemment chacun des membres de l'équipe n'a pas les mêmes envies, n'aime pas les mêmes choses (certains préfèrent creuser de nouveaux sujets, d'autres chercher les frameworks collant à ce que l'on veut faire, etc...) et c'est en cela que les méthodes agiles sont assez interessantes :
L'equipe définit qui accomplit les taches , le fait de tourner sur les sujets fait que il y a peu de sujets sombres.

Evidemment tout n'est pas parfait,
Penser qu'un des développeur puisse partir sans dommage pour le projet est un voeu pieux

L'intégration d'un nouvel élément à une equipe fonctionnant sous ce principe est doublement compliqué car les liens créés entre les membres sont, à mon avis, plus forts que dans une gestion de projet plus classique et il faut qu'il accepte la manière de faire.

Je ne pense pas qu'il y ait un vrai rôle de CDP comme décrit dans l'article, plutôt un "chef administratif" pour toutes les paperasses à la française et un interlocuteur privilégié (et non unique) avec le client, seulement privilégié car sinon c'est un filtre donc une perte d'info,

Avez-vous d'autres inconvénients (argumentés) ?
27 déc. 2006 12:23 - Cyril Gambis
En voyant le titre, j'ai eu un peu peur au niveau de la qualité de l'article; mais au fur et à mesure, j'ai été assez rassuré.

Le poste de chef de projet ne va certainement pas disparaitre avec les méthodes agiles. Il a un rôle qui tient effectivement plus du "coordinateur" et du "leader". Il est sans doutes plus proche des hommes et plus éloigné du "papier" (documents de specifications, contrats, mails aux utilisateurs/clients...). Bref, je veux bien croire que son rôle (ou ses rôles) évolue(nt).

Mais dire qu'il va disparaitre comme le laissait supposer le titre est une grande incompréhension des méthodes agiles (car il y a justement des rôles de coordination, encadrement, évangélisation et communication qui sont essentiels).
28 déc. 2006 00:03 - bibi
C'est vrai que le chef de projet a besoin d'agilité pour eviter les baffes du client et de son équipe s'il applique tout ces conseils.

C'est quoi ce truc, Mickey au pays de l'informatique ? Tout dépend de l'équipe. Si tu bosses avec des ingenieurs bac+5 tout justes sortis de l'école, oui c'est facile de 'synchroniser' à la motivation intellectuelle. Si tu bosses avec des equipes de seniors qui ont aussi d'autres contraintes (aller chercher les enfants à l'école..) et qui ne sont pas formés depuis des années car la boite attends qu'ils partent et eux attendent d'être virés alos là oui, c'est autre chose la gestion de projet.

29 déc. 2006 08:53 - Gap
Propos élégant mais un peu myope. En témoigne cette citation extrait de l'article :
"Il s�??agit d�??arriver à destination, c�??est-à-dire à la livraison du logiciel"

Autrement dit : agile jusqu'à la livraison. J'ai livré, j'ai fini ( ou presque, j'ai encore quelques correctifs de defects à faire). Attitude logique pour un développeur.

Je fais de la MOA depuis des années et franchement, le monde est très différent pour le projet... vu par l'entreprise-cliente. Pour elle, la livraison (en recette) marque, disons, le début de la deuxième moitié de projet.

La vraie difficulté de la "logique agile" est de prolonger ses propres postulats dans la deuxième moitié. Disons la recette, la perf, la migration des données s'il y en a une, la mise en préprod, la simul en vraie grandeur avec les SI externes, la mise en place d'une exploit, la prépa du roll out, la documentation de la solution pour les futurs utilisateurs et exploitants, le Change, etc. etc.

L'obligation de tout faire en parallèle ( le fameux "time to market") invite à une sorte "d'agilité" pendant la deuxième moitié de projet. Mais quelle "agilité" exactement ?

Pas si simple. Car à ce stade, on parle contrôle, rigueur, homologation... de l'appli sans sa totalité. Et c'est normal : demain, des vrais acteurs-métier utiliseront l'appli pour leur vrai business, leur vrai gagne-pain. Pas question de lancer sans avoir tout homologué, simulé etc.

Il est séduisant - et efficace - de jouer agile (parallèle, itératif...) pendant la conception, l'archi tech, les dev, les tests unitaires... Eviter l'effet-tunnel jusqu'au roll-out, c'est beaucoup plus délicat. Possible oui - je le sais j'ai essayé. Mais sacrément délicat quand même.
1 janv. 2007 14:56 - fabrice
Article de vulgarisation intéressant qui aurait mérité d'être approfondi par quelques liens externes pour inviter le lecteur à écorner le simple bavardage (néanmoins intéressant) de cet article.

Je me suis posé dans le cadre d'un projet sur la méthode agile, j'ai fini par en faire un mixage entre cycle classique en V, XP. La meilleure méthode est celle en laquelle adhère toute l'équipe projet. Je ne pense pas qu'il n'y est de méthode en particulier mais plutôt une infinité de méthodes composées par la touche individuelle de chaque projet et équipe projet. Agile, XP, Cycle en V ne sont que des références ou piocher les ingrédients nécéssaires à la composition de sa recette personnelle.
Ainsi font les meilleurs cuisiniers !
2 janv. 2007 21:49 - Vieux retrograde
Méthode agile ?
C'est à la mode ces temps ci.
La mode de quoi ?
On se demande ... bla bla bla ... tout ça pour pondre des usines à gaz qui vont refaire la même chose que le logiciel d'avant mais en plusss bôooo.
En 25 ans, j'en ai vu passer des trucs à la mord moi le noeud, mais, restons zen, dans quelques mois on aura trouvé autre chose ... pas de soucis, les informaticiens de salons sont inventifs ;-)
4 janv. 2007 18:02 - Maurice
Salut Vieux retrograde, j'ai aussi un passé et bcp d'usines sont passés sous mes yeux. Il n'est pas question de mode ici. Il est question de rapprocher la MOA et les développeurs dans un process défini et compris par tous. C'est le fameux pb de production de la brouette que les anciens connaissent et qui aboutit à un tracteur. Les méthodes agiles ont l'avantage de rapprocher non seulement MOA et équipe de dev, mais aussi de créer, stimuler une cohésion d'équipe, ce qui est un des devoirs du chef de projet.

Dire que ce sont les informaticiens de salons qui créent ou inventent ces méthodes est un peu rapide. 25 ans de métier ne cautionnent pas ce que tu exprimes. mes 31 ans de métier non plus, mais je m'exprime après avoir essayé.

Concernant les différents cycles, ces méthodes ne viennent pas en concurrence ni en remplacement, elles ciblent des types de projets particuliers (mal définis au démarrage ou fluctuant, sur des tailles d'équipes relativement réduites, ...)
10 janv. 2007 08:00 - Eric
Bonjour,

Un brillant consultant de Valtech m'a conseillé la lecture du livre de Ken Schwaber le co-inventeur de Scrum dont le titre est "Agile project management with Scrum". Je vous le conseille à mon tour car il pousse bien sur plus loin l'analyse proposé dans cet article. Je l'ai pour ma part dévoré en une semaine.

Je lutte aussi effectivement pour implanter Scrum dans un univers très conservateur. Mais en apprenant à connaitre notre environnement, à nous d'adapter les principes de l'agilité aux contraintes de nos clients : la maturité des développeurs, la connaissance des outils, etc.

Peut être dans certains cas devront nous nous contenter de "faire de l'agile" sans le dire.

19 janv. 2007 11:40 - Eric Lefevre
Bonjour Eric,

"Agile project management with Scrum" n'est pas mal mais le meilleur dans le genre reste pour moi "Lean Software Development - An Agile Toolkit", de Mary & Tom Poppendieck (il y a une suite depuis quelques mois: "Lean Software Development - From Concept to Cash").
Mary Poppendieck a travaillé chez 3M qui applique vraiment des principes de type Agile à la R&D et à la production. Son retour d'expérience est assez lumineux.

Pour répondre à Vieux rétrograde: 3M, Toyota, GE, Google et d'autres sans doute aussi dans la mode du moment. Je ne pense pas que ça les empêche de continuer dans cette voie...

La discussion est maintenant close