L’ère d’une informatique de moyen s’achève et … · Lean Office. Simultanément, porté par les réseaux, le client-serveur et les interfaces graphiques, ... Le paradigme

AGILE

Scrum et au-delà

Pilotage des projets

Mise en œuvre rapide

Jean-Pierre Vickoff

« Think globally »

À la fois culture et méthode d’un monde en évolution accélérée, l’Agilité se caractérise par une recherche d’efficience appliquée au futur immédiat. Dans cette vision, les premières sociétés parvenant à s’assurer de la maîtrise opérationnelle du paradigme Agile au niveau organisationnel global gagneront la bataille des systèmes d’informations et, par-là même, la guerre économique.

« Act locally »

Désormais, le futur des systèmes d’information se trouve, d’une part, dans l’instrumentation et la personnalisation « à la carte » de pratiques essentielles aux développements dans un contexte spécifique et, d’autre part, dans un élargissement de la recherche d’agilité à tous les aspects organisationnels. L’objectif de la proposition.

Préface

L’unique personne susceptible de préfacer légitimement cet ouvrage était James Martin. Ce précurseur publia en 1991 Rapid Application Development, la première des méthodes adaptatives en rupture avec le cycle projet prédictif. Ce grand monsieur s’est malheureusement éteint en 2013 dans son île privée des Bermudes.

Sa méthode ne rencontra jamais le succès obtenu quinze années plus tard par Scrum. Ce point est certainement dû au fait qu’elle était orpheline, son auteur l’ayant immédiatement abandonnée pour se consacrer à son grand œuvre « The Meaning of the 21st Century ». Cela laissa la place libre à un simple sous-ensemble, nommé Scrum. Lequel, malgré son plagiat évident de quelques principes basiques et surtout grâce à son simplisme, s’appuya sur l’Agile Manifesto pour conquérir le petit monde des projets informatiques.

Pour ma part, l’aventure méthodologique avait commencé beaucoup plus tôt en France. Plus précisément en 1977, avec la « Préprogrammation » et l’outil SpeedCobol. Comme à cette époque, et d’ailleurs encore maintenant, rien ne pouvait émerger ailleurs qu’en Amérique du Nord, je m’étais donc installé au Canada.

Je travaillais pour Hydro Québec à Montréal lorsque débarqua le Lean Office. Simultanément, porté par les réseaux, le client-serveur et les interfaces graphiques, émergeait alors la première méthode itérative. Le couplage de ces deux mouvements, malgré le succès du projet, me coûta mon poste (une sorte de CDD renouvelable par année). Il est vrai que l’eau coulant sous les ponts et surtout dans les barrages, la nécessité de changement n’était pas vitale. En revanche en 1993, les secteurs de la téléphonie mobile et du pharmaceutique

JEAN-PIERRE VICKOFF 4 ETAT DE L’ART AGILE

faisaient connaissance avec la notion de différenciation concurrentielle du SI. En ce qui me concerne, cela se concrétisa par deux projets réussis à ajouter au crédit de l’itératif. Évidemment, je communiquais régulièrement sur le sujet dans les médias spécialisés.

En 1993, à l’occasion d’un Noël en France (le pays de Merise), je fus recruté lors de la privatisation de la SEITA (la compagnie des tabacs). Cela concernait un gros projet de développement. Il couplait toutes les nécessités de différenciation concurrentielle auxquelles je savais répondre de par mes récentes expériences (portabilité sur ardoise, interface graphique, itinérance, générateur de langage métier, système expert, etc.). Pour un test de la méthode RAD, ce fut le rêve : équipe de profil unique de type concepteur-développeur, mode plateau, mode projet, métier sur place, animateur compétent et dynamique et surtout disposant des moyens d’obtenir la « motivation rationnelle » des ressources humaines impliquées. Mes rapports de conseils sur la méthode se vendaient alors un bon millier d’euros. La plus part des grandes entreprises en firent l’acquisition. En 1996, j’acceptais d’être publié sous la forme d’un simple livre « Développement Rapide d’Application », le « MacMillan », par l’éditeur de James Martin. Les missions suivantes furent beaucoup moins enthousiasmantes et malgré le succès des projets, comme à Hydro Québec, il m’en resta un goût amer d’injustice : l’eau continuait à couler sous les ponts, même où il n’y en avait pas.

Je rédigeais et publiais donc le livre « Reengineering, Vite fait, bien fait. Le paradigme du futur immédiat ». Le tirage de 5000 exemplaires fut gracieusement expédié dans les universités, écoles d’informatique, entreprises, administrations ainsi qu’à un choix éclectique de sénateurs, de députés et même de ministres. Des retours et remerciements, je me souviens de ceux d’Alain Juppé et de Laurent Fabius qui m’avaient alors autorisé à écrire «C'est politiquement neutre et donc utilisable par tous ! »

Il fallut attendre 1999 et l’eXtrem Programming de Kent Beck pour que les choses bougent un peu. Il y avait bien eu en 1995 la présentation d’un sommaire de deux ou trois pages nommé « Scrum » par Ken Schwaber lors d’une conférence sur « l’orienté


objet », mais personne n’en avait entendu parler à l’époque. Ceux prétendant en France s’y être intéressés avant fin 2001, date de la première publication, sont des menteurs (« références requises », comme il est souvent précisé sur Wikipédia face aux bobards).

2001 ! L’odyssée de l’adaptatif commença par un changement de dénomination. Les méthodes itératives, ou s’en vantant, se qualifièrent d’ «Agiles ». Profitant de son simplisme si facilement assimilable, une méthode incomplète techniquement et douteuse organisationnellement, assassinat alors toutes les autres. Le crime se perpétra à coup de certifications aussi « bidons » que pyramidales. Actuellement nous en sommes encore là. On sait à qui profite le crime, on connaît le nom du coupable, mais l’arnaque continue.

Certains pensent que je ne crois plus à « l’Agile », c’est faux. Je pense même que les organisations n’en ont jamais eu autant besoin. Ce dont je doute, c’est de leur capacité à changer leurs structures lorsqu’elles n’y sont pas contraintes. Quant à Scrum, puisque cette « méthode » est un sous-ensemble de RAD même si ses adeptes le réfutent, il suffit d’en contrôler les errements organisationnels et de lui adjoindre quelques techniques adaptatives pour en faire un socle méthodologique acceptable. On ne va même pas l'assassiner, on va juste l'aider à devenir ce qu'elle aurait pu et du être. C’est d’ailleurs la raison de mon comeback professionnel et de la publication de ce livre. Lequel présente dans la partie « Act locally » des techniques et des formes d’utilisation indispensables à la maîtrise des vrais développements adaptatifs.

Pour conclure cette préface avec un peu de légèreté, je vous propose la lecture de « Protectora Galactica ». C’est un simple roman de vacances où parmi bien d’autres choses moins techniques, se trouvent de nombreux clins d’œil à des formes d’Agilité réellement surprenantes et parfois futuristes.

Jean-Pierre Vickoff

Jean-Pierre Vickoff est un concepteur développeur, praticien du pilotage de projets sous contraintes et expert en méthodologie du développement des systèmes d'informations stratégiques.

Dès la fin des années 1980, ses communications régulières en Amérique du Nord et en France sur l’approche incrémentale, itérative, puis adaptative – pour laquelle il développe les techniques de contrôle – le positionne comme un pionnier et un fondateur de ce courant de pensée (dont il est l’initiateur francophone) qui se qualifiera d’Agile en 2001,. Sa bibliographie officielle est sur Wikipédia et ses dernières communications sur JDN.

Bibliographie officielle sur Wikipédia www.Vickoff.com [email protected]

http://www.vickoff.com/


Préambule

« Think globally »

L’Agilité est une vision holistique du changement, une révolution de paradigme imposée par l’évolution brutale de la société.

En 2003, dans l’ouvrage Systèmes d’information et processus Agile, j’écrivais : « L’émergence d’une économie mondialisée et numérisée positionne la dimension temporelle de la performance comme le vecteur déterminant d’une recherche exacerbée de différenciation stratégique. »

Cette phrase, ainsi que bien d’autres réflexions publiées dans les livres et communications précédentes et suivantes restent toujours d’actualité. L’urgence de la comprendre fonctionnellement et opérationnellement s’est simplement accrue. Il est donc étonnant de constater que plus de vingt-cinq ans auront été nécessaires au mouvement itératif qui se nomma ensuite « Agile », parallèlement à la pression de la différenciation concurrentielle pour commencer à bousculer sérieusement la conduite de projet classique.

Dans cette recherche d’adaptation, la culture française centralisatrice et de la forme d’éducation qui en découle ne nous aide pas vraiment. Confrontée à des processus en évolution rapide, la quête de perfection propre au rationalisme cartésien aboutit désormais à la paralysie de l’action.

Dans le film culte de Denys de la Patellière, un taxi pour Tobrouk, Maurice Biraud et Charles Aznavour, en observant Lino Ventura, constataient : « Deux intellectuels assis vont moins loin qu’une brute qui marche. » Appliquée au contexte de cet ouvrage, la paraphrase est aisée. « Deux rationalistes qui planifient produisent moins qu’un


pragmatique qui développe. ». Le Nord-Américain, adepte de l’empirisme pragmatique, conclura par just do it !

L’observation des tentatives de mises en œuvre de cette formule dans la plupart des organisations porte à conclure que, décidément, le système d’information est une chose trop importante pour être exclusivement confié à des informaticiens, et que, de toute évidence l’expression « think globally, act locally » n’est pas d’origine latine.

« Act locally »

Au-delà de ces réflexions généralistes, dans les entreprises en quête « d’agilité », les vraies questions à se poser par les dirigeants devrait être :

1. « Pour quels motifs précis doit-on devenir Agile dans notre contexte ? »

2. « Quels moyens seront concrètement alloués aux nécessaires adaptations de processus, de fonctions »

3. « Quelle communication va accompagner le changement qui va être imposé, s’il n’est pas issu des demandes de la base ? »

À ce sujet, il n’est pas inutile de rappeler les débuts de l’agilité. Les méthodes actuelles sont issues des envies naturelles des équipes d’informaticiens qui souhaitaient améliorer leurs environnements organisationnel, méthodologique et technologique de travail. C’est à partir de ces réalités pratiques issues de la base, et non pas à partir d’une théorie globale ou structurante, que l’Agilité progressait jusqu’alors vers les sphères les plus hautes de l’organisation. Je ne suis pas certain que la démarche inverse permette d’obtenir les mêmes résultats. Dans tous les cas, il faudra beaucoup de finesse dans la communication pour diffuser le message et faire accepter un réel changement rarement perçu comme indispensable.


Avertissement sur le fond du problème

Ce serait une erreur pour une organisation de penser qu’elle pourrait introduire de l’Agilité dans ses projets de systèmes d’information et leur exploitation, sans commencer par remettre en question ses structures.

En clair, il n’existe que trois voies pour obtenir l’osmose du « métier » avec l’informatique de développement dans un mode réellement Agile. Tout d’abord, il faut assimiler fonctionnellement que cette recherche d’efficience implique avant tout une « spécification détaillée, conception-développement ainsi que la validation fonctionnelle » se réalisant de manière intégrée lors d’une interaction unique.

Dans ce cas,

soit les deux parties sont naturellement et géographiquement proches ;

soit le métier déporte ses représentants sur le lieu de la réalisation des projets,

soit c’est l’équipe informatique - du développement en question – qui est déplacée géographiquement au cœur du « métier ».

Avertissement sur la forme de la solution

Si l’on me pose la question : « On vous confie un projet de développement d’application. En regard de votre expérience, quelle méthode choisissez-vous ? ».

Ma réponse est évidente : « En admettant utiliser Scrum pour le pilotage du projet et la validation de la qualité fonctionnelle applicative, il est ensuite nécessaire de déterminer un framework de développement sur la base d’une partie des techniques de eXtreme Programming pour la qualité technique. Mais cela ne sera pas suffisant pour couvrir l’organisation et la production du « sprint zéro » (les étapes de préparation préalables à tout projet Scrum). Pour ce faire, j’utilise les techniques de structuration des besoins proposés par Puma dans le cadre de son moteur de communication.


Pour compléter cet ensemble, dans une structuration logique du fameux « Sprint zéro », je mettrais en œuvre les trois premières phases détaillées par la méthode RAD (Initiation, Cadrage, Design). Ainsi, je disposerai d’un canevas cohérent incluant le choix des acteurs et la variabilité de leurs engagements, la justification financière de mon action, un cadre prévisionnel de contrôle de la « boîte de temps » allouée. »

Avec ces outils, je pourrai aussi prendre en considération les divers impacts organisationnels ou d’architecture ainsi que la modélisation Agile minimum, mais indispensable à tout développement de SI.

Cette vision d’ensemble est d’ailleurs le type d’intégration proposée par PUMA. Encore faut-il le savoir et en maîtriser les connaissances sous-jacentes. Cette réponse est la principale raison de la présence dans cet ouvrage d’un rappel succinct de ce qu’étaient et reste les techniques et préconisations de la méthode RAD.

Parmi les autres points de friction, on retrouve régulièrement les idées fréquemment colportées que le métier « ne saurait pas ce dont il a besoin » et que de toute façon « il n’aurait pas le temps de le préciser ». Ces vieux démons ont la vie dure. Pour les combattre sans vouloir réellement les tuer, les dirigeants ont recours à des maîtrises d’ouvrage déléguées ou des assistances à maîtrise d’ouvrage. Du point de vue Agile, cela ne change rien au problème d’efficience, même si cela le dissimule un peu. C’est une doctrine Agile : la MOA doit être DU métier, pas DE métier.

Un autre problème majeur posé par l’adoption de l’Agilité dans les grandes entreprises, se situe dans la structure même de leur organisation. Elles sont habituellement issues d’un passé informatique très proche, lorsque ce n’est pas toujours la réalité d’un présent consacrant une rupture dans la localisation des métiers et celle de l’informatique.

Cette situation représente l’héritage direct de la vision passéiste des développements de SI organisés en projets suivant le mode « cascade ». C’est-à-dire séparant la production d’un document obtenue dans une première phase, du développement global


envisagé dans une phase suivante (souvent dans un autre lieu avec d’autres personnes). Les exigences des projets actuels ont rendu cette vision basée sur la documentation obsolète et dangereuse.

Autre point majeur, dans une entreprise, quelle que soit sa taille, lorsque le siège regroupe physiquement les deux entités informatique et métiers, l’adoption de l’Agile n’est généralement pas un problème sous peu que les partenaires s’engagent dans cette voie de la performance par la communication.

En revanche, si métiers et informatique sont géographiquement distants, il est évident que les technologies actuelles de communication tentant de réduire cette fracture ne correspondent malheureusement pas encore aux exigences du pilotage des projets « Agiles ». À défaut de pouvoir obtenir le regroupement global d’entités gigantesques, il faut alors décentraliser la fonction informatique au cœur du métier. Et ce, pour chaque métier. Autant le dire tout de suite, ce genre de restructuration n’est ni si simple ni indolore.

Pour en revenir au « think globally, act locally », c’est dans ce principe que j’ai organisé ce document en deux parties.

Dans la première partie, « penser globalement », j’ai réveillé les espoirs et les réalités qui ont bercé et bercent toujours le monde Agile depuis ses débuts. Certains textes recyclés semblent intemporels et demeurent les meilleurs vecteurs de compréhension de ce qu’il faudrait enfin faire.

Dans la deuxième partie, mon côté pragmatique a repris le dessus et après un survol de l’origine des méthodes et techniques actuelles (il est toujours utile d’observer le passé afin d’éviter d’en reproduire les erreurs), j’en ai détaillé le contenu pratique pour ensuite vous proposer leur évolution indispensable à travers le Processus Urbanisant les Méthodes Agiles PUMA.

Organisation de l’ouvrage

Préambule 7

Vous avez dit Agile ? 14

Échecs et méthodes 16

Le stratégique en péril 16

Les causes de rejet de l’Agilité 17

Conditions d’échec 18

Quels projets pour Agile ? 19

Les enjeux du processus Agile 20

RAD première méthode Agile publiée 24

Survol de la méthode 24

1999 : le framework XP 28

2001 : Scrum 28

Méthode Agile 30

Origine du qualificatif Agile 30

Valeurs et Principes Agiles 31

Mise en œuvre : précision avertissement 35

Fondement du paradigme 38

Pratiques communes aux méthodes Agiles 41

Itératif, incrémental et adaptatif 42

Les outils du pilotage Agile contrôlé 46

Scrum méthode basique 54

Une méthode essentiellement incrémentale 55

Les Rôles 56

Les Évènements (rituel, cérémonial) 59

Les artéfacts 62


Scrum et réalité d’entreprise 64

Plongeon dans une méthode simplette 64

L'analyse élémentaire de trois problèmes 66

1 – Les récits utilisateurs rédigés par les informaticiens 67

2 – L’estimation de charges en points de complexité relative 68

3 – La disparition des chefs de projets 69

Scrum, le fond des problèmes 72

Le meilleur des mondes ? 75

PUMA Essentiel 77

PUMA Essentiel en pratique 80

Environnement de collaboration avancée 85

Estimation Agile 88

Organisation Agile et ressources humaines 99

Point sur l’ état de l’art Agile 2016 103


