Merci pour ton excellent commentaire à la fin de l’article consacré au Software Craftsmanship. Je t’écris discrètement car je sais que tu es encore dans une réunion « PowerPoint-Acronyme » avec GrandChef. Qu’est-ce qu’il présente ce matin ? La Nouvelle Nouvelle Stratégie ? Les Objectifs Q1 2011 ? Ses photos de vacances ?
Courage, ce n’est qu’une heure de perdu. 6 personnes dans la salle, ah en fait c’est 6 heures de perdu pour l’entreprise. Bref passons, on est pas là pour parler de cela. Courage, on a envoyé une équipe pour t’extraire.

Alors oui, j’ai cédé à l’effet mode en écrivant un article sur Craftsmanship. Standardisation versus Artisanat. Grégory pour qui j’ai beaucoup d’estime et qui a présenté un point de vue sur son blog, se positionne sur la vision « industrialisation » de notre métier. De mon côté, je suis plus intéressé par le côté « artisanal » de la chose… le développement informatique. Alors voyons ce que cela donne.

Si nous étions meilleurs, nous n’aurions pas ces débats. Nous pourrions en effet imaginer une industrie mieux organisée en parlant de notre métier. Une Industrie est une organisation qui met tout en oeuvre pour pouvoir réduire le temps de fabrication et la part d’aléatoire dans la construction d’un bien. Appliqué au développement logiciel, nous pensons Model Driven Architecture. Je ne suis pas convaincu par cette approche. Je la respecte, car je crois que des personnes très intelligentes y passent beaucoup de temps. Mais je ne peux m’empêcher de penser que c’est un moyen de déplacer le problème. Là où nous n’avions pas de bons développeurs Java, est-ce que nous aurons de bons analystes à même de modéliser une application ? Est-ce que la solution ne fait pas que déplacer le problème ? Je suis donc peu convaincu par ces solutions et par cette approche. Mais cela reste personnel. Je suis convaincu qu’il y a de bons projets réalisés grâce à l’approche MDA. Elle répond à un besoin précis, mais cette approche n’est pas nécessaire pour réussir un projet.

Nous nous rapprochons pourtant depuis 15 ans de l’industrialisation. Sur le projet où je travaille, nous utilisons une usine logicielle. Compilation, gestion du code source, audit de la qualité du code, gestion de tickets, gestion des exigences et des spécifications, un outil complet qui rend de grands services. Tu es d’accord avec moi, aujourd’hui un projet informatique sans gestionnaire de code source, ce n’est pas réaliste. Il en est de même pour l’intégration continue, la gestion des incidents et tout un ensemble de bonnes pratiques.

De ce côté là donc, nous pouvons dire que nous nous sommes industrialisés petit à petit. Nous sommes capable de construire rapidement une version de notre logiciel. C’est donc un contre-argument à ceux qui pensent que nous ne serions que des artisans.

S’il y a un endroit où cependant nous pouvons encore nous améliorer en 2011, c’est du côté de la mise en production et de la gestion de configuration (Application Lifecycle Managment). Nous verrons au 3ème anniversaire du ParisJUG une petite présentation sur DevOps par Patrick Dubois. C’est un mouvement très pragmatique qui vise à réconcilier le développeur et la personne qui fait l’exploitation. Si tu as encore une réunion cet après-midi, je te conseille de lire ce billet de ton blog favori. Il y a donc encore un peu d’amélioration à espérer de ce côté là.

Ensuite quoi d’autre ? Ah le développement lui-même.
Il y a 10 ans tout juste, dans une galaxie lointaine, des Jedis se sont réunis et ont lancé le Manifeste Agile. D’abord centré sur l’organisation d’une équipe avec l’eXtreme Programming, la sauce a ensuite coulé jusqu’à l’organisation du projet avec Scrum, puis maintenant l’entreprise avec Lean/Kanban et autre.

Mais moi, simple développeur, ça change quoi ?

Merci, chaque matin un bonhomme me demande ce que j’ai fait la veille, ce que je vais faire aujourd’hui, puis il court bouger des post-its, comme on lui a expliqué. Par contre il n’est pas capable de me donner une vision à un mois, il est incapable d’expliquer ce que fait le logiciel dans son ensemble et il est incapable de gérer des clients qui ne veulent pas faire de l’Agile…

Alors arrêtons d’être « industrialisé » et regardons simplement comment nous travaillons.

Peu m’importe que le buzzword « Software Craftsmanship » soit encore un n-ième mot à la mode. Je vous rappelle que nous sommes pas mieux que ces filles qui s’extasient sur la collection des sacs en cuir automne-hiver 2011. Cela dit, il faut essayer de comprendre à chaque fois ce que les personnes placent comme intention et comme valeur derrière ces mots clés.

Profession : développeur

Pour terminer, je vais t’expliquer ma vision de notre métier. Je pense de moins en moins à marquer « Architecte » ou « Chef de projet » sur mon CV. Pourtant j’ai été CDP (note l’acronyme) pendant 3 ans. Mais j’ai arrêté. Car mon métier, c’est développeur. Pour gagner plus, il suffit de bosser plus comme dirait 1m68. Il suffit aussi de penser que sa passion peut être un moyen de gagner plus. Et là, je ne parle pas d’argent. Je parle de rencontre, de beaux projets, de qualité de vie, d’équipe, de présentation devant une audience et de communauté.

Etre développeur en 2011 c’est être ouvert aux autres, capable de réaliser un logiciel simplement et humblement. C’est être en mesure de travailler avec d’autres développeurs, sans qu’un « chef de… » soit nécessaire. Etre à l’opposé d’une vision industrielle de notre monde, tout en étant capable d’apporter des outils et de bonnes pratiques. C’est aussi comprendre que lorsque nous codons, nous réalisons une pièce unique.

Etre développeur, c’est aussi se rendre compte que nous avons le pouvoir de créer à peu de frais un logiciel. Regardez l’eXpress-Board : il y a 12 mois je n’avais rien. Quelques mois plus tard, des candidats et des recruteurs se rencontrent. Et tout ceci ne m’a pas coûté grand chose, quelque chose comme 2 mois de travail à temps plein. C’est rien dans une vie professionnelle. Je dis donc aux gars qui nous écoutent : lancez-vous, développez une application pour iPhone le soir, investissez-vous dans la communauté ou en donnant des cours aux étudiants : c’est comme cela que nous resterons des Développeurs et pas des poulets industrialisés, comme certains le pensent encore.

Allez, je te laisse. Courage pour ta réunion. N’oublie pas qu’il y a largement de quoi s’éclater et qu’il n’est pas si difficile de changer de boulot. Préparer son CV, le déposer au bon endroit, hop un coup de fil, tu vas en entretien. Là tu croises des gens qui s’éclatent.

Tu démissionnes et ensuite par contre, tu n’auras plus le temps de lire le Touilleur Express en réunion, car crois-moi, tu vas t’éclater.

A+

Nicolas

Quelques mots sur le speaker. Régis Medina est bien connu dans la communauté Agile Française. Coach Lean spécialisé dans l’accompagnement des équipes techniques, il découvre XP en 98, il a co-écrit avec d’autres auteurs le livre « Gestion de projet : eXtreme-Programming » paru chez Eyrolles. C’est un orateur passionnant, qui propose une vision où le Lean et l’Agile sont mis en parallèles. Et accessoirement c’est un utilisateur d’IDEA IntelliJ, donc je +1 avec plaisir.

Arrêtons-nous un instant sur ce que nous produisons. Parfois, nous suivons à la lettre ce que demande le client. Peu importe la méthode de développement, ou de gestion de projet. Lorsque l’on regarde quelques temps plus tard certains projets, certains apparaissent comme dangereux. Regardez cette théière utilisé par Régis pour illustrer son idée, fruit du travail de Donald A.Norman. Sur le plan du cahier des charges, l’ensemble des besoins sont développés. Simplement, cet objet est inutile. Et combien de projets ou d’outils inutiles avons-nous croisé dans notre carrière ?

