Agilité Puma

2013
2 PUMA - PROCESSUS URBANISANT LES METHODES AGILES
Le développement agile se caractérise par un style de

conduite de projets itératif, incrémental et adaptatif.
Son action est centrée sur l’autonomie de ressources
humaines impliquées dans la spécification, la production
et la validation d’une application intégrée et testée en
continu.
Approche de troisième génération, PUMA Essentiel
offre une mise en œuvre simple et élégante de l’Agilité
dans les projets conséquents ou les environnements
complexes
Jean-Pierre Vickoff 2013 Entreprise-Agile.com

PUMA ESSENTIEL - METHODE AGILE DE 3
EME
GENERATION
3

L’Agilité, c’est le passage du mode collaboratif au mode coopératif

Présenter le mouvement Agile, ses valeurs, ses principes, ses
pratiques, ses méthodes ainsi que leurs avantages et en proposer
une synthèse assortie d’une instrumentation fédératrice et
complète, tels sont les objectifs des 32 pages de ce petit livre.
Mais attention, il n’y a pas de « voie royale ». Ne vous laissez pas
leurrer par les deux jours de formation du « scrumaster certifié ».
C’est mieux que rien, mais si le principe fait le bonheur des chefs de
projets coupés du développement, il en faudra beaucoup plus pour
développer une expertise et une culture opérationnelle de l’Agilité.
Sachez par contre qu’une formation, un sérieux coaching et de
nombreuses semaines de pratiques sont nécessaires à des
concepteurs-développeurs expérimentés avant qu’ils n’aient acquis
fonctionnellement les techniques de l’eXtrême Programming.
Prises indépendamment, les méthodes agiles actuelles sont
incomplètes. D’une part, bien que parfaites pour répondre à un
besoin basique, elles ignorent la notion de cohérence systémique.
D’autre part, même en joignant les pratiques collaboratives de
Scrum à l’ingénierie du logiciel XP, le résultat, s’il est acceptable
pour des projets moyens, reste encore loin de satisfaire les besoins
des organisations conséquentes ou les solutions complexes.
Enfin, il serait illusoire de penser que la culture française assimilera
sans réticence ni problème la brutalité d’une mise en œuvre directe
de ces techniques américaines.
Pourtant, il ne tient qu’à vous d’appliquer sérieusement l’agilité à
vos projets pour en sécuriser le déroulement, en maîtriser la
performance et assurer la qualité fonctionnelle et technique de vos
applications. Voici les raisons qui m’ont amené à proposer à la
communauté Agile une approche de troisième génération, élargie,
libre et ouverte.
Jean-Pierre Vickoff

EME
GENERATION
5
Table des matières
Les trois vecteurs de l’Agilité ........................................... 6

Agile : histoire et évolution ............................................. 7
Les origines des méthodes Agiles 7
Adaptatif versus prédictif 12
Des chiffres pour comprendre et convaincre 14
L’agilité et le développement applicatif 15
PUMA Essentiel (développement des SI) ....................... 19
Les « moteurs » ne sont pas des phases 21
Techniques associées au couplage des moteurs 25
Prochaine étape : l’entreprise Agile ............................... 27
Le manifeste de l’entreprise Agile 27
Les vecteurs de la dynamique d’entreprise 28
Orientation service et processus métier 28
L’Agilité est fractale 30
Vers le professionnalisme et l’industrialisation 31
L’énergie du rythme 32

Les trois vecteurs de l’Agilité

Une Entreprise est fonctionnellement Agile lorsque ses composants
opérationnels collaborent en synergie formelle à anticiper ou à capter
le changement, aux fins de le compenser dynamiquement, puis de
l'intégrer. L’Agilité représente donc la dynamique de l’organisation
réactive et apprenante. L’Agilité, paradigme d’une nouvelle vision de
l’organisation, s’affirme alors comme un outil d’alignement et de
cohérence entre les forces internes et les défis externes qui dynamisent
l’entreprise. En pratique, l’Agilité se matérialise par une orientation
« services » et s’instrumente dans la conjonction de trois vecteurs
indissociables :
la motivation rationnelle des ressources humaines,
des processus configurés en continu,
l’usage intensif des nouvelles technologies.
Figure 1. — Dynamique de l'Agilité
Au niveau de projection supérieur se trouve l’hyper Agilité. Son atteinte

nécessite une forme opérationnelle de pro-activité : la veille
collaborative. Elle s’instrumente par l’anticipation rationnelle d’un
futur immédiat dont l’intérêt des évolutions émergentes est évalué
sous la forme d’une balance entre catalyseurs et inhibiteurs. Afin
d’élargir le scope des méthodes actuelles au management global,
PUMA Entreprise a pour ambition d’instrumenter cette recherche en
intégrant l’impact des NTIC dans l’organisation de mutations Agiles et
concourantes appliquées à l’orchestration des processus, à l’adaptation
des ressources humaines et, in fine, à l’architecture de l’entreprise en
évolution.
Au niveau opérationnel, l’engagement Agile permet de gérer la
complexité de détail en détectant les émergences de nouveaux besoins

EME
GENERATION
7
et les réponses immédiates à leur donner [Madoz, 2005] ; ce qui

permet de déterminer les points d’inflexions du changement au niveau
stratégique (et non l’inverse). L’Agilité nécessite alors, autant qu’elle
permet, d’abolir les distances entre partenaires. Selon G. Balantzian
« L’Agilité apporte aussi des éclairages et des solutions à divers
problèmes découlant de comportements humains pouvant paraître
irrationnels. Créatrice d’unité, l’Agilité pose les fondations d’un cercle
vertueux de l’engagement qui se matérialise initialement dans une
fierté d’équipe et aboutit à l’évolution de la culture de l’organisation
qui accepte de la mettre en œuvre. »
Pour l’équipe projet de développement, l’Agilité c’est avant tout
l’acceptation du changement dans la transparence d’une métrique
objective de celui-ci et la garantie d’un mode gagnant-gagnant pour
elle et pour son client. L’Agilité est aussi la capacité d’aller à l’essentiel.
En résumé et pragmatiquement, l’Agilité initie la transition d’un mode
collaboratif classique, donc individualisé, vers un mode réellement
coopératif par agrégation de toutes les actions, de leurs responsabilités
et de leurs récompenses à un niveau global.
Agile : histoire et évolution

