Fortunes projet

En écho à l’article concernant une convergence possible (ou pas) entre agile et cmmi, vous trouverez ici les fortunes CMMi que j’avais évoqué. J’ai décidé de les renommer “fortunes projet” car je les ai passablement reformulées, et pour ne pas chagriner les anti de tous poils.

L’idée derrière ces fortunes est de donner aux équipes des éléments de réflexion pour les aider à la réussite de leurs projets (qu’ils soient agiles, classiques, ou autre).

Vous trouverez donc ici :

http://www.areyouagile.com/wp-content/uploads/2011/11/areyouagile_fortune_0_3.pdf

Les fortunes et une proposition de mode opératoire, mais sur ce dernier point je fais surtout appel à votre imagination, et je serai friand de vos retours.

ps : l’image du “make love, not bugs” vient de là.

This entry was written by pablo, posted on November 16, 2011 at 6:44 am, filed under cmmi, gestion projet, management, méthodes agiles and tagged agile, bonnes pratiques, cmmi, fortune, fortunes, projet. Leave a comment or view the discussion at the permalink.

Agile & CMMi, potion magique ou grand fossé ?

Je reviens sur la session Agile & CMMi : potion magique ou grand fossé que nous avons donné récemment Yassine (@yassinezakaria) et moi même lors de l’Agile Tour Toulouse 2011.  Les slides sont disponibles ici (ou intégrés plus bas) et je souhaitais les commenter un peu, même si des commentaires écrits remplacent rarement une session.

D’abord sachez que cette session nous a amené -Yassine & moi- a pas mal de discussions assez musclées.

Pourquoi avoir fait une session sur Agile & CMMi ? D’abord car nous trouvons un peu absurde les levées de boucliers et les préjugées dont font preuve une grande partie des gens de ces deux mondes vis à vis l’un de l’autre. Nous nous sommes amusés à mettre cela en forme au travers de différents slides. Mais la malheureuse réalité est que quand l’esprit des gens ces caricatures ne sont pas loin d’être vraies. Et d’ailleurs de nombreuses mauvaises applications de l’agile ou de CMMi les rendent souvent vraies ou les renforcent…

(more…)

This entry was written by pablo, posted on October 28, 2011 at 3:37 pm, filed under cmmi, kanban, méthodes agiles, scrum, XP and tagged agile, asterix, cmmi, obelix, toulouse. Leave a comment or view the discussion at the permalink.

Vos pratiques projets sous la loupe CMMi

Je voudrais prendre le temps de rappeler l’existence de cette fiche excel (trouvée un jour par hasard sur le web) en provenance directe de Richard Basque, et dont je me suis servi maintes fois dans le cadre d’audits (en citant ma source !). Car cette fiche mentionne : Permission de réutiliser mais avec la référence obligatoire: ” © 2006 Alcyonix (www.alcyonix.com)” . Voilà, c’est chose faîte une nouvelle fois. Merci Alcyonix (et au passage je ne sais pas si c’est encore d’actualité : “salut Eric ! salut Christian !”).

En 9 mots : CMMi est un très intéressant ensemble de pratiques projets (c’est un résumé très succinct que je fais là, lisez plutôt ceci). L’une de ses forces est de laisser chacun implémenter ces pratiques comme il le souhaite. Concernant certaines de ses faiblesses je vous laisse consulter certains de mes précédents billets. Pour ma part, et je l’ai déjà évoqué, j’utilise surtout mes connaissances et mon expérience CMMi dans le cadre d’audits (d’où aussi cette checklist). Je recommande à tous les chef de projets ou scrummaster ou autres de se plonger un peu dans les différentes questions proposées ici et qui -je l’espère- nourriront votre réflexion concernant vos projets informatiques. Merci encore Al’ !

Le lien vers la fiche excel : template-cmmi-v13-standard-piis

This entry was written by pablo, posted on November 20, 2010 at 1:28 pm, filed under cmmi, gestion projet and tagged cmmi, projet. Leave a comment or view the discussion at the permalink.

Scrum agit, CMMi observe. CMMi/Scrum billet #4

Donc cette fameuse question : Scrum et CMMi sont-ils antinomiques ? ou sont-ils complémentaires ?