Régis Medina pose la question suivante : « Comment faire des logiciels en mesure de satisfaire pleinement les clients ?« .

A priori, la réponse serait de prendre une bonne méthode de développement, et une bonne méthode de gestion de projet. Prenons le cycle en V, qui anime les soirées d’hiver et qui permet de se chauffer grâce aux tonnes de documentations produites…
Faire une spécification pour certains utilisateurs, c’est un peu découper le catalogue de la Redoute dans les pages Jouets. Certains utilisateurs, de peur de manquer, chargent à mort les spécifications fonctionnelles. Le fait de demander en amont aux clients, puis de spécifier de manière exhaustive leurs besoins, peut conduire parfois à une perte de temps, à un certain gâchis.

Les spécifications c’est fait. La conception ressemble ensuite à une équipe dans un sous-marin nucléaire. Impossible d’accéder à l’équipe de développement, c’est du cycle en V. Si tu veux leur parler, on te demandera d »écrire une spécification. Et de la donner aux développeurs avec une fourche.

Une fois le développement terminé tant bien que mal, souvent à l’arrache, vient le temps de la validation. Autant éteindre un feu avec un verre d’eau. Si la Validation se passe bien (ahahah) vous irez en production. Ne donnez pas votre vrai nom au gars qui fait la mise en prod. Il serait capable de venir vous casser la figure. Le déploiement… Régis utilise l’image d’une personne qui a peur.

Alors arrive l’Agile
Après avoir dépeint un tableau noir de la situation, Régis passe à la page « Agile ». Premier principe : nous allons écouter le client et délivrer des incréments de logiciels qui fonctionne, petit à petit. Cela permet de lisser l’inconnu et de s’assurer que le logiciel fonctionne.

Régis explique cependant, qu’en appliquant trop à la lettre les demandes des clients, vous risqueriez de développer une théière avec un manche mal placé. Le client ne sait pas toujours exprimer correctement ses besoins. Et faire de l’Agile, faire du Scrum, ne veut pas dire « ne pas prévoir à 2 ou 3 mois » ou « ne pas faire de l’Architecture ». C’est un anti-pattern de Scrum, que de croire que l’Architecture émerge magiquement du développement (ça c’est de moi).

Le Client n’est pas concepteur de logiciel. Pourquoi lui demander d’apprendre l’UML pour exprimer son besoin ? Si vous commenciez par écouter, et par apprendre le domaine du client… Je sens que Régis est aussi un fan de DDD comme moi.

Alors vient souvent la phrase « oui mais il faut un BON Product Owner« . Cette phrase est à mon avis un moyen élégant de dire « le client est un abruti, il en faut un plus intelligent« .
Je retourne la question : « Oui mais il faut une BONNE équipe capable d’écouter le client« .
Cela va mieux dans ce sens là non ?

Régis explique l’importance de définir le domaine du client, de cadrer les frontières de son problème. Il recommande de travailler par exploration, de découvrir le domaine, les mots du clients, à s’approprier le vocabulaire et la connaissance de celui-ci. C’est du DDD non monsieur Medina ?

Et bien il poste un nouvel acronyme : PDL pour Problem Driven Development.

Notre mission sera désormais de résoudre les problèmes des clients. Et de les résoudre complètement. Les tests vont piloter le développement. Nous, développeurs, sommes là pour comprendre, analyser et résoudre les problèmes du client.
Pour cela, Régis propose d’appliquer deux des principes du Lean :
– Plan Do Check Adjust
– Aller sur le terrain (Gemba)

Demandez à aller voir le client, l’utilisateur qui sera 8h par jour avec votre logiciel. Regardez comment le client utilise votre logiciel, ou comment il utilise un logiciel similaire. Listez les problèmes qu’il rencontre, et tirez-en des leçons pour vraiment écouter le client.

La voix du client
Prenons les 5 points suivants :
1. Donne moi exactement ce que je veux
2. Quand je le veux
3. Où je le veux
4. Soyez fiables
5. Ne me faîtes pas perdre mon temps, je n’ai pas envie d’apprendre

Le point 1 apporte la valeur. Les points 2 à 5 seront du gachis pour le client s’ils ne sont pas respectés. Les 2 points les plus importants : le 1 et le 5 : donnez moi exactement ce que je veux et ne me faîtes pas perdre mon temps, je n’ai pas envie d’apprendre à utiliser votre logiciel. Le meilleur exemple ? Pensez à l’iphone. Avec une ergonomie et une puissance importante, vous allez à l’essentiel. Si seulement nos bonnes vieilles applications de gestion pouvaient s’en inspirer…

Le meilleur service finalement, c’est celui que l’on ne voit plus. Régis nous demande de réflechir à tout ce qui est mis en oeuvre entre toi, lecteur qui lit cet article, et les byes stockés dans une base MySQL sur un serveur quelque part… sans parler d’électronique. Vous vous rendez compte du parcours de l’information ?

La démarche d’être très simple, très rapide et très efficace est aussi illustrée par Google. Lorsque vous arrivez, que vous tapez un mot, puis que vous partez sur une page de résultat, il s’écoule moins de 5 secondes… Quand on pense à tout ce qui se passe derrière, en amont, c’est assez impressionnant.

Régis propose donc de nous faire réfléchir aux meilleurs choix pour résoudre le plus efficacement possible le problème du client.

Regarder la performance
On ne peut améliorer que ce que l’on mesure. Il faut des indicateurs, afin de se rendre compte de ses progrès ou non. Que ce soit le nombre d’utilisateurs, le nombre d’appel sur la hotline, ou le taux de pertes de paquets réseaux, il faut des indicateurs.

Voir les problèmes
Un problème est l’écart entre l’indicateur et sa valeur actuelle. Gemba dans la démarche Lean, nous pousse à aller sur le terrain, pour comprendre ce qui cloche. Regardez l’utilisateur, la séquence d’utilisation, les stratégies d’évitement qu’il met en oeuvre pour résoudre un problème… c’est très intéressant. Comme dit Régis : « tant que l’on ne l’a pas vu… on ne l’a pas vu… c’est le problème ».

La courbe de connaissance entre vous, développeurs, et eux, les utilisateurs, est aussi très importante. Un développeur « sait » comment marche son logiciel, puisqu’il l’a codé. Quel est l’écart entre ce que sait le client et ce que vous savez ? Quel est la taille du problème (cf plus haut) ?

Inversement, les développeurs parfois ne connaissent pas le métier fonctionnel. Cela donne des perles, comme des objets financiers implémentés avec des getter/setter, alors que l’objet lui-même, dans la vraie vie, EST IMMUABLE ! Je m’égare…

Résoudre le problème
Résoudre c’est bien, mais il faut être proactif, et il faut penser en permanence à l’amélioraton du système. Pour cela, la technique du PDCA : Plan Do Check Adjust. Il faut voir les causes d’un problème, anticiper le résultat lorsque le souci sera corrigé, élaborer une contre-mesure en cas d’erreurs.

En tirer de bonnes leçons
Ecoutez les clients, et mettez en place des ateliers d’apprentissage afin que les développeurs s’approprient le domaine du client. Pour travailler, faites des ateliers de prototype, des interviews, des sessions de brainstorming avec le client. Lorsque vous développerez votre prochain site Web avec Play! Framework, ou votre application de gestion sérieuse avec Play! Framework, pensez aux écrans, à l’idée que pour résoudre un problème, il faut aller vite.
Imaginez Google ou l’interface de l’iphone développé par un gars qui n’aurait aucunes idées de votre besoin… ou qui ne chercherait pas à résoudre efficacement et rapidement vos problèmes…