Les origines des méthodes Agiles
C’est en 1986 que débutent des communications qui se limitent à
quelques pages, sur ce qui constitue aujourd’hui les bases du génie
logiciel itératif, incrémental. En 1991, la première méthode itérative
incrémentale intégrant l’aspect adaptatif fut présentée par James
Martin sous le nom de Rapid Application Development. En 1995 Ken
Schwaber reprit dans une courte communication de 3 pages la
métaphore du Rugby et une partie des techniques de conduite de
projet de la méthode RAD (1991) pour décrire succinctement les
fondements de ce qui deviendra la méthode Scrum : une méthode
générique de conduite de projets n’incluant pas de pratique de génie
logiciel. En 1999 Kent Beck publiait XP (eXtrem Programming) et en
2001, après l’Agile Manifesto, Ken Schwaber faisait équipe avec Mike
Beedle pour décrire officiellement le contenu de la méthode dans le
livre Agile Software Development With Scrum.
Ce qui caractérise une méthode adaptative, c’est sa capacité à accepter
les changements dans le cadre d’une métrique formelle de ceux-ci.
La méthode RAD, à l’instar de toutes les autres méthodes Agiles qui lui
ont succédé, reposait sur un cycle de vie semi-itératif, une construction

incrémentale et des techniques adaptatives (à l’instar de XP ou de

1
Scrum d’ailleurs Figure 5). Cet aspect est souvent mal compris des
néophytes qui pensent que le RAD ne serait pas itératif et que Scrum
ou XP le serait totalement.
L’agilité en matière de développement d’applications c’est avant tout le
paradigme de l’adaptabilité dans le cadre d’un cycle projet itératif et
incrémental. Les notions sous-jacentes à ces principes sont
fréquemment mal comprises. La métaphore du tableau de la Joconde,
choisie par Jeff Patton (Erreur ! Source du renvoi introuvable.) pour
matérialiser individuellement ces concepts est particulièrement
pertinente.
Figure 2. — Itératif / incrémental (Jeff Patton)
Afin de visualiser le principe les combinant, je propose sur cette base le

montage suivant (Figure 3) 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.
1
Lire à ce sujet le billet : Le mythe de l'itératif sans concession sur
http://agiles.blog.com

EME
GENERATION
9
Figure 3. — L'itératif combiné à l'incrémental
A 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 il serait achevé. La figure suivante
illustre l’addition du concept « adaptatif ». Au-delà des apparences :
conforme aux nouveaux besoins.
Figure 4. — Le concept "adaptatif"
Ce qui caractérise une méthode itérative, c’est sa capacité à planifier

une itération de production en termes de fonctionnalités et
d’interdépendances.
Figure 5. — Les méthodes Agiles sont semi-itératives
Le mode semi-itératif est indispensable à la plupart des projets (lire à

ce sujet « The Decline and Fall of Agile » sur le blog de James Shore). Le
mode semi-itératif préserve en début de projet une réflexion minimum

sur les contraintes du projet, l’expression globale des exigences, les

impacts organisationnels, l’architecture ainsi que l’estimation initiale et
la planification des itérations.
Figure 6. — Semi-Itératif, Incrémental, Adaptatif
Parallèlement en France, la méthode RAD parvenait en 1999 à la

2.
maturité d’une deuxième génération Commandé et publié par le
Gartner Group à Jean-Pierre Vickoff, RAD2 s’appuyait sur la
formalisation de modes opératoires des techniques utilisées et d’un
processus léger et adaptable recherchant la compatibilité avec le CMM
niveau 5.
RAD2 détaillait, étape après étape, la conduite de projet adaptative. De
plus, ce n’était pas seulement le périmètre applicatif qui pouvait servir
3
de variable d’ajustement , mais la modulation de plusieurs facteurs
distincts (délai, ressource, visibilité, qualité, coût, périmètre)
permettant une planification stratégique fine adaptée aux exigences du
projet et de l’application envisagés.
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
2
Comme XP et Scrum sont largement publiées, les rappels sur RAD ont pour
but d’apporter une vision historique.
3
En réaction aux débordements de temps et de coûts, facteurs d’ajustement
des méthodes classiques.

EME
GENERATION
11
l’application. XP peut donc enrichir ou se substituer à la phase

Construction (Figure 7) de la méthode RAD ».
Figure 7. — Méthode RAD (Construction)
Une itération RAD comprend sa planification priorisée en terme de

fonctionnalités à produire, ses validations permanentes (fonctionnelles
et techniques), sa livraison et sa rétrospective (Focus ou Show). La
notion de prototypage « actif » recouvre la production et la « validation
permanente » d’un produit livrable. Les itérations « Jalons ZD » (pour
Zéro Défaut) correspondent aux tests, validations et intégrations
journalières.
Les « emprunts » de Scrum à la première des méthodes Agile, le RAD,
sont aisés à mettre en évidence à travers les techniques et même leurs
dénominations, qui n’ont pas été adaptées à la métaphore du Rugby,
mais conservent les aspects « commando » du RAD (SWAT, War Room,
etc.). Voila une simple petite synthèse des pratiques les plus en vue :
L’équipe : Team pour Scrum et SWAT Team pour RAD (SWAT à
l’origine du mot : Special Weapons And Tactic ou dans le cas
informatique : Skill With Advanced Tools). La composition de
l’équipe est identique et se limite dans les deux cas au client, aux
informaticiens de développement et à un facilitateur nommé
Animateur pour le RAD ou Scrumaster pour Scrum.
La salle de travail se nomme War Room aussi bien pour le RAD
que pour Scrum (on notera que cette dénomination militaire
correspond à la salle de travail du SWAT).

Le reporting mural : même usage des murs avec, pour Scrum et