Vous avez dit Agile ?

« Ce n’est pas la technique qui représente le vrai danger pour la civilisation, c’est l’inertie des structures. » Louis Armand, Plaidoyer pour l’avenir (ça ne date pas d’hier…).

La nécessaire évolution des méthodes

L'informatique évolue et les applications se sophistiquent (nomadisme) autant que leur typologie se diversifie (orientation services au client final, (le fameux end-user)). L'échec de projet devient une hantise justifiée par les statistiques des autres autant que par ses propres expériences fâcheuses.

Dans un registre plus fonctionnel et économique, la recherche permanente de qualité nécessite que la différenciation concurrentielle soit au cœur des préoccupations de l'organisation. La finesse et la complexité des nouveaux besoins impliquent alors l'engagement d'un utilisateur averti et motivé autant que responsable et demandeur (du métier, pas de métier). Pour répondre à ces exigences accrues de services, l'informaticien constate alors la nécessité de s'impliquer dans une ré-ingénierie de la fonction développement et comprend qu'il lui faut disposer d'un nouveau cadre méthodologique puissant mais ouvert, offrant la capacité :

de s'adapter à la typologie des applications ;

de se dimensionner en fonction des contraintes (budget, délai, qualité, visibilité) ;

prenant en compte la dimension « communication interpersonnelle ».


Pour résumer, il faut bénéficier de la souplesse d’une méthode adaptative disposant de technique « à la carte » et assurant la maîtrise d'un accompagnement fiable du pilotage de sa mise en œuvre (reporting visuel, mural et en temps réel).

Ainsi se déclinent les conditions actuelles de la réussite du développement d'applications. La réponse la plus pertinente actuellement consiste en la mise en œuvre des concepts Agiles.

Une méthode Agile ne permet pas miraculeusement de développer plus vite. Pas plus qu'un Grand Prix ne se gagne par hasard. La réussite d’un projet en mode Agile, comme une compétition de hautes technologies, nécessite :

une volonté d'investir,

de l'organisation,

des moyens techniques à l’optimal,

le sens du risque calculé,

un personnel spécialisé, formé, entraîné et motivé.

Alors ensuite, et seulement ensuite, vous obtenez la performance, la réussite et un retour sur investissement exceptionnel :

une application totalement approuvée répondant aux besoins des utilisateurs ;

la sécurité d'une visibilité qualitative et quantitative de l'avancement des travaux ;

la livraison rapide des fonctionnalités stratégiques ;

des coûts de développement permettant un retour sur investissement concret.

Dans cette optique, la méthode PUMA représente l'état de l'art en matière de qualité des procédés de développement d'applications informatiques. Elle intègre votre savoir-faire actuel (qui peut-être Scrum, XP, etc.) et reste ouverte sur les évolutions futures que la profession finira bien par réclamer et obtenir.


Échecs et méthodes

« Il faut se montrer génial pour traiter simplement des problèmes complexes. »

Le stratégique en péri l

Les développements informatiques constituent désormais l’activité humaine la plus récente, la plus complexe et le facteur de progrès le plus important qui conditionne la croissance, la mutation et la survie de la plupart des secteurs de l’économie moderne. Insatiable, incontournable, l’informatique s’est donc imposée comme outil stratégique aux chefs d’entreprise, mais la plupart ignorent que de nombreux projets dérivent ou ne satisfont pas les utilisateurs et que beaucoup sont abandonnés avant leur mise en exploitation.

Ce gouffre économique est la conséquence directe du manque de concertation entre informaticiens et utilisateurs, de l’inadaptation des méthodes à l’évolution technologique et de la durée excessive des projets.

Cet état de fait est édifiant mais non surprenant. Une pratique de quelques décennies de conception, de réalisation et de pilotage de projet à titre de consultant permet d’acquérir une large vision du sujet. Durant toutes ces années, aucune des organisations visitées ne disposait d’un processus vraiment Agile pour guider ses développements. Au mieux, une approche de modélisation simplifiée ou une méthodologie de conduite de projet proposait quelques grandes lignes directrices.

Certains se contentent de coller l’étiquette « Agile » sur leurs habitudes et feignent d’être surpris de ne pas obtenir ensuite les


résultats escomptés. Beaucoup d’autres refusent cette évolution malgré les échecs répétitifs de leurs certitudes. Mettre en œuvre Agile requiert donc courage et motivation ou bien restriction budgétaire et obligation de résultat.

Les causes de rejet de l’Agilité

Pour faire accepter les contraintes de l’approche Agile, il faut, en regard des chiffres et de l’inertie des professionnels, une prise de conscience de l’enjeu par les dirigeants. Au plus haut niveau des organisations, la direction doit comprendre que personne du côté informatique ne sort immédiatement gagnant d’un passage à une méthode Agile :

Le chef de projet y perd en autorité. Il lui est nécessaire de s’impliquer comme membre à part entière d’une équipe qui se rétrécit.

Les analystes et les programmeurs formés à l’ancienne rechignent à la reconversion. Ces deux métiers fusionnent dans un seul profil : le concepteur-développeur.

Les sociétés de services redoutent la réduction des budgets et les exigences d’une performance accrue.

Le directeur informatique est en première ligne, face aux réticences de la plupart des intervenants devant le changement qui les bouscule dans leurs habitudes.

Mettre en œuvre Agile requiert courage et motivation ou restriction budgétaire et obligation de résultat. Le processus doit être initié conjointement par les directions métiers et la direction informatique, sous l’égide d’un « facilitateur » neutre, qu’il se nomme « animateur » ou « Scrum Master », il devra répondre à la direction générale.


Conditions d’échec

Dans une situation où l’équipe projet est supposée faire « de l’Agile », mais où le pouvoir intermédiaire en place se refuse à accepter les contraintes de la méthode, la marge de manœuvre est très faible. Cela arrive en moyenne une fois sur deux. Si, au début d’un projet, devant le refus de formation et d’adaptation vous criez immédiatement « au feu ! » personne ne vous croit : vous êtes externe à l’organisation et personne ne voit ni feu ni fumée. Il est donc nécessaire de laisser la situation pourrir. Cela représente des coûts et une perte de temps, mais, à moins d’être suicidaire ou particulièrement engagé, il n’y a en général pas d’autre choix.

Laisser le problème se développer ne signifie pas non-intervention. Au contraire, il faut régulièrement informer par écrit des écarts à la méthode et des risques en découlant. Il faut ensuite attendre le point où la situation est suffisamment dégradée pour qu’il soit évident que les moyens employés ne sont pas adéquats. Une analyse documentée de la situation suivie d’une synthèse doit alors démontrer point par point que le respect de la méthode permet la résolution du problème. Une analyse plus critique peut alors suivre.

Cette étape ne présente pourtant aucun intérêt à partir du moment où tous les intervenants, ayant compris le problème, sont prêts à jouer le jeu Agile pour redresser la situation. À ce point vous venez de clôturer une crise grave. Le projet s’oriente définitivement vers les techniques Agiles, ou alors il vous faut partir. Le coup de barre doit être total. Il n’est plus question d’accepter les compromis, sinon, attendez-vous à être considéré comme définitivement responsable de l’échec qui en résultera.

Dans un contexte économique qui se radicalise, l’informatique est devenue l’outil de la compétitivité. La réussite des projets est désormais vitale. Le principe d’une amélioration drastique des processus de développement finira donc par être accepté. Espérons que le réveil ne sera pas trop difficile pour certains et trop tardif pour les autres.


En résumé, un échec de projet ou une dérive est moins l’échec des hommes que l’échec de l’organisation qui n’a pas su les diriger et les contrôler. Le retard de projet ou la non-conformité du projet est donc imputable avant tout à l’organisation. C’est l’échec des dirigeants à travers leurs actions ou leurs inactions.

Note : Lorsque, et c’est souvent le cas, les hommes sont changés sans qu’aucun correctif ne soit apporté à l’organisation, il y a peu de chances que la deuxième tentative soit plus satisfaisante, bien qu’elle puisse en général s’appuyer sur les leçons de la première.

Quels projets pour Agile ?

Certaines questions reviennent régulièrement en conférence. Elles portent souvent sur la typologie de projet la plus propice à une méthode Agile. En fait, il n’y a pas de projet type pour Agile. Il y a juste des organisations plus ou moins aptes à accepter les contraintes de l’Agile, pour ensuite pouvoir en apprécier les bénéfices. Il est possible d’appliquer Agile sur un projet de dix ou quinze jours de charges, comme sur un projet de trente années ou plus. Néanmoins, au-dessous d’un certain seuil de quelques dizaines de jours, seule une organisation disposant déjà de l’expertise et de l’environnement de travail Agile peut obtenir des bénéfices immédiats avec cette méthode.

Le premier projet Agile n’est pas en général le plus économique, compte tenu des investissements de tous ordres nécessaires pour créer un milieu propice à la performance Agile. Pour conclure comme M. de La Palisse, c’est de l’incapacité de l’organisation à appliquer Agile que découle l’impossibilité de réaliser un projet en Agile.


Prenons pour exemple pratique et réel une étude préalable. Elle démontrait qu’un projet classique évalué à 290 mois homme pouvait être réalisé en 140 mois homme si l’on adoptait une démarche Agile :

La planification classique démarrait avec deux analystes. Après six mois, huit analystes-programmeurs devaient intervenir et l’équipe devait encore augmenter par la suite pour atteindre douze personnes durant la phase de réalisation.

La planification Agile se basait sur l’engagement immédiat et constant d’une équipe de cinq concepteurs-développeurs.

Comme aucun budget de projet n’avait été officiellement alloué, il était plus facile de commencer avec la solution classique. Et il me fut dit : puisque nous n’avons pas les moyens de faire de l’Agile, il faut employer la méthode classique. Je pleure avec vous, gestionnaires.

Les enjeux du processus Agile

Parfois, la réussite d’un projet informatique se matérialise par :

une application totalement approuvée répondant aux besoins des utilisateurs ;

la livraison rapide des fonctionnalités stratégiques ;

des coûts de développement permettant un retour sur investissement concret ;

la sécurité d’une visibilité qualitative et quantitative de l’avancement des travaux.

Pour un professionnel de l’informatique, il n’y a pas de miracle ni de circonstance, seulement des techniques de réduction du risque : dimension temporelle, validation permanente, reporting mural temps réels, métriques des modifications, présentation régulière et rétrospectives de processus. En clair : la mise en œuvre basique de l’agilité, rien de plus.


Au sujet de la rupture entre l’expression du besoin et le développement, il a été constaté que les méthodes de conduite de projet dites classiques, c’est-à-dire basées sur la validation de documents rédigés par des « uns » puis confiés à des « autres », mènent désormais le plus souvent à un échec dans les projets conséquents ou complexes.

Les différences fondamentales entre une conduite de projet classique et une conduite de projet Agile sont les suivantes :

La structuration des phases est différente. C’est particulièrement évident pour la réalisation qui applique les techniques du prototypage et impose une spécification détaillée directement exprimée en termes de code sous la dictée de « l’homme du métier ».

La dimension temporelle est différente, les projets se planifient en boîte de temps d’environ dix jours travaillés.

Les intervenants sont différents. Un profil unique de concepteur-développeur hautement compétent et motivé s’avère indispensable. Les équipes rétrécissent, et le statut de « chef de projet » laisse place, selon Scrum à l’auto gestion de l’équipe. D’autres méthodes tout aussi agiles acceptent une fonction de coordination assumée généralement par un des membres de l’équipe projet ou même une responsabilité de pilotage dans la mesure où son autorité est validée par l’acceptation consensuelle de l’équipe (PUMA par exemple).

L’engagement des utilisateurs est stable et permanent. Il est à la base du principe de « validation permanente » et de « présentation » de l’application qui garantissent visibilité et qualité.


Sur le plan des communications

À toutes les phases du développement, sont introduites la spécialisation et la gestion des relations interpersonnelles. Le classique chef de projet fait place à un binôme composé d’un coordonnateur fonctionnel issu de la maîtrise d’ouvrage qui impose la dynamique applicative et d’un coordonnateur technique représentant la maîtrise d’œuvre qui intègre la dimension technologique. Les rapports entre les partenaires du développement se simplifient et se formalisent.

Agile implique alors un troisième acteur (animateur) dont la mission est d’obtenir un consensus et une expression formelle des besoins par la maîtrise des techniques d’entretien, de prévision et de gestion des conflits. Des auxiliaires réalisent en direct la modélisation de l’application et sa validation lors de travaux de groupe organisés dans un espace de communication dédié (atelier de génie logiciel sur micros, moyens électroniques de rétroprojection, etc.).

Dans le domaine des ressources humaines

Le prototypage déporte les spécifications détaillées dans la phase de réalisation. Les compétences de conception détaillées et de réalisation fusionnent. En parallèle, la pluralité technologique requiert une spécialisation accrue de l’équipe de projet. C’est le principe de l’équipe Agile (TEAM) ou de l’ancien SWAT (Skilled With Advanced Tools) l’équipe de la première des méthodes Agiles, le RAD.

Les équipes Agiles sont composées de spécialistes-généralistes, experts sur des techniques ou outils précis et nécessairement généralistes sur les autres. La coordination harmonieuse de ces profils à travers un contrat de projet initie une dynamique de groupe basée sur la gestion de la complémentarité. Cette synergie favorise le sens de l’identité de l’équipe, le partage de l’information et la notion d’entraide.


En termes de méthodologie

Jusqu'à maintenant, les méthodes se distinguaient par leur approche monolithique des problèmes. On décomposait la structure (top-down) ou l'on élaborait à partir des besoins (bottom-up). Une méthode de conduite de l'évolution de type « Agile » réconcilie les deux tendances. La systémique s'applique à la conception haute et le prototypage de réalisation à la spécification détaillée.

Une approche exclusivement par les besoins (bottom-up) a l’avantage d’offrir une réponse immédiate à un utilisateur confronté à de multiples problèmes qui souvent le débordent. L’organisation travaille au coup par coup sans disposer de recul pour élaborer un projet guide. Il en résulte le plus souvent, outre le gaspillage de ressources, une multiplicité d’applications partiellement redondantes sans intégrité référentielle. L’aboutissement est en général la perte de contrôle du système d’information ou le déploiement d’efforts démesurés pour maintenir un semblant de cohérence.

Agile est un phénomène récent, à la fois cadre méthodologique, méthode de conduite de projet, outil de communication, technique de qualité et parfois choix de modélisation. Opportuniste et prudent, Agile s’appuie d’abord sur une approche systémique (top-down) dans la première partie de sa mise en œuvre.

La partie principale : la construction de l’application en incrément dans des boîtes de temps s’appuie exclusivement sur le développement du prototype applicatif. À travers diverses techniques, le développeur plonge alors au cœur des besoins pour construire une application répondant à tous les critères de qualité et de conformité fonctionnelle. Et ce, jusque dans le moindre détail des attentes d’un utilisateur final et d’un responsable du métier participants actifs de la spécification depuis le début du projet.

Le pragmatisme des méthodes Agiles consacre de fait la rupture entre la lenteur des cycles traditionnels et le dynamisme de la recherche d’une réponse optimale à des besoins en évolution.


RAD première méthode Agile

publiée

« Composer avec une méthode entraîne un risque sérieux d’échec » Jean-Marc Berlioux.

Survol de la méthode

La méthode RAD est la première des méthodes Agiles publiées. La méthode RAD était parfaitement itérative et adaptative comme eXtrem Programming. Ce qui n’était pas, et n’est toujours pas le cas de Scrum. Cette méthode concrétisait et formalisait la rupture des approches incrémentales et itératives avec le cycle en V.

La méthode RAD couvrait totalement le scope de Scrum, une partie de celui de XP ainsi que de plusieurs autres techniques qui font actuellement défaut aux frameworks Agiles actuels.

La structure d’un projet RAD se caractérisait par quatre groupes de préoccupations correspondant à des nécessités toujours bien réelles :

Initialisation : La présence d’un animateur-facilitateur responsable d’une charte projet acceptée par tous les intervenants.

Cadrage : L’intervention régulière d’un utilisateur qui valide en permanence la pertinence des besoins exprimés.


Design : Une forme élémentaire d’expression des exigences obtenue en travail de groupe dont découlera, si nécessaire, une modélisation simplifiée et une architecture.

Figure 1. — Méthode RAD

Construction : Un développement du produit piloté par un affichage mural et réalisé selon des règles d’ingénierie applicatives structurées (mais non extrêmes) incluant les concepts de qualité du code et de validation permanente des fonctionnalités. Ceci représentait l’équivalent des préalables aux sprints 0 de Scrum. La CONSTRUCTION privilégiait la définition détaillée des besoins parallèlement à leur codage. Ceci représentait la partie des sprints de 1 à n de Scrum. Cette homogénéité constitue, avec la prise de décision immédiate et la validation continue, les bases mêmes de la productivité et de la qualité Agile.

Le projet RAD s’achevait après une recette et généralement un site pilote, par un « cutover » où certains membres de l’équipe (généralement là pour cela), prenaient en charge les maintenances correctives et évolutives.


Figure 2. — Quatre variables de planification et d'ajustement

L’évolution représentée par RAD2 s’exprimait dans un processus qualité détaillé formalisant étape après étape la conduite de projet RAD. Cette formalisation couvrait les aspects :