Conclusion
En conclusion, Régis nous rappelle les principes de la démarche Lean, et de sa possible mise en place dans les équipes de développement logiciel. Avec de grands principes, qui placent le client au centre des préoccupations, j’ai bien accroché. J’aime aussi cette vision où le développeur et ses frameworks n’est plus le plus important. C’est vrai que parfois, nous donnons l’image de gosses qui bidouillent avec une boîte de « Petit chimiste », alors que l’on nous demande juste de faire une chose : résoudre les problèmes des clients simplement, le plus efficacement possible, et sans lui faire perdre son temps.

A méditer.

Merci à Régis, en espérant avoir retranscris l’esprit.

La Direction Générale travaille avec la DSI, dont la mission est d’assurer la réalisation des projets informatiques de l’entreprise, dans un triangle constitué de la maîtrise des coûts, de la maîtrise des délais et bien sûr, de la qualité. L’arrivée des méthodes Agiles a permis de maîtriser le temps. En divisant en petites itérations la réalisation d’un logiciel, l’incrémental itératif permet de réduire les risques, donc en partie les coûts. Lorsqu’une équipe de développement a la perspective de délivrer un logiciel fonctionnel toutes les 2 semaines, plutôt qu’à la fin d’un cycle de 3 mois, clairement c’est plus encourageant.

Pierre nous rappelle la situation dans les années 80. Des entreprises se sont informatisées. D’autres se sont informatisées ET se sont réorganisées. Celles qui ne se sont pas réorganisées souffrent, et n’ont pas tiré « la substantifique moelle » de leur SI.

L’informatisation sans remise en question de l’organisation de l’entreprise ne fait qu’ajouter de la complexité. Le Lean propose des outils pour observer, mettre en place, mesurer, bref pour faire progresser.. J’y reviendrai lorsque je vous parlerai de la présentation de Régis Medina sur ce sujet, qui fut passionnante.

Les entreprises tendent parfois à créer des règles sur la base d’incidents. Lorsqu’un problème survient, une règle d’entreprise est établie. Par défaut, certaines entreprises interdissent tout, là où d’autres ont fait le choix d’ouvrir et de faire confiance aux gens. Pierre cite l’exemple de Wikipedia. Ce système repose sur l’observation que 99% des gens ne font pas n’importe quoi. Quant bien même un hurluberlu aurait l’envie de changer une page, vous pouvez être certain que l’erreur sera corrigée rapidement. Comment appliquer ce paradigme à l’entreprise ?

L’Agilité y contribue en donnant une autonomie et une responsabilité aux équipes. J’y reviendrai dans un prochain billet, puisque j’ai ensuite assisté à la présentation d’une organisation Agile avec 200 personnes chez un éditeur, dans la finance. Donner de la responsabilité au groupe entraine des changements en profondeur.

Lean rappelle l’importance de mettre des indicateurs en place. Appliqué à cette idée, l’évaluation de la performance individuelle devient obsolète et contre-productive. Il existe des systèmes comme les évaluations 360 pour prendre un feedback et reconnaître la performance de chacun. Pourquoi ne pas tenter cette approche ?

Pierre rappelle que le plus important est la performance globale. Comment ensuite délivrer de manière durable, et comment donner de l’autonomie ? Essayez ! Oui c’est aussi simple mais c’est vrai.

Le DSI saute et dit « Oui mais ils ne sont pas capables » : donnez-leur un manifeste, pour dire ce qu’ils peuvent faire, pour permettre. Retirez les obstacles pour qu’ils soient capables, aidez-les à concevoir rapidement des solutions en contribuant à la stabilité du système global. Permettre l’autonomie des équipes, en mettant des indicateurs pour pouvoir suivre l’évolution.

Un autre dit « Oui mais cela va être le foutoir… » : placez des standards simples. Il est important de donner des repères pour que l’entreprise réalise. Mais vous devez aussi rendre simple la possibilité de contribuer à ces standards. Repensez à Wikipedia. Pourquoi ne pas permettre aux équipes de contribuer ?

Un troisième dit « Oui mais… ils vont échouer » : donnez de l’autonomie, et surtout du sens. L’accomplissement personnel des développeurs, surtout dans les tranches 25-35 ans, passe par l’expression d’un sens. Chaque équipe doit avoir une phrase qui résume en 4 lignes ce qu’elle fait. A quel partie de l’entreprise contribue-t-elle ? Définir un sens pour l’équipe est primordial.

Les relations inter-équipes et l’évaluation doivent puiser dans les principes du Lean : la satisfaction du client est le plus important. Ne pas oublier que la raison d’être de votre produit, de votre logiciel, est de délivrer le plus rapidement possible de la valeur au client.

En conclusion, on peut essayer le pari de la confiance, l’idée de laisser ses équipes s’organiser en les aidant. La facilité d’utilisation des outils pour les clients est primordiale. La possibilité de contribuer aux standards de l’enterprise permet de ne pas oublier que l’informatique est avant tout une histoire d’homme.

Etre un individu est plus important qu’être un intitulé de poste.

Conclusion et Rétrospective
J’ai apprécié le fil conducteur de la présentation, comme le fond et la forme. Les principes du Lean transpirent dans la présentation, mais on a parfois envie d’une explication « encore plus simple » justement.
C’est une présentation du Lean Managment, qui nous amène à se demander s’il y a réellement une place pour l’entreprise classique, massivement hiérarchique. Pendant la présentation j’ai visualisé une structure monarchique de communication, où la communication se fait du haut vers le bas. L’arrivée d’Internet, le développement en méthodes Agiles et les attentes des développeurs sont autant de facteurs qui ébranlent cette approche, afin de construire des canaux de communications en étoile. L’individu est au centre, puis son équipe, puis les fournisseurs de services comme les RH/le support interne/l’équipe d’exploitation. Et la communication ne passe plus par le « chef de quelque chose ». Il est en effet temps de penser à un management différent.

Pierre,
j’ai pas fait le coup de « Philippe Manoeuvre » mais là tu prenais un bleu, car il y avait du sens justement, ce que j’ai vraiment bien aimé.

Cette conférence essentiellement francophone, est aussi le point de rendez-vous de nos voisins Suisses, Belges et Canadien comme l’an passé. Avec 280 personnes l’an passé, chaque session fut bien remplie. Les sponsors sont invités à se faire connaître pour aider l’équipe Agile France qui fait un travail remarquable.

Le site Agile France vous donnera tous les détails nécessaires : http://conf.agile-france.org/

Voici les articles publiés sur le Touilleur Express l’an dernier, afin de vous donner un avant-goût de ce qui vous attend :
XP Day France 2009 – journée 1 publié le 2009-05-27 00:22:41
XP Day France 2009 – jour 2 publié le 2009-05-27 20:03:05
XP Day France 2009, Scrum est-il dangereux ? publié le 2009-05-29 21:50:38
XP Day France 2009 – jour 2, Dans la peau du Challenger et Business Value Game publié le 2009-05-31 13:57:32

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

En novembre dernier, James Shore a publié un article intitulé « The Decline and Fall of Agile« . En substance, James explique que les clients qu’il rencontre et qui disent avoir mis de l’Agilité dans leur gestion de projet sont souvent en souffrance. En passant d’une conception où le design et l’architecture sont fait en amont à un processus itératif comme Scrum, ses clients emmagasinent une énorme dette technique. Certes les fonctions clés du logiciel sont livrées mais il regrette que ses clients ne prennent pas en compte aussi les bonnes pratiques de la conception Agile proposées par l’eXtreme Programming (XP).