XP, l’avantage indéniable de l’évolution formelle de cette
pratique.
La planification est adaptative et essentiellement basée sur la
valeur pour l’ensemble des méthodes. La comparaison s’arrête là
pour Scrum car le RAD, qui est une approche dédiée aux
développements applicatifs, prend en compte plusieurs autres
interdépendances techniques ou besoins exprimés et propose
une planification stratégique incluant des variables de contraintes
pour compléter la priorité basée sur la valeur ajoutée.
Les réunions : Morning meeting pour le RAD, Stand Up meeting
pour Scrum
Les retrospectives : Focus de fin d’itération (ou Show) pour le RAD
et « de fin d’itération » pour Scrum. Rétrospectives de fin de
projet pour Scrum et post-mortem de projet pour le RAD
(rarement fait dans le cas d’équipes externes).
Note : Ces quelques points représentent un simple historique et une

comparaison entre les méthodes Agiles actuelles et leur souche
commune, le RAD, désormais pratiquement en désuétude en tant que
méthode commercialisée.
Adaptatif versus prédictif
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, qui démontrait que les méthodes Agiles avaient un socle
identique.
Pour faire suite, fin 2001, je rédigeais la communication initiale traitant
de PUMA (Proposition pour l'Unification des Méthodes Agiles) qui,
partant du socle commun, mettait en exergue l’intérêt des éléments
différenciateurs dans des contextes spécifiques. Sa traduction fut alors
expédiée aux tenants du mouvement Agile et aux universités
américaines.
Pour une entreprise ou une organisation, la notion d’Agilité caractérise
l’aptitude à s’adapter. Cette qualité détermine une démarche
d’évolution essentiellement basée sur :
La motivation rationnelle des ressources humaines, permettant de
gérer en continu la complexité de détail ;

EME
GENERATION
13
L’usage intensif des nouvelles technologies caractérisé par une

constante projection dans l'avenir, imposant l’alignement des
ressources et des processus sur cette innovation ;
Des processus reconfigurés en continu, aux fins d’adaptation
dynamique de l’organisation à l’accélération du changement.
L’agilité, composante essentielle d’un mouvement managérial basé sur
une vision réellement collaborative, s’affirme alors comme la
dynamique de l’organisation performante, réactive et apprenante. Au
niveau de projection supérieur se trouve l’hyper Agilité dont l’atteinte
nécessite une forme opérationnelle et instrumentée de pro-activité.
Note : Pour détail sur « Management Agile » consulter Wikipédia.

Pour l’employé, l’Agilité nécessite le développement d’une culture de
l’engagement généralement acquise sur la base d’un volontariat dans la
recherche d’amélioration de ses compétences.
Dans le domaine du développement d’application, l’Agilité se
caractérise par un cycle de conduite de projet itératif, incrémental et
adaptatif. Chaque nouvelle fonctionnalité est développée sur une base
saine de code. Elle est intégrée et testée en continu et fait l’objet d’un
feedback fonctionnel permanent. Ces techniques sont totalement mais
légèrement outillées pour permettre des évolutions fréquentes et sans
régression.
En 2003, seules 131 entreprises acceptaient de répondre au sondage
de l’Agile Alliance, mais elles étaient 4332 en 2006. Aux USA, 41% des
organisations ont déjà adopté une méthode Agile et 65% une ou
plusieurs techniques Agiles indépendantes.
En 2008, les développements classiques représentaient encore environ
75% des projets contre 25% pour les approches Agiles. Par contre, il
faut s’attendre, selon les prévisions de l’ensemble des cabinets de
prospective (dont le Gartner Group), à un équilibrage avant la fin de la
décennie et à un rapport inverse avant 10 ans.
Les principaux freins à l’adoption des méthodes Agiles sont le manque
de ressources expérimentées et la résistance naturelle au changement.
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 interne.s

Des chiffres pour comprendre et convaincre
La première question que se pose le manager face à l’Agilité concerne

l’avantage économique qu’il est possible d’en obtenir. Selon les retours
d’expériences récents, les gains de productivité, de qualité et la
réduction du délai de mise sur le marché sont considérables.
Note : La compression du temps est d’ailleurs souvent le facteur recherché par

les organisations devant faire face à un grand changement ou à une
problématique de différenciation concurrentielle. Généralement dans ce cas, le
facteur coût est d’une importance secondaire, alors même que les techniques
Agiles permettent d’accélérer considérablement le ROI.
Le cabinet Forrester analyse les résultats obtenus par des entreprises

pilotées sur la base de techniques Agiles et constate pour :
93% une productivité améliorée,
88% une nette amélioration de la qualité,
83% une progression évidente de la satisfaction des clients.
Le Gartner Group remarque que « les approches Agiles permettent
d’obtenir le leadership économique. Les principaux atouts de l’Agilité
mis en évidence sont les suivants :
Accroissement de la productivité par la motivation des ressources
impliquées dans une amélioration continue permettant de
supprimer les tâches inutiles ;
Amélioration drastique de la qualité par des pratiques extrêmes
d’ingénierie du logiciel (pilotage par les tests, etc.).
Réduction du « time to market » par la priorisation des tâches
porteuses de valeur ajoutée ;
Avantages compétitifs liés à la réactivité au changement par
l’adaptation immédiate de la solution aux besoins en évolution.
Pour Brian Hanly (British Telecom) : « En pratique, la valeur métier
obtenue au bout de 9 mois avec les approches classiques est réalisée
en seulement 3 mois avec une approche Agile. » Boeing : « plus que
surpris lui-même du résultat, le chef du premier grand projet Agile
annonce l’avoir mené à bien sur la base de 4 années-homme en regard
de 60 planifiées avec l’approche classique ». Chez Salesforce (85
millions de transactions journalières), l’ensemble du service recherche
et développement (200 personnes) est passé d’une méthode classique
en cascade à l'Agilité en 3 mois !

EME
GENERATION
15
L’agilité et le développement applicatif
En 1988, confronté aux limites des méthodes prédictives, B.W. Boehm

présente un modèle de développement itératif et incrémental. En
1989, J. Martin s’appuyant sur cette vision communique sur la méthode
RAD. Ses valeurs bases des approches Agiles actuelles, consistent en un
phasage simple et mettent en exergue le principe adaptatif. La même
année Jean-Pierre Vickoff (détail dans Wikipédia) initiait ses premiers
projets RAD à Hydro-Québec, puis Bell MC et Abbott. L’ouvrage RAD de
J. Martin fut publié en 1991. À partir de 1994, Jean-Pierre Vickoff en
France, notamment avec le Processus RAD2 publié par le Gartner
Group, et Jennifer Stapleton en Grande-Bretagne avec DSDM,
introduisent des compléments ou des adaptations à l’évolution des
formes de modélisation, des technologies et des normes.
En 2001, dix-sept chefs de projets Nord-Américains se réunissent pour
partager leurs expériences et étudier leurs méthodes respectives. Ce
travail fut formalisé dans un communiqué intitulé « Manifeste Agile »,
considéré désormais comme la définition canonique du développement
Agile et le point de départ de son essor commercial actuel. Le
Manifeste déclare 4 valeurs Agiles fondamentales :
1. L'équipe « Personnes et interaction plutôt que processus et
outils » : La compétence et la cohésion de l'équipe (SWAT Team)
sont plus importantes que les moyens matériels ou les procédures.
2. L'application « Logiciel fonctionnel plutôt que documentation
pléthorique » : Il est vital que depuis sa première fonctionnalité
l'application soit en état de « livraison permanente ». Le reste, et
notamment la documentation technique représente une charge de
travail aussi importante que secondaire. C’est avant tout le code qui
doit être abondamment commenté.
3. La collaboration « Collaboration avec le client plutôt que
négociation de contrat » : Le client est impliqué dans le
développement à toutes les étapes du projet. Il collabore avec
l'équipe et fournit un feed-back continu sur l'adaptation du logiciel
à ses attentes.
4. L'acceptation du changement « Réagir au changement plutôt que
suivre un plan » : La planification et la structure du logiciel sont
flexibles afin de permettre l'évolution permanente de la demande
« métier ». Les releases provoquant généralement des demandes de
modifications et d’évolutions.

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes

les méthodes agiles :
1. La priorité de l’équipe est la satisfaction du client par des
livraisons fréquentes et régulières d’un logiciel testé
techniquement en continu et validé fonctionnellement en
permanence.
2. Le changement est accepté et mesuré, même au cours du
développement, afin d’obtenir une adéquation fonctionnelle
optimale et un réel avantage compétitif pour le client.
3. Une application fonctionnelle est livrée régulièrement à
chaque itération (5 à 20 jours, en privilégiant les fréquences
les plus courtes).
4. Les gens du métier et les développeurs font partie d’une seule
équipe et collaborent quotidiennement au développement de
l’application.
5. Le projet s’initie par une charte formellement acceptée par
des personnes volontaires et motivées, disposant d’un
environnement de travail adapté et d’un soutien hiérarchique
réel.
6. Lors des entretiens d’exploration la présence simultanée de
tous les intervenants est impérative.
7. La seule mesure de l’avancement du projet est basée sur le
résultat des tests techniques et fonctionnels.
8. L’engagement des ressources respecte un rythme de
développement soutenable afin d’éviter, entres autres
désagréments, les erreurs coûteuses liées à la fatigue.
9. Les développeurs portent une attention continue à la qualité
de la conception (Design Patterns) et à l'excellence technique
(Tests driven development, refactoring, intégration continue).
10. La recherche de simplicité porte les valeurs de la qualité
applicative (fiabilité, performance, robustesse et élégance).
11. L’équipe est incitée à s’auto-organiser car il est constaté que
cette indépendance aboutit aux architectures, aux conceptions
et aux spécifications les plus efficientes.
12. Lors de « rétrospectives » régulières, l'équipe s’interroge sur
ses possibilités d’amélioration, puis ajuste ses pratiques en
conséquence (Lean).

EME
GENERATION
17
L es pr at iqu es c o mm u nes
Pr a tiq ues l ié es au x r es s o ur c es hu ma in es
1. Intégration de l’utilisateur final dans une équipe unique.

2. Groupes de travail disposant du pouvoir de décision.
3. Autonomie technique de l’équipe.
4. Spécification et validation permanente des Exigences.
L es pr at iqu es li é es a u p il ota ge d u pr oj et
1. Niveau méthodologique variable en fonction du contexte.

2. Pilotage par les enjeux et les risques.
3. Réalisation itérative incrémentale en « Jalons Zéro Défaut »
4. Recherche continue d’amélioration des pratiques.
L es pr at iqu es li é es à la qua lit é d e la pr od uct io n
1. Recherche d’excellence technique de la conception.

2. Expression visuelle d’une modélisation limitée à
l’indispensable.
3. Vision d’une documentation « nécessaire et suffisante ».
4. Normes et techniques raisonnables de qualité du code.
L’ensemble des méthodes Agiles préconise une équipe particulière, le
SWAT TEAM. Elle est concrètement motivée et spécialement outillée.
Elle se compose d'un profil unique de concepteurs-développeurs
formés à des spécialités techniques complémentaires. Le SWAT
travaille avec les utilisateurs dans une salle spécifique (War Room) où
les murs font office de cokpit de management de projet (Information
Radiator).
L es pr at iqu es di f fér e nci atr i c es
DSDM spécialise les acteurs du projet dans des rôles (propriétaire,

sponsors exécutifs, ambassadeurs, visionnaires, conseillers, etc.).
SCRUM préconise de courtes réunions régulières (stand-up meeting,
rétrospectives).

FDD particularise un guidage par la valeur métier (mission focused).
Note : Cet aspect se retrouve aussi dans la méthode RAD sous la forme des
objectifs de Show ou dans Scrum dans la notion d’objectifs de sprint (backlog).
XP pousse à l’extrême des techniques d’ingénierie du logiciel dans la
recherche d’un code de qualité (pair programming, refactoring, etc.),
XP propose aussi une approche de planification collaborative
matérialisée sous la forme d’un jeu intitulé Planning poker game.
Note : la méthode RAD utilise les même outils et techniques. Par contre, le RAD
après la phase d’acquisition de techniques communes, limite la programmation
en binôme aux parties les plus stratégiques ou complexes.
Le plus sérieux apport du RAD à la communication de projet et à la
formalisation des exigences applicatives fut le Groupe d'Animation et
de Rapport (GAR).
Le RAD dans sa version 2 (publiée par le Gartner Group) recommande
pour les grands projets, la variabilité de la taille et de la maturité des
groupes de travail en fonction des étapes afin d'optimiser
l'engagement des ressources et de préserver leur intérêt. Avec RAD 2,
l'organisation des réunions est basée sur un mode opératoire des
entretiens et sur des techniques de validation permanente. Un
processus compatible CMM est disponible l’arrêt d'urgence (Go/No-Go)
fait partie de la charte « projet ».
Ver s u ne mé th od e c om pl èt e et h o mo 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 maintenant AgileAlliance.com
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 »4.
4
Proposition de projets étudiants sur www.MyMethode.com

EME
GENERATION
19
PUMA Essentiel (développement des SI)
Dans la forme : la simplicité de la présentation d’une méthode et de

son usage est souvent déterminante de son acceptation. PUMA
Essentiel a donc été étudié afin que sa structure incite naturellement à
son adoption en limitant à quatre le nombre de ses éléments.
Pour réussir un projet, en plus de la motivation rationnellement
obtenue des personnes impliquées, il faut réunir quatre ingrédients :
1 - de la communication,
2 - de la structuration,
3 - de la méthode,
4 - de la technicité.
Une méthode efficiente doit donc s’attacher à mettre en œuvre cet
ensemble dans un cadre formel. 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, chacun étant instrumenté par
4 pratiques Agiles :
1. Un moteur de Communication pour faciliter l’engagement et le
consensus.
2. Un moteur de Solution pour structurer l’expression de l’exigence
et de la solution.
3. Un moteur de Pilotage pour gérer l’évolution de la performance
et de l’engagement.
4. Un moteur de Réalisation pour assurer la qualité fonctionnelle et
technique de la solution.
Chacun des 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.

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

EME
GENERATION
21
Les « moteurs » ne sont pas des phases
1. Le moteur de
Solution, par exemple,
n’est pas une phase
mais un modèle itératif
de structuration des
exigences. Il est mis en
œuvre (si nécessaire)
dans le cadre du
moteur de
Communication.
2. Le moteur de
Communication n’est
pas non plus une phase
mais lui aussi un
modèle itératif de
facilitation de la
communication en
environnement
sensible.
4. Le moteur de Pilotage spécialisé dans la conduite itérative

incrémentale du projet est le seul élément pouvant être
apparenté à une phase.
5. Imbriqué dans cette phase, un moteur de Réalisation pouvant,

dans le cas d’un développement spécifique, être basé sur XP
ou sur une structure moins extrême, n’est en fait qu’une
simple boîte à outils composée des meilleures techniques
actuelles de développement.
Note : plusieurs autres techniques d’animation ou de facilitation sont

disponibles dans la boîte à outils complète de PUMA.

22
Méthode Agile – Les meilleures pratiques
L e m ot eur d e C o m m uni cat io n

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 itérations).