Si l’on en croit le fameux article de Jeff Sutherland “Scrum and CMMI Level 5: The Magic Potion for Code Warriors“, que vous retrouverez traduit ici grâce à Fabrice Aimetti (merci à lui), la réponse est oui, mille fois oui. Mais bon, il s’agit d’une entreprise CMMi niveau 5 (ça ne court pas les rues dans le coin, je ne parle pas de telle ou telle SSII qui s’est fait tamponner niveau 5 sur son groupuscule indien de 10 développeurs et qui étend magiquement le macaron à l’ensemble de son groupe…). Si tant est que ayez la chance de travailler dans une structure CMMi niveau 5, je suppose qu’elles sont rares celles qui implémentent Scrum ou Lean comme dans l’exemple de Jeff Sutherland.

Mais il n’empêche je suis assez d’accord pour dire, selon mon expérience personnelle que les deux se complètent bien, car je vois bien dans ma pratique personnelle que selon les besoins je me tourne soit vers l’agilité (Scrum/XP) soit vers CMMi. Alors dans quels cas ? Puisque c’est cela la question.

Pour résumer : je me tourne vers l’agilité dès qu’il s’agit de produire, de créer, donc de réaliser des projets. Je me tourne vers CMMi dès que je dois auditer. Normal, rien de surprenant. C’est une joyeuse lapalissade. CMMi est un modèle, Scrum est une méthode. Les mots sont importants, une méthode, c’est un ensemble de procédés raisonnés pour faire une chose ;  un modèle c’est une représentation, en informatique (pour CMMi) des structures, des traitements, de pratiques… Une représentation c’est aussi une image, un tableau, une photo prise à l’instant T. La temporalité (oh là là on va m’accuser de branlette intellectuelle, mais que voulez vous j’ai fait fac de lettres ) est différente : action (mouvement, durée) du côté de Scrum, représentation (état, analyse, définition, instant présent) du côté de CMMi.

Naturellement dans l’entreprise les deux sont requis : l’action (création de valeur : les projets etc.), la représentation (indicateurs, analyse, consolidation, etc.). La difficulté est que les deux se situent sur des plans différents et ne sont pas forcément réalisés par les mêmes personnes, ni comme on l’a vu dans le même rythme. Le scrummaster (allez disons le chef de projet), les développeurs, etc. sont dans l’action ; le management (pour utiliser un mot chapeau facile) consolide, analyse à un niveau macro (le Scrummaster consolide et analyse au niveau de son projet !). Rien n’est demandé par exemple spécifiquement au membre de l’équipe scrum concernant l’utilisation de son temps. Il fait parti de l’équipe et il participe (constamment) au projet. Pourtant on comprend bien qu’il devra saisir à un moment ou à un autre son temps passé sur tel ou tel projet dans un outil de consolidation groupe. Je me rappelle aussi d’un projet Scrum qui avait très bien marché et sur lequel on me demande une consolidation tâche/planning dans un cadre CMMi. En forme de pied de nez j’ai remis les photos des radiateurs au fil des jours (c’est une bonne pratique de prendre ses radiateurs en photo tous les jours) mais cela n’est pas vraiment une bonne réponse à la question qui m’était posée j’en conviens car c’est assez inexploitable en l’état… Il faut donc que l’agilité ait l’intelligence de fournir à des modèles comme CMMi les informations nécessaires (je pense que tout l’outillage XP est un premier pont important. Il va donner des métriques importants). En contrepartie il ne faut pas que l’inertie, le côté statique du modèle, vienne rompre le rythme et le dynamisme du projet Agile.

Il faut essayer de réaliser des convergences c’est tout l’enjeu. CMMi sera demandeur, et Scrum fournisseur. A mes yeux on a un pris le chemin en sens inverse : aujourd’hui c’est Scrum qui vient dynamiter l’inertie de CMMi dans les sociétés. C’est plutôt CMMi qui devrait venir consolider les processus Scrum déjà en place. Consolider en donnant des indicateurs forts qui permettront de mieux mener les projets agiles sans les déranger par ailleurs. Une convergence riche d’enseignement mais qui tient sur un équilibre probablement fragile.

This entry was written by pablo, posted on February 24, 2010 at 6:28 pm, filed under cmmi, méthodes agiles, scrum and tagged cmmi, scrum. Leave a comment or view the discussion at the permalink.

Le nouvel arrivant, scrum & cmmi, billet #3.1

Toute ressemblance avec des personnes existantes ou ayant existé est purement fortuite.

