29 juillet 2008
CMMI et Agilité
Chez nous on est en train de débuter un programme autour du CMMI. Actuellement on est en train de voir à quel niveau nos équipes sont. Sur papier on est à au moins au niveau 3 car notre méthodologie actuelle (Centre Productivité P+) est full CMMI. Le problème n'est pas avec le niveau de maturité de la méthode mais plutôt avec celui de l'utilisation de la méthode. D'une équipe à une autre il y a effectivement de grandes variations dans la compréhension et la maitrise de la méthode.
Comme je me fais le promoteur de l'agilité dans notre entreprise, et que la tendance va être à la "certification" CMMI, je ressort la litérature existante sur le sujet. Généralement il n'y a pas d'incompatibilité entre les approches agiles et le CMMI, tout comme il n'y en avait pas avec le PMBOK. Souvent c'est une incompréhension des divers éléments en cause qui ammène une perception négative.
Ainsi à la base, le cadre du CMMI indique les pratiques qui doivent être mise en ouevre par les organisations et non comment les mettre en oeuvre. Or les approches agile décrivent pluôt comment mettre en oeuvre les pratiques. Donc pas d'incompatibilité fondamentale.
Il est possible cependant qu'une approche agile ne couvre pas tous les aspects (KPA) d'un niveau CMMI donné. C'est le cas de SCRUM qui se concentre plus sur la gestion de projet que sur les pratiques d'ingénieries logiciels prescrites par le CMMI et les bonnes pratiques en générale. C'est d'ailleur la raison pour laquel j'utilise rarement SCRUM seul.
Comme il faut s'y attendre il existe déjà le site http://www.agilecmmi.com/.
Dans la littérature on trouve par exemple la façon dont MicroSoft a rendu sa méthologie agile au niveau 3. La présentation de 2005 (en PDF) montre comment a été conçu MSF for Agile.
Jeff Dalton, un évaluateur CMMI à un blog intéressant sur CMMI et l'agilité. Un autre blog intéressant est celui de Glen Alleman.
Le papier présenté en 2006 au SPICE discute de 3 études de cas de CMMI dans un contexte agile
L'excellente revue (militaire) CrossTalk discute dans un article de 2007 des processus d'ingénierie, de l'agilité et de la maturité. D'ailleur tout le numéro d'avril 2007 de CrossTalk est consacré à l'agilité et adresse la maturité. En février 2008 on trouve un excellent article de Capers Jones qui présente des données touchant les bénéfices du CMMI et de l'agilité et des approches hybrides.
Un article de Dr. Dobbs discute des approches agiles (valeurs de base) du TSP (Team Software Process) et du CMMI en général.
22:50 Publié dans Scrum | Lien permanent | Commentaires (0) | Trackbacks (0) | Envoyer cette note
24 septembre 2007
Sommes-nous agile?
Sommes-nous agile?
Le projet est démarré depuis quelques jours, et l'équipe a assisté à une présentation d'une heure sur Scrum. On est dans ce qu'on appelle une iteration 0, itération où dans notre cas on introduit l'équipe à plusieurs choses:
- l'équipe elle-même, puisse que les personnes ne se connaissent pas;
- les concepts de l'orienté objet, au moins un rafraichissement des notions;
- la technologie .NET, puisque peu ont des bases en C# et .NET;
- l'architecture distribuée et les services web;
- les possibilités de WPF et de xbap de .NET 3.0;
- l'application à réécrire;
- la notion de composant réutilisable.
On me demande "Jean, on applique l'approche agile, n'est-ce pas?".
Je réponds qu'il faut nuancer car on comprendra que dans ce contexte, il est difficile d'introduire en plus une nouvelle approche (Scrum et ses techniques: backlog, sprint backlog, user stories, mêlée quotidienne, burndown) et les techniques d'ingénieries appropriées (intégration continue, test-driven, test-first...). D'autant plus que le but ultime est de développer autour de la technologie et bâtir des composants réutilisables, avant de développer selon une approche agile. Autrement dit le but est de former et de réaliser des composants, le moyen étant de le faire de façon agile.
Donc comment être agile, du moins se mettre dans un esprit qui nous y fait tendre, sans adopter ces pratiques en bloc à priori?
Le premier élément que j'ai chosi, est d'établir un rythme autour d'itérations de deux semaines.
Le second élément est de rammener les actions de l'équipe dans le contexte de la valeur, du point de vue du client.
Ces choix sont d'abord stratégiques. Nous avons une pression importante de la gestion à démontrer un avancement, une progression. Le choix d'itérations de deux semaines permet de revenir rapidement à la gestion avec quelque chose de concret. Cette durée permet d'avoir un total de 7 itérations (0, 1 ,2, 3,4, 5,release) durant notre projet. Plus d'itérations serait difficile, d'autant plus que l'équipe est en partie à 3 jours-semaine. Plus long et on n'aurait pas suffisament de feedback sur l'avancement réel.
Le choix de la "valeur" va aussi dans ce sens. Il est primordial dans notre situation de montrer concrètement l'avancement de la réalisation de fonctionnalités reliés à l'application.
Ces deux éléments, rythme et valeur, représentent à eux seul un changement important pour l'équipe compte tenu de nos paradigmes existant et bien ancrés. Les courtes itérations donnent un cadre sur lequel le processus peut être constamment amélioré, adapté et qui supporte l'introduction graduelle des techniques. Le focus sur la valeur permet de focusser l'équipe sur les objectifs et de constamment recadrer les actions dans une perspective client.
Par exemple, tant qu'à regarder du code "exemplaire", pourquoi ne pas le faire avec le code de l'application proprement dite. Ainsi on démontre de la valeur au client par du code utile et par une formation spécifique aux besoins immédiats.
Pour revenir à la question de départ, "sommes nous agiles?", je dirais que non, puisqu'il manque énormément d'éléments de l'agilité, mais que dans le contexte et après une semaine, on aborde le problème avec deux des principes agiles (customer value, et l'adaptation par le feedback rapide des itérations).
On aurait pu considérer d'autres principes mais dans notre contexte et culture organisationnelle, ceux choisis m'apparaissent comme ceux qui permettent de démarrer rapidement et d'obtenir des résultats rapides. Ces autres principes seront introduit plus tard.
14:56 Publié dans Scrum | Lien permanent | Commentaires (0) | Trackbacks (0) | Envoyer cette note | Tags : valeur, rythme, principes
13 septembre 2007
Démarrage et présentation de SCRUM
Cette semaine nous avons démarré un nouveau projet avec une équipe de 8 personnes, un chargé de projet, et 3 personnes "d'encadrement". Il s'agit d'un projet qui vise à former l'équipe à l'utilisation de .NET 3.0 et C#, une nouvelle techno pour la plupart des membres de l'équipe. Le projet durera trois mois et devra livrer des composants réutilisables et une application fonctionnelle en démontrant l'utilisation.
Pour mettre tous le monde dans le bain nous avons présenter une introduction à l'approche SCRUM à l'équipe en utilisant la présentation de Mike Cohn (ici). Cette présentation a été suivi d'un rappel des concepts de l'orienté objet. Dans les journées suivantes, l'équipe à assister à des présentations/vidéos animées par les experts (encadrement).
Cette première semaine (de 3 jours où les 2/3 des personnes étaient disponible) a visé à introduire l'équipe à .NET, à l'architecture à haut niveau et à présenter l'application à construire (il s'agit d'une application Access qui nous réécrivons en .NET avec WPF (XBAP), des services web et une BD Oracle.
Au cours d'une session de travail, l'équipe a identifié une liste de composants réutilisables (backlog) et les a priorisés.
En parallèle, on a procéder à l'acquisition des postes de travail et à leur installation. Le serveur Team Fondation Server était déjà fonctionnel, de même que l'environnemnent d'essais. On travaille avec VisualStudio 2005, .NET 3.0, Enterprise Library 3.0, Retina, Expression Blend 2.0 Beta.
On a aussi constitué un comité directeur des gestionnaires.
En résumé c'était le début de l'itération zéro 0, où nous avons:
- participation active des stakeholders
- définition des paramètres du projet (financement, ressources, portée, délais)
- construction de l'équipe (accueil et mise en contexte)
- modélisation initiale des spécifications
- modélisation de l'architecture générale
- installation des équipements requis (locaux, postes, téléphones...)
17:15 Publié dans Scrum | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : Démarrage
16 décembre 2005
(Mauvaises) Odeurs de Scrum
Une odeur dans les approches agile est un symptome d'une situation à corriger. Il existe des "odeurs de code" (code smells) et Mike Cohn a publier des odeurs de Scrum, donc des symptomes que quelque chose cloche dans l'application du Scrum. Vous les trouverez ici.
19:45 Publié dans Scrum | Lien permanent | Commentaires (0) | Envoyer cette note | Tags : odeur, scrum, mêlée quotidienne