Scrum est un formidable bâton de dynamite.
Pour peu que votre projet soit un peu bancal, mettez en place Scrum, laissez exploser cette dynamite et les poissons morts viendront à la surface. C’est un catalyseur qui mettra en avant l’ensemble des points faibles d’un projet ou d’une équipe, chose que l’on ne voit pas aussi vite avec un projet au forfait classique.
Alors que faire pour éviter cela ou se corriger ? La question est : comment durer ?
James explique que l’introspection est l’un des principes les plus importants souvent oublié ou négligé par les personnes qui débutent avec Scrum.
Le souci numéro un, et je le vois aussi aujourd’hui dans ma mission, c’est que l’on est tenté de ne choisir qu’une partie des règles de Scrum. Imaginez jouer au foot mais en ajoutant que vous pouvez ramasser la ballle avec la main et que la durée des mi-temps n’est pas fixée à 45mn mais à votre bon vouloir…
Premier principe : suivre dans un premier temps le processus. Agile ne veut pas dire « je peux faire n’importe quoi ».

Une critique faite à Scrum est aussi de ne pas avoir de pratique d’ingénierie. Oui en effet, Scrum n’est pas XP (eXtreme Programming). Scrum est un framework léger de gestion de projet. Ce n’est pas votre mère. Si vous souhaitez coder comme un cochon, libre à vous de faire ce que vous voulez. Jeff Sutherland explique qu’il voit que les équipes Scrum s’équipent en complément de méthodes XP, mais qu’il ne faut pas tomber dans le dogmatisme à outrance. J’ai fait l’expérience de faire du Scrum avec des pratiques de l’extreme programming (intégration continue, tests unitaires) sans non plus appliquer les 13 Principes d’XP car mon équipe marchait très bien sans. Et je ne suis pas le seul à le dire.

Regardons nos méthodes de développement : il est acquis en 2009 que l’industrialisation, l’intégration continue, les tests unitaires et le travail en binôme sont importants. Je me souviens de l’excitation autour d’XP que les gens ont un peu oublié. En 2002 un livre écrit par des français comment Laurent Bossavit plutôt bien écrit m’a fait découvrir XP. Aujourd’hui nous sommes tous d’accord pour dire que les tests unitaires, la pratique du TDD, la refactorisation sont des pratiques importantes, indispensables et professionnelles.
Donc pour moi, je considère comme acquis dans notre conscience ce besoin, et qu’il n’est pas forcément nécessaire de cristalliser les personnes qui font du Scrum en leur disant « ET FAITES AUSSI DU XP NOM DE DIEU… ».
La majorité des équipes qui appliquent Scrum utilisent déjà tout ou partie des pratiques XP. Un développement au forfait fonctionne aussi bien avec des bonnes pratiques proposées par XP.

Revenons à Scrum : l’importance de l’environnement.
Je travaille depuis quelques mois dans une nouvelle équipe. Scrum ne fonctionne pas comme je l’ai vu fonctionner avant. Pour l’instant je dis que cela ne fonctionne pas encore. Je m’interroge et je me demande si c’est de ma faute, si c’est la faute des gens, des managers… Pourquoi cette recette de cuisine ne semble-t-elle pas fonctionner pour l’instant ?
Parce que justement ce n’est pas une recette.
Je pense maintenant que Scrum donne un cadre et des pratiques simples. En modifiant ce que faisait l’équipe auparavant, le premier effet est de voire surgir les problèmes que nous n’avions pas identifié. Merci à Scrum. Ensuite je pense que bien que la recette soit définie, je dois m’autoriser à adapter une partie de Scrum à la vraie vie, ce que je fais. En faisant cela, j’ai bien conscience de prendre le risque de rendre les choses encore plus terribles… ce sera la faute de Scrum à la fin non ?

Alors j’ai regardé mon environnement : les équipes, le produit, les managers. Et c’est là qu’il faut travailler, redoubler d’efforts pour que la mise en place de Scrum ne soit pas partielle mais complète. Expliquer, rassurer, accompagner, coacher, écouter, parler, dessiner, dialoguer, diriger… mais ne pas faire du Scrum light.
Je l’ai dit au départ à un stand-up un matin: il n’y a pas de « on fait un peu de Scrum, il faut s’engager complétement et suivre toutes les pratiques ».

Si vous pensez à Scrum pour gérer votre projet, je vous conseille d’y aller complètement et de ne pas suivre qu’une partie du framework Scrum. Ne prenez pas que le dessert. Prenez l’entrée, le plat de résistance et le dessert. Avant de critiquer un sport, assurez-vous de bien en connaître toutes les règles, de l’avoir pratiqué et d’avoir aussi accepté toutes les contraintes.

Nous en venons maintenant à ce que je dirai devant pas mal de monde en avril : scrum est un pétard qui a deux effets : euphorisant d’une part, explosif d’autre part.
Dans les équipes qui travaillent encore avec des méthodes classiques de développement en cascade, le passage à une méthode Agile est un vrai explosif. Imaginez un chef de projet qui travaille 4 semaines sur une spécification technique. Il écrit noir sur blanc toutes les idées du client. Ensuite il rencontre les développeurs, qui ne sont pas d’accord ou qui objectent une partie du cahier des charges… Il réécrit alors ce cahier… Et ainsi de suite.
Basculez ce projet à Scrum et la vie sera plus rose, le client sera impliqué et acteur de ses décisions. Nous livrerons moins mais mieux et plus souvent…. Scrum dans ce cas dynamite un peu l’organisation. Les cycles sont plus courts, la vélocité de production augmente et la satisfaction des clients augmente… C’est le premier effet Scrum.

Dans une équipe complètement déstructurée, chaotique, qui travaille dans l’urgence avec la méthode LaRACHE, la valeur de chacun est estimée sur le temps qu’il passe à réaliser son travail. Souvent le principe est de répondre aux demandes du client afin de s’assurer que celui-ci soit satisfait.
Je pense dans ce cas que Scrum apporte un effet apaisant en structurant le dialogue entre les clients externes (les chickens) et les chefs de projets (les pigs).
Dans une équipe chaotique pour ne pas utiliser un autre mot, le client peut venir voir le développeur et demander une modification au nom du principe édicté par une personne qui n’a jamais codé : « le client est roi ».
Ce principe consomme beaucoup d’énergie, produit de la valeur sur le court terme mais n’est pas viable à terme. Imaginez une équipe de foot où les spectateurs pourraient venir sur le terrain pour expliquer au défenseur comment jouer…
L’apport de Scrum dans ce type d’équipe est donc une structuration relativement légère qui permet un recadrage en douceur.

Regardons un peu plus loin : au delà de Scrum, honnêtement je n’imagine pas travailler, diriger une équipe ou même demain une entreprise sans au moins réfléchir aux pratiques, aux valeurs et aux techniques de cette méthode. Et parce que c’est une méthode simple, je me dis qu’il n’y pas de coûts excessifs à l’utilisier.
Il reste cependant important d’intégrer des pratiques industrielles et des pratiques XP mais je pense que cela fait maintenant partie de nos habitudes. Il faut encore attendre et laisser mûrir Scrum.

Pour terminer, imaginez que vous êtes skipper, que je vous confie la mission de traverser l’Atlantique en bateau. Pour cela, pensez comment cela se passerait dans le cadre d’un projet au forfait classique puis ensuite sous la forme d’un projet Agile utilisant Scrum…

Moi je dis que le bonhomme qui chaque jour corrige son cap fait de l’itération car il sait qu’il n’y a pas qu’un seul cap pour traverser l’atlantique. Sa carte marine est son burndown-chart : il a dessiné la route idéale avant de partir, et il reporte chaque jour le trajet réalisé afin de savoir le « reste à faire »…

Sur ce, bonne journée.

