Dimitri Baeli d’eXo Platform m’a fait suivre un article publié sur le site IBM DeveloperWork à propos d’APMM, The Agile Process Maturity Model. Dans cet article, Scott Ambler propose une échelle de classement des processus Agile afin d’aider à identifier selon votre organisation la solution la plus adaptée. Son point de vue est « one does not fit all », une solution ne peut convenir à tout le monde, à l’ensemble des problèmes d’une organisation.
L’article original en anglais est disponible à cette adresse, la traduction reprend le contenu en essayant d’être le plus fidèle possible. Je vous invite à lire la version en anglais pour suivre le sens précis des propos de Scott Ambler.
[Début de la traduction de l’article original de Scott Ambler]
L’Agile Process Maturity Model (APMM)
L’objectif de l’Agile Process Maturity Model (APMM) est de fournir un cadre de mesure pour la pléthore de méthodologies Agiles présentes aujourd’hui. L’APMM définit trois niveaux, dont chacun s’appuie sur les autres, pour des processus et méthodes Agiles. Chez IBM, nous avons constaté que de nombreux clients trouvent que le message Agile est confus, en partie en raison de la multitude de voix au sein de la communauté agile mais plus encore parce que la rhétorique agile semble souvent ignorer ou masquer de nombreuses questions importantes de nos clients qui font face au jour le jour à ces méthodes. De là vient le besoin de quelque chose comme APMM afin de fournir un cadre [nécessaire] pour les méthodes et pratiques agiles
APMM Niveau 1: Agile Software Development
Le niveau 1 du processus de maturié Agile adresse une partie du système de cycle de développement (SDLC). Quelques exemples de processus agiles de niveau 1 :
– Scrum. L’objectif de Scrum est la gestion du développement au sens projet d’un produit et un outil pour la gestion des exigences. Les promotteurs de Scrum affirment que c’est un processus cadré, mais si c’est le cas alors il est épars (sparse en anglais) et, au mieux, incomplet. Une description plus précise [de Scrum] est que c’est un cycle de haut niveau pour la construction d’itérations (ce que Scrum appelle « sprints ») et de plusieurs pratiques telles que la réunion quotidienne de l’équipe (stand-up « Scrum »), la mise en place d’un responsable de produit (Product Owner), d’un carnet de produits (Product Backlog), de réunions de planifications, et l’objectif de livrer à chaque fin de sprint un produit potentiellement prêt à fonctionner.
– Extreme Programming (XP). XP est une collection de pratiques logiciels, comme le refactoring, les tests avant l’écriture du code, la programmation en binôme, la présence sur site du client, la mise en place de l’intégration continue, la responsabilité collective de l’équipe et la mise en place d’itérations.
– Agile Modeling (AM). AM est un ensemble de pratiques pour faire de la modélisation légère et de la documentation, y compris la gestion des exigences, de spécifications exécutables, participation active des parties prenantes, gestion par ordre de priorité des exigences, et preuve du fonctionnement avec le code (NDLR comme le canada dry, c’est du scrum sans l’alcool…).
– Agile Data (AD). AD est un ensemble de pratiques Agile pour le développement de base de données. Cela comprend par exemple une modélisation Agile des données, mettre en place une base de test, de refactoring et un système d’intégration continue pour la mise à jour de la base.
APMM Niveau 2: Disciplined Agile Software Delivery
Le niveau 2 du modèle de maturité étend le niveau 1 afin de se rapprocher du système de cycle de vie complet (SDLC). Comme les critères de développement d’une équipe Agile et Disciplinée le suggèrent, le niveau 2 tend à pousser encore plus certaines pratiques Agile comme les tests, la mesure de performance et la mise en place d’indicateur de qualité afin d’assurer un audit continu du produit. (NDLR : ce que l’on retrouve dans CMMI par exemple). Des exemples de processus de niveau 2 :
– Rational Unified Process (RUP). RUP est une méthode de prise en charge du cycle de vie du développement d’un logiciel qui peut être mise en place et adaptée à votre cadre, que ce soit de manière très agile ou sous forme très traditionnelle. Quelques pratiques de RUP incluent par exemple l’évaluation du risque et de la valeur, le développement piloté par les tests (TDD), de la modélisation des processus métiers et l’intégration continue.
– Open Unified Process (OpenUP)
OpenUP, disponible en open source, regroupe et étend les pratiques de Scrum, XP, AM et RUP pour les équipes de plusieurs départements qui construisent des applications d’entreprise. Quelques pratiques d’OpenUP sont la réunion de l’équipe tous les jours, le développement par ordre de priorité, la gestion et l’évaluation dans le cycle de vie du risque, les TDD, la participation active des parties prenantes(stakeholder) et l’intégration continue.
– Dynamic System Development Method (DSDM). DSDM est un processus Agile de livraison initialement fondé sur Rapid Application Development (RAD), qui est souvent utilisé pour le développement intensif des interfaces utilisateurs d’une application. Quelques pratiques de DSDM comprennent le prototypage, le test dans l’ensemble du cycle de vie, la mise en place de changements réversibles, et l’étude de faisabilité.
APMM Niveau 3: Agility à l’échelle
Au début de l’Agilité, les applications où le développement Agile était appliqué étaient plus petites et couvrait des objectifs simples et clairs. Aujourd’hui la situation a beaucoup changé et les entreprises souhaitent appliquer les méthodes Agile à un spectre plus large d’applications. Les méthodes Agile ont donc besoin de s’adapter afin de répondre à différents besoins métiers, différents types d’organisation, et différents types de problèmes techniques que les entreprises rencontrent aujourd’hui. C’est l’objectif de ce niveau 3 de cette échelle de maturité : adresser explicitement les complexités que les équipes disciplinées et agiles rencontrent dans le monde réel.
Les facteurs de difficultés qu’une équipe Agile peut donc rencontrer à un niveau plus ou moins important sont par exemple : la taille de l’équipe, la répartition physique, la distribution décidée par l’entreprise, la conformité réglementaire à respecter, l’organisation et l’enracinement culturel inadapté, la complexité des SI existants, la discipline de l’entreprise (tels que respecter les choix d’Architecture NDLR ou la stratégie de réutilisation de licences de logiciels payés les yeux de la tête…). Chacun de ces facteurs apporte une échelle de complexités et de difficultés pour une équipe Agile, et donc chaque équipe rencontrant une combinaison différente, aura donc besoin d’un processus différent adapté à son cadre et à son entreprise afin de s’adapter précisément à son environnement.
Malheureusement le terme de « maturité » est chargé d’un sens assez lourd dans le domaine des processus logiciels, et non des moindres, en raison du processus CMMI du Software Engineering Institute (SEII). Beaucoup de bon travail a été fait pour montrer que CMMI et les méthodes Agile peuvent être mis en oeuvre en même temps, et je me réjouis de voir que cette stratégie se concrétise. Cependant, l’objectif de CMMI est de fournir un cadre pour l’amélioration des processus métiers ; l’APMM est beaucoup plus modeste :
– il ne cherche à définir un cadre qui peut être utilisé pour mettre un contexte ordonné aux myriades de processus Agile. A l’avenir sur ce blog je vous parlerai de comment CMMI et APMM peuvent fonctionner ensemble. »
[Fin de la traduction]
Analyse
L’article part du constat qu’il y a de plus en plus de mise en place de méthodes Agile au sein des entreprises, et que cette mise en place est difficile. La difficulté vient du cadre, du milieu et de l’existant. La proposition de ce modèle est donc de classer par niveau de maturité les différentes méthodes Agiles. Le but semble-t-il est d’expliquer que chacune de ces méthodes couvre tout ou partie des besoins. Scrum et XP n’adressent qu’une partie des besoins, là où RUP propose d’adresser un spectre plus large de problèmes, et donc de besoins. Après avoir lu cet article, je trouve que le classement est un peu faible. Cité dans l’article sur le Processus Unifié de Wikipedia, Scott Ambler est l’auteur ou le co-auteur de 19 ouvrages. C’est un partisan de RUP et des différents processus unifiés apparus ces dernières années.
Je vois ces 3 niveaux comme un empilement successif de soins pour un même patient souffrant de différentes pathologies dont la gravité n’est peut-être pas forcément toujours bien évaluée. Entre un ongle cassé, une bonne bronchite ou une jambe cassée, il convient d’adapter le traitement. Un coach Agile dont la mission est d’aider une équipe, doit en premier lieu observer avant d’agir. Il y a certainement une partie dogmatique, que ce soit chez XP ou chez Scrum, où chacun des coaches Agile de ces 2 camps est certain de détenir le bon remède pour le patient. Je ne pense pas qu’un processus comme RUP réponde aux besoins récurrents et identifiés dans les entreprises de favoriser le canal de communication entre l’équipe de développement et les responsables produits. C’est le rôle de Scrum.
De même je ne pense pas qu’une solution comme EUP proposé par Scott réponde au besoin de qualité et de transparence qu’XP apporte à une équipe. Il est donc important de prendre le temps de comprendre le fonctionnement de l’existant dans une équipe, un département et une entreprise avant de tenter d’insérer une méthode Agile, quelque soit son nom. Pour cette raison, toutes les méthodes Agile ne sont donc pas forcément adaptées. Je pense cependant que plus une méthode Agile tente de proposer des processus et une structuration, moins elle est Agile. RUP est une méthode Agile au sens itératif, incrémental, guidée par les besoins des utilisateurs et centrée sur l’architecture logicielle. Scrum est une méthode Agile qui est aussi itérative, incrémental et guidée par les besoins de l’utilisateur. Et le mot « Architecture » a été prononcé jeudi dernier aussi par Jeff Sutherland. Pourtant elle n’a rien à voir avec RUP ou XP… car elle ne répond pas au même besoin.
Si vous voyez une offre d’emploi pour un Coach XP ou Scrum, imaginez une petite annonce d’un malade qui recherche un gastroentérologue pour traiter la chute des cheveux… Le patient s’est auto-diagnostiqué et il cherche maintenant son médecin ! C’est fort non ?
Il faut donc parler « Coach Agile » et ensuite rencontrer plusieurs personnes. Celle qui ne vous dit pas de quoi vous soufrez (si vous êtes en soufrance) n’est pas la bonne personne. Enfin pour terminer sur l’analogie avec la médecine, en chine les bons médecins ne soignent jamais car leurs patients ne sont jamais malade. Pour cela, la thérapie chinoise s’applique à traiter de manière préventive plutôt que curative. Appliqué à notre monde d’informaticien, cela revient à mettre en place quand tout va bien des principes Agile comme l’intégration continue, la gestion des demandes du client par priorité, la modélisation et l’architecture agile, les tests unitaires, etc.
Lorsque tout va mal il est plus difficile de mettre en place un processus large comme RUP, il est plus facile par contre de travailler pour mettre quelques pratiques XP dans une équipe. Il faut à mon avis d’abord travailler avec des outils et des méthodes simples avant d’envisager de mettre en place des processus plus complexs, même s’ils sont Agile.
Plus le médicament est fort, plus les effets secondaires sont intenses.
Références
Voici quelques articles pour aller plus loin :
– http://www.agilemodeling.com : la page de l’Agile Modeling dont l’auteur est aussi Scott Ambler, est une présentation d’une méthode Agile pour modéliser et documenter un logiciel. Les principes d’itération, de livrer par incrément, de privilégier la communication, bref une méthode Agile.
– http://www.enterpriseunifiedprocess.com/ Scott (toujours lui) s’est ensuite attaqué à définir une méthode de gestion du cycle de vie de l’application dans le cycle IT. Là où RUP est axé uniquement sur le logiciel, EUP est un travail qui tente de définir le cycle de vie d’un logiciel. A cet instant précis j’essaye de comprendre l’intérêt de faire des courbes en couleur pour expliquer au lecteur que la conception d’un logiciel comprend une phase d’analyse, une phase de réalisation et une phase d’obsolescence…
– Présentation du Processus Unifié et de RUP sur Wikipedia
– Scaling Scrum ? par Ivar Jacobson. Son point de vue est que Scrum n’est pas adapté pour de larges architectures mais que c’est une très bonne solution pour des projets unitaires. Il utilise l’image suivante : imaginez que vous découvrez un processus chimique dans une éprouvette qui fonctionne à merveille. Pour le mettre en place à grande échelle, est-ce que vous prenez 1000 tubes à essai ou vous réflechissez à un moyen de mettre en oeuvre votre découverte ? Il recommande de conserver Scrum comme un des moyens de résoudre des problèmes, et que c’est l’utilisation au cas-par-cas de différentes méthodes qui permettent de « monter en charge ». Il explique aussi que la technique de « Scrum of Scrum » proposée par l’alliance scrum n’est pas une solution pour monter en charge. On ne peut pas faire du Scrum partout, c’est idiot et cela montre que l’on a rien d’autres à proposer.
Fichtre ! Encore une théorisation de l’agilité !
Qu’est-ce qu’il ne faut pas faire pour rentrer dans un moule acceptable d’un point de vue « business »…
Ou alors c’est un complexe d’infériorité face à des CMMI et consorts.
Bien… Essayons de voir le bon côté des choses : avec « PUMA », la francophonie tient peut être la seule méthode qui puisse envisager le niveau 3 de cet APMM 😛
Je profite de ce post pour faire un peu d’autopromotion ;o) car j’ai traduit les derniers articles de Scott Ambler publiés sur Doctor Dobb’s Journal. Il y explique comment être agile tout en conservant une approche ‘RUP’.
> Emmanuel
Bravo pour les efforts de traduction, j’ai commence à me plonger dans tes articles.
> Olivier
J’y ai pensé en écrivant la partie 3.