|
de votre performance |
|
| PUMA Essentiel |
|
|
Prises indépendamment, les méthodes agiles actuelles sont incomplètes. D’une part, alors qu’elles sont 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 logiciel d’XP, le résultat, s’il est acceptable pour les projets moyens, reste encore loin de couvrir les besoins des organisations conséquentes ou des solutions complexes.
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 PUMA Essentiel une approche élargie, libre et ouverte, construite sur les meilleures pratiques existantes qu'elle intègre, fédère et complète (voir le comparatif). PUMA Essentiel
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] : 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é fonctionnel et technique de la solution. Chacun de
ces 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.
Moteur de pilotage Scrum "like".Moteur de réalisation : soit XP, soit RAD2 (techniques structurées mais non extrêmes). Une mise en œuvre simple et élégante de l’Agilité Une méthode Agile ultime en termes de légèreté et de complétude. Quatre « moteurs » couvrent les besoins basiques - Le moteur de Réalisation est, basé sur des pratiques de conception-développement (pourquoi pas celles d’XP reconnues comme très performantes) 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 pur (un ERP par exemple) un autre processus spécialisé lui sera substitué. - Le moteur de Pilotage est basé sur des pratiques de pilotage itératives et incrémentales et des pratiques Agiles d’estimation des priorités, des charges et des risques ainsi que sur l’ensemble des recommandations Agile en matière de gestion de réunion, de monitoring et de reporting mural (War Room, Information radiator, BurnDown chart, etc.). - Le moteur de Solution se caractérise par un modèle utilisé systématiquement et naturellement par les utilisateurs en maîtrisant les concepts. Par contre, son utilité ne pourra initialement être comprise que lorsque la problématique sera suffisamment complexe pour justifier l’effort initial de l’apprentissage et de la mise en œuvre de ses pratiques. - Le moteur de Communication sera utilisé systématiquement et naturellement par les utilisateurs en maîtrisant les concepts. Par contre, son utilité ne pourra initialement être comprise que lorsque l’environnement organisationnel sera suffisamment difficile pour justifier l’effort initial de l’apprentissage et de la mise en œuvre de ses pratiques. Les deux derniers moteurs peuvent très bien s’appliquer à des projets d’organisation sans aboutissement informatique. Des « moteurs à quatre temps » Chaque « moteur » est basé systématiquement sur un groupe de quatre pratiques Agiles Voici le détail des pratiques préconisées pour chaque moteur.
Le moteur de Communication a pour but d’obtenir un engagement formel des diverses ressources impliquées dans le projet. Il préconise aussi des techniques et une structure d’organisation des réunions : 1. Initialisation du Projet (charte, itérations). 2. Pré-session (organisation d’un entretien). 3. Session (traitement des thèmes). 4. Post-session (alimentation PDL 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. Le moteur de Solution est structuré par les quatre classes de préoccupations désormais représentatives de la nouvelle Expression des Exigences : 1. Aspects Stratégie et Contraintes. 2. Aspects Fonctionnels. 3. Aspects Technologiques. 4. Aspects Organisationnels. 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 la « profondeur itérative » se limite[2] à quatre niveaux : 1. Vision. 2. Cadrage. 3. Spécifications. 4. Services. 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 ». Ce dernier aspect est un point central en termes d’identification et de granularité dans le cadre d’une architecture orientée services (SOA). Plusieurs autres techniques d’animation ou de facilitation sont disponibles dans la boîte à outils complète de PUMA. L’une d’entre elles, le principe de la documentation par « espaces », est citée infra. Les moteurs de Pilotage et de Réalisation représentent souvent à eux seuls un outil suffisant pour répondre aux besoins de développements applicatifs raisonnablement simples entrepris dans un contexte organisationnel raisonnablement léger. Le développement se compose alors de deux groupes de pratiques, l’une liées au pilotage des itérations et l’autre à la construction de l’application.
Des pratiques basiques essentielles permettent la gestion des itérations : 1. Expression des Exigences (backlog). 2. Planification (priorité, estimation, risques). 3. Radiateur d’informations (Burndown chart) 4. Maîtrise de la Vélocité. Des pratiques basiques essentielles garantissent la performance et la qualité de la conception-développement : 1. Pilotage par les tests. 2. Programmation en binôme et rotation 3. Refactoring. 4. Intégration et build continus Couplage des moteurs - Détail des 4 ponts multi-relationnels
La mise en œuvre de PUMA Essentiel
Mettre en
œuvre des pratiques Agiles dans une organisation nécessite un plan d’actions
aussi simple que rigoureux : 1.
Evaluer l’état actuel et
décrire les objectifs souhaités. 2.
Anticiper les effets
directs et collatéraux des changements. 3.
Elaborer et obtenir un
consensus sur le plan d’action. 4.
Mettre en œuvre les
pratiques Agile et en mesurer les effets. En résumé,
après diagnostic des pratiques réelles, les techniques Agiles recherchées (QuickWins)
donnent lieu à une formation et s'implémentent par coaching.
L’efficacité obtenue est ensuite mesurée par monitoring. L’énergie du rythme
PUMA s'appuie sur les fondements du
mouvement Agile et sur les meilleures pratiques, communes ou différenciatrices
des méthodes les plus connues, qu'il fédère et complète. Par son large
périmètre, PUMA offre à ces méthodes initialement limitées au
développement applicatif, l’accès à un niveau supérieur d’organisation en
matière d’évolution Agile des entreprises. PUMA est donc un guide de mise en œuvre de
l'Agilité globale et offre une réponse à la question : en fonction de quoi
et comment devons-nous changer le processus, le SI, ainsi que les compétences
des ressources humaines. Le détail fait l’objet de nos conférences et formations Contactez Jean-Pierre Vickoff 06 09 03 01 27
[1] Dans le quotidien des entreprises, cette présence simultanée des conditions minimales de réussite est très rarement observée. - [2] Dans les petits projets, un seul niveau du type de l’étape d’exploration XP peut s’avérer suffisant.
|