Références:
Hervé Lourdin OCTO Technologies
http://blog.octo.com/index.php/2009/02/05/233-la-faute-a-scrum

Martin Fowler, sur XP et Scrum
http://martinfowler.com/bliki/FlaccidScrum.html

James Shore
Scrum met en avant des problèmes existants, attention à sa fausse simplicité
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

Le Chaos et l’ordre, Scrum vient déplacer votre ecosystème (merci à Gabriel Kastenbaum)
http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html

Scrum ou XP ? Scrum ET XP
Guillaume Bodet, Xebia
http://blog.xebia.fr/2008/01/10/scrum-ou-xp-scrum-et-xp/

Pourquoi les projets Agile ne peuvent pas être vraiment menés au forfait
http://blog.xebia.fr/2009/02/04/pourquoi-les-projets-agiles-ne-peuvent-pas-vraiment-etre-menes-au-forfait/

La méthode Lean tire ses racines du constructeur automobile Toyota. Celui-ci applique des principes depuis une dizaine d’années, ce que l’on appelle The Toyota Way. Pascal nous propose simplement de dérouler et d’expliquer les 14 principes clés de Lean…
Là je te sens sceptique lecteur. Tu te dis : super, on part pour 14 chapitres, je vais m’arrêter là.
Grave erreur.
Reste jusqu’à la fin, tu ne seras pas déçu. Sur les conseils de Thomas, j’ai bien saupoudré cet article d’exemple et de petites phrase afin de faire fonctionner tes muscles du sourire, et que le message passe, comme Pascal l’a fait ce soir.

14 points pour faire simple

Les principes de la méthode se découpent en 4 chapitres :
– les processus
– les personnes
– l’amélioration
– la philosophie

1) Les processus

Dans un premier temps, Pascal commence par expliquer que les bases de Lean sont de définir des processus exacts et justes, afin de produire le résultat attendu. Si votre développement dans votre équipe n’est pas guidé par des règles, le résultat ne peut pas être à la hauteur des espérances.

1.1 Le débit

Visualisez votre méthode de production de logiciel. Retirez les temps d’attentes et de latences et donnez un rythme, des repères de temps. L’idée est de créer un mouvement, de donner des contraintes de temps. La sortie d’une nouvelle version prend 4 heures. Je passe 1h pour créer une branche, 2h pour le packaging et les tests, 1h pour l’installation. Je gagne du temps en m’assurant que les problèmes surgissent très rapidement afin de les résoudre. J’essaye d’éviter le « Muda » ou gachis. Pour cela je réduis l’attente, le transport d’un point à un autre et les mouvements excessifs. En clair : je supprime les étapes qui dépendent lors de ma release d’une approbation d’un email. Je réduis le transport en supprimant un upload FTP et en compilant le produit sur la machine d’intégration. Je supprime les mouvements excessifs en mettant en place des scripts d’intégration afin d’éviter de devoir faire trop d’opérations pour sortir ma release…
L’objectif est de réduire le temps d’attente entre la commande du client et la livraison de sa demande. Cycle itératif court, livraison au fil de l’eau si possible plutôt que par paquet de 10… Pourquoi pas ?

1.2 Basculer vers un système où le client « tire » la production

L’idée est de produire (donc de développer) uniquement selon la demande des clients. Pascal utilise l’image d’un rayon de supermarché : tant que le client n’a pas pris d’articles sur le rayon, on ne produit plus. Dès qu’il « consomme » un article, on lance alors l’approvisionnement.
Rapporté à mon travail à la BNP, cela revient donc à dire que tant que l’utilisateur final n’a pas validé, commencé à utiliser ma superbe fonction, je ne m’embarque pas dans des développements. Cela a du sens.
On évite ainsi la surproduction, le gâchis, et surtout d’avoir des fonctions jamais utilisées dans un logiciel.
Pascal parle alors des cartes Kanban qui sont utilisés par Toyota afin de suivre la production. Voir aussi un article écrit l’an passé sur le sujet.

1.3 Lissez la charge de travail/la production dans le temps

Appelé « Heijunka » en japonais, ce concept vise à éviter l’épuisement des personnes (« Muri ») en s’assurant que la charge de travail soit constante, avec un rythme soutenu mais soutenable. Lorsque les équipes sont surchargées, elles peuvent certes répondre très ponctuellement à une demande. Si la situation perdure, on rentre alors dans un cycle d’épuisement, de démotivation et la chute est encore plus brutale.
Pascal raconte l’histoire d’un développeur qui refuse de quitter son poste. Le premier soir, il lui demande de partir, le développeur répond qu’il doit encore terminer une tâche. Le deuxième soir, même chose. Le troisième soir, le développeur est encore là. Le lendemain, le coach le rencontre en entretien, et se rend compte alors d’un problème dans le logiciel dont le développeur ne souhaitait pas parler.

Il est aussi important d’éviter le « Mura ». En Français : coup de bourre. Dans la mesure du possible, si le cycle de travail de la personne n’est pas lissé, celle-ci va alors s’épuiser très rapidement. De plus, les temps d’arrêt et de redémarrage coutent chers. Amusez vous à interrompre un développeur toutes les 30 minutes, vous verrez à la fin de la journée la tête du bonhomme.

1.4 Mettez en place une culture pour arrêter de résoudre les problèmes, car ceux-ci n’arrivent pas

Oooh que j’aime cette idée. Au lieu d’utiliser de l’énergie pour résoudre un problème, arrangez-vous pour qu’il n’arrive pas. Pascal explique qu’en 1924, un inventeur Japonais mets au point le premier métier à tisser qui s’arrête en cas de problèmes. Avant cela, il fallait employer à plein temps une personne pour surveiller le métier à tisser et dire « … jusqu’ici tout va bien » afin d’arrêter la machine en cas d’erreur…
La qualité n’est pas une option. Les tests unitaires ne sont pas un gadget, ce n’est pas négociable. Pensez votre logiciel afin qu’en cas d’erreur, celui-ci soit capable de se rendre compte que quelque chose cloche et qu’il s’arrête d’envoyer des messages JMS par exemple…
Mettez une grosse lumière rouge dans votre open-space. Lorsque l’intégration continue explose, il faut que toute l’équipe se mobilise, il faut que le leader en soit informé. Pensez à réduire le nombre de fonctions que vous livrez, afin d’en livrer moins mais de meilleures qualités. Vous gagnerez du temps, et finalement vous pourrez en livrer plus, contrairement à ce que vous pensez au départ.

1.5 Les tâches standardisées mais avec de l’humain

Toyota utilise des robots pour construire ses voitures. Les robots sont utilisés pour les tâches pénibles et dangereuses, mais pas pour tout. Un humain a un cerveau, il sait s’adapter. Il faut donc conserver le pouvoir et le donner aux employés, au développeur.
Enfin quelque soit le standard, celui-ci doit être amélioré en permanence. La personne qui fait de la production a le droit et le devoir d’améliorer le processus, chaque jour. Le gachis est de ne pas utiliser l’énergie des gens. Pour cette raison, Toyota a mis en place des boîtes à idées et récompense les ouvriers qui ont des idées, ce qui est le cas de tout le monde. Les experts sont les ouvriers, pas les managers.

1.6 Utilisez le contrôle visuel, afin que les problèmes ne soient pas cachés