diagnostic de l’organisation et du domaine,

mode opératoire des communications,

assurance qualité de la conception et de la réalisation,

techniques de modélisation adaptative,

construction itérative incrémentale adaptative,

techniques structurées de qualité du logiciel.

De plus, ce n’était pas seulement le périmètre applicatif qui pouvait servir de variable d’ajustement, mais la modulation de 4 facteurs distincts permettant une planification stratégique fine adaptée aux exigences du projet et de l’application envisagés (Figure 2).

Actuellement, la méthode RAD avec son minimum de formalisation des besoins et ses techniques de génie logiciel structurées mais non extrêmes, reste toujours une voie adaptée aux développements raisonnablement maîtrisés.


Figure 3. — Méthode RAD (Construction)

La phase de Construction du RAD était identique à XP dans son principe, mais moins eXtrême dans la mise en œuvre de techniques de qualité du code. Si les tests systématiques et l’intégration continue étaient exigés, la programmation en binôme par exemple n’était pas imposée sauf pour les parties « sensibles » ou complexes de l’application. C’est d’ailleurs cette similitude qui m’a autorisé à publier dès 2001 sous le titre de RAD Construction Agile et XP « Portant la programmation au rang d'une discipline collective, l'eXtrem Programming propose un ensemble cohérent de techniques apportant des solutions à la grande majorité des problèmes de performance et de qualité en matière de développement d’application. XP peut donc enrichir ou se substituer à la phase Construction (figure 3) de la méthode RAD ».


1999 : le framework XP

En octobre 1999 Kent Beck et Ron Jeffrie, qui travaillaient sur un projet de refonte de la paie de Chrysler, officialisèrent la méthode eXtrem Programming. XP formalise les douze (ou 13, selon la distinction des types de tests) pratiques d’ingénierie du logiciel qui poussées à l’extrême permettent l’obtention d’un code particulièrement propre, efficient et maintenable. Comme RAD, XP est incrémental et itératif.

2001 : Scrum

En mars 2001 survint l’Agile Manifesto, une réunion où le mot « Agile » a été employé pour la première fois en qualificatif du tronc commun d’une dizaine de méthodes désormais pratiquement disparues, car écrasées par le simplisme de Scrum.

Ce n’est qu’en novembre 2001, donc six mois après, que Ken Schwaber faisant équipe avec Mike Beedle décrivait la demi-douzaine de techniques impliquées dans le livre Agile Software Development With Scrum. Techniques très incomplètes et d’ailleurs intégralement empruntées aux autres méthodes. Cela n’empêcha absolument pas le succès commercial qu’on reconnaît aujourd’hui à Scrum, bien au contraire.

Techniquement, Scrum reprend un sous-ensemble des pratiques de la méthode RAD (le pilotage des incréments) qu’elle intègre dans un cérémonial convivial et très porteur.

En revanche, Scrum ne précise pas les formes d’expressions ou de modélisation des exigences complexes, fait abstraction des techniques de développement et surtout se limite à un pilotage du projet par incrément sans permettre de gérer les aspects réellement adaptatifs (modifications importantes détectées en cours de sprints, à l’exception depuis 2010 de détails mineurs).

https://fr.wikipedia.org/wiki/2001


Pour aller plus loin dans l’adaptatif, vu qu’aucune métrique des modifications en cours de projet n’est proposée, il faut donc se baser uniquement sur la bonne volonté des hommes d’accepter la variabilité du périmètre comme moyen d’ajustement des dérives quelles qu’en soient les causes.

Note : Je vous rappelle que pour tout procès ensuite, votre avocat peut compter sur moi pour éclaircir la situation et ses causes.


Méthode Agile

« La chose la plus importante en communication, c’est d’entendre ce qui n’est pas dit » Peter Drucker

Origine du qualificatif Agile

L’Agile Manifesto

En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour débattre des éléments communs de leurs méthodes respectives. De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du développement Agile et de ses principes sous-jacents. Le Manifeste Agile est constitué de 4 valeurs et de 12 principes fondateurs (traités infra).

Le Manifeste Agile débute par la déclaration suivante : « Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes. »

Les méthodes Agiles sont donc des groupes de pratiques de pilotage et de réalisation de projets. Initialement destinées au développement en informatique (conception de logiciel), leur champ d'application s'élargit régulièrement. Les méthodes Agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle du client en priorité aux termes d'un contrat de développement. Les méthodes Agiles reposent sur une structure (cycle de


développement) itérative, incrémentale et, plus récemment, adaptative. Elles doivent respecter quatre valeurs fondamentales déclinées en douze principes desquels découlent une base de pratiques, soit communes, soit complémentaires.

Les méthodes qualifiées d'Agiles depuis la publication de l'Agile Manifesto sont en premier lieu la méthode RAD (Développement rapide d'applications) (1991) et DSDM sa version anglaise (1995). Suivirent plusieurs autres méthodes comme ASD ou FDD qui reconnaissent leur parenté directe avec RAD. Les deux méthodes Agiles désormais les plus utilisées sont : la méthode Scrum qui fut présentée sous la forme d’un sommaire en 1995 par Ken Schwaber, puis publiée en 2001 par lui-même et Mike Beedle pour enfin être diffusée mondialement par Jeff Sutherland ainsi que la méthode XP Extreme programming publiée en 1999 par Kent Beck.

Valeurs et Principes Agiles

Les quatre valeurs fondamentales Agiles déclaraient privilégier :

L’interaction entre acteurs plutôt que les processus et les outils.

Un produit opérationnel plutôt qu’une documentation pléthorique.

La collaboration avec le client plutôt que la négociation de contrat.

La réactivité face au changement plutôt que le suivi d'un plan.

Les douze principes fondamentaux Agiles étaient déclarés être :

Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.

Le changement est accepté, même tardivement dans le développement. Les processus Agiles exploitent le changement comme avantage compétitif pour le client.

Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.


Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet.

Bâtissez le projet autour de personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.

La méthode la plus efficace de transmettre l'information est une conversation en face à face.

Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.

Les processus Agiles préconisent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.

Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.

La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.

Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.

À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

C’est à partir de la mise en œuvre de ces réalités pratiques, et non sur la base d’une théorie globale ou structurante, que l’Agilité progresse vers les sphères les plus hautes de l’organisation. La figure 4, issue du « survey » annuel de Version One offre une bonne vision des avantages obtenus par la mise en œuvre d’une approche de ce type.

Comme le faisait remarquer à juste titre Emmanuel Etasse sur son blog « Le manifeste Agile ne propose aucune solution toute faite, pas de processus, pas d'outils non plus... vous y trouverez tout simplement des VALEURS. L'histoire des constructeurs automobiles américains copiant en vain les procédés de Toyota (approche Lean) montre que les richesses d'une entreprise sont parfois invisibles, trop


subtiles pour être photographiées. Une culture, un état d'esprit, ça prend un certain temps pour se construire. Aussi, n'attendez pas des résultats immédiats, mais préparez-vous à investir aujourd'hui pour demain. Beaucoup de courants de pensée (en dehors du développement logiciel) alliant performance, humanisme et écologie m’incitent à croire que la complexité grandissante de notre monde nous condamne à nous remettre en question un peu plus chaque jour. »

Figure 4. — Avantages obtenus par l'organisation Agile

À ce sujet, les avantages recherchés et obtenus sont pourtant flagrants comme année après année les sondages de plus en plus populaires et significatifs le démontrent.

Ce constat de réussite est d’autant plus étonnant que le plus souvent, les organisations ne se donnent pas la peine de mettre réellement en œuvre les techniques Agiles les plus efficaces mais souvent techniquement difficiles à maîtriser, et se limitent même parfois à organiser de simple réunions le matin (figure 5).


Si les méthodes Agiles paraissent révolutionnaires, il ne s’agit de rien d’autre que de la formulation de principes issus du bon sens et de l’expérience acquise par la pratique de développeurs et de chefs de projets chevronnés durant les années précédant l’Agile Manifesto.

Cette pertinence issue du terrain devrait rassurer, mais cependant, les sondages mettent en évidence la persistance de doutes techniques (en revanche, c’est la dimension sociologique sous-jacente et la remise en question de l’organisation hiérarchique du travail qui freinent actuellement leur adoption).

Figure 5. — Principales techniques réellement utilisées

Les difficultés (figure 6) rencontrées lors de la mise en œuvre de l’agilité sont toujours le reflet de l’incapacité de l’organisation à accepter de résoudre ses conflits internes.

Le degré de refus étant souvent variable et pouvant se situer de la simple réaction temporaire à un changement mineur au rejet brutal d’un changement considéré comme culturellement inacceptable.

Le temps du changement est une période délicate où l’Agilité devient alors « l’Art du possible ».


Figure 6. — Principaux freins et causes d'échec

Mise en œuvre : précision avertissement

L’Agilité représente souvent, en regard d’un processus lourd, un ensemble de raccourcis méthodologiques dont la caractéristique est une prise de risque, nécessitant pour être rationnellement maîtrisée, un haut niveau de compétence des intervenants.

L’imprécision et le changement sont inquiétants pour un gestionnaire, mais ils sont inhérents aux activités complexes, donc au développement applicatif. Ces situations « floues » sont gérables, mais requièrent contrôle et adaptabilité mesurée.

La planification Agile dont la responsabilité incombe au « client » (le Product owner de la méthode Scrum) ne se limite pas à organiser la production d’un simple incrément de valeur ajoutée mais se focalise sur la recherche du plus important retour sur investissement possible, en l’instant.

La liste de l’ensemble des exigences à produire (Backlog) est affichée de manière visible de tous sur un affichage mural. Chaque exigence


est priorisée par le client et estimée en termes de charges et de risques par l’équipe de développement. Les exigences sont reconsidérées systématiquement en cours de développement car elles sont susceptibles d’être altérées par la réalité de l’évolution des besoins.

Le monitoring et le reporting Agiles (ou suivi), s’effectuent sur des exigences livrées et non sur des tâches en cours. Comme pour l’ensemble des pratiques Agiles, le monitoring et le reporting Agiles ne sont pas l’affaire d’un chef de projet ou d’une ressource dédiée, mais de la responsabilité de toute l’équipe (SWAT). Le monitoring est réalisé en temps réel par chaque personne impliquée dans une action. L’ensemble des indicateurs du reporting est visible par tous sur un « Radiateur d’informations » (Information radiator) sur les murs de la pièce consacrée au projet.

Si, en théorie, il ne devrait pas y avoir de chef dans un projet Scrum, nous savons tous que les dirigeants des grandes organisations et, souvent aussi des plus petites, exigent d’avoir un interlocuteur privilégié (et surtout responsable). Deux manières d’aborder le sujet sont envisageables :

Soit tous les membres de l’équipe sont des concepteurs développeurs et c’est un choix de l’équipe de confier cette mission à l’un de ses membres le plus à même de la représenter ou d’organiser une rotation.

Soit il a été mandaté pour cette tâche un gestionnaire de projet ne participant pas au développement, donc coupé de ses réalités et souvent de ses techniques réelles. Dans ce cas, celui-ci ne devra pas intervenir dans les choix de l’équipe, qu’ils soient techniques ou autres.

C’est cela l’Agilité en développement applicatif. Si une organisation ne veut pas respecter ce principe qu’elle ne se targue pas d’être Agile et ne s’étonne pas ensuite en cas de déception.

Pour résumer, l’Agilité, c’est de l’intelligence organisationnelle et technologique, que l’on couple à de l’énergie collective, afin d’obtenir de l’efficience au futur immédiat.


L’Agilité, c’est la « glasnost » et la « perestroïka » du management de projet.

En revanche, de même que les différents courants de l’Objet se sont fusionnés pour offrir le standard UM, il aurait été vraiment raisonnable que les méthodes Agiles s’intègrent sans pour autant perdre la diversité de leurs préoccupations et la complémentarité de leurs pratiques. Je pense que c’est malheureusement trop tard maintenant. Il nous reste juste à espérer qu’une nouvelle méthode (une vraie cette fois) nous débarrasse définitivement de Scrum.

En 2005, toujours aux USA, un certain nombre d’acteurs signifiants du monde Agile ont signé une « Déclaration d’interdépendance » qui se résume à six concepts : valeur, incertitude, client, individu, équipe, contexte. Comme ce n’est pas connu de tout le monde, je vais en faire une synthèse :

Il ne peut être créé de valeur sans la collaboration d'un client pouvant définir précisément ce qui est représentatif de sa notion de valeur à un moment déterminé.

La performance d’une équipe est directement fonction de la motivation rationnelle de ses membres dont l’appréciation et la récompense doivent respecter le niveau de leur contribution.

L’incertitude et le risque ne se maîtrisent qu’en fonction de la compréhension de la spécificité de chaque contexte.


Fondement du paradigme

Au-delà des quatre valeurs et des douze principes préalablement présentés, les méthodes Agiles prônent quatre aspects fondamentaux (entre parenthèses, les citations du manifeste) :

L'équipe (« Les individus et leurs interactions, plus que les processus et les outils ») : dans l'optique Agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique, composée de développeurs (éventuellement à niveaux variables), plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale.

L'application (« Des logiciels opérationnels, plus qu'une documentation exhaustive ») : il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).

La collaboration (« La collaboration avec les clients, plus que la négociation contractuelle ») : le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un compte rendu continu sur l'adéquation du logiciel avec ses attentes.


L'acceptation du changement (« L'adaptation au changement, plus que le suivi d'un plan ») : la planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières livraisons du logiciel vont souvent provoquer des demandes d'évolution.

Une fois ces principes acquis, il est nécessaire de mettre en œuvre des techniques opérationnelles.

La première des méthodes Agiles, le RAD, depuis ses débuts en 1991, préconise la formation d'une équipe de développement particulière. Ce concept fut ensuite repris par l’ensemble des méthodes agiles suivantes.

Cette équipe est autonome, spécialement formée, concrètement motivée et parfaitement outillée. Elle se compose essentiellement d'un profil unique de concepteurs-développeurs formés à des spécialités techniques complémentaires.

L'équipe travaille « en direct » avec les utilisateurs et généralement un animateur dans une salle spéciale, isolée, spécialement équipée dans le style « plateau projet », où les murs sont utilisés pour afficher un « radiateur d'information » (une forme de cockpit de management de projet). Cette organisation et ces techniques sont devenues communes à l'ensemble des méthodes Agiles.

Parmi les techniques caractéristiques de la conduite de projet Agile apparues plus récemment, on trouve l'expression des exigences formalisée de préférence en « récits utilisateur » et son évaluation consensuelle par l'équipe dans le cadre d'un jeu sérieux intitulé planning poker qui estime la charge à produire dans une unité de valeur pouvant être soit des « journées idéales » soit des « points de récit ».

Les récits utilisateurs doivent ensuite subirent une translation de forme (en exigences) d’un niveau suffisamment détaillé et technique pour être utile aux développeurs.


Toutes les méthodes Agiles utilisent un mode opératoire similaire, voire identique :

Un responsable fonctionnel définit et ordonne la production des composants de l'application.

Le projet est structuré en incréments de une à six semaines suivant les nécessités (taille, réactivité, visibilité...).

Une réunion initiale organise chaque incrément en définissant les tâches à réaliser.

L’équipe pilote la qualité et la performance du projet de manière consensuelle.

Chaque jour, une courte réunion d'avancement donne à l'équipe une vision globale du projet, met en évidence les éventuels problèmes et permet de factoriser les solutions.

Un 'reporting' mural (Kanban, graphes de progression, etc.) est mis à jour en temps réel par les membres de l'équipe.

Un incrément achevé contient une livraison complète, développée, approuvée et testée.

Une réunion finale présente l'application et est suivie d'une rétrospective technique du processus de développement.

Le responsable fonctionnel valide le travail de l'équipe et ajuste les besoins entre chaque incrément.

https://fr.wikipedia.org/wiki/Kanban


Pratiques communes aux méthodes Agiles

Pratiques l iées aux ressources humaines

Participation de l’utilisateur final aux groupes de travail.

Groupes de travail disposant du pouvoir de décision.

Autonomie et organisation centralisée de l’équipe (motivation).

Spécification et validation permanente des Exigences.

Pratiques l iées au pilotage du projet

Niveau méthodologique variable en fonction des enjeux du projet.

Pilotage par les enjeux et les risques.

Planification stratégique globale basée sur des itérations rapides.

Réalisation en jalons par prototypage actif itératif et incrémental.

Recherche continue d’amélioration des pratiques.

Pratiques l iées à la qualité de la production

Recherche d’excellence technique de la conception.

Vision graphique d’une modélisation nécessaire et suffisante.

Vision de la documentation nécessaire et suffisante.

Normes et techniques raisonnables de qualité du code.

Architecture à base de composants et d’objets.

Gestion des changements automatisés.


Itératif, incrémental et

adaptatif

La moitié de la profession jargonne en franglais des concepts qu’elle ne comprend pas. Parmi les errements mineurs se situe le « Planning poker game » dans lequel il n’y a pas de notion de planning mais essentiellement d’évaluation de charge. Je préfère le terme « Estimation poker game ». Le plus pénalisant des égarements est la notion d’itération confondue avec celle de lotissement. À qui profite le crime ? Les concepts sous-jacents sont fréquemment mal compris.

