Agile-Entreprise.com

Avril 03, 2008

Comparatif Scrum, XP, PUMA

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.

L’Agilité des systèmes d’information est en marche. Ferez-vous le bon choix en fonction de votre contexte et de vos besoins spécifiques ? Les informations du tableau suivant vous guideront dans cette recherche.

Scope des pratiques Agiles	SCRUM	XP	PUMA
Recueil élémentaire des besoins Simple liste ou fiches de récits utilisateurs	OUI	OUI	OUI
Gestion systémique des exigences Formalisation Agile d’un document structuré mais élémentaire	NON	NON	OUI
Gestion formelle des communications complexes Organisation, charte projet, plan de communication, techniques optimisées de maîtrise de réunions en contexte difficiles.	NON	NON	OUI
Estimation de charges Agiles niveau « équipe » Axée sur la vision des intervenants, typiquement : planning poker game	OUI	OUI	OUI
Techniques et outillage d’estimation de charges Agiles Basées « métriques » standardisées (points de Cas d’utilisation, de récits, de scénarios, d’objets WEB, Evaluateur, etc.)	NON	NON	OUI
Pilotage des niveaux d’itérations d’un projet	OUI	MINIMA	OUI
Gestion des réunions « équipe »	OUI	OUI	OUI
Techniques extrêmes de qualité du code	NON	OUI	OUI
Techniques standards mais formalisées et structurées de qualité de la conception et du codage	NON	NON	OUI
Approche globale simplifiée (PUMA Essentiel)	NON	NON	OUI
Justifications financières agiles et formelles	NON	NON	OUI
Techniques Agiles de suivi des risques externes	NON	NON	OUI
Techniques simples d’amélioration du processus Agile (Lean management)	OUI	OUI	OUI
Rapprochement avec des bases ou processus normés (CMM)	NON	PARTIEL	OUI
Disponibilité de Frameworks Agiles (architecture globale d’entreprise, techniques de veille technologique, SOA, BPM)	NON	NON	OUI

Mais attention, si quelques heures d'information permettent de sensibiliser, il n’y a pas de « voie royale » pour appliquer :

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.
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.

Posted by Jean-Pierre Vickoff at 15:52:59 | Permanent Link | Comments (0) |

Mars 10, 2008

Le mythe de l'itératif sans concession

En matière de conduite de projet de SI, selon les théoriciens, deux formes de méthodes s’opposent :

· L’une dite « en cascade » se réfère du rationalisme cartésien et du prédictif.

· L’autre dit « itérative » se réfère du pragmatisme empire et de l’adaptatif.

En 1994, je communiquais sur une forme intermédiaire : le semi-itératif.

Le cascade trouve ses limites face a plusieurs problème dont l’un des moindres est le fait qu’en termes d’exigences, seuls 18% des applicatifs sont en mesure d’être définis précisément en début de projet. J'ai lu des déclarations au sujet de l’approche cascade qui prétendaient qu’elle était itérative « puisqu’elle se composait de plusieurs étapes et qu’elle acceptait une étape de prototypage après des étapes de spécification ».

J’ai aussi lu des déclarations au sujet des méthodes Agile qui prétendaient qu’elles étaient « tellement itératives que même leur modèle d'origine, la méthode RAD, n’était pas assez itérative ».

Note : Une méthode totalement itérative-incrémentale-adaptative nécessiterait que le client et l’informaticien se serrent la main et commencent immédiatement à développer.

Qu'en est-il dans la réalité des projets Agiles ? Et bien, ils commencent par une phase d’exploration, ils déterminent les besoins sous la forme d’une liste de fonctionnalités, les utilisateurs précisent ensuite leurs priorités, les informaticiens estiment la charge, on prend en compte les risques et l’architecture technique existante ainsi que les contraintes d’outils ou de normes en vigueur dans l’entreprise, on planifie lle développement. C'est généralement à ce point que la réalisation débute. Comme aurait-dit Belmondo « Et hop cascade ».

D’ailleurs pour illustrer cette « vérité » voici les processus des 2 principales méthodes se réclamant du « plus itératif que ca tu meurs » :

Le cycle « full » itératif n’existerait donc pas ? On nous aurait menti à l'insu de notre plein gré ? Et si, comme X-Files, la vérité était ailleurs ? Dans une approche semi-itérative ou les acteurs se donneraient un temps de réflexion avant de passer à l’action ?

Posted by Jean-Pierre Vickoff at 15:59:46 | Permanent Link | Comments (0) |

Janvier 07, 2008

Le Mythe du périmètre variable

De nombreux principes Agiles me semblent mal compris dans leur finalité. La notion de périmètre variable est le premier que je vais aborder. J’ai choisi cette technique qui est peut-être la plus mal interprétée par les informaticiens et la plus controversée par les utilisateurs.

Récemment dans une conférence, un utilisateur questionna « Est-ce que cela signifie que je n’aurais pas toute mon application ? ». Très naïvement le conférencier lui répondit « Exact, c’est cela le principe Agile ». Attristant pour l’utilisateur, amusant pour moi, mais dangereux pour un prestataire face à son client.

La première chose à comprendre concernant l’Agilité face aux contraintes d’un projet est justement la notion de contraintes. En synthèse le chef de projet doit composer avec 4 grandes classes de contraintes : le coût, le délai, le périmètre et la visibilité. Dans les approches classiques, la notion de visibilité n’était pas intégrée mais le chef de projet avait déjà pas mal à faire avec les trois autres qui ne pouvaient absolument pas être initialement variables, du moins en théorie. En pratique, le temps et les aléas du projet finissaient régulièrement par ramener ces ambitions prédictives à ce qu’elles étaient réellement : des vœux pieux.

L’apport de J. Martin avec la méthode RAD fut d’énoncer le premier postulat Agile, à savoir que pour une prédiction de projet puisse se réaliser à tous les coups, il fallait que certains aspects du pilotage soit fixes et que d’autres soient variables. Il proposa donc des techniques pour gérer les diverses variantes possibles de ces situations :
- Un délai fixe (dead line) est imposé : utilisez une Time-box pour limiter la durée des itérations.
- C’est le budget qui est fixe : utilisez le Design-to-cost (l’équivalent du backlog en « Agile moderne »).

Figure 1. - Les formes Agiles de planification stratégique

Lorsqu’en 1994, j’introduisis les notions additionnelles de visibilité, de risque et de fiabilité (ou de qualité) comme variables d’un projet, la couverture Agile venait de s’étendre à la notion de planification stratégique.

Comme, bien évidemment, aucune de ces variables ne pouvait être totalement indépendante des autres et que leur combinatoire devait pouvoir être facilement adaptée, je créais un utilitaire (Evaluateur, toujours disponible sur RAD.fr) permettant de faire varier simplement les quatre curseurs.

Figure 2. - Petit outil d'optimisation combinatoire

L’ensemble des contraintes se matérialisait, en termes de développement, par un périmètre priorisé déterminant des itérations. Cette « Architecture de réalisation » fondée sur le principe itératif incrémental adaptatif connue ses lettres de noblesse en 1999 dans un rapport de conseil du Gartner Group qui lui était dédié. Il est amusant de constater que cette approche tombée en désuétude n’a toujours pas grand-chose à envier au couplage actuel de Scrum à XP (à l’exception de l’extrême systématisation des pratiques dans XP).