Le principe ici est de mettre en place des indicateurs que toute l’équipe voit, ainsi que les managers et les clients. Concrètement, mettez au mur une feuille blanche, prenez des post-its de couleur, mettez une colonne « incidents en cours » ou « bugs urgent » et marquez les problèmes sur ces post-its. Oui vous pensez faire des loisirs créatifs, mais réfléchissez à l’utilité de ce genre d’indicateur. Un tableau se voit tout le temps. Les post-its représentent une quantité de problèmes à résoudre. Les clients voient au mur que votre équipe est surchargée. Vous pouvez aussi faire un suivi du temps de résolution. Il suffit de déplacer le post-it dans une colonne « Terminé » et d’indiquer le temps perdu sur la tâche.
Pascal va encore plus loin en montrant la photo d’un urinoir. Au dessus de celui-ci on peut lire « 11 bugs de Sev1, je sais que j’ai ton attention, alors au boulot ! ». Pas mal non ?
Les indicateurs visuels chez Toyota c’est un panneau lumineux placé sur la chaîne qui indique aussi les facteurs de productivité, les objectifs à atteindre, les problèmes en cours…

1.7 Utilisez des technologies fiables, éprouvées et testées qui aident vos clients et vos développeurs

Certainement le point qui fait le plus mal… Arrêtons 5 minutes avec nos frameworks de double-inversion de contrôle où tu configures en XML ce que tu faisais en Java… Revenons sur Terre 2 minutes, prenons des outils qui ont fait leurs preuves et arrêtons de nous faire plaisir, avec ce framework « jante alliage » qui aura disparu dans 6 mois, ou cette superbe librairie de parsing pour lire un fichier texte de 3 lignes…
Il faut stimuler la recherche selon 3 étapes, de la plus facile à mettre en place à la plus révolutionnaire :
– conserver la solution existante
– améliorer par incrément
– faire une percée radicale
Il y a souvent peu de problèmes de personnes, bien plus souvent un problème de processus.
N’hésitez pas à investir du temps pour réaliser un prototype si vous souhaitez prendre une nouvelle technologie. Rejetez aussi les technologies qui ne sont pas compatibles avec votre culture, et encouragez les développeurs à toujours regarder ce qu’il se passe sur le marché, afin d’éviter de tomber dans un cul-de-sac technique… Et surtout, pensez à vous outiller. Je vous parlerai prochainement de SpringFuse, le produit de Jaxio. Il est temps d’arrêter de jouer aux Legos et de passer à des jeux un peu plus industriel.

2) Les personnes

La force d’une entreprise c’est son patrimoine humain. Sortons un instant de Lean. Regardez les cabinets de consultants sur Paris. Ce qui fait la valeur d’une entreprise c’est ses équipes. Pas son logiciel, pas ses méthodes. Non, juste ses équipes. Le secret des cabinets de consultant (SSII) qui marchent, c’est l’investissement dans les valeurs humaines. Le ticket d’entrée est plus cher, le retour sur investissement est bien plus important.

2.1 Fait grandir des leaders

Pascal explique que l’idée est de faire grandir des leaders en prenant des personnes du vivier de l’entreprise. Rien de pire qu’un manager parachuté à la tête d’une équipe d’après son expérience. Il explique que les leaders doivent servir de modèle pour les arrivant, et qu’un bon leader doit connaître les processus de son équipe en les ayant pratiqué. J’ai eu en tête le responsable du MacDo à côté de chez moi. Le gars a commencé il y a 7 ans comme équipier. Il gère aujourd’hui une équipe de 21 personnes… Et il n’a que 26 ans…

2.2 Développe des gens exceptionnels et des équipes qui suivent la philosophie de ton entreprise

Pascal explique qu’il est plutôt souhaitable de faire en sorte que les équipiers ne soient pas trop spécialisés dans une équipe de développeur. Pour cela, il faut mettre en place une dynamique et faire en sorte que le brassage des développements soit une réalité. Je suis un peu plus sceptique sur ce point, mais je comprends l’idée.

2.3 Le respect est une valeur essentielle

Tout d’abord respectez vos clients, mais aussi vos fournisseurs. Toyota rapproche géographiquement ses fournisseurs et montre toujours un respect important. L’exemple que Pascal utilise est le suivant : un constructeur automobile va voir un fournisseur de moteur. Il demande 5% de réduction, sinon c’est la fin du contrat… Aucuns respects du client.
Toyota va voir le même fournisseur et propose de prêter 3 de ses ingénieurs afin de réduire les coûts de développement de 10%, et donc d’obtenir 5% de réduction aussi. Sauf que Toyota ne sera alors que le seul à bénéficier de cette réduction. Respect et intelligence…

3) L’amélioration

L’amélioration en permanence nous aide à résoudre les problèmes au fur et à mesure. En s’introspectant après chaque itération, une équipe de développement qui fait du Scrum s’autocritique et s’améliore. Pascal insiste sur le fait que l’introspection est peut-être le concept le plus important de Lean. Je pense à cet instant dans ma tête que chez mon client en ce moment, c’est le point que nous ne traitons pas. Il est temps de remettre en place ce processus d’urgence.

3.1 Allez voir par soi-même les sources des problèmes « Genchi Genbutsu »

Pour améliorer la production, Toyota préconise aux managers de descendre et d’aller sur la chaîne afin d’observer et de regarder en situation ce qu’il se passe. Il faut que le manager aille voir la production et qu’il identifie les problèmes. Pascal raconte l’histoire de la Poste Belge qui perdait du temps pour traiter l’envoi de colis internationaux à cause d’un mur (un vrai avec des briques) entre le quai de déchargement des camions et la pesée, obligatoire pour les envois et la facturation. En détruisant le mur, la productivité a augmenté.
Il faut que votre chef passe un peu de temps avec vous afin de comprendre ce qu’il se passe.

3.2 Prenez des décisions avec un consensus et le plus tard possible

Dans un premier temps, listez toutes les options possibles. La Toyota Prius avait ainsi 80 projets de moteur différent au départ. Dessinez un rétro-planning en partant de la date de sortie souhaitée. Revenez en arrière et représentez à chaque fois la date limite où il faudra prendre une décision (Spring ou EJB 3.1 ?). Ne prenez la décision qu’au dernier moment, pas au début.
En cas de problèmes, discutez avec toutes les personnes impliquées afin de prendre l’avis de tout le monde, et qu’une énergie commune fasse que les choses changent (« Nemawashi »).
Le consensus prend peut-être du temps mais vous donnera un résultat de meilleur qualité. Le planning poker pour estimer le temps de développement d’une tâche est un exemple de consensus.

3.3 Réflexions et améliorations

La réflexion (« Hansei ») et l’amélioration continue (« Kaizen ») sont deux facteurs clés de la méthode Lean. Préparez des processus métiers qui ne demandent pas beaucoup de travail d’inventaire. Cela forcera les équipes à s’améliorer en permanence.
Lorsqu’un process est stable mais qu’un problème survient, pensez à demander 5 fois « Pourquoi » à votre développeur.
- « Je ne peux pas corriger ce problème car je n’ai pas le temps »
- Pourquoi n’as-tu pas le temps ?
- Je suis occupé par une tâche de production que je dois faire, je dois envoyer un nouveau mot de passe à un utilisateur
- Pourquoi dois-tu envoyer un nouveau mot de passe ?
- Parce que le système ne sait pas le faire
- Pourquoi ne sait-il pas le faire ?
- Nous n’avons pas développé de fonction « me renvoyer un nouveau mot de passe » sur la page d’accueil
- Pourquoi ?
- Parce que nous avons oublié de le marquer dans le Product Backlog et que nous n’avons pas écouté le chef de projet. La prochaine fois nous le marquerons dans le product backlog et nous ferons en sorte de l’implémenter.

4) La philosophie

Pascal Van Cauwenberghe termine par le point le plus important pour lui : la philosophie à long terme.
Basez vos décisions de manager sur du long terme, même si le coût à payer à court terme est important..
Pour cela il évoque Toyota qui fait la promesse d’offrir un emploi à vie à ses salariés. En raison de la crise il se demande si cette philosophie pourra perdurer. Il explique que Toyota en accord avec ce principe, tente de former les gens en ce moment au lieu de les faire travailler sur des chaînes, afin que lorsque la crise sera passée, ils soient encore meilleurs… C’est beau…