La notion d’incrémental est essentiellement liée au pilotage du projet.

La notion d’itératif est liée à l’affinement du besoin applicatif.

Figure 7. — Comprendre l’incrémental et/ou l’itératif

D’abord il faut savoir que Scrum est simplement incrémental et qu’il ne dispose pas de métrique lui permettant de pousser l’itératif


« cosmétique » jusqu’au vrai adaptatif (capacité de modifier le contenu des sprints sans devoir tout arrêter). Si l’on considère que le principe déterminant de l’agilité repose sur l’acceptation de changements majeurs (lors d’itération sur l’ouvrage en cours), on comprend alors mieux pourquoi Scrum a tenu à qualifier d’itérations son petit lotissement bien classique. La métaphore de la Joconde, choisie par Jeff Patton pour matérialiser individuellement ces concepts d’incrémental et d’itératif est particulièrement pertinente (Figure 7. — Comprendre l’incrémental et/ou l’itératif).

Afin de visualiser le principe les combinant, j’ai proposé sur cette base le montage suivant (Figure 8. — L'itératif combiné à l'incrémental) qui matérialise la dimension temporelle de l’itération, donc le pilotage du projet en regard de la dimension applicative de l’incrément. À la fin de la première itération, un livrable utilisable est produit. En effet, si la production devait cesser à ce point, le client disposerait d’un portait au lieu d’un buste, mais au moins il serait achevé.

Figure 8. — L'itératif combiné à l'incrémental

Pour obtenir la maîtrise de l’adaptatif, il faut aller encore un peu plus loin et se doter d’une métrique des modifications.


Jusqu’ici, aucune méthode Agile ne disposait d’une métrique formelle du changement. Cette notion est pourtant indispensable à la mise en œuvre raisonnable des valeurs de l’agilité dans le cadre des impératifs d’un forfait ou simplement pour sécuriser de nombreuses modifications en cours de développement. Voici une solution formalisée.

Figure 9. — Adaptatif et son coût (« full iteratif »)

Pour être vraiment Agile, une méthode de conduite de projet appliquée au développement du système d’information se doit d’être incrémentale, itérative et adaptative. Avec la méthode Scrum par exemple, depuis sa publication en 2001 par Ken Schwaber et Mike Beedle, seul le concept incrémental était mis en œuvre et la modification importante de fonctionnalités en cours de développement était interdite durant le « sprint ». La notion d’itération qui consiste à « revenir sur pour affiner » n’était donc pas supportée, ce qui nécessitait un gros travail prédictif initial pour spécifier les fonctionnalités à produire (baklog).

Plus récemment, une mise à jour du guide d’utilisation permis de légères modifications en cours de développement à condition qu’elles ne modifient pas les objectifs de l’incrément à livrer. Les


méthodes RAD (1991) et XP (1999) étaient parfaitement itératives et s’appuyaient sur la notion de conception émergente pour tenter d’être aussi « adaptative » mais jusqu’ici, aucune de ces méthodes ne disposait d’une métrique formelle du changement. Cette notion était pourtant indispensable pour permettre la mise en œuvre raisonnable des valeurs de l’agilité dans le cadre des impératifs d’un forfait ou simplement pour éviter les incompréhensions entre développeurs et clients en cas de changements importants ou fréquents en cours de développement. Voici donc une solution à ce problème qui a durant des années laissé penser qu’un forfait Agile n’était pas gérable.

Un contrat Agile se base sur l'évaluation du périmètre connu à produire avec une technique comme, par exemple, le jeu d'estimation consensuelle. Ce principe exprime en unité d'œuvre, comme les journées idéales par exemple (Ideal Day), un engagement de l’équipe sur le périmètre initial défini. C’est ce périmètre qui fait l’objet du contrat-projet initial. Le contenu fonctionnel peut ensuite être modifié, en permanence et même en cours de développement, par le propriétaire du produit.

Chaque modification sera tracée sur le Post-it de la fonctionnalité modifiée ou abandonnée en cours de développement. Ils seront conservées en bas du « reporting mural » (kanban) dans une zone latérale nommée tout simplement « Abandonné, achevé ou en cours de développement ». Les parties de développement éventuellement réutilisables seront ensuite réintégrées dans l’évaluation formelle des modifications ou des nouvelles fonctionnalités. Dans ce contexte, l’équipe aura pour obligation de livrer en fin d’incrément un nombre d’unité d’œuvre au moins égal à sa vitesse nominale prévue en début de projet (nombre de personnes * nombre de jours ouvrés de travail sur l’incrément). Le nombre d’unités d’œuvre (UE) permettant de présenter graphiquement la productivité obtenue pour chaque incrément (BurnUp chart) se composera alors ainsi : UE livrées au total = UE livrées utiles + UE livrées abandonnées.


Les outils du pilotage Agile

contrôlé

Le Post-it nécessaire à l’agilité contrôlée, comme le montre la Figure 10, est en pratique un peu plus complet que ce qui se trouve généralement sur les murs. Il est d’ailleurs très rare que ce soit la vraie fonctionnalité complète et ses cas de tests réels qui y soient détaillés. De plus, l’aspect autocollant éphémère impose que les fonctionnalités soient conservées sur un support plus pérenne (Excel, Jira, etc.).

Figure 10. — La structure du Post-it vraiment utile

Dans les salles dédiées modernes, c’est l’ensemble des murs qui est magnétisé pour fixer les post-it avec des aimants. Généralement, il est aussi possible d’utiliser ces murs comme Paperboard.


La deuxième étape Agile consiste à impliquer l’équipe dans un « Jeu estimation » nommé (on se demande bien pourquoi) « Planning poker game ». Ce jeu, indispensable à l’estimation du contrat projet, permet aussi un approfondissement de la compréhension de l’équipe et conduit à son engagement moral en regard de l’évaluation.

Un contrat Agile est tout à fait possible. Il se base sur l'évaluation du périmètre connu à produire avec une technique Agile comme le jeu d'estimation consensuelle. Ce principe exprime en unité d'œuvre, telle les journées idéales par exemple, un engagement de l’équipe sur des objectifs précis. Ces objectifs font l’objet du contrat-projet initial. Le contenu fonctionnel peut ensuite être modifié, en permanence et même en cours de développement, par la maîtrise d'ouvrage. Chaque modification est tracée sur la fiche de récit utilisateur de la fonctionnalité modifiée ou abandonnée en cours de développement. Les parties de développement réutilisables sont réintégrées dans l’évaluation formelle des modifications ou des nouvelles fonctionnalités. Il y aura aussi quelques petites règles à respecter pour ne pas se pénaliser ni pénaliser le « client ».

Figure 11. — Reporting mural et métrique du changement


Lorsque l’on installe un reporting mural, la première chose à coller au mur est « la liste des freins et des obstacles ». Ce n’est pas négociable ! Ensuite, ce sera le tour du Kanban.

La mise à jour du Kanban (par déplacement de post-it) doit impérativement se faire en temps réel. Attendre le stand-up meeting pour le faire est une erreur. D’une part le modèle s’écarterait de la réalité et d’autre part, les acteurs pourraient très bien ne pas être là le lendemain.

Les avantages de l’affichage mural temps réel sur les anciennes formes de reporting sont nombreux. Lorsque ces informations sont conservées dans des outils automatisés, il est rare que les dirigeants y accèdent. De plus, lorsqu’ils souhaitent avoir une vision de l’avancement, ils interrogent généralement le chef du projet, lequel dérangera alors à son tour l’équipe pour obtenir l’information à jour (en admettant que tous les membres soient présents). Avec le reporting mural temps réel, une personne formée à sa lecture disposera de l’information complète et la plus récente, d’un seul coup d’œil et sans déranger personne.

Figure 12. — La forme efficiente du reporting Agile


En ce qui concerne le « Daily, morning, stand up, meeting » dont le but est d’obtenir un feedback journalier, il doit se réaliser devant le Kanban et la transparence doit être totale.

Dans le contexte d’un engagement Agile sur un contrat projet, l’équipe a pour obligation de livrer en fin d’incrément un nombre d’unités d’œuvre au moins égal à sa vitesse nominale prévue en début de projet (nombre de personnes * nombre de jours ouvrés de travail sur l’incrément) ; le nombre d’unités d’œuvre (UE) permettant de présenter graphiquement la productivité obtenue pour chaque incrément se compose alors ainsi : UE livrées au total = UE livrées utiles + UE livrées abandonnées. Ce principe se matérialise ensuite avec la forme de reporting Agile nommé BurnUp chart (Figure 12. — La forme efficiente du reporting Agile).

L'acceptation du mode adaptatif, permet au client de modifier ses exigences en cours de projet, aura pour conséquence l'éventualité d'un périmètre variable. Dans la plupart des projets conséquents ou stratégiques, des contraintes plus nombreuses doivent être prises en compte afin d'optimiser le pilotage de la réalisation.

Figure 13. — Bien formaliser une User Story


L’équipe Agile

Contrairement à des idées reçues, les développeurs excessivement compétents et techniques sont à éviter sauf si le travail en binôme et la rotation des binômes est généralisé jusqu’à « l’appropriation collective du code » et la montée en compétence qu’elle favorise.

Figure 14. — Le plateau projet type

Il faut particulièrement se méfier de leur capacité d’abstraction lorsqu'ils s'attachent à mettre en œuvre l'intégralité de leur astucieux savoir sans le partager. En effet, les langages de développement sous Windows disposent d'un nombre impressionnant de fonctions complexes. La diversité des solutions possibles est telle que la maintenance d'un module réalisé par un « top » développeur peut devenir presque inexploitable après son départ.

Une culture d’entraide est à la base de l’efficacité de l’équipe. Elle doit être initiée par l’animateur, puis comprise et développée par tous les membres de l’équipe.


Ressources à temps partiel

Les membres de l'équipe n'ayant pas l'expérience des principes et surtout des techniques « Agiles » doivent bénéficier d'une formation avant tout engagement.

Dans un projet Agile, les membres de l’équipe sont engagés à cent pour cent. Les ressources ne disposant pas de cette disponibilité ont d’autres préoccupations que celle du projet. Elles peuvent participer au projet à divers titres, mais non comme membres de l’équipe à des ressources internes engagées sur d’autres projets ou dans des activités d’exploitation. Leur expérience des aspects fonctionnels ou organisationnels sont des connaissances de grande utilité, aussi devront-ils être sollicités ponctuellement à titre d’experts du domaine concerné.

Durant les étapes préalables au projet Agile, les ressources à temps partiel peuvent être déléguées au support de la maîtrise d’ouvrage pour faciliter l’expression des besoins et aux validations. Durant la construction, il est possible qu’elles assurent les vérifications qualitatives, fonctionnelles et techniques.

Après la livraison, ces ressources disposent alors de connaissances permettant la maintenance applicative et corrective. Leur mission peut alors s’exprimer dans le cadre d’une équipe d’assistance technique au métier ou au client, la notion de client ayant dans un contexte qualité le sens d’utilisateur du produit.

L’esprit d’équipe

Au-delà du profil général et de la complémentarité spécifique des membres d’un Team, ce qui différencie avant tout une équipe de « gagnants », c’est l’esprit qui naturellement en émerge. Aussi, faut-il favoriser toutes les formes de participation extra professionnelles susceptibles de favoriser la cohésion de l’équipe. Une équipe de projet dont les membres n’éprouvent pas le besoin de déjeuner ensemble le plus souvent possible devient difficilement une vraie équipe Agile.


D’expérience, je peux assurer que l’humour en général, et la naissance d’un humour de « projet » en particulier, est un pas significatif vers la notion d’appartenance caractérisant les équipes gagnantes.

L’effort requis pour réaliser un logiciel croît exponentiellement parrapport à sa taille.

En réduisant de moitié les fonctions d’un logiciel de taillemoyenne, vous réduirez à un tiers l’effort de développement.

Pour gagner 23% sur les délais, il faut augmenter le personnel de75 %

(MCP

classiq

ue),

L’accroissement de coût est alors de 33 %.

Figure 15. — Éléments de la problématique « taille équipe »

La plus grande partie de la récompense doit être collective, mais il faut récompenser individuellement toutes les actions de soutien afin de développer une vraie culture d’entraide. La performance a un prix, mais ce prix n’est rien en regard des économies qu’elle fait naître et surtout des gains stratégiques qui en découlent. Tout est un rapport de retour sur investissement.

La qualité nécessite la communication

La communication externe est considérée comme un facteur additionnel de réussite. Un organe de presse, même sommaire à l’en-tête du projet, est régulièrement publié. Pour un petit projet, une ou deux pages publiées une ou deux fois par mois, en fonction de la durée du projet, sont suffisantes. À travers ces quelques lignes,


graphiques ou dessins (amusants de préférence), le projet prend vie, et les futurs utilisateurs se l’approprient. Surtout lorsque, nombreux, ils ne peuvent pas tous participer aux spécifications.

La publication régulière est aussi synonyme de bonne santé, c’est-à-dire d’avancement. Il faut d’emblée exclure toute langue de bois de ce type de communication. La plupart des gens n’en sont pas dupes. Les sujets généraux doivent être traités sous un angle humoristique. Ainsi, sont rappelées les dates importantes du projet ainsi que les événements non moins importants de la vie des participants. L’arrivée de nouveaux membres ou de nouveaux matériels (attendus parfois depuis trop longtemps) peut ainsi faire l’objet d’une célébration spéciale.

Tout est bon pour promouvoir l’intérêt et l’engagement. Une entreprise doit vivre au rythme de ses projets.

Lorsque l’on réussit, on peut tout se permettre, y compris de ne pas sembler trop sérieux. Néanmoins, la réussite doit toujours demeurer modeste, car elle nécessite en général la collaboration de toute l’organisation qui doit « supporter » le mode projet qu’elle implique. Un rejet ou un frein du reste de l’organisation doit être évité à tout prix. Le meilleur moyen pour cela reste l’élargissement du partage de la satisfaction au plus grand nombre possible.

La démocratie dans une équipe Agile s’exprime par une décision collégiale. Lorsqu’une décision est prise, son exécution est immédiate, et, comme l’équipe entière a participé au choix, aucune remise en question personnelle n’est admise. Tout détournement personnel de la décision doit être considéré comme une faute grave.

Après plusieurs projets Agiles, les choix généraux de développement sont acquis, seules les décisions particulières nécessitent une séance d’approbation. Dans une équipe Agile, la bonne foi et la logique président à chaque décision. Dans le cas où l’esprit de l’équipe est dénaturé, il est préférable de demander sa mutation. Laisser la situation dégénérer se termine toujours mal, et il est ensuite trop tard pour dégager sa responsabilité.


Scrum méthode basique

Scrum est un processus empirique qui s'appuie sur trois concepts fondamentaux :

1 - Transparence

Scrum met l'accent sur le fait d'avoir un langage commun entre l'équipe et le management. Ce langage commun doit permettre à tout observateur d'obtenir rapidement une bonne compréhension du projet. D’où la nécessité incontournable d’un affichage mural mis à jour en temps réel.

2 - Inspection

À intervalles réguliers, Scrum propose de faire le point sur les différents artéfacts produits (qualité applicative) et sur les processus de production (efficience du développement).

3 - Adaptation

Si un problème ou une faiblesse est constaté pendant l'inspection, le processus doit alors être adapté. Scrum fournit des rituels, durant lesquels cette adaptation est possible. Il s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective de sprint.

Note : Comme on le constate, il est tout à fait possible de parler Scrum en respectant le français. Une bonne partie de ces exemples viennent d’ailleurs de Wikipédia.

https://fr.wikipedia.org/wiki/Empirisme


Une méthode essentiellement incrémentale

La méthode s'appuie sur le découpage d'un projet en « boîtes de temps », nommées « sprints ». Les sprints peuvent durer entre quelques heures et un mois (avec une préférence pour deux semaines). Chaque sprint commence par une estimation suivie d'une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé. Avant de démarrer un nouveau sprint, l'équipe réalise une rétrospective. Cette technique analyse le déroulement du sprint achevé, afin d'améliorer ses pratiques. L'adaptation et la réactivité de l'équipe de développement sont facilitées par son auto-organisation.

La méthode Scrum ne couvre aucune technique d'ingénierie du logiciel. Dans le cas d'un développement d'application, il est nécessaire de la compléter avec des pratiques de qualité du logiciel. Par exemple, on pourra utiliser des pratiques issues de l'eXtreme Programming, de la phase de construction structurée de la méthode RAD, ou un ensemble de pratiques de qualité du logiciel émergeant du vécu de l'équipe projet.

De même, concernant les « préalables » au premier sprint, il serait judicieux de s’intéresser aux phases d’initialisation, de Cadrage et de Design de la méthode RAD ou aux moteurs et modèles de communications et de solution de la méthode PUMA.

Un principe fort des méthodes Agiles est la participation active du client. Cela permet de choisir plus finement les fonctionnalités réalisées à chaque incrément. Avant le démarrage du sprint 1, les objectifs sont définis lors d'un sprint 0. La mêlée (Scrum meeting) a lieu quotidiennement et des réunions spécifiques permettent de lever les obstacles bloquants. Le sprint à une durée variable (idéalement deux semaines). Après chaque sprint, une démonstration suivie d’une rétrospective a lieu. Le propriétaire du produit peut à tout moment compléter ou modifier la liste des fonctionnalités à produire pour les prochains sprints. Sans modifier le but du sprint en cours, celui-ci peut être affiné et faire l'objet d'une

