Denis Dollfus' Blog

Agilité des développeurs français : résultats de l'enquête

Le questionnaire sur les pratiques Agiles de management et d'ingénierie a été très bien accueilli puisque depuis sa mise en ligne le 6 janvier près de 270 personnes l'ont rempli. Il faut dire que  Claude Aubry, Olivier Azeau, David Brocard et Emmanuel Chenu ont donné à ce questionnaire une excellente visibilité.

En un coup d'oeil, voici les 270 scores portés sur les deux axes (voir plus bas pour la méthodologie) : 

 

Ce qui saute aux yeux, c'est que les résultats sont plutôt bons, il y a une accumulation de réponses vers les 100%.

Il apparait aussi une corrélation moyenne (0,7 pour les puristes) entre les deux dimensions.

En fait le nuage de points n'est pas symétrique. Il n'est pas rare que le répondant ait une bonne maîtrise des bonnes pratiques d'ingénierie sans que la gestion du projet dans lequel il travaille soit Agile. Pour caricaturer : il y a plus de développeurs Agiles travaillant dans un management rigide que l'inverse. Ce déséquilibre est clair quand on constate que la concentration de points sur l'axe des ordonnées n'a pas d'équivalent sur l'axe des abscisses.

Dans l'ensemble ces résultats, y compris cette disymétrie, sont encourageants pour ce qui est de l'adoption des méthodes agiles : les développeurs semblent prêts à adopter une gestion de projet Agile.

Qu'en pensez-vous ?

Bien sûr il y a des biais :

• L'enquête a été pour une grande part diffusée via des blogs orientés Agilité. Les répondants sont très probablement eux-mêmes sensibilisés aux méthodes Agile et peuvent tirer les scores vers le haut.
• Il est possible que certains répondants s'exercent à viser le 100%. Ca fait partie du côté pédagogique du questionnaire mais les scores peuvent en être biaisés.

Méthodologie. Chacune des 29 questions portait soit sur l'aspect "management/gestion de projet" de méthodes agiles (stand-up meeting, itérations courtes, estimation par les développeurs, etc.), soit sur la dimension "Ingénierie" (techniques pour garder le logiciel évolutif à moindre coût -- tests unitaires, refactoring, etc.). Une fois l'ensemble des questions traité, le profil du répondant correspond à une fraction d'un 100% théorique maximum sur ces deux axes. Ces profils sont portés sur le graphique ci-dessus, avec épaississement du point quand plusieurs profils sont superposés.

Développeurs, déterminez votre niveau d'Agilité

On parle tellement en ce moment des méthodologies Agiles (eXtreme Programming, Scrum, Lean, ...) qu'on finirait presque par se croire tous Agiles. Voici un petit test qui vous permettra d'évaluer votre niveau d'agilité personnel, de faire la part entre l'agilité idéale et les pratiques mises en oeuvre au jour le jour par vous et les autres membres de l'équipe.

Ce test n'est pas une évaluation formelle mais un test plutôt ludique qui vous aidera à vous situer par rapport aux canons des méthodes agiles, à la manière des tests de magazines.

Comme j'ai remarqué une certaine indépendance entre les pratiques agiles de gestion de projet et les pratiques agiles de développement, le résultat de ce test vous sera présenté sur ces deux axes, management et ingénierie. Vous pourrez non seulement vous y situer par rapport à un "100% Agile" théorique, mais aussi vous situer par rapport aux autres développeurs ayant répondu au test sur un graphique de ce type (avec beaucoup plus de points je l'espère !) :