Conclusion et réflexions

Après vous avoir présenté Lean tel que je l’ai vu ce soir, j’ai quelques réflexions.
Tout d’abord je visualise maintenant mieux comment une méthode comme Lean est compatible avec Scrum ou XP. Pour tout vous dire, je vois Lean comme des jalons et des repères pour travailler mieux. Ensuite Scrum apporte un framework qui aide à piloter le cycle de développement d’un logiciel. Enfin XP est pour moi maintenant dans les habitudes des développeurs, et je pense par contre que vouloir caler ses 13 principes reste assez difficile.
Donc on a un escalier avec 3 marches, la marche la plus haute étant XP, et la première étant Lean.
Qu’en pensez-vous ?

Merci à Zenika qui a organisé une soirée très riche. A la sortie, remise d’un résumé de Lean, apéritif, accueil sympathique.. rien à redire. Bravo à eux.
Zenika est sponsor du Paris Java User Group, ainsi que sponsor des XP Days le 25 et 26 mai 2009.

Enfin j’ai appris aussi comme Olivier un peu au dernier moment que le 3ème Java Barcamp aura lieu samedi 31 janvier toute la journée, cette fois-ci organisé par Eric Lefevre Ardant et Anthony Dahanne de Valtech. Plus d’information : http://barcamp.org/JavaCampParis3.
Le BarCamp se déroulera le samedi chez SUN au Sun Customer Briefing Center, 42 avenue de Iéna, 75016 Paris. Superbes locaux où j’ai travaillé deux mois pour une mission (soupir…).
Moi je suis déjà pris, donc ce sera sans moi.

J’en profite pour vous annoncer que le 14 avril prochain je présenterai Scrum avec Eric Mignot de Pyxis au Paris JUG, le 10 mars ce sera une soirée sur le Web et le 10 février, anniversaire du Paris JUG avec 3h de conférences au programme !!! le tout gratuitement !

A mercredi !

Je me pose pas mal de questions sur Scrum.

Une grosse partie de la méthode Scrum a révolutionné ma vision sur le développement informatique. A un point tel que j’ai vraiment du mal avec les méthodes classiques de gestion de projet. D’un autre côté la maîtrise de Scrum demande des efforts qui vont au delà d’une simple formation.

Après quelques mois et un peu plus de recul, je commence à croire qu’il faudrait adapter et revoir culturellement la méthode avant de l’appliquer en France telle quelle. On peut reprocher à Scrum son cérémonial rigide. En effet malgré le peu de cérémonies, celles-ci sont des rendez-vous important pour que le processus fonctionne. La cérémonie qui fonctionnait le moins bien pour nous (chez Reuters) était la Sprint Review Meeting. Je demandais à l’équipe de lister les points qui s’étaient bien déroulés et les points à améliorer. Et finalement tout tournait autour de Scrum. Je sais que Scrum met en avant les points délicats dans la gestion d’un projet, que c’est l’un de ses effets. Cependant l’équipe n’arrivait pas à passer à l’étape suivant et à voir un intérêt à ces événements.

Alors réfléchissons à une autre méthode, la méthode RESTO (copyright Le Touilleur Express).

Les bases de cette méthode : cycle itératif court et limité dans le temps, une liste de fonctionnalités à implémenter, aucunes cérémonies, la capacité pour chaque développeur de prendre n’importe quand n’importe quel élément d’un tableau. Techniquement il vous faut des post-it, des marqueurs de couleur, un « paper board » et un peu d’organisation. Ensuite j’y ajoute des rôles tournants afin de pouvoir palier aux soucis venant de l’exterieur. Il me faudra un barman, des cuisiniers et des serveuses. A noter que si votre équipe est trop petite, vous pouvez cumuler les rôles.

Faire le Menu de votre RESTO

Tout d’abord la première étape est de regrouper dans un fichier Excel toutes les demandes de vos clients, les bugs et les demandes de changement. Pour chaque élément, vous allez identifier par une phrase comment le client testera la fonction.

Par exemple :  « j’ouvre mon navigateur, je me connecte sur l’adresse de la prod, je vois une page d’authentification. Je mets mon login et mon mot de passe et je peux alors entrer dans l’application. Sur la page d’accueil je peux cocher une fonction ‘Se souvenir de moi’ et c’est tout »
Ce fichier doit être mis à jour en permanence selon les demandes des clients. C’est ce que j’appelle le Menu, et c’est ni plus ni moins un Product Backlog.

Les Serveurs auront pour mission durant la durée de la Mission de mettre à jour le contenu de ce fichier en y insérant les demandes des Clients. Les Cuisiniers seront chargés de donner le Prix à payer pour chaque élément, en respectant mes explications sur ce qu’est une Estimation dans le cadre du développement d’un logiciel.

Un peu de réunionite

Ensuite je verrai bien une première réunion à laquelle j’inviterai un client avec l’équipe. L’idée est qu’avant de commencer à développer, le client est présent afin d’expliquer en détail et de clarifier les points qui seraient mal expliqué. Appelons cela la Commande. Une fois la Commande passée aux Serveurs, le Client doit attendre tranquillement que son plat soit préparé.

Le Barman : mister Cocktail

Le Barman est là pour le faire patienter. Il peut venir l’aider ponctuellement afin de l’aider à corriger un problème urgent. C’est la personne en charge de la production en quelques sortes. Il est disponible pour travailler avec le Client pendant que le reste de l’équipe bosse. L’idée par rapport à Scrum serait d’avoir une personne disponible et allouée afin de traiter les problèmes du Client en dehors du cycle de production. En fait le Barman se charge de faire boire le client pour le faire patienter. Je piquie cette idée à ce que nous faisons actuellement sur la plateforme de Prime Brokerage : l’un de nous est en charge de la production pour 5 jours et durant cette durée, ne participe pas aux développements de l’équipe.

La batterie de Cuisine

Les Cuisiniers ne voient pas le client, ce qui est peut-être une faiblesse par rapport à Scrum. D’un autre côté ils peuvent travailler en permanence sans devoir être présent à des réunions, ou être obligé de participer à des cérémonies comme pour Scrum. J’imagine ainsi accélérer la productivité en n’impliquant qu’une partie de l’équipe dans la relation client< ->équipe.

Il est important de ne rien faire une fois par semaine

Enfin j’y ajoute un concept qui vient de mon expérience chez Reuters : le vendredi c’est ravioli.

Derrière cette phrase magique, l’idée est de dire à toute l’équipe qu’une journée de la semaine est consacrée à faire autre chose que le boulot habituel. Durant cette journée, chacun fait ce qu’il veut tant que cela reste en rapport avec son travail. Je reprends une idée appliquée chez Google.
Aurélien mon petit-frère a travaillé 2 ans chez Google en Irlande. Il m’expliquait ainsi qu’une partie de leur évaluation et donc de leur bonus est calculé sur leurs initiatives pour la communauté. Mon frère a ainsi monté un groupe de rock/folk et il a participé à une œuvre caritative, en plus de son travail, ce qui lui a valu des points en retour par son management. Évidemment cela ne rapporte rien, si ce n’est un esprit, une ambiance et quelque chose que les autres compagnies n’ont pas.

Je pense que la personne qui a l’idée d’un nouvel outil pour améliorer la productivité, ou qui a l’idée d’apporter un panier de basket pour que l’équipe se détende, devrait être récompensé. Attention je ne vois pas un système anglo-saxon basé sur la performance, plutôt un système bien français basé sur la bon humeur.