https://fr.wikipedia.org/wiki/D%C3%A9veloppement_rapide_d%27applications

https://fr.wikipedia.org/wiki/D%C3%A9veloppement_rapide_d%27applications


renégociation entre le propriétaire du produit et l'équipe de développement à la suite de nouvelles connaissances. Si le but du sprint devient obsolète, le propriétaire du produit a la capacité d'annuler un sprint en cours.

Chaque sprint constitue donc un incrément, facilitant le pilotage du projet. La notion d'itération couvre l'adaptabilité au quotidien. Cette adaptabilité est limitée par le but immuable d'un sprint.

Le cadre du Scrum consiste en la définition des rôles projets, activités ou artefacts, et réunions ou événements. Ceux-ci sont décrits dans le Guide, rédigé par les créateurs de la méthode.

Figure 16. — Scrum vision globale du processus

Les Rôles

Scrum définit trois rôles : le propriétaire du produit (product owner), le Scrum Master et l’équipe de développement.

L e P r o p r i é t a i r e d u p r o d u i t

Le propriétaire du produit est le représentant des clients et des utilisateurs. Il est « responsable de maximiser la valeur du produit et

https://fr.wikipedia.org/wiki/M%C3%A9thode_it%C3%A9rative

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-FR.pdf#zoom=100


du travail de l'équipe de développement »7. Il s'agit d'« une personne et non d'un comité ». Il est seul à diriger l'activité de l'équipe de développement à qui il n'est « pas permis de suivre les instructions d'une autre personne ».

De ce fait, cet acteur se charge de différents rôles et responsabilités :

Il définit l'ordre dans lequel les fonctionnalités seront développées.

Il prend les décisions déterminantes concernant l'orientation du produit.

Il s'assure que le détail des fonctionnalités est compris de l'équipe de développement au moment de leur mise en production.

C'est également lui qui, en accord avec l'équipe, fixe les objectifs d'un incrément (sprint) au début de celui-ci. Si ces objectifs deviennent obsolètes pendant le sprint, il a alors l’obligation de l'interrompre.

Par contre, en utilisant une métrique des changements (proposée par Jean-Pierre Vickoff), il peut désormais continuer le sprint en l’adaptant aux nouvelles exigences du métier.

Dans l'idéal, le propriétaire du produit travaille dans la même pièce que l'équipe. Il est important qu'il soit disponible pour répondre aux questions et pour donner son avis.

L e M a î t r e d e m ê l é e

Le Maître de mêlée (Scrum Master) est responsable de la compréhension, de l'adhésion et de la mise en œuvre de la méthode, mais il ne dispose d'aucune autorité sur les autres membres de l'équipe. Ce n'est pas un chef de projet, ni un développeur, ni un intermédiaire de communication avec les clients. Le rôle de Scrum Master ne peut pas être cumulé avec celui de propriétaire du produit. En tant que facilitateur, il aide l'équipe à déterminer quelles interactions avec l’extérieur lui sont utiles, et lesquelles sont

https://fr.wikipedia.org/wiki/Scrum_(m%C3%A9thode)#cite_note-7


freinantes. Il aide alors à maximiser la valeur produite par l'équipe. Parmi ses attributions :

communiquer la vision et les objectifs à l'équipe ;

apprendre au propriétaire du produit à rédiger les composantes du carnet du produit ;

faciliter les rituels de Scrum ;

coacher l'équipe de développement ;

faciliter son intégration à l'entreprise, surtout si celle-ci n'est pas pleinement Agile ;

écarter les éléments pouvant perturber l'équipe ;

aider l'adoption des méthodes agiles au niveau de l'entreprise ;

travailler avec les autres facilitateurs/animateurs pour coordonner plusieurs équipes, s'il y a lieu.

L ’ é q u i p e d e d é v e l o p p e m e n t

L'équipe de développement est constituée d’une à 12 personnes et a pour responsabilité de livrer à chaque fin d'itération une nouvelle version de l'application enrichie de nouvelles fonctionnalités et respectant le niveau de qualité nécessaire pour être livré.

L'équipe ne comporte pas de rôles prédéfinis ; elle est « structurée et habilitée par l'entreprise à organiser et gérer son propre travail ».

L'équipe est auto-organisée et choisit la façon d'accomplir son travail, sans que ce soit imposé par une personne externe. Il n'y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises par consensus. Ce mode d'organisation a pour objectif d'augmenter l'efficacité et la motivation.

L'équipe est pluridisciplinaire et devrait comporter toutes les compétences pour réaliser son projet, sans faire appel à des personnes externes.


L'équipe a pour objectif de livrer le produit par incréments. Ainsi, à tout instant, il existe une version du produit « potentiellement testable, si ce n’est utilisable » disponible.

L'équipe s'adresse directement au propriétaire du produit, et ne prend ses instructions que de lui. Son activité est uniquement liée au carnet de produit. Dans le respect des principes basiques de Scrum, elle ne peut pas être multi-produits.

Les Évènements (rituel, cérémonial)

Toutes les activités (sprint, réunions de planning, revues, rétrospectives et mêlées) décrites dans le framework Scrum sont effectuées lors de boîtes de temps.

L e s p r i n t

Le sprint est une période, au bout de laquelle l'équipe délivre un incrément du produit, potentiellement livrable. Une fois la durée choisie, elle reste constante pendant toute la durée du développement. Un nouveau sprint démarre dès la fin du précédent.

Chaque sprint possède un « but » et on lui associe une liste d'éléments du carnet du produit (fonctionnalités) à réaliser. Selon la méthode, durant un sprint :

l'objet du sprint ne peut être modifié ;

la composition de l'équipe reste constante ;

la qualité n'est pas négociable ;

la liste d'éléments est sujette à négociations entre le propriétaire du produit et l'équipe de développement.

La durée maximum est d'un mois afin de limiter la complexité et donc les risques liés au sprint. L’idéal étant deux semaines.

https://fr.wikipedia.org/wiki/Timeboxing


M ê l é e q u o t i d i e n n e

La mêlée quotidienne (daily scrum) permet aux développeurs de faire un point sur les tâches en cours et sur les difficultés rencontrées. Cette réunion dure généralement 15 minutes au maximum. Le propriétaire du produit peut venir en observateur.

À tour de rôle, chaque membre aborde trois sujets :

1) Ce qu'il avait prévu de faire la veille.

2) Les éventuelles difficultés rencontrées.

3) Ce qu'il compte réaliser aujourd'hui.

Si le besoin s'en fait sentir, des discussions sont alors menées après la clôture de la mêlée pour traiter des préoccupations mises en évidence lors de la séance.

Cette réunion permet la synchronisation de l'équipe, l'évaluation de l'avancement vers l'objectif de l'itération, la collecte d'informations nécessaires à l'auto-organisation.

C'est le niveau quotidien des principes d’inspection et d’adaptation de Scrum.


R é u n i o n d e p l a n i f i c a t i o n d ' u n s p r i n t

Toute l'équipe est présente à cette réunion, qui doit se limiter à une demi-journée pour un sprint de deux semaines. Pour un sprint plus court ou plus long, la durée est modulée proportionnellement. À l'issue de cette réunion, l'équipe a décidé des éléments du carnet du produit qu'elle traitera dans le cadre de la prochaine itération, et comment elle s'organisera pour y parvenir.

Cette réunion est une étape d’approfondissement des spécifications générale. Elle se déroule en deux temps. Dans la première partie, l'équipe de développement cherche à prévoir ce qui sera développé durant le prochain sprint. À l'entrée de cette phase, l'équipe doit avoir à sa disposition :

le carnet du produit priorisé et amené à un niveau de détail suffisant aux développeurs.

la capacité de production (vélocité) prévue pour ce sprint. L’estimation est théorique (nombre de jours de la durée du sprint multiplié par le nombre de membres de l’équipe moins les absences prévues) pour le premier sprint. La vélocité appliquée aux sprints suivants est ensuite basée sur le constat de la productivité réelle obtenue.

L'équipe et le propriétaire du produit détermine le but du sprint.

R e v u e d e s p r i n t

À la fin du sprint, l'équipe et les parties prenantes invitées se réunissent pour effectuer la revue de sprint, qui dure au maximum quatre heures. L'objectif de la revue de sprint est de valider l'incrément de produit qui a été réalisé pendant le sprint. L'équipe énonce les éléments du carnet de produit sélectionnés en début de sprint. L'équipe présente les éléments « finis » complètement réalisés, testés techniquement et fonctionnellement et officiellement acceptés (« Done ») par le Propriétaire du produit. Les éléments partiellement réalisés ne sont ni présentés ni pris en compte dans le


reporting (la théorie fumeuse du « restant à faire » n’existe pas dans les méthodes Agiles).

R é t r o s p e c t i v e d u s p r i n t