2. Pré-session (organisation d’un entretien).
3. Session (traitement des thèmes).
4. Post-session (alimentation du plan de développement (liste de
fonctionnalités ou Backlog)).
A 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érences.
Figure 9. — Moteur de communication
L e m ot eur d e S olu ti o n
C’est un modèle 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.

23
Méthode Agile - Guide de mise en œuvre
Ces aspects s’explorent dans l’ordre fondamental précisé. Par contre, 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 de 1 à 4 niveaux de profondeur
itérative :
1. Vision.
2. Cadrage.
3. Formulation.
4. Service.
Figure 10. — Moteur de Solution
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 ».
Cet aspect est un point central en termes d’identification et de
granularité dans le cadre d’une architecture orientée services (SOA)
[Ambler] [Fowler] [Evans].

24
L e m ot eur d e P il ota g e et l e m ot eur d e R é alis a ti on
Figure 11. — Moteur de Réalisation
Des pratiques basiques essentielles guident la performance et la gestion

des itérations :
1. Expression des Exigences (liste des Récits utilisateurs) [Cohn].

2. Planification (priorité, estimation, risques).
3. Radiateur d’informations (Monitoring et Reporting).
4. Maîtrise de la Vélocité.
Dans le cas d’un développement spécifique, des pratiques basiques
mais essentielles garantissent la qualité du développement :
1. Pilotage par les tests.