[Mise à jour du 26/01/2009 : les résultats sont publiés ici -- ce qui ne vous prive pas pour autant d'y répondre pour connaître votre score...]

Et un grand merci à Claude Aubry, Olivier Azeau, David Brocard, Emmanuel Chenu et Jean-Marie Damas dont l'expérience des méthodologies agiles a été précieuse pour m'aider à mettre au point ce questionnaire (je ne pense pas qu'ils cautionnent pour autant la totalité des questions, surtout celles ajoutées à la dernière minute).

Voici donc les questions, qu'il vous faut dans l'ensemble faire précéder d'un "Honnêtement et sincèrement, dans votre projet de développement actuel, ..." :

Chrome : portes ouvertes permanentes sur la compilation et les tests

(Marcel Gotlib,
Pervers Pépère)

Pour ceux qui douteraient encore (je sais qu'il y en a) de l'intérêt de l'intégration continue, c'est-à-dire de l'exécution périodique de la compilation et des tests unitaires de l'ensemble des modules d'une application, lisez-bien ce qui suit, vous allez en rester baba. Les autres, laissez tomber (je vous aurais prévenu).

Chrome, le nouveau navigateur open-source de Google est en développement. Soit, jusqu'ici ça va.

Mais attention : les processus de build qui tournent en ce moment même pour générer un composant de  Chromium pour XP, un morceau de WebKit pour Vista ou une extension pour Linux, tous ces process, mesdames et messieurs tenez-vous bien, y compris l'exécution des tests unitaires qui échouent, les compilations qui plantent, tout cela, c'est énorme, vous pouvez y accéder en permanence et en temps-réel à cette adresse !

Comme j'entends déjà les blasés me dire qu'ils le savaient déjà et que ça fait longtemps que ça se fait, je leur réponds en anticipant que, et d'un, ils n'auraient pas du lire ce billet rapport au premier paragraphe ce qui prouve bien qu'ils sont de mauvaise foi, et que ensuite, s'ils l'ont lu quand même c'est parce que l'illustration les a attiré ce qui prouve de surcroit leur qualité de geeks pervers.

Le pire, c'est qu'ils ont raison (Cf. FireFox -- et Eclipse me signale Aurélien dans les commentaires) mais moi ça m'épate encore quand je constate un tel niveau de transparence sur un projet d'une telle ampleur, et ça démontre que les pratiques d'ingénierie logicielle Agile peuvent s'appliquer à des gros projets. Ou plutôt l'inverse : les gros projets ne peuvent se passer des pratiques agiles, au moins celles-là.

Pour rappel l'intégration continue et les tests unitaires sont des composantes essentielles (mais pas les seules) d'eXtreme Programming (XP).

Scrum et XP en pratique : un livre en français à télécharger

Emmanuel Chenu vient de signaler la sortie de la traduction française de "Scrum and XP from the trenches", d'Henrik Kniberg.

Loin de la théorie et de la simple déclaration d'intention de l'Agile Manifesto, ce livre décrit les pratiques (et leur justification) à mettre en oeuvre au jour le jour pour développer en mode Agile grâce à Scrum et XP.

Il est téléchargeable gratuitement depuis cette page.

Agilité : grandeur et décadence ?

Un article de James Shore intitulé "grandeur et décadence de l'agilité" fait du bruit (Cf. par exemple Claude Aubry). Le raisonnement de ce billet tient en deux points :

• Pour un projet donné, Scrum échoue sur le long terme si aucune méthode d'ingénierie logicielle ne vient compléter Scrum.
• Avec le temps, la multiplication de ces échecs donnera une réputation calamiteuse aux méthodes agiles, qui feront alors fuir tous les chefs de projets.

J'approuve ce point de vue sur Scrum. Scrum seul est réellement une calamité pour les logiciels à longue durée de vie parce que rien dans Scrum n'aide à bâtir des logiciels maintenables et évolutifs. Or rester agile, c'est-à-dire maintenir un rythme d'itérations courtes, requiert de développer un logiciel qui accepte les évolutions fréquentes. Ce qui n'a rien d'évident.

Pour y parvenir, les bonnes pratiques d'ingénierie logicielle, au premier rang desquelles les tests unitaires (TDD ou non), le refactoring et l'intégration continue doivent compléter les méthodes de management pur déconnectées du métier du software telles que Scrum. Ces pratiques doivent être adoptées pour que l'agilité dépasse la déclaration d'intention. Et pour que la réputation des méthodes agiles ne soit pas mise en danger.

Hélas, ces pratiques ont un succès tout relatif parce que Scrum et son écosystème rémunérateur de certifications est la plus vigoureuse et la plus visible des méthodes agiles.

On en arrive à la thèse de James Shore : la méthode Agile qui est en train de gagner entrainera toutes les méthodes agiles à leur perte.

Certes on a vu récemment des crises plus graves dans des domaines qui se portaient mieux, mais n'est-ce pas pessismiste ? Peut-on revigorer XP ?

L'agilité sans tests unitaires, c'est comme...

Si vous travaillez sur un projet qui a grandi sans investissement en tests unitaires, vous pouvez ressembler à Wile le Coyote quand on vous annonce que le client souhaite quelques changements, changements mineurs pour tout le monde sauf pour vous :

L'Agilité sans méthode ni outil : courage, courage, courage.

La déclaration d'intention Agile est sciemment sans moyen. A vous de compléter votre courage (ou votre rage) par l'équipement minimal, les tests unitaires.

Hulk oriented programming

Il vaut mieux du code mal écrit et privé de tests unitaires que le contraire : plus il y a de bugs et de régressions, plus c'est rageant, et la colère donne des forces, Hulk ne me contredira pas (s'il me contredit je change d'avis). Ca tient debout.

Quoi ! Je corrige un bug et y'en a deux qui apparaissent ?
Raaa je vais tout corriger, rien ne m'arrêtera !
(Image Marvel)

On peut voir le Hulk oriented programming comme une variante de "Get Me Promoted Methodology", dans laquelle le code de piètre qualité et sans test unitaire entraine le développeur dans des corrections héroïques dont la juste récompense encourage le code de piètre qualité. Ca aussi c'est du solide.

Visite d'une équipe Scrum / eXtreme Programming

Gizmo, un monstre de premier plan

Emmanuel Chenu, dont j'ai découvert le blog et l'expertise Agile à partir du site Agile Tour 2008 (mais je ne sais plus par quel chemin), vient de publier un document en forme de reportage photo (et commentaires) sur l'organisation de son équipe de développement.

De quoi démystifier les outils et pratiques des méthodes agiles tels que stand-up meetings, gizmo, burndown-charts, le niko-niko ou la machine d'intégration continue.

Le document pdf d'Emmanuel est un peu lourd à télécharger mais votre patience en vaut la peine. Vous le trouverez sur ce post.

Attendez ! Pendant qu'on y est, profitez aussi des slides des cours d'Emmanuel, c'est le document en français le plus complet que j'ai eu l'occasion de voir sur l'ingéniérie logicielle et les méthodes agiles.

Agile tour 2008, le développement Agile près de chez vous

Pour mieux connaitre les méthodes de développement agiles, les experts des méthodes agiles viendront vous voir lors de l'Agile Tour 2008 qui passera par Besançon, Mulhouse, Genève, Grenoble, Lille, Toulouse et Valence, le tout du 1er au 23 octobre 2008.

Le programme de chaque étape est en voie d'être finalisé, mais il permet déjà de constater que les intervenants, qui représentent des entreprises de toute taille (de Yahoo à Octo en passant par Sfeir), seront clairement dans le concret des retours d'expérience. Une excellente occasion de les bombarder de questions.

Dépêchez-vous, pour Grenoble, c'est déjà complet.

http://www.agiletour.com

Les dabbawalas : un modèle d'agilité ?

Connaissez-vous un service de livraison dont la croissance et la qualité font baver d'envie les managers de tout poil, y compris les gourous du management ? Ce sont les Dabbawalas, livreurs de repas en Inde, qui atteignent  l'incroyable taux d'erreur de l'ordre de 1 pour 6 millions de livraisons !

Imparable logistique. (photo Joe Zachs)

Preuves de leur présence au top des tendances du management, le prince Charles et Richard Branson (créateur de Virgin) ont tenu à rencontrer les Dabbawalas, la Harvard Business School leur a consacré une étude, et Tata, Coca-Cola et Daimler les ont invité pour comprendre leurs méthodes de travail.

Leur secret pour résoudre tous les petits problèmes quotidiens d'acheminement des colis ? Une organisation "bottom-up" qui mise sur "une authenticité humaine et sociale" plutôt que sur un ensemble de procédures documentées, d'outils techniques et de hiérarchie top-down.

Bigre. C'est précisément la première des valeurs identifiées comme vertueuses par  les auteurs du Manifeste Agile, pour lesquels la réussite d'un projet de développement logiciel dépend des individus et de leurs interactions plutôt que des procédures et des outils. C'est aussi tout le sens de "Peopleware", livre de 1987 devenu un classique de l'organisation humaine du développement de logiciels, dans lequel on peut lire : “The major problems of our work are not so much technological as sociological in nature.”

Source The Economist http://www.economist.com/business/displayStory.cfm?source=hptextfeature&story_id=11707779