La rétrospective du sprint (maximum trois heures pour un sprint d'un mois, et réduit selon la durée du sprint) a pour but l'amélioration continue du processus de réalisation. L'objectif est d’analyser le sprint venant de s’achever, afin de déterminer les éléments du processus de développement efficient et ceux qui sont à améliorer. L'équipe de développement en déduit un plan d'améliorations qu'elle mettra en œuvre progressivement (une par une) lors du sprint à venir.

Les artéfacts

C a r n e t d u p r o d u i t ( p r o d u c t b a c k l o g )

Le carnet de produit est une liste ordonnée de toutes les exigences (fonctionnelles, techniques, organisationnelles) liées à la réalisation du produit. Ce document évolue constamment au cours de la vie du produit.

À chaque élément du carnet sont associées une description et une estimation de l'effort nécessaire à sa réalisation. La priorisation du carnet de produit est de la responsabilité du propriétaire du produit. Il peut changer à discrétion l'ordre des éléments, en ajouter, modifier le découpage en éléments, modifier leur description, ou supprimer des éléments qui n'ont pas encore été réalisés par l'équipe de développement. Les éléments en tête du carnet de produit qui sont destinés à être traités dans le prochain sprint sont les plus finement décrits et estimés (cas de tests compris). Ils sont dits « prêts ». Les éléments moins prioritaires peuvent être découpés plus grossièrement en attendant d’être affinés à leur tour. L'activité d'affinage du carnet de produit et de ses éléments est effectuée conjointement par le propriétaire du produit et par l'équipe de


réalisation. C'est notamment elle seule qui a le mot final sur les estimations des éléments du carnet du produit.

C a r n e t d e s p r i n t ( s p r i n t b a c k l o g )

En début de sprint, un but est décidé. Pour atteindre cet objectif, l'équipe de développement choisit lors de la réunion de planification de sprint quels éléments du carnet de produit seront réalisés. Ces éléments sont alors groupés dans un carnet de sprint ou plus pratiquement dans une colonne du Kanban. Chaque équipe met à jour régulièrement le carnet de sprint au cours de son activité, afin que celui-ci donne une vision la plus précise possible de ce que l'équipe prévoit de réaliser pour atteindre l'objectif du sprint. Le carnet de sprint est sous la responsabilité de l'équipe et elle est seule à pouvoir le modifier en cours de sprint.

I n c r é m e n t d e p r o d u i t

L'incrément de produit est l'ensemble des éléments du carnet de produit finis pendant un sprint.


Scrum et réalité d’entreprise

Plongeon dans une méthode simplette

Il suffit d’aller sur Vickoff.com ou sur Wikipédia pour comprendre que je suis depuis l’aube de l’informatique un acteur actif en matière de méthode. J’ai donc assisté à la naissance de Scrum sur la base du plagiat d’une demi-douzaine de concepts issus de la méthode RAD. Lesquels avaient d’ailleurs été officiellement repris dans les méthodes suivantes comme Adaptative Software Development, Feature Driven Development et quelques autres tout aussi inconnues de ce côté de l’Atlantique. Les principaux emprunts se situaient dans :

la présence d’un animateur facilitateur (renommé Scrum Master par Scrum) ;

la tentative de réduction de la dualité métier informatique par la « validation permanente » de l’utilisateur final ;

le rythme des lotissements (devenus des sprints) et des « Show » de l’application ;

la cadence des rétrospectives quotidiennes (stand up meeting) et des autres.

Il y avait aussi quelques petits détails techniques comme la salle dédiée (War Room), les tentatives d’obtenir une équipe engagée en mode projet et en mode plateau, mais ayant à l’évidence perdu les compétences techniques du SWAT (Skill With Advanced Toools).

J’ai donc assisté à la montée de Scrum suite à l’Agile Manifesto et au livre de Schwaber et Beedle qui s’en est ensuivi. Je dois dire que me


suis personnellement payé ma dose de problèmes en communiquant sur l’escroquerie intellectuelle en cours (cabales de tout type, suppression de pages dans Wikipédia, etc.). Mais que voulez-vous, un truc de simplet, pour des simplets, c’était tellement tentant. D’une certaine manière, je piétinais leurs rêves de certifications pyramidales.

Puis, est survenue la prise de conscience progressive de l’impuissance relative de cette méthode et son lynchage par ses premiers adorateurs confrontés à la réalité complexe des projets et aux divers types d’échecs qui en découlèrent.

Revenons maintenant à la technique. Il est amusant de constater qu’aux débuts de Scrum, de nombreux consultants souhaitaient remplacer le RAD (au nom si peu porteur en français et surtout que j’avais verrouillé en termes de possibilités de certifications). Ils menaient donc une guerre de principe à cette toute première des méthodes Agiles en prétendant qu’elle ne l’était pas. C’était étonnant, car entre autres techniques « Agiles » dont elle était l’initiatrice, la méthode RAD comme XP, acceptait le changement des besoins utilisateurs (même en cours de développement). Ce qui n’était pas, et n’est toujours pas le cas de Scrum. Scrum se révélait donc, dans la réalité de sa mise en œuvre, être une méthode éminemment prédictive. Citons, pour ceux qui ne comprendraient pas ce problème, des points précis comme : la nécessité du backlog produit en sprint 0 et surtout l’interdiction de modifier les fonctionnalités en cours de sprint. Ce point fondamental peut désormais se corriger en appliquant une métrique permettant d’assurer en temps réel la comptabilité des demandes de modifications (base du développement "adaptatif").

Quant aux métaphores organisationnelles sous-jacentes, le « team » du rugby pour Scrum ou la notion de SWAT (skill with advanced tools) dans une War Room pour RAD, de toute façon, elles n’avaient pas été poussées assez loin pour qu’une réelle philosophie d’action s’en dégage. Ce n’était qu’un effet de mode. D’ailleurs, je ne serais pas étonné si dans peu de temps, les aspects « commandos » du Swat ou

http://www.journaldunet.com/solutions/expert/53067/une-solution-agile-au-probleme-contractuel-des-changements.shtml

http://www.journaldunet.com/solutions/expert/53067/une-solution-agile-au-probleme-contractuel-des-changements.shtml

https://fr.wikipedia.org/wiki/Adaptatif


opérationnels de la War Room, revenaient à la mode avec l’évolution actuelle de nos sociétés.

Un autre aspect malheureux concerne l’unicité indispensable de la spécification - conception – développement – validation. Beaucoup semblent avoir oublié que dans un projet de système d’information, au-delà du relationnel (qui néanmoins conserve toute son importance), au final c’est du code qui s’exécute dans un ordinateur.

Cette réflexion du passage de l’idée à la solution implémentable amène à un constat encore plus grave, le même problème que je combattais dès le début de l’aventure Agile : la rupture entre la conception et le développement subsiste.

Je pensais cet aspect compris et réglé depuis longtemps, mais dans la réalité des entreprises, il n’en est rien. Les penseurs de la fuite d’eau se refusent toujours d’en être les plombiers. Le résultat de cette dichotomie n’a pas évolué avec le temps : le passage du témoin (les spécifications en l’occurrence) est toujours aussi générateur de travail additionnel de rédaction, de réunionite, de manque d’exhaustivité et de compréhension des détails. Les résultats sont évidemment toujours les mêmes : déperdition d’énergie, flou de la communication, génération d’incompréhensions et au final d’erreurs coûteuses aussi bien en développement qu’ensuite en maintenance. Sans parler de la spécification-validation permanente rarement comprise et encore moins souvent mise en œuvre, bien qu’elle soit la clé du succès des projets.

L'analyse élémentaire de trois problèmes

Toute cette réflexion conduit à un constat trop long pour le détailler exhaustivement. Je vais donc me limiter à trois points problématiques :

La raison d’être et l’usage mal compris des récits utilisateurs (surtout lorsque ce ne sont pas les utilisateurs qui les rédigent avec simplisme).


Le délire de l’estimation de charge exprimée en points de complexité (dans le but plus ou moins avoué de rendre incomparable et surtout incompréhensible le reporting mural).

La volonté d’éradiquer les chefs de projet sans éclaircissement préalable de la réalité de leur sort.

En prémices, un genre de petite métaphore :

De la même façon qu’au pays des Schtroumpfs se parle le schtroumpf, au pays de Scrum se parle le Scrum. La grande question actuelle au pays de Scrum est « Comment écrire un récit utilisateur ». Celle du pays des Schtroumpfs est « Comment composer du Mozart ».

1 – Les récits uti lisateurs rédigés par les informaticiens

Au début étaient les besoins ; paix à leurs exigences. Commençons donc par un peu de recueillement.

En mode Agile, depuis la méthode RAD puis eXtreme Programming, il est impératif de confier à l’utilisateur réel de l’application le soin d’exprimer ce qu’il souhaitait (de préférence sous le contrôle de la ressource d’encadrement la plus apte à disposer d’une vision prospective du métier).

En mode Agile, la forme de cette expression est primaire : en tant que X, je souhaite disposer de la possibilité Y, (et éventuellement : pour la raison Z). C’est parfaitement simple et presque suffisant à un détail près : les systèmes d’informations sont généralement un peu plus complexes que ne l’imaginent les experts Agiles « qui ont appris leur métier en deux jours ». De ce fait, imaginant avec leurs clients se trouver devant une forme d’expression obligatoire, tout ce beau monde va abandonner la rigueur des contraintes de l’espace de la solution pour se précipiter dans la rédaction d’Users Story miraculeuses d’Agilité alors même qu’ils ne sont pas des utilisateurs. De la suite découlera le constat que personne d’autre que Mozart ne peut composer du Mozart.


De plus, dans un projet de développement applicatif, qu’il soit classique ou Agile, une translation de forme permet, partant du besoin fonctionnel de modéliser les contraintes techniques de l’espace de la solution. Cela se formalise (au minimum textuellement) par une décomposition en « exigences » voire en tâches, qu’elles soient techniques, fonctionnelles, de granularité de réalisation, etc. Si l’on dispose déjà de la formalisation nécessaire à l’espace de la solution, ce qui est parfois le cas, il serait absolument paradoxal et non Agile de perdre à nouveau du temps pour reformuler ce qui aurait « à l’idéal » dû être précisé par l’utilisateur, et en plus le faire décrire par des « non-utilisateurs ». Pour conclure ce point, comme aurait dit Monsieur de La Palisse : « Pourquoi lorsque l’on y est déjà chercher à y venir ? ».

2 – L’estimation de charges en points de complexité relative

Le second point est encore plus désopilant. Il concerne l’estimation de charges.

Pour tenter d'obtenir une évaluation raisonnable, le choix habituel est d’utiliser le « planning poker game » et c'est évidemment une bonne chose.

Cette technique aboutit à un affinement de la compréhension du sujet et surtout à une estimation par l’équipe de réalisation (qui du fait s’engage moralement).

Au passage, on s’étonnera d’un détail : le mot « planning » n’a aucun sens à ce niveau et le terme exact aurait dû être « estimation poker game ». Mais ceci n’est pas vital. Le vrai problème se situe au niveau de l’unité d'œuvre employée. Personnellement, comme je sais que tout finit par se compter en jours, j’utilise la « journée idéale ». Bien évidemment, c’est trop simple, pratique, raisonnable sans embrouille et surtout insuffisamment en rupture avec ce que souhaitent les tenants de l’ésotérisme Agile. Ils ont donc trouvé une


unité d’œuvre incomparable, dans le sens de « ne pouvant pas permettre de comparaison de productivité entre les équipes ». Cela a été baptisé « points de complexité ». Le principe implique de prendre « 1 » comme référence de l’user story la plus petite (ce qui nécessite de les avoir étudié toutes), puis de noter les autres en rapport avec cette complexité (par exemple : 2,5 fois). Mais fois quoi en clair ? On le saura à la fin du projet je présume. Imaginez la tête du dirigeant venant observer l’affichage mural incompréhensible et qui demande lui aussi : « Mais fois quoi !!?? ». Après une petite estimation sérieuse du « 1 », on imagine que ce pourrait être une journée et demie. Cela devient de suite beaucoup plus clair, mais il faut faire la multiplication pour chaque Post-it. C’est d’un drôle… Au fait, de tête, en trois ou quatre secondes à perdre, cela fait combien 2,5 fois 1,5 jour ? Au final, même si l’on se limitait à ces deux points, ce serait déjà beaucoup pour une méthode si simplette. Mais le pire selon moi concerne le fait que sans une métrique permettant d’assurer la comptabilité des demandes de modifications en cours de développement (introduisant les concepts de "livré utile" et de "livré abandonné"), il serait inconséquent de passer outre l’interdiction de Scrum d’accepter la remise en cause du contenu du sprint ou de ce qui est déjà livré. De là à penser que cette méthode ne respecte pas le deuxième plus important des principes Agiles « Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. » …

3 – La disparition des chefs de projets

Le plus amusant de la révolution, surtout pour les concernés, est sans nul doute la disparition des chefs de projets.

Certaines méthodes Agiles composent avec leur présence en leur préconisant le dialogue et le consensus lors de toute décision. Derrière l’apparente simplification des relations humaines liée à leur suppression, se cache un incroyable piège organisationnel. Réfléchissez à deux fois avant de vous lancer sans avoir communiqué préalablement aux intéressés à qui appartiendront leurs bureaux, ou


même le simple fait qu’ils devront se remettre en question professionnellement. N’oubliez pas non plus de justifier l’aspect rémunération du Scrum Master et ses tâches réelles en regard des exigences de l‘organisation et des phantasmes de la méthode. Ces derniers points amuseront beaucoup les responsables RH impliqués.

Merci pour tout

Pour finir par une sorte de remerciement hypocrite, car au final je veux bien reconnaître à Scrum une chose : avant de faire condamner le mouvement Agile, au moins il l’aura fait connaître. Comprenez-moi bien, je n'ai jamais été aussi certain de la nécessité de maîtriser une approche agile. Je n'ai jamais pensé, à quelques petites erreurs près, que Scrum n'était pas utile, je pense juste qu'il est à l'évidence insuffisant et tant mieux. Comme cela il reste une bonne marge de progression vers l'efficience. On ne va même pas l'assassiner, on va juste l'aider à devenir ce qu'il aurait pu être.

Vous me direz : « Bon, cela ne semble pas simple comme contradictions à résoudre mais ce n’est pas mortel… ». Effectivement vous avez raison, au final et au bout des projets, ce sera plutôt le tribunal que le cimetière. Voici quelques paragraphes sur des « détails » et des responsabilités réciproques des uns et des autres que les vendeurs de certifications et soupe Agile à base de « bouquins » pompés sur les méthodes US ne vous annoncent pudiquement jamais.

Voici quelques paragraphes sur des « détails » et des responsabilités réciproques des uns et des autres que les vendeurs de certifications et soupe Agile à base de « bouquins » pompés sur les méthodes US ne vous annoncent pudiquement jamais.


Scrum, le fond des problèmes

Figure 17. — Quelques techniques manquantes à l’Agilité

Depuis la fin des années 80, j’ai intégralement consacré ma carrière et mes temps libres à la promotion d’une conduite de projet itérative incrémentale adaptative et en particulier à la première de ces méthodes : le RAD de James Martin. Aujourd’hui, je suis totalement sidéré d’observer comment, des sectaires (“Agile is starting to sound a lot more like religious rhetoric than an engineering practice”), sans culture de leur métier, tentant de s’affranchir de cette antériorité en dénigrant sans complexe ce qui est l’origine même des pratiques qu’ils idolâtrent. La suite se présente comme encore plus triste et pénalisante pour le monde Agile.


Encore récemment, quelques fanatiques me reprochaient d’affirmer et de prouver que les méthodes Agiles actuelles sont incomplètes même en en couplant plusieurs (généralement Scrum et XP) et que, de plus, leurs couvertures respectives se chevauchent. Pire, frisant « l’iconoclastie » je prétendais que mes clients se plaignaient de ne pas disposer de structuration Agile des exigences pas plus que de formes Agiles de maîtrise des communications en environnement organisationnel complexe. Ces sectaires voulaient suivre « Scrum in the book ». Au vu du panorama des préoccupations des entreprises face à leurs systèmes d’information, peut-on m’expliquer comment avec la panacée nommée Scrum, il serait possible de répondre aux questions posées par les points d’interrogation de la figure 17.

Amusant, cet aspect « ne touchez plus à rien » pour les jeunes défenseurs inconditionnels d’une Agilité qu’ils auraient souhaitée totalement révolutionnaire et totalement nouvelle. Il est vrai que cette virginité permettait de promettre une martingale incontournable du succès. La deuxième génération de méthodes itératives aurait eu comme avantage de ne rien devoir à personne et, du même coup, se serait pour un temps affranchie du passif de la pléthore d’échecs organisationnels aussi sûrement programmés que non évités dans la plupart des grandes organisations ayant refusé pour de multiples « bonnes » raisons la véritable évolution Agile.

La critique la plus dure vient des US et elle est cinglante. En effet, une controverse majeure est en expansion. À son origine, l’article du « The Decline and Fall of Agile » sur le blog de James Shore d’un expert indiscuté du domaine auteur de l’ouvrage The Art of Agile Development.

Ce praticien confirme globalement :

Que prises indépendamment, les méthodes Agiles actuelles sont incomplètes.

Que Scrum est en train de faire déconsidérer globalement le mouvement Agile (“Rescuing Scrum teams keeps me in business“).


Qu’une approche semi-itérative (un retour au RAD, quoi…) qui permet de définir un minimum de besoins et d’architecture est mieux adaptée à la plupart des développements. (“When in fact if you are truly agile, you will use waterfall (design up front) when necessary”).

Il s’est ensuivi un dialogue qui a permis à plus d’une centaine d’autres praticiens de venir exposer leurs problèmes.

En résumé, « L'engouement pour Scrum a fait que nombre d'équipes insuffisamment préparées se retrouvent dans des situations inextricables de dette technique. Ils ont naïvement cru que l'on pouvait tirer bénéfice d'une gestion de projet agile sans en payer le prix. »

Sincèrement je n’aurais pas pu imaginer mieux pour inciter certains fanatiques à se questionner un minimum.

Les directions informatiques ne doivent pas être dupes et il serait logique qu’elle considère PUMA Essentiel qui est la seule approche européenne et française. Simple et complète, elle permet d’obtenir une Agilité raisonnablement pensée et parfaitement en adéquation avec notre culture. De la méthode, oui, mais la plus efficace de préférence, surtout si elle est française !

À ce point, il devient nécessaire de considérer la Scalabilité Agile à l’échelle de grandes organisations ou de grands projets. Devant l’inconsistance de Scrum une réponse structurante est apparue son nom est SAFe. Mais est-ce encore de l’agilité ?

Le meilleur des mondes ?

Partant de SAFe qui intègre déjà Scrum, Lean, Kanban et bien d’autres techniques. Sachant que Scrum intègre aussi Kanban et bien d’autres techniques et que Puma se contente d’utiliser ce qui peut l’être dans cet ensemble, la figure 18 nous donne un petit aperçu de ce qu’il faudrait mettre en œuvre pour obtenir une couverture relativement Agile du développement et du déploiement des systèmes d’information en entreprise.

Figure 18. — Le meilleur des mondes ou l’inverse

Mais au fait, d’où vient ce félin nommé PUMA ?

En 2001, parallèlement au Manifeste Agile, je publiais en français et en anglais la première version de PUMA qui, à l’époque, signifiait Proposition Unifiant les Méthodes Agiles. Ces documents se trouvent toujours sur le site ADELI.org et sur le Wiki de Ward Cunningham.


À l’époque, le président de XP France avait souhaité connaître ma position sur ce sujet. Je lui avais confié que je n’ignorais pas que les Américains auteurs des méthodes Agiles ne souhaitaient pas fusionner et, que de toute façon, une telle proposition ne pouvait venir d’un étranger.

Initialement, PUMA consistait en une étude de toutes les méthodes Agiles publiées. Le but était d’isoler leurs pratiques communes et surtout de mettre en évidence leurs pratiques différenciatrices.

Immédiatement, la démarche XP me sembla représenter une avancée majeure pour la performance et la qualité des développements, aussi je proposais de la substituer à la phase de construction du RAD pour ceux qui rechercheraient la qualité extrême en acceptant d’en payer le prix organisationnel.

En revanche, je ne trouvais rien de nouveau dans Scrum par rapport à RAD, à l’exception de la systématisation des rétrospectives.

C’est sur ces bases qu’en 2008, j’ai proposé PUMA Essentiel, la première mouture de la troisième génération de méthodes Agiles, urbanisées et optimisées.

PUMA Essentiel

La maîtrise des projets de SI

PUMA les origines

En septembre 2001, je rédigeais la communication initiale traitant de PUMA (Proposition pour l'Unification des Méthodes Agiles). Sa traduction fut alors expédiée aux tenants du mouvement Agile et aux universités américaines.

En décembre 2001, Développeur Référence (IDG) me sollicita sur le sujet. Il utilisa d'ailleurs le graphisme du PUMA en couverture d'un numéro consacrant un dossier à cette méthode Agile novatrice. Cette proposition de composition d'une méthode à la carte fut ensuite reprise en 2002 par de nombreuses publications dont : ADELI (Lettre 48), Forum Logiciel, Le Monde Informatique, etc.

Initialement, PUMA consistait en une étude de toutes les méthodes Agiles publiées. Le but était d’isoler leurs pratiques communes et surtout de mettre en évidence leurs pratiques différenciatrices.

Immédiatement, la démarche XP me sembla représenter une avancée majeure pour la performance et la qualité des développements, aussi je proposais de la substituer à la phase de construction du RAD pour ceux qui rechercheraient la qualité extrême en acceptant d’en payer le prix organisationnel. En revanche, je ne trouvais rien de nouveau dans Scrum par rapport à RAD, à l’exception de la systématisation des rétrospectives.


C’est sur ces bases qu’en 2008, j’ai proposé PUMA Essentiel (Processus Urbanisant les Méthodes Agiles), la première méthode Agile de troisième génération, urbanisée et optimisée.

PUMA Essentiel

V e r s u n e m é t h o d e c o m p l è t e e t h o m o g è n e

L’expérience amène à penser que la méthode Agile idéale pour un contexte projet particulier s'appuierait sur une utilisation optimisée des pratiques du tronc commun et s'adjoindrait une sélection des pratiques spécifiques utiles à ce contexte. Ainsi est né PUMA, le Processus Urbanisant les Méthodes Agiles, dont les communications initiales se trouvent sur les sites d’ADELI.org et ont été publiées en anglais sur le site de AgileAlliance.com avant que les aspects commerciaux ne l’emportent et que les ressources gratuites aient été supprimées.

Tout en respectant les apports des approches qui l’ont précédé, PUMA s’affirme donc comme la première formalisation d’une nouvelle génération de méthodes globales et « à la carte ».

Note : Les entreprises qui s’engagent dans une approche Agile sont généralement surprises par le nombre et la profondeur des changements nécessaires. Les difficultés rencontrées lors de la mise en œuvre de l’Agilité sont toujours le reflet de l’incapacité de l’organisation à accepter de résoudre ses conflits internes.


PUMA Essentiel en pratique

La simplicité d’une méthode détermine son adoption, aussi la structure de PUMA s’appuie sur la métaphore du moteur pour limiter à quatre le nombre de ses éléments Essentiels.

Pour réussir un projet, au-delà d’une motivation rationnellement obtenue des personnes impliquées, il faut réunir quatre ingrédients essentiels : communication, structuration, méthode, technicité. C’est sur la base de ce simple constat que PUMA Essentiel vous propose un cadre élémentaire basé sur 4 moteurs Agiles de réflexion et d’action :

1. Un moteur de Communication pour faciliter l’engagement et le consensus.

2. Un moteur de Solution pour structurer l’expression des exigences et la formalisation de la solution.

3. Un moteur de Pilotage pour gérer la performance de l’engagement.

4. Un moteur de Réalisation pour assurer la qualité fonctionnelle et technique de la solution.

Chacun de ces 4 moteurs s’appuie simplement sur 4 pratiques Agiles basiques pour couvrir dans le cadre d’un développement, le scope complet des aspects humains, organisationnels, économiques et techniques. Les quatre moteurs ne sont pas obligatoirement utilisés dans chaque projet.

1. Le moteur de Réalisation est basé sur des pratiques de conception-développement de type « XP » qui seront utilisées dans le cas de projets portant sur le développement d’une application. Si le projet n’est pas un développement, un autre processus spécialisé lui sera substitué.

2. Le moteur de Projet est basé sur un pilotage itératif-incrémental et des pratiques Agiles (estimation, priorité, risque) ainsi que sur des techniques de gestion de réunion, de monitoring, de reporting mural (Information radiator, BurnDown chart, etc.).


3. Le moteur de Solution se caractérise par un modèle utilisé naturellement par les utilisateurs en ayant acquis les concepts. En revanche, son utilité n’apparaît que lorsque la problématique est suffisamment complexe pour justifier l’effort initial de l’apprentissage et de la mise en œuvre de ses pratiques.

4. Le moteur de communication sera utilisé systématiquement par les utilisateurs en maîtrisant les pratiques. Son utilité devient évidente en environnement organisationnel difficile.

Chaque moteur (parfois de simples modèles d’organisation ou de structuration d’un document) est instrumenté par 4 pratiques Agiles.

Le moteur de pilotage est basé sur Scrum et celui de réalisation dépend du type de projet.


Figure 19. — Les 4 « moteurs » de PUMA Essentiel


Le moteur de Communication

Il a pour but d’obtenir un engagement formel des diverses ressources impliquées dans le projet. Il préconise aussi des techniques d’entretien et une structure d’organisation des réunions :

1. Initialisation du Projet (acceptation charte et planification des incréments de documentation).

2. Pré-session (organisation d’un entretien).

3. Session (traitement des thèmes).

4. Post-session (alimentation du plan de développement (ou backlog)).

À l’inverse, lors de la construction de l’application, ce sont des relations faiblement structurées, plutôt basées sur la disponibilité régulière et l’implication personnelle, qui sont recherchées entre les binômes de développement et leurs utilisateurs de référence.

Figure 20. — Moteur de communication


Le moteur de Solution

C’est en fait un modèle de document structuré par les quatre classes de préoccupations représentatives de la nouvelle Expression des Exigences :

1. Aspects Stratégie et Contraintes.

2. Aspects Fonctionnels.

3. Aspects Technologiques.

4. Aspects Organisationnels.

Figure 21. — Moteur de Solution

Ces aspects s’explorent dans l’ordre fondamental précisé. En revanche, et toute la complexité relative de l’opération ainsi que sa pertinence résident dans ce principe, ils doivent, afin de prendre en compte la globalité des interrelations et des dépendances induites, être appréhendés globalement et de manière itérative.


Généralement l’exploration se limite à quatre niveaux de profondeur itérative :

1. Vision.

2. Cadrage.

3. Spécifications.

4. Services.

Note : Dans les petits projets, un seul niveau du type de l’étape d’exploration XP peut s’avérer suffisant.

Les Exigences sont, dans un premier temps, considérées comme des « Visions », pour devenir par affinement des « Cadrages », puis des « Spécifications » et finalement des « Services ».

Le moteur de Pilotage et le moteur de Réalisat ion

Ces deux moteurs sont le plus souvent couplés, ils représentent souvent à eux seuls un outil suffisant pour répondre aux besoins de développements simples dans un contexte organisationnel léger. Le développement se compose alors de deux groupes de pratiques, l’une liée au pilotage des itérations et l’autre à la construction de l’application. Environnement de collaboration avancée

Environnement de collaboration avancée

Les plus récentes études réalisées sur les pratiques Agiles (Stephanie Teasley, Université du Michigan) démontrent que le travail en équipe sur un plateau projet dédié double au minimum la productivité des développements par rapport au travail réalisé par la même équipe travaillant dans un environnement de bureau conventionnel. « Cet avantage est essentiellement obtenu par l’extrême fluidité des communications et l’intensité de la collaboration. »


Figure 22— Reporting mural et métrique du changement

Information Radiator

Utilisant généralement les murs du plateau projet, accessible et visible par tous, le radiateur d’information agrège en un point unique les informations clés du projet et présente en temps réel ses principaux indicateurs d’avancement et ses principaux freins.

Un Information Radiator efficace conjugue une surface et un positionnement permettant à toute l’équipe d’avoir une vision utile de l’information affichée. Facile à interpréter et à mettre à jour, il permet de :

conserver le focus sur l’information opérationnelle ;

mettre en exergue les ralentissements et les retards ;

réduire les pertes de temps liées au reporting.

Un radiateur d’information complet n’implique pas un investissement autre que la volonté de le mettre en œuvre et de le maintenir.


Expression des exigences

Les méthodes Agiles actuelles s’appuient sur de nouvelles formes d’expression des exigences : récits d’utilisateur, matérialisés synthétiquement sur des Post-it.

Au recto on trouve, la fonctionnalité exigée sous la forme d’un « récit utilisateur » (ou une référence de localisation), sa priorité attribuée par l’utilisateur et le temps estimé par l’équipe pour sa réalisation.

Au verso l’utilisateur précise les conditions d’acceptation de cette fonctionnalité. Cette fiche peut aussi supporter des précisions complémentaires : niveau de risques, modification de la demande, réévaluation, etc.

Un récit est une exigence du système à développer (ou une référence de localisation), formulée en une ou deux phrases dans le langage de l'utilisateur. Il est aussi possible d’utiliser les cas d’Utilisation si une expression des besoins en UML a été modélisée.

La notion de « récit » peut amener à une forme d’estimation en « points de récits ou de complexité » mais pour des raisons


d’expériences pratiques, j’utilise personnellement l’estimation en « ideal days » (même s’il n’y a pas beaucoup de journées vraiment idéales). La fiche d’expression d’un besoin est simple.

Note : L’ideal day est exactement l’inverse d’une journée idéale durant laquelle le développeur ne serait pas perturbé par son environnement ou autres freins et obstacles.

Mais attention, Points de Récit (User stories) et Cas d’utilisation ou (Use cases), même s’il s'agit de deux modes de représentation des exigences utilisées par les méthodes Agiles, n'ont ni la même portée, ni le même niveau de détail :

Le Récit se décrit en une courte phrase (Rôle -> But) alors que le Cas d’Utilisation est beaucoup plus riche en informations. Il possède un Titre (le but), est lié à un Acteur, propose un résumé, et surtout, décrit un déclencheur, un scénario nominal, les variations à ce nominal, des options alternatives, ainsi que tous les cas d'erreur et leur mode gestion. Il peut décrire aussi les règles métiers et les données.

Le Récit propose uniquement un but, pas une séquence d'actions. Il se lit donc plus facilement.

Le Récit correspond souvent et seulement à l'un des scénarios (nominal ou alternatif) du Cas d’Utilisation, parfois à une simple activité utilisateur.

Note : lire à ce sujet Jean-Claude Grosjean (qualitystreet.fr).

Estimation Agile

Certains modèles d’estimation sont dérivés des approches classiques et d’autres, entièrement nouveaux, ont émergé de l’expérience des projets réalisés en approches Agiles.


Le Planning poker game

Le Planning Poker permet à une équipe d’estimer la charge de développement d’une fonctionnalité.

Une estimation ne nécessite pas une précision absolue, mais raisonnable. Par contre cette étape est le moment idéal pour l’équipe d’approfondir sa compréhension des fonctionnalités à développer.

Note : J’ai encore récemment initié des estimations en Planning poker game dans plusieurs grands comptes, dont des groupes du CAC40. Je peux vous assurer que non seulement cela fonctionne dès la barrière du changement franchie, mais qu’en plus les participants apprécient la responsabilité qui leur est confiée et se sentent engagés par leur estimation.

Figure 23. — Deux formes d’estimations complémentaires

Note : Mes cartes de Planning Poker sont disponibles en format Word (recto/verso) sur Wikipédia Il suffit de les imprimer sur un support rigide puis de les « massicoter ».


Planification Agile

La planification selon Scrum se limite à une priorisation opérationnelle du développement par le propriétaire du produit.

Pour d’autres approches Agiles, d’autres niveaux de planification sont envisageables en fonction de l’importance ou de divers impératifs :

Au niveau stratégique du projet : une pratique de simulation et d’optimisation en matière de choix de planification permet de faire évoluer des scénarios en fonction des diverses contraintes (délais, coût, périmètre, qualité, visibilité, risque). L’intérêt principal de cette pratique réside dans la mise en évidence immédiate des incidences de chaque option antagoniste envisagée.

Au niveau de la mise en œuvre opérationnelle de l’applicatif : deux approches basées sur les techniques de conception « en vue de modification » et justifiées par des critères technico-financiers (vélocité du changement / ROI d’usage) sont envisageables. Ces deux aspects peuvent être imbriqués à des niveaux fractals différents, et ils impliquent des stratégies de planification distinctes :

Le développement par la stabilité des objets.

Le développement par thèmes utilisables.

Au niveau des itérations de développement : les opérations de hiérarchisation des besoins ou de priorisation des fonctionnalités sont de la responsabilité du client mais font l’objet d’un consensus avec les informaticiens qui disposent des connaissances permettant la mise en évidence des dépendances techniques. Cette pratique se matérialise par des choix de développement (par thèmes utilisables ou par stabilité temporelle des composants).


Reporting Agile

La gestion d’une véritable approche itérative et adaptative nécessite la comptabilisation des changements. Pour l’équipe projet, c’est la seule technique raisonnable pour autoriser le client à modifier à tout instant ses demandes.

Figure 24. — Burndown chart (avancement et calcul vélocité)

Il est souvent nécessaire de disposer d’une colonne matérialisant des découpages en tâches techniques et toujours indispensables de conserver un groupe de lignes en bas du tableau pour maintenir visuellement la trace des changements ayant affecté la planification initiale.

La charte projet

S’engager dans une approche Agile représente un risque non négligeable qui nécessite, pour être réduit, d’établir au préalable un cadre régissant les rapports entre les parties. Un contrat Agile décrit des responsabilités.

Il n’est pas non plus inutile de se souvenir que la bonne formulation d’un contrat, même de principes et même concernant un développement Agile, reste la pierre angulaire de bonnes relations tout au long d’un projet.


Les techniques Agiles apportent réellement un plus dans la capacité de gérer les changements, mais elles n’incluent pas de recettes miracles aux problèmes que les hommes rencontrent lorsque leur responsabilité est mise en cause.

Communication de l’équipe projet

La communication de l’équipe projet se base sur la publication permanente de l’avancement dans son Radiateur d’information mural. À chaque fin de période de développement (sprint pour Scrum), la présentation du travail réalisé se fera lors de « Shows ou Focus » de visibilité et de validation.

La communication externe est considérée comme un facteur additionnel de réussite. Une newsletter, même sommaire, est indispensable.

Pour un petit projet, une ou deux pages publiées une ou deux fois par mois, en fonction de la durée du projet, sont suffisantes. À travers quelques lignes, graphiques ou dessins, le projet prend vie, et les futurs utilisateurs se l’approprient. Surtout lorsque, trop nombreux, ils ne peuvent pas tous participer aux spécifications. La publication régulière est aussi synonyme de bonne santé, c’est-à-dire d’avancement.

Note : Il faut d’emblée exclure toute langue de bois de ce type de communication. Sinon, la plupart des gens ne sont pas dupes, et, très rapidement, c’est toute l’autorité qui est sapée à travers le mensonge.


Les 12 pratiques « qualité » de XP

XP utilise la programmation comme une discipline collective. Voici une synthèse des 12 pratiques fondamentales de XP présentées dans la chronologie de leur mise en œuvre.

1 - Le planning est un consensus entre le client et le développeur. Comme pour le Risk Driven Development, il est procédé par priorités (parfois techniques lorsque liées à des dépendances, mais plus fréquemment fonctionnelles). Le développeur se focalise uniquement sur les buts principaux et diffère le traitement des objectifs secondaires. Le principe de « courage » s’applique dans les négociations avec le client, lors des éventuelles divergences.

Technique : Planning Game. Le client produit des scenarii d'utilisation et les priorise. Ces scénarios sont ensuite implémentés par l'équipe de développement. Le projet est considéré comme achevé lorsque le client n'est plus en mesure de trouver un nouveau scénario.

2 - Les équipes XP emploient des métaphores. La métaphore est une abstraction de niveau élevé. La métaphore ne doit pas être une simplification abusive du concept initial, mais doit permettre de simplifier l'expression d'une chose complexe comme, par exemple, clarifier des fonctionnalités. Le mérite d’une métaphore est d'être synthétique et parlante.

Technique : Les métaphores sont utilisées pour décrire le système et son fonctionnement avant la livraison de fonctionnalités réelles, afin de le rendre compréhensible par les non-informaticiens et les utilisateurs impliqués dans le développement.


3 - L’application est rapidement disponible dans une version limitée. La phase de construction se compose d’itérations structurées en étapes (spécifications courtes, développement, tests, retour du client). Le fonctionnel est décrit en brefs scénarios implémentables validés immédiatement par le client. Le risque d’incompréhension est alors réduit au minimum. Les modifications peuvent être fréquentes mais concentrées dans un cycle très court. L'objectif est de disposer rapidement d'un pilote opérationnel. Les parties applicatives livrées pourront éventuellement être utilisées en fonctionnalités réduites si les dépendances d’autres parties non livrées ne sont pas trop fortes.

Technique : Releases fréquentes. Elles permettent un feed-back immédiat, tout en offrant des fonctionnalités validées pouvant être utilisées. Fréquence de livraison hebdomadaire.

4 - Le design est simple et focalisé sur les besoins actuels. Sans préfigurer des évolutions fonctionnelles ultérieures (non exprimées), le développeur code l'essentiel, en se basant sur les besoins immédiats et dans l’ordre de leurs priorités.

Technique : Planification initiale basée sur la valeur ajoutée des fonctionnalités attendues. Conception et codage simples, afin de faciliter les évolutions futures en rendant le produit aisé à comprendre et à modifier. Livraisons en fonctionnalités réduites. Documentation minimale adaptée aux besoins réels.


5 - Développement en binôme. Deux ressources de développement travaillent simultanément sur l’implémentation du même code. À tour de rôle, elles programment et valident la qualité afin de produire un code propre, robuste et fiable. Dans certains projets, les développeurs s'associent en binômes uniquement lors des séances de refactoring (comme pour la méthode RAD), ou lorsque le problème est particulièrement ardu. Cette pratique est associée à celle de la rotation des binômes. L’ensemble est considéré comme la forme Agile la plus performante d’apprentissage collectif et d’intégration des débutants.

Technique : Les programmeurs XP travaillent en binôme sur la même machine. Le premier développeur (appelé driver ou pilote), a la responsabilité du clavier et travaille sur la portion de code à écrire. Le second développeur (appelé partner ou copilote) l’assiste en suggérant des options ou en décelant d'éventuels problèmes.

6 - Appropriation collective du code. L'équipe est collectivement responsable de l'application, elle est donc supposée avoir connaissance de l'intégralité du code. Selon cette théorie, la qualité de l’ensemble du code est de la responsabilité de l’ensemble des programmeurs. Cette pratique accroît la qualité effective du code, la réutilisation, la compréhension, et supprime les principaux problèmes liés au turnover.

Technique : Les développeurs réorganisent fréquemment les binômes, ce qui permet d'améliorer la connaissance collective de l'application et la communication au sein de l'équipe.


7 - Rythme soutenable. Les ressources fatiguées commettent des erreurs toujours plus coûteuses à corriger a posteriori.

Technique : Planning individuel n’impliquant pas d'heures supplémentaires durant deux semaines d’affilée.

8 - Le client collabore en permanence et en direct. Afin d'assurer une meilleure réactivité et un feed-back rapide, un représentant du client doit être présent pendant toute la durée du projet. Cette ressource dédiée au projet est chargée de déterminer les besoins, de fixer les priorités et de valider les recettes.

Technique : Un représentant permanent du client est présent sur le site. Ce représentant doit maîtriser les connaissances pratiques d'un utilisateur final, tout en disposant d’une vision globale du résultat à obtenir. C’est en général un cadre opérationnel.

9 - Standards de codage. Pour faciliter l'appropriation collective de l’applicatif, la réutilisation et la communication, les programmeurs codent, dans un style et avec des règles identiques (normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.).

Technique : Standards de codage, frameworks, design patterns, convention de nommage, etc.


10 - Un logiciel XP est testé et validé en permanence. XP préconise, pour la partie technique, la programmation pilotée par les tests (TDD) : pour chaque classe de l'application, les développeurs écrivent une classe chargée de la tester et de vérifier le résultat de ces tests.

Technique : Jalons Zéro-Défaut par Test-Driven Development sur la base de tests issus d’une translation de bas niveau des tests d’intégration.

Les fonctionnalités sont pour leur part validées en test de recette (avec et par l’utilisateur).

Technique : Jalons Zéro-Défaut par finalisation des validations permanentes obtenues de l’utilisateur lors du prototypage.

11 - Intégration continue. Les modules développés sont assemblés journalièrement ou à la fin du codage de chaque jalon. La version de départ d’une nouvelle implémentation de code à jour s’effectue ainsi sur un applicatif stabilisé.

Technique : Jalons Zéro-Défaut par intégration permanente de configurations testées. Construction planifiée en petits modules intégrés et testés progressivement. Pratique de plusieurs intégrations journalières, si nécessaire.


12 – Refactoring du code. Au cours du développement, le code est remanié continuellement et progressivement. Le logiciel est propre et simple. Dans le cas contraire, les correctifs sont beaucoup plus coûteux, la conception se corrompt, le code se fragilise, et l’application se déstructure.

Technique : Refactoring par amélioration continue de la qualité du code sans en modifier le comportement (commentaire, respect des règles de nommage, simplification, etc.). Le résultat du « nettoyage » s’effectue régulièrement et se valide lors de séances de travail collectif impliquant toute l'équipe.

Les pratiques Agiles de qualité du code (particulièrement le Pair programming) génèrent un coût de réalisation de l’ordre de 20 % supérieur à celui d’un développement classique. En retour, elles réduisent notablement le nombre d’erreurs résiduelles de l’applicatif à sa mise en exploitation, selon une l’étude Strengthening the Case for Pair-Programming.

Organisation Agile et

ressources humaines

Dans l’entreprise à la recherche de performance, l'approche classique d'une hiérarchie appliquant des contrôles verticaux fait place à l'engagement de tous dans un processus horizontal orienté « services ». Les motivations théoriques des deux principes sont identiques, mais les moyens divergent pour une qualité de résultats sans commune mesure.

L’important c’est l ’équipe

L’équipe, c’est la synergie et la complémentarité de professionnels engagés dans un succès commun. Ce seul point justifierait un livre complet (comme celui de la communication d’ailleurs). Voici quelques principes fondamentaux dont la mise en œuvre requiert néanmoins volonté et expérience autant que moyens réels. Ils seront détaillés plus loin.

D é v e l o p p e r u n e c u l t u r e d u d é f i :

Définir précisément le défi à relever.

Formaliser la récompense.

Enrôler l’équipe : donner le choix de l’engagement.

Organiser l’autonomie de l’équipe (moyens).

Publier l’avancement global des résultats.

Surveiller le tarissement de l'enthousiasme.

Fêter l’accomplissement des jalons significatifs.


D é v e l o p p e r u n e c u l t u r e d ’ e n t r a i d e :

Favoriser l’émergence de signes d’identité de l’équipe.

Récompenser informellement les signes de solidarité.

Mesurer individuellement l’échange de services.

Éliminer les craintes du « demandeur ».

Stopper immédiatement les réactions négatives.

Focaliser les récompenses sur les résultats d’équipe.

M o t i v a t i o n s e t c o n d i t i o n s d ’ o p é r a t i o n

La totalité du cycle de développement doit être réalisée par une équipe de base, totalement engagée dans son projet et en total accord avec la méthode qu’elle emploie. L’équation Performance = Qualité + Motivation est au cœur de la culture Agile.

La base de l'équipe de développement Agile est un petit groupe de professionnels expérimentés qui doit avoir le sens de son identité. James Martin, le fondateur du courant Agile, déclare : « Ils doivent disposer de locaux spécialement aménagés et décorés, et la réalisation des engagements doit donner lieu à des célébrations, leur coordonnateur surveillera tout signe précurseur de burn-out. »

L ’ e n g a g e m e n t s i m u l t a n é d e s r e s s o u r c e s

Point crucial : les ressources doivent intervenir simultanément dès le début réel du projet. Leur compréhension est alors globale et unique. Les utilisateurs ne sont alors pas sollicités à plusieurs reprises. La formalisation et le transfert d’information s’en trouvent minimisés ainsi que les risques d’erreurs inhérents à ces activités. Si le projet est conséquent, ces ressources se spécialisent dans un sous-projet pour entrer « just-in-time » dans le flot du détail.

Dissocier la spécification du développement laisse place à l’interprétation et à l’erreur. Cette étape est non seulement coûteuse, mais les documents produits sont souvent inutilisables dans un développement moderne.

À l’exception du descriptif du périmètre global, dans un projet informatique, tout besoin détaillé doit s’exprimer lors du


développement et être documenté directement dans le code de l’application (comme les cas de tests). Cela implique un effort de formation de la part de la maîtrise d’ouvrage si elle souhaite spécifier elle-même ses exigences dans une forme directement utilisable par la maîtrise d’œuvre. En attendant cette MOA idéale, le principe Agile propose un renforcement des liens entre les informaticiens de l’équipe et les utilisateurs.

Fanatiques de la performance

La démocratie dans une équipe Agile s’exprime par une direction collégiale étendue à tous les participants. Une décision prise, son exécution est immédiate, et, comme l’équipe entière a participé au choix, aucune remise en question personnelle n’est admise. Cet engagement implique la constitution préalable d’une « vraie » équipe Agile, c’est-à-dire composée d’acteurs expérimentés, maîtrisant la méthode et soucieux du succès de leur mission.

Après plusieurs projets Agiles, les choix généraux de développement sont acquis par tous, seules les décisions spécifiques au projet nécessitent encore parfois des séances d’approbation. Dans un groupe bien rôdé, la bonne foi et la logique président à chaque décision. Dans le cas où l’esprit de l’équipe Agile est dénaturé d’une manière ou d’une autre, il est préférable de quitter le projet. Laisser la situation dégénérer par faiblesse (crainte de perte du contrat par exemple pour un consultant) se termine toujours mal, et il est ensuite trop tard pour dégager sa responsabilité. À l’inverse, participer à l’action d’une équipe de fanatiques de la performance et de la réussite de projets est la plus belle chose qui puisse arriver à un développeur.

L’entreprise Agile vit au rythme de ses projets, et l’énergie de cette dynamique assure son existence.

Dès 1982, établi au Canada et travaillant à l’occasion pour des entreprises américaines, je commençais à saisir la profonde différence de philosophie qui guide l’action du Français et celle du Nord-Américain. Le Français se tourmente et s’empêtre dans une


vaine recherche de conceptualisation alors que le Nord-Américain se contente de réaliser ce qu’il croit possible. « Just do it », telle est sa devise empirique et pragmatique.

Porteur ce cette philosophie, le mouvement Agile se consacre à l’essentiel et offre la possibilité d’atteindre la puissance simplificatrice. Alors tentons de simplifier, et dans la limite de notre action, prenons pour devise « be Agile ».


Point sur l’ état de l’art Agile

2016

Le rêve de l’élargissement de l’Agilité à l’ensemble des composantes des organisations n’a jamais été aussi près de son effritement technique. Avec l’échec de Scrum, incapable de déborder de la simple gestion de sprint, c’est vers le Lean Développement que se tournent maintenant les consultants. Cette variante du Lean se caractérise par une nouvelle tentative de pseudo socialisation du travail basée sur une forme de démocratie d’entreprise. En résumé, de grandes idées mais pas évidentes à concrétiser. Les vœux pieux du genre « si tout le monde se parle, cela ira mieux » (ce qui n’est pas forcément faux par ailleurs), sont insuffisants et conduisent le plus souvent aux déceptions d’un passé connu : Lean, Cercle de qualité, MTQS, etc. Il faut malheureusement constater que c’est uniquement la facilité de cette dernière approche qui semble pour l’instant prévaloir. C’est un peu comme si des incantations pouvaient résoudre des problèmes insolubles et les trois colonnes de Scrum assurer le succès des projets complexes. Il est navrant de constater que seul l’eXtrem Programming, a publié une approche de qualité logiciel en 1999 et que depuis, plus rien de fondamental n’a émergé officiellement du mouvement agile.

Je plaide donc pour une extension technique du concept Agile étendu qui irait bien au-delà de la simple conduite de projets. Ce besoin émerge directement de clients qui souhaitent l’agilité globale de leurs entreprises, sans arriver à saisir à partir de nos écrits actuels en quoi cela peut bien consister dans le concret. Rien ne me navre plus que de leur dire : « Officiellement nous avons du Scrum qui permet de contrôler les projets sur la base d’un lotissement par incréments et du XP si nous


souhaitons de l’itération, donc de la qualité applicative ; mais rien d’autre officiellement accepté. »

Pourtant je ne rejette pas ces deux méthodes, bien au contraire, car au-delà de la simple conduite de projet, même si elles s’avèrent insuffisantes, elles n’en demeurent pas moins utiles. En revanche, il est maintenant nécessaire de dépasser le contexte des projets et s’attaquer à régler les grands problèmes de la pérennité de nos entreprises. Il me semble possible de s’appuyer sur les valeurs Agiles actuelles pour les compléter et les spécialiser si nécessaire. Y compris en y intégrant des réflexions de types psychologiques, car la production industrielle par exemple n’a pas de rapport totalement similaire à la gestion d’une petite équipe de projet informatique. Ce que je rejette en revanche, avec l’expérience de ces tentatives de coller des approches étrangères (asiatiques généralement) sur nos cultures professionnelles occidentales européennes ou nord-américaines, c’est le bla bla et le pipeau généralisés.

Redécouvrant le Lean (qui je le rappelle date de la dernière guerre), de nombreux consultants se qualifiant d’Agiles présentent ces nouveautés englobées de réflexion sur les nouvelles formes de démocratie d’entreprise, ce qui conduit à faire ressembler de plus en plus les manifestations Agiles à des congrès de psychanalystes en mal de clients.

Je peux comprendre que les professionnels souhaitent se trouver une porte de sortie de l’impasse où nous a plongé l’abandon des penseurs paralysés par l’omniprésence de Scrum, mais cette évolution ne se fera pas avec des théories d’arrière-garde ressuscitées des abandons du passé. Ma dernière et grande question est simple : où sont, au présent, les chercheurs qui doivent concrétiser le futur technique des méthodes ? Je conseille fortement à tous ceux qui souhaitent dépasser le blocage actuel de jeter un œil sur PUMA Essentiel, c’est gratuit et si cela peut insuffler quelques idées je n’aurais pas perdu totalement mon temps à communiquer sur ce futur qui se présente si inquiétant mais si passionnant.

En conclusion


Comme on le comprend, l’informatique dynamise l’évolution et la conditionne. L’organisation essaie de répondre aux attaques en accroissant sa compétitivité, mais l’inertie et le conservatisme de sa structure freinent tout effort visant à l’améliorer comme à la déstabiliser. Cet état réactionnaire ne serait pas mortel dans un monde fermé aux communications et aux échanges. Malheureusement, l’ordinateur sur votre bureau est d’origine américaine, votre indispensable Windows est américain, Internet est américain.

Dans la recherche d’une réponse adaptée, certains pensent que miraculeusement, une approche méthodologique Agile permettrait d’aller plus vite sans remise en cause de l’organisation des développements. Il n’en est rien. La lecture de tous les ouvrages traitant du sujet démontre au contraire que la réussite Agile est avant tout la mise en œuvre d’une organisation parfaite des développements. Depuis, il est devenu tout aussi évident que la réussite des nouveaux projets implique simultanément la réorganisation de la fonction informatique et celle de la fonction à informatiser. Ce constat n’est d’ailleurs pas le fait d’Agile uniquement. Il découle d’une vision pragmatique de la qualité de service intimement liée à la compétence des cadres opérationnels. C’est dans cet esprit qu’il faut comprendre la notion de « Qualité : pensez globalement » et la critique d’un constat d’absence de « voie royale ».

L’homme est faillible. Aussi, des processus formalisés lui sont-ils indispensables à la maîtrise de son action. Il lui faut ensuite une farouche volonté ou obligation de les respecter et l’intelligence de les adapter. De ces contraintes naît la capacité de piloter dans la qualité et la performance les activités les plus complexes. C’est au prix de cet « état de l’art » et à celui de la simplification que le professionnel obtiendra finalement l’amélioration d’une réussite de projet qui visiblement et statistiquement lui fait toujours défaut.


L’énergie du rythme

Il y a un long chemin à parcourir avant d’arriver à un système optimal dans la plupart des organisations.

En disséquant par le détail les techniques mises en œuvre par le mouvement Agile, certains seront déçus de ne rien découvrir de totalement nouveau ou miraculeux. Effectivement, le bon sens ramène les concepts les plus théoriques de l’Agilité à de simples améliorations des pratiques managériales.

Pas de miracle, mais une évolution conduisant à une dynamique de projet :

Amélioration des modes de communication.

Adaptation des pratiques de pilotage.

Perfectionnement des techniques de conception.

Optimisation des conditions de réalisation.

Mais, au-delà d’une simple progression de l’état de l’art, ce qui est essentiel dans ces changements, c’est le rythme qu’ils induisent à notre réflexion :

Rythme de l’engagement des utilisateurs.

Rythme des modes d’entretiens.

Rythme de la dimension temporelle.

Rythme des Shows de livraison.

Dans un environnement en évolution accélérée, les dynamiques issues de la communication facilitée, de l’organisation repensée et des systèmes d’information fluidifiés entrent en synergie et s’imposent comme l’énergie du rythme.

Rythme du changement, rythme gagnant, rythme Agile.


Liste des mots « clés »

A Amérique du Nord · 101

autonomie · 99

autorité · 92

B binôme · 22, 95

C classes · 96

collectif · 98

collégiale · 101

communication · 95, 96, 99, 106

communication

espace · 22

qualité · 92

compétitivité · 18

composants · 90

compromis · 18

consultant · 16

contraintes · 90

coordinateur · 100

culture

entraide · 50, 52

D De La Palisse · 19

dérive

stat. · 16

dimension temporelle · 43, 106

dimension temporelle

phase · 20

dynamique

applicative · 22

de projet · 22

E échec

de projet · 17, 21

responsabilité · 18

économie · 16, 52

Emmanuel Etasse · 32

engagement · 99

entraide · 22, 50, 52

eXtrem Programming · 27, 28

F Focus

communication · 92

fonctionnel

conformité · 23

coordonateur · 22

couverture · 51

formation · 101

formation

swat · 51

G gaspillage · 23

I Information Radiator · 86

J James Martin · 72, 100

Jean-Claude Grosjean · 88

Jeff Patton · 43

K Kent Beck · 28

M maintenance

applicative · 51

module · 50

prévue · 50

Manifeste Agile · 30

meeting · 85

métaphores · 93


méthode de conduite de l'évolution ·

23

moteur de Communication · 80, 83

moteur de Pilotage · 80, 85

moteur de Réalisation · 80, 85

moteur de Solution · 80, 81, 84

P périmètre

modélisation · 100

Points de Récit · 88

projet type · 19

prototypage

spécifications · 23

publication · 53, 92

PUMA Essentiel · 74, 77, 79, 80, 82

Q qualité · 95, 98

R RAD · 95

RAD2 · 26

réactivité · 96

récompense · 52

relations interpersonnelles · 22

Releases fréquentes. · 94

ressource

disponibilité · 51

gaspillage · 23

ROI · 90

Ron Jeffrie · 28

rythme · 106

S Scrum · 73, 74, 76, 78

sociologique · 34

spécialiste-généraliste · 22

spécification

détaillée · 23

structuration

phasage · 21

structure

(Top-Down) · 23

SWAT · 100, 101

SWAT

composition · 22

systémique

conception · 23

T TDD · 97

temps partiel · 51

typologie

projet · 19

U utilisateur

engagement · 21

V valeur ajoutée · 94

vélocité · 90, 91

W War Room · 85

X XP · 93, 95, 97


Liste des Illustrations

Figure 1. — Méthode RAD 25

Figure 2. — Quatre variables de planification et d'ajustement 26

Figure 3. — Méthode RAD (Construction) 27

Figure 4. — Avantages obtenus par l'organisation Agile 33

Figure 5. — Principales techniques réellement utilisées 34

Figure 6. — Principaux freins et causes d'échec 35

Figure 7. — Comprendre l’incrémental et/ou l’itératif 42

Figure 8. — L'itératif combiné à l'incrémental 43

Figure 9. — Adaptatif et son coût (« full iteratif ») 44

Figure 10. — La structure du Post-it vraiment utile 46

Figure 11. — Reporting mural et métrique du changement 47

Figure 12. — La forme efficiente du reporting Agile 48

Figure 13. — Bien formaliser une User Story 49

Figure 14. — Le plateau projet type 50

Figure 15. — Éléments de la problématique « taille équipe » 52

Figure 16. — Scrum vision globale du processus 56

Figure 17. — Quelques techniques manquantes à l’Agilité 72

Figure 18. — Le meilleur des mondes ou l’inverse 75

Figure 19. — Les 4 « moteurs » de PUMA Essentiel 82

Figure 20. — Moteur de communication 83

Figure 21. — Moteur de Solution 84

Figure 22— Reporting mural et métrique du changement 86

Figure 23. — Deux formes d’estimations complémentaires 89

Figure 24. — Burndown chart (avancement et calcul vélocité) 91


Bibliographie principale

Ambler (S), Agile Modeling : Effective Practices, Wiley, 2002.

Beck (K), Extreme Programming, Campus Press, 2002.

Beck (K), Test Driven Development, Pearson Education, 2003.

Cohn (M), User Stories Applied, Addison-Wesley, mars 2004.

Debrauwer (L), Design Patterns, Editions ENI, 2007.

Evans (E), Domain-Driven Design:, Addison Wesley , 2002.

Fowler (M), Patterns of Enterprise Application Architecture, Addison

Wesley, 2002.

Greenfield (J), Short (K), Cook (S), Kent (S), Software Factories,

Wiley, 2004.

Hammer (M), Champy (J), Le Reengineering, Dunod, 2000.

Kerievsky (J), Refactoring to Patterns, Addison Wesley, 2004.

Cross (T), Maîtriser les projets avec XP, Cépaduès Éditions, 2004.

Cohn (M), Agile Estimating And Planning, Prentice Hall, 2004.

Larman (C), Agile and Iterative Development, Addison Wesley, 2004.

Madoz (J-P), L'amélioration continue, Afnor, 2005.

Meszaros (G), Unit Test Patterns: Refactoring Test Code, Addison-

Wesley, 2007.

Newkirk (JW), Vorontsov (A), Test-Driven Development in.Net,

Microsoft ,2004.

Schwaber (K), Agile Project Management with SCRUM, Microsoft

Press,2004.

Vickoff (J-P), Systèmes d’Information et processus Agiles, Hermes,

2003.

Vickoff (J-P), Estimations et Architectures développements Agiles,

Hermes, 2005.

Vickoff (J-P), Méthode Agile, QI, 2009.

Vickoff (J-P), RAD, MacMillan, 1996.

Williams (L), Kessler (R), Pair Programming Illuminated, Addison

Wesley, 1990.

Documents

L’ère d’une informatique de moyen s’achève et … · Lean Office. Simultanément, porté par les réseaux, le client-serveur et les interfaces graphiques, ... Le paradigme