2. Programmation en binôme et rotation.
3. Remaniement du code.
4. Intégration et assemblage (Build) continus.
Ces deux moteurs sont le plus souvent couplés et représentent souvent
à eux seuls un outil suffisant pour répondre aux besoins d’un
développement simple dans un contexte organisationnel léger.

25
Le moteur de réalisation est interchangeable

Les projets de SI ne se limitent pas à la programmation d’une
application spécifique. Afin de couvrir les diverses préoccupations d’un
chef de projet compétent et ouvert, PUMA prend en compte plusieurs
autres formes d’obtention de la solution. Le moteur de réalisation est
donc interchangeable et PUMA propose des techniques de :
développement en programmation extrême (XP),
développement structuré non extrême (figure 7),
développement à base de solutions ou de composants
(proposition en 7couches),
développement option « progiciel »,
développement encadré par processus (obligation, CMM, …).
Techniques associées au couplage des moteurs
Dans la plupart des organisations, le problème n’est pas tant la

réalisation ou la conduite du projet technique que la formalisation
d’une expression consensuelle des besoins et des responsabilités par de
nombreux intervenants. C’est de cette problématique que traitent les
moteurs de Communication et de Solution. Ces moteurs sont en fait des
modèles d’animation et de facilitation des relations interpersonnelles
qui se situent à la convergence de la plupart des problématiques
d’évolution de l’entreprise. Ils sont aussi de puissants moyens
d’enrichissement des modes de travail qui facilitent la fluidification des
communications ainsi que l’adoption du savoir être et du savoir-vivre
coopératif. Leurs impacts organisationnels dépassent notablement la
simple production d’une solution, aussi performante ou utile soit-elle.
Ils sont à la base de la dynamique applicative dans une approche de
pilotage « par la valeur métier ».
État de l’art en composition de solutions Agiles
Les méthodes Agiles actuelles se limitent à une recherche