Nous pourrions imaginer qu’à la fin de chaque Mission, tout le monde donne un point à une personne de son choix. Celui qui a le plus de point est alors proclamé Grand Manitou, et il peut alors affecter une tâche rébarbative dont il a la charge à un de ses collègues. Le Grand Manitou a le droit de refuser une Commande d’un client pour la prochaine Mission. A chaque fin de Mission on élit alors un nouveau Grand Manitou et ainsi de suite.

Oui cela vous choque… pourtant j’ai entendu cette semaine le cas d’un grand cabinet de consultant qui a offert un iPhone à deux de ses collaborateurs les plus méritants, qui, par leurs contributions sur le blog de l’entreprise, ont contribué à améliorer la visibilité et la réputation de cette entreprise.

Prenons ensuite une spécificité franco-française que nos voisins Belges ou Suisses nous envient (peut-être) c’est la fin d’une mission. Après 2 semaines de développement, le dernier vendredi de ces 2 semaines sera une journée Ravioli, avec l’obligation de fêter la fin de la Mission. Pour cela vous pouvez apporter des croissants et faire un petit-déjeuner, vous pouvez faire un restaurant le midi ou même organiser un apéritif après le travail dans un bar à côté de votre travail… L’objectif est de FETER la fin de la Mission.

Dans le bâtiment lorsqu’une équipe termine un chantier, les ouvriers, l’architecte et les conducteurs de travaux se retrouvent afin de faire un grand repas pour fêter la fin du chantier. Je pense que nous devrions faire la même chose et formaliser cela dans la méthode RESTO.

Voilà un billet bien décalé qui nous sort de la morosité ambiante, qui nous permet d’envisager un processus adapté à nos habitudes, et qui je l’espère, vous donnera de l’inspiration pour vous épanouir et vous faire plaisir en travaillant. Je sais qu’au final derrière ce que je viens d’expliquer, ça sent le Scrum.

Bonnes fêtes.

J’ai assisté tout d’abord à une présentation sur les techniques d’estimation du temps de développement appliquées à notre secteur. Le speaker, Gioavanni Asproni, a donné un ton très sympa à cette présentation.

Dans un premier temps, un bon mot pour commencer:

Estimation : Prediction is a very difficult task especially about future ones… »

Giovanni demande à l’assistance qui donne des estimations de temps de développement ? la majorité de la salle. Qui se fait négocier par son managment ces temps de développement ? Encore une fois pas mal de monde.

Il explique ensuite la différence entre « Estimation » et « Engagement ».
L’estimation est la mesure objective du temps nécessaire pour faire une tâche. Cette estimation n’est donc pas négociable. L’engagement représente le but à atteindre et donc la promesse. Cette promesse regroupe un niveau de qualité, un certain nombre d’itérations, bref c’est bien la promesse de ce que le client aura. L’estimation c’est le prix à payer.

Sur une route vous roulez avec un camping-car dont la hauteur est de 2m30. Arrive un pont dont la hauteur est limitée à 2m00. Est-ce que vous penser réussir à fare passer votre camping-car sous ce pont ? non. Vous pouvez toujours estimer si « ça passe » mais dans ce cas, à vous d’assumer les conséquences.

Donc l’estimation étant une mesure approximative, mais une mesure, vous ne devez pas négocier cette estimation. Vous devez donc négocier les engagements. Je reprends l’image du réservoir d’essence : lorsque le voyant s’allume car le réservoir est presque vide, sans le savoir votre cerveau bascule en mode « estimation ». Et vous êtes d’accord pour dire que cette estimation n’est pas négociable.

Il fait ensuite référence à un très bon livre de Steve McConnell « Software Estimation » afin d’expliquer finalement en quoi consiste une estimation.
En tant que développeur nous allons nous efforcer de donner une valeur pour la taille, le coût, l’effort en jours et les risques pour réaliser une tâche. Lorsque votre responsable vous demande une estimation vous devez donc répondre « 3 jours avec un risque important que la base ne tienne pas la charge, à 2 développeurs par jour avec une licence de GridGain »

Les estimations sont par nature sources de problème et de frustration, car le managment tient pour acquis le contrat passé entre vous et eux. Pour cette raison, Giovanni pense que les processus Agile par leurs cycles itératifs sont plus adaptés au développement logiciel que l’effet escalier, basé sur la contractualisation des échanges entre les développeurs et les personnes du business. Une spécification ne pourra jamais résoudre un problème de communication.

Il présente ensuite un cône sur une échelle de temps afin d’expliquer qu’en général, les estimations données pour une activité sont fausses, et que la marge d’erreur va de 0.25 à 4 sur une échelle verticale. Si je réponds 3 jours pour faire ce développement, il pourra en fait en prendre 4 fois plus. Ce travail est basé sur l’analyse de gros projets dans l’industrie de l’armement américaine, et des travaux de la NASA.

Ce cône est donc une fenêtre de tir pour nous clairement que nos estimations sont en générales fausses.

Comment alors réussir à travailler et répoondre aux attentes des clients ?
Dans un premier temps, il faut passer beaucoup plus de temps sur l’engagement, sur la notion du fini, sur ce que désire le client. Regardez le temps que vous passez pour acheter une cuisine chez IKEA ou pour acheter une voiture. Pour quelles raisons le client refuserait-il de vous répondre sur un projet d’un million d’euros ?

Comment gérer les changements du client ?
Vous devez penser que les changements sont gratuits et qu’ils vont arriver en cours de développement. Pour cette raison, les estimations doivent aussi être revues à la hausse ou à la baisse. Il est aussi important de rappeler à votre client que s’il décide de prendre les jantes alliages, cela coûte alors 400 EUR de plus… Pensez à toujours ajuster vos estimations afin que le client ne découvre pas au dernier moment l’addition.

Faut-il surestimer ou sous-estimer ?
A cette question, Giovanni répond que les développeurs sont trop optimises de 30%. Par sécurité il faut donc mieux ajouter un peu plus à une estimation initiale. Cependant, l’effet inverse s’appelle la loi de Parkinson : le temps de travail temps à rejoindre le temps donné pour effectuer une tâche. Si tu me donnes 10 jours pour faire cette tâche, je vais tendre à remplir ces 10 jours, c’est humain.
Avoir trop de temps disponible entraine aussi le phénomène de procastination (décidemment avec le Touilleur Express vous faîtes aussi de la psycho). On tend à remettre à demain des tâches (payer ses impôts…) car on sait que l’on a jusqu’au « XXX pour payer ».

Les techniques d’estimation
Il en existe un grand nombre, certaines basées sur l’observation du passé pour prédire le futur. A noter que dans la finance c’est une technique de calcul du risque sur un produit financier. Il y a des techniques scientifiques basées sur les probabilités, mais comme il le montre avec des formules un peu complexes, cela ne remplace pas l’humain.

Son point de vue est que les techniques suivantes fonctionnent bien :
– faire faire les estimations par les développeurs, surtout pas les chefs de projet
– faire des estimations collégiales pour que tout le monde donne son avis
– utiliser des analogies pour améliorer la précision d’une estimation
– ne pas oublier les activités connexes comme les tests, la mise en prodution, les tests en UAT par exemple.
– utiliser vos experts pour avoir de bonnes estimations mais ensuite pensez à augmenter ce temps. Tout le monde n’est pas un expert.

Les domaines où les prédictions/estimations sont appliqués sont la Finance, avec le succès que l’on sait aujourd’hui et sinon la dame en mini-jupe le dimanche soir sur TF1 : la météo de la semaine. Il y a aussi Mme Irma dans sa roulotte et Mr Marabout à Barbès.

Bref les estimations sont par nature fausses, il faut simplement travailler avec le client afin de le rassurer, de mettre en place des plans d’atterrissages d’urgence si le budget est dépassé. Et il faut aussi rappeler au client que le prix à payer n’est pas négociable.

Voilà pour cette première présentation