Imaginons Cinthia, fraichement diplômée, qui se lance dans sa vie professionnelle. Elle est développeuse .Net et deux belles entreprises ont répondues positivement à sa candidature. Dans la première, on lui vante les mérites de CMMi, que la société décline jusqu’au niveau 4 (ce qui est excellent); dans la seconde on lui dit qu’elle sera “agile” avec XP & Scrum.

Je vais essayer de ne pas être négatif du tout pour faire ressortir que les bons côtés de chaque approche. Je vous fais confiance pour imaginer tout ce qui pourrait ne pas se passer ainsi dans la réalité.

Imaginons qu’elle opte pour la première. Le très évident avantage qu’elle va tirer d’une société CMMi est l’encadrement méthodologique sur lequel elle va pouvoir s’appuyer, les gardes-fous qu’on va lui proposer. On va vérifier qu’elle a pris connaissance de tous les éléments du projet sur lequel elle va travailler. Elle verra clairement les tâches qu’on lui affectera (avec des specs très précises), ainsi que la charge que l’on estimera (avec elle si c’est possible). Elle va clairement tracer dans son code sur quelle partie du projet elle travaille, et à quelle demande, quelle exigence du projet elle répond ainsi. Son code sera soumis de temps en temps à des revues de la part d’experts, on va s’assurer qu’elle a bien connaissance de la configuration du projet (serveur de dev, de staging, de prod, arborescence du code, etc etc.) et son planning. Mieux, on lui signale que le taux d’anomalies qu’elle a relevé ne correspond pas aux moyennes de ce genre de projet dans ce contexte et qu’elle devrait refaire une passe dessus pour valider que vraiment tout est ok. Bingo, elle découvre une belle série d’anomalies qui lui avaient échappées.
Pour elle c’est parfait, le côté bordélique et fofolle qu’elle a bien pris soin de cacher en entretien d’embauche, est gommé par le cadre méthodologique qu’on lui propose. Dieu est chef de projet ou le chef de projet est Dieu. En tous cas le chef de projet est l’interface avec le reste du monde : le client, le management, le responsable qualité, etc. Elle est tranquille dans son coin, avec son casque sur les oreilles dans lequel elle écoute à fond Neil Young chanter “Heart Of Gold” et elle jubile, car, ça y est, elle “pisse” du code.

Imaginons qu’elle opte pour la seconde. La voici qui débarque. On lui présente François, Martial & Yves. Ils ne payent pas de mine mais ils ont l’air sympas. C’est l’équipe lui dit-on. Son équipe. Et voici Pierrot le ScrumMaster, il s’arrange pour qu’elle se sente à l’aise et s’assure que tout roule. Demain le projet démarre elle fera une journée avec l’équipe, son équipe, et le client, ils vont parler du projet, de ce que le client veut, de ce qu’il est possible de faire. Ca y est le projet a démarré. Tous les jours on parle : qu’est ce qui marche, qu’est ce qui ne marche pas, du coup elle entend et comprend tout, et n’hésite pas à poser des questions si quelque chose lui échappe. Elle apprend vite et si elle a un souci, Martial vient développer avec elle. De toute façon on lui demande de faire des tests automatiques tout le temps, du coup ça la rassure : elle sait qu’elle ne casse rien, elle sait que son code marche. ouf. Son côté bordélique et fofolle qu’elle a caché lors de l’entretien d’embauche n’est pas très problématique car le périmètre est finalement très précis, et limité dans le temps avec des itérations relativement courtes. Elle n’a pas l’occasion de s’oublier dans des dérives stériles. Tout est là, à l’esprit, clair. D’ailleurs on présente régulièrement au client le résultat du boulot et celui oriente l’équipe ou précise ce qui ne va pas. Incroyable le client a apprécié une de ces propositions et son idée sera déployée dans le produit final. Le projet avance bien et on fête ça ce midi en partageant tous une megapizza et en gueulant comme des fous “T N T, I’m dynamite !!!“.

Au prochain post, je parle de Caroline, chef de projet fraichement arrivée d’une entreprise sans aucune méthode et qui se fait embaucher dans les deux même sociétés et j’essaye de résumer ma pensée (un peu bordélique et fofolle).

This entry was written by pablo, posted on January 16, 2010 at 4:36 pm, filed under cmmi, méthodes agiles, scrum, XP and tagged cmmi, scrum. Leave a comment or view the discussion at the permalink.