d’amélioration des conditions du développement. Elles ne couvrent pas
l’agilité du système d’information par lui-même et encore moins au
contenu ou à l’opération des processus instrumentés. Même au niveau
du développement, ces méthodes ne prennent pas en compte les
aspects processus ou architecture, qui pourtant, de plus en plus
imbriqués, sont prédominants en regard de l’Agilité globale du SI.
En ce qui concerne les systèmes d’information Agiles et, plus
particulièrement, la vision métier et l’architecture applicative devant la
supporter, deux approches majeures collaborent complémentairement à la

26
recherche de la solution optimale, l’une, le management des processus

métiers (BPM), est liée à la maîtrise du processus opérationnel, l’autre,
l’Architecture Orientée Services (SOA), apporte une solution élégante et
urbanisée au développement des composants du système d’information :
Le BPM s’appuie sur la modélisation métier pour optimiser et adapter

l’ensemble des activités. En remodelant l’organisation autour des
processus composant le cœur de l’organisation, le BPM s’impose
comme le levier principal de la performance opérationnelle.
La SOA, par son approche de conception et de construction de services
sous la forme de briques applicatives indépendantes, facilite
l’instrumentation des processus. L’avantage de la SOA est de produire
des composants simples, modulaires et faiblement couplés, donc
permettant de recomposer rapidement l’agencement applicatif des
fonctionnalités qu’ils assurent.
Figure 12. — SOA Identification et granularité des services
Les projets de BPM comme de SOA font l’objet de groupes de pratiques

spécialisées de la conduite de projet PUMA. L’identification et la
granularité des « services » représentent la préoccupation essentielle
lors de la conception d’une SOA. PUMA propose en réponse deux
dérivations (Figure 12) effectuées à partir de deux modèles UML
s’autovalidant et une classification des composants des services
prenant en compte leur stabilité :

27
La dérivation fonctionnelle-organisationnelle (côté couche

présentation). Elle s’instrumente à partir des cas d’utilisation. La
granularité idéale du « service utile » correspond à la plus petite
décomposition d’un cas, dont la demande de « service » permet
d’obtenir en retour une information fonctionnellement utilisable,
c'est-à-dire un service complet de type « client-utile ».
La dérivation métier (sémantique /stabilité) (côté couche
données). Elle s’instrumente à partir des classes (ou E-R). La
granularité du « service utile » représente une possibilité de
composition entre des classes dont la portée sémantique avait
autorisé une mise en relation (généralement un objet métier
regroupement de classes fonctionnellement insécables).
Note : Ceci conclura la présentation courte et basique de l’Agilité du SI
au service de l’Agilité de l’organisation.
Prochaine étape : l’entreprise Agile

Le manifeste de l’entreprise Agile
A l’instar de l’Agile Manifesto malheureusement limité aux aspects du
développement applicatif, voici ce que pourrait être le manifeste de
l’entreprise Agile :
En matière de processus, la philosophie de l’entreprise Agile est
« The one best way » : les processus sont modélisés, simplifiés,
reconfigurés en continu.
En matière de ressources humaines, la technique de l’entreprise
Agile est « Empowerment » : l’autonomie des groupes de travail
assure la régulation globale des micro-changements.
En matière d’automatisation, le principe de l’entreprise Agile est
« High-tech, High-touch » : l’usage rationnel des technologies
émergentes est anticipé systématiquement.
En résumé, une vision réellement coopérative du management :
instrumentée par l’implication rationnelle de l’ensemble des
ressources humaines ;
permettant de maîtriser en continu la complexité de détail (aux
fins d’adapter dynamiquement l’organisation à l’accélération du
changement) ;
caractérisée par une constante projection dans l'avenir imposant
l'obligation d'innover perpétuellement en adaptant les structures
et les processus à cette innovation.

28
Les vecteurs de la dynamique d’entreprise
Une organisation est fonctionnellement Agile lorsque ses composants

opérationnels (ressources humaines, processus opérationnels,
systèmes d’informations et technologiques) collaborent en synergie
(formalisée et outillée) à anticiper ou capter le changement aux fins de
le compenser dynamiquement, puis de l’intégrer. L’entreprise Agile est
donc une communauté qui régule ses processus en continu [Badot,
1998].
Selon le Gartner Group, l’entreprise Agile doit être « temps réel,
orientée services et pilotée par les événements ». D'ici 2012 ce cabinet
de prospective prédit que 50% des DSI seront devenues des
prestataires de services business, alors qu'elles n'étaient que 5% dans
ce cas en 2004. Pour ce faire, les directions informatiques doivent se
départir de leur rôle de fournisseur de ressources technologiques pour
se concentrer sur les fondamentaux de l'activité d'une entreprise :
l'information, les processus et les échanges.
Dernier point, et cela constitue un avertissement primordial, si la notion
d’ « Architecture d’Entreprise » est un élément déterminant de l’Agilité,
il doit cependant être compris que la motivation rationnelle des
ressources humaines est absolument indispensable à l’atteinte
concrète de cet objectif.
Pour être Agile, l’entreprise doit maîtriser en continu les dynamiques
d’évolution du processus métier, des ressources humaines et du
système d’information. L’Agilité à ce niveau nécessite une projection
dans le futur qui doit être instrumentée par des techniques formelles
comme l’anticipation rationnelle.
Note : cette recherche, instrumentée par une pratique PUMA, permet
d’appréhender la dimension des évolutions technologiques ou
fonctionnelles en émergence et leurs impacts prévisibles sur les
composants de l’organisation.
Orientation service et processus métier
Appréhender l’architecture de l’entreprise sur la base d’une

modélisation formelle est un préalable indispensable à toute forme
d’action dans le domaine des processus. Par contre, il est vain d’en
chercher la clé d’évolution dans une approche axée sur la structure du
SI. La réponse n’est pas dans la structure mais dans la dynamique du
processus.

29
Plus précisément dans une double dynamique :

la première, au présent, est une réaction immédiate d’adaptation
opérationnelle du processus ;
la seconde, au futur immédiat, est une anticipation rationnelle des
évolutions technologiques et fonctionnelles.
La première préoccupation de l’entreprise Agile est une modélisation
stratégique des exigences « client ». Cette formalisation inclut l’état, au
présent et au futur immédiat, des solutions technologiques susceptibles
d’apporter une réponse opérationnelle.
La seconde préoccupation de l’entreprise Agile consiste en une
modélisation métier [Hammer et Champy, 2000]. Cette technique
permet à l’organisation de formaliser les processus devant supporter
ses missions. C’est seulement ensuite qu’apparaît la notion
d’architecture technique, qui s’applique à un système informatique ou
à un système industriel de production.
Figure 13. — Modèle d’Entreprise Agile
Afin de répondre à l’ensemble de cette problématique, PUMA propose

un modèle (ou une architecture) réellement global d’Entreprise Agile
(Figure 13). Cet outil organisationnel offre ainsi une réponse formalisée
et justifiée à la question : « En fonction de quoi et comment devons-
nous changer le processus, le SI ainsi que les compétences de nos
ressources humaines ? »
Malheureusement, pour l’heure, les méthodes Agiles actuellement
opérationnelles se limitent à la partie spécifique du développement des
applications. Dans sa version complète PUMA (Figure 14) dépasse le
cadre du développement d’applications spécifiques pour fournir des

30
réponses opérationnelles aux besoins des 6 modèles et des 9

interactions de l’entreprise Agile (Figure 13) ainsi qu’aux spécificités des
grands projets qui s’annoncent : processus (BPM) orchestrant des
appels de services (SOA).
L’Agilité est fractale

À l’instar de la qualité dont elle en est une composante de plus en plus
vitale, l’Agilité ne se décrète pas au plus haut des structures. L’Agilité
émerge de la base de la pyramide organisationnelle et en conquiert
patiemment tous les niveaux, car l’Agilité est fractale. Dans les grandes
organisations, le changement doit être véhiculé par une puissante
mutation organisationnelle.
Le problème de fond, c’est la formation, celle qui mène à l’expertise.
Réponse opérationnelle à des contraintes aussi importantes que celles
imposées par la mondialisation des échanges, le principe d’intelligence
collective sur lequel repose l’Agilité aboutira progressivement à la
généralisation des diverses formes de la hiérarchie plate.
Figure 14. — Du code à l'Entreprise

31
Vers le professionnalisme et l’industrialisation
La méthode bien comprise ne s’apparente pas au principe du tout ou

rien. Une démarche intelligente adapte le « niveau de service
méthode » à la typologie du besoin. Ce dimensionnement économique
de l’effort permet alors de préserver la base de rigueur indispensable
au pilotage des projets actuels « mouvants » ou sous contraintes.
Il est tout aussi indispensable au chef de projet de choisir avec
discernement la méthode dont le cycle sera le mieux adapté aux
exigences de sa future application. Ce véritable pilote du
développement doit désormais systématiquement en évaluer les
diverses formes d’obtention (progiciel, solutions, composants,
externalisation) sous l’angle des contraintes (budget, qualité, délais ou
ressources). De même, en matière de conception, le choix d’une forme
et d’un niveau de modélisation relève le défi d’une modélisation devant
s’adapter au spécifique de chaque problème. Le concepteur-
développeur compétent conçoit désormais « en vue de modifications »
et cherche les techniques de conception susceptibles d’intégrer le
changement, car une modélisation efficace doit évoluer en synergie
avec la réalité qu’elle décrit.
La valeur ajoutée est le credo de l’Agilité
Dans de nombreux domaines de l’informatique de gestion, la recherche
de la perfection et de la réduction complète du risque est une
dangereuse chimère. L’obtention d’une qualité relative dans un
contexte donné en fonction de contraintes précises est en fait le seul
but pouvant être atteint. Cet abandon de la notion de perfection est le
principe le plus difficile à accepter intellectuellement pour l’esprit
logique d’un rationaliste ou d’un informaticien. C’est pourtant la
recherche de l’absolu qui amène des projets à se perdre « corps et
biens ».
La gestion du budget en regard des fonctionnalités doit être le
problème de la maîtrise d’ouvrage et non celui de l’informaticien.
Refuser la demande d’un utilisateur n’est pas chose aisée, il est vrai.
Pour éviter le traumatisme d’un refus, il est préférable d’obtenir un
renoncement de sa part. Pour rendre cette situation possible, il faut
chiffrer le coût de chaque fonctionnalité. L’enveloppe budgétaire est
dans ce cas confiée à l’utilisateur. Celui-ci est alors conscient de son
budget en regard de ses besoins et s’impose des priorités.

32
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 :
1. Amélioration des modes de communication.

2. Adaptation des pratiques de pilotage.
3. Perfectionnement des techniques de conception.
4. 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 :
1. Rythme de l’engagement des utilisateurs.

2. Rythme des modes d’entretiens.
3. Rythme de la dimension temporelle.
4. 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.
Depuis la conférence Unix 95, ces deux paragraphes concluaient mes
interventions. Mais, comme l’a écrit au sujet de l’Agilité des équipes de
développement le premier président de XP France, en paraphrasant
une citation d’un artiste au sujet de la Samba « plus qu’un rythme, c’est
un état d’esprit. »
Désormais, il n’est pas exagéré de dire que, l’Agilité doit devenir une
culture.

Jean-Pierre Vickoff est un pionnier en matière d’évolution des
méthodes de développement du système d'information.
Dès la fin des années 1980, ses communications régulières sur
l’approche itérative incrémentale adaptative et plus
particulièrement sur la méthode RAD, le positionne comme l'un
des fondateurs de ce courant de pensée dont il est l’initiateur
francophone.
Avec PUMA, Jean-Pierre Vickoff propose une méthode Agile de

troisième génération complétant et urbanisant les méthodes
actuelles, ainsi qu’une extension de leur champ d’application au
domaine des architectures et du management Agile des
entreprises.
Photo JPV, 2006

Agile-Entreprise.com
[email protected]
2013
34
Bib li ogr a phi e pr i nc ip ale

Ambler (S), Agile Modeling : Effective Practices, Wiley, 2002.
Badot (O), Théorie de l'entreprise agile, L'Harmattan, 1998.
Beck (K), Extreme Programming, Campus Press, 2002.
Beck (K), Fowler (M.), Planning Extreme Programming, A. Wesley, 2001.
Beck (K), Test Driven Development, Pearson Education, 2003.
Cros (T), Maîtriser les projets avec XP, Cépaduès Éditions, 2004.
Cohn (M), Agile Estimating And Planning, Prentice Hall, 2004.
Cohn (M), User Stories Applied, Addison-Wesley, mars 2004.
Debrauwer (L), Design Patterns, Editions ENI, 2007.
Delbaldo (E), CMMi light, Editions AFNOR, 2008.
Evans (E), Domain-Driven Design:, Addison Wesley , 2002.
Fowler (M), Patterns Enterprise Application Architecture, A. 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.
Larman (C), Agile and Iterative Development, A.Wesley, 2004.
Madoz (J-P), L'amélioration continue, Afnor, 2005.
Martin (J.), Rapid Application Development, Macmillan 1991.
Meszaros (G), Unit Test Patterns: Refactoring Test Code, . Wesley, 2007.
Petit-Etienne (M) - Peyraud (Y.), Reengineering, Éd. d'organisation, 1996.
Schwaber (K), Agile Project Management with SCRUM, Microsoft,2004.
Stapleton (M), Dynamic Systems Development Method, A. Wesley, 1997.
Vickoff (J-P.), RAD, MGI 1994 et Macmillan 1996.
Vickoff (J-P.), RAD CMM UML, Gartner Group, 1999.
Vickoff (J-P), Systèmes d’Information et processus Agiles, Hermes, 2003.
Vickoff (J-P), Méthode Agile, Les meilleures pratiques, QI, 2009.
Williams (L), Kessler (R), Pair Programming Illuminated, A. Wesley, 1990
L es as s o ci ati ons pr o f es s i onn el les

35
L is te d es f igur es e t t abl eau x

Figure 1. — Dynamique de l'Agilité 6
Figure 2. — Itératif / incrémental (Jeff Patton) 8
Figure 3. — L'itératif combiné à l'incrémental 9
Figure 4. — Le concept "adaptatif" 9
Figure 5. — Les méthodes Agiles sont semi-itératives 9
Figure 6. — Semi-Itératif, Incrémental, Adaptatif 10
Figure 7. — Méthode RAD (Construction) 11
Figure 8. — Les 4 « moteurs » de PUMA Essentiel 20
Figure 9. — Moteur de communication 22
Figure 10. — Moteur de Solution 23
Figure 11. — Moteur de Réalisation 24
Figure 12. — SOA Identification et granularité des services 26
Figure 13. — Modèle d’Entreprise Agile 29
Figure 14. — Du code à l'Entreprise 30
Mes publications préférées
Speed COBOL, 1981 RAD, MacMillan 1996 PUMA, 2002

36

37
Communication de Jean-Pierre Vickoff

RAD QI Qualité Ingénierie
78920 Ecquevilly

38

Agilité Puma

Transféré par

Droits d'auteur :

Formats disponibles

Agilité Puma

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agilité Puma

Transféré par

Droits d'auteur :

Formats disponibles

2013

2 PUMA - PROCESSUS URBANISANT LES METHODES AGILES

Le développement agile se caractérise par un style de

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

L’Agilité, c’est le passage du mode collaboratif au mode coopératif

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

Table des matières

Les trois vecteurs de l’Agilité ........................................... 6

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

Les trois vecteurs de l’Agilité

Figure 1. — Dynamique de l'Agilité

Au niveau de projection supérieur se trouve l’hyper Agilité. Son atteinte

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

et les réponses immédiates à leur donner [Madoz, 2005] ; ce qui

Agile : histoire et évolution

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

incrémentale et des techniques adaptatives (à l’instar de XP ou de

Figure 2. — Itératif / incrémental (Jeff Patton)

Afin de visualiser le principe les combinant, je propose sur cette base le

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

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

A la fin de la première itération, un livrable utilisable est produit. En

Figure 4. — Le concept "adaptatif"

Ce qui caractérise une méthode itérative, c’est sa capacité à planifier

Figure 5. — Les méthodes Agiles sont semi-itératives

Le mode semi-itératif est indispensable à la plupart des projets (lire à

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

sur les contraintes du projet, l’expression globale des exigences, les

Figure 6. — Semi-Itératif, Incrémental, Adaptatif

Parallèlement en France, la méthode RAD parvenait en 1999 à la

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

l’application. XP peut donc enrichir ou se substituer à la phase

Figure 7. — Méthode RAD (Construction)

Une itération RAD comprend sa planification priorisée en terme de

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

Le reporting mural : même usage des murs avec, pour Scrum et

Note : Ces quelques points représentent un simple historique et une

Adaptatif versus prédictif

En 2001, aux États-Unis, dix-sept figures éminentes du développement

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

L’usage intensif des nouvelles technologies caractérisé par une

Note : Pour détail sur « Management Agile » consulter Wikipédia.

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

Des chiffres pour comprendre et convaincre

La première question que se pose le manager face à l’Agilité concerne

Note : La compression du temps est d’ailleurs souvent le facteur recherché par

Le cabinet Forrester analyse les résultats obtenus par des entreprises

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

L’agilité et le développement applicatif

En 1988, confronté aux limites des méthodes prédictives, B.W. Boehm

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes

Jean-Pierre Vickoff 2013 Entreprise-Agile.com

1. Intégration de l’utilisateur final dans une équipe unique.

1. Niveau méthodologique variable en fonction du contexte.

1. Recherche d’excellence technique de la conception.

DSDM spécialise les acteurs du projet dans des rôles (propriétaire,

Jean-Pierre Vickoff 2013 Entreprise-Agile.com