Les experts des méthodes Agiles partageront leur vision de l'agilité et répondront à vos questions durant tout le mois d'octobre et dans toute la France.
On lit souvent qu'XP et Scrum s'entendent comme larrons en foire parce qu'ils sont complémentaires, l'un comblant les lacunes de l'autre, et vice versa. L'expérience que j'ai de ces deux méthodologies et l'intérêt que je leur accorde me font dire que l'idée est consensuelle mais inexacte.
Scrum ♥ XP
Nouvelle matérialisation du consensus, le questionnaire sur les méthodes agiles en France publié par le Scrum User Group français fait apparaître la dichotomie habituelle. Scrum rassemblerait les techniques de gestion de projet (réunion d'itération, réunion brève quotidienne, etc.) et XP les techniques d'ingénierie logicielle (tests unitaires, intégration continue, etc.). L'alliance Scrum-XP serait alors la synergie idéale.
XP seul
La réalité est qu'XP possède ses propres pratiques de gestion de projet et n'a donc pas besoin de Scrum pour couvrir l'aspect management des développements. Les itérations courtes, les réunions de planification d'itération, la présence quasi permanente du client, le partage des connaissances entre membres de l'équipe sont autant de pratiques XP qui ne sont pas de l'ordre des pratiques d'ingénierie. Pour être clair :
Scrum seul
Réciproquement, il existe quantité de contextes dans lesquels Scrum n'a pas besoin de compléments XP. Scrum seul excelle dans des projets ou XP est hors sujet car fortement lié à des langages de programmation orientés objets et fortement typés.
Par exemple les tests unitaires chers à XP sont inapplicables en environnement RAD, quand le code est auto-validé au moment même où l'utilisateur (le développeur ?) finit son glisser-déplacer d'un champ de la base de donnée sur un formulaire en construction. Dans ce cas Scrum, lui, reste pertinent, comme plus généralement dans les projets dominés par l'emploi d'outils de génération de code.
Autre exemple, le refactoring intensif est une des pratiques clés d'XP. A chaque changement du code, qu'il soit évolutif ou correctif, le refactoring améliore l'architecture, facilite la maintenabilité du code et fondamentalement le maintient dans un état qui autorise les futures modifications ("embrace changes"). Or le refactoring (petits ou gros remaniements du code) devient délicat et dangereux quand les outils de refactoring automatique (e.g. extract method) ne peuvent plus épauler le développeur. Or les langages dynamiques, JavaScript en tête (et SmallTalk inclus), mettent les bâtons dans les roues à ces outils car certaines ambiguités de syntaxe ne peuvent être résolues qu'au runtime. Dans ce cas encore XP perd de son charme, pas Scrum.
Scrum plus libre qu'XP
En somme XP a une forte adhérence aux environnements de développement devenus standards que sont Java, C# et dans une moindre mesure car un peu plus résistant au refactoring, C++. Dans des contextes dominés par ces langages, faire de l'agile sans adopter les pratiques d'ingénierie d'XP, c'est se priver de ce qui maintient le code évolutif et léger, c'est un peu vouloir construire un building en mode agile…
En revanche dans d'autres contextes, non seulement Scrum se suffit à lui même, mais XP est out. C'est le cas des projets sur lequel le code n'est pas un élément central du système à construire, par exemple lorsque les outils sont graphiques, lorsque le code est généré ou lorsqu'il s'agit de paramétrer un progiciel (SAP, Reporting, CMS, etc.). Ou encore quand le projet comporte un degré d'innovation tel qu'il n'existe pas encore de bonnes pratiques reconnues, mais ça je l'ai déjà dit.
[Si vous atterrisez ici en cherchant le questionnaire d'auto-évaluation il est ici]
Le Scrum User Group français vient de mettre en ligne une grande enquête sur l'adoption des pratiques agiles en France. Les résultats ne peuvent être qu'intéressants, je vous invite à la remplir, ça prend moins de 5mn.
N'hésitez pas à mettre "Denis Dollfus" dans la zone "Parrain", ça peut me faire gagner une WII !
Remplir l'enquête sur les méthodes agiles.
Même si la vision d'XP qui transparaît dans la dernière question n'est pas des plus pertinente... mais c'est un autre sujet.
XP Day, c'est la conférence agile sur les méthodes agiles.
Ca se passe à Paris, et contrairement à ce que laisse entendre le nom de l'évènement, d'abord c'est sur deux jours, les 25 et 26 mai, et ensuite ça ne concerne pas qu'XP mais Scrum, Lean ou autres approches agiles du développement de logiciels.
Le programme est disponible sur le site xpday.fr, au passage on y notera le grand nombre (et la qualité) des sponsors.
Je suis aussi intrigué par des présentations qui sortent de l'ordinaire, tout particulièrement "le développement hédoniste", avec Michel Onfray en référence : l'agilité, à l'inverse des méthodes classiques, encouragerait à éviter le travail désagréable. Je le comprends comme ça : on évite la correction de bugs grâce aux tests unitaires, on évite les tâches répétitives grâce à l'automatisation et au code DRY, on collectione les retours gratifiants grâce aux livraisons fréquentes et finalement, grâce aux interactions constantes avec le client et le reste de l'équipe, on évite le travail de pure exécution qui consiste à suivre un plan défini à l'avance.
Moi ça me va, mais d'autres ne préfèrent-ils pas suivre un plan sans se poser trop de questions stressantes (c'est plan-plan) ?
Quelqu'un aurait-il à partager des comparaisons de turn-over entre équipe classique et équipe agile ?
Il existe toute sorte de logos pour mettre en avant toute sorte de certifications, voici maintenant, sous l'impulsion (et le coup de crayon) d'Emmanuel Chenu, de quoi identifier d'emblée les développeurs qui pratiquent ou qui on pratiqué l'eXtreme Programming :
Je l'adopte !
Après quelques années de développement dans des contextes très différents dont quatre en mode agile, j'apprécie l'apport de l'Agilité, de Scrum et d'XP. Petit point de vue sur l'Agilité via Scrum.
Scrum va beaucoup plus loin que la déclaration d'intention Agile parce qu'il complète les voeux qui la composent par des moyens pratiques. Il donne corps aux valeurs Agiles, au premier rang desquelles figurent les individus et leurs interactions. Il aide à mettre en place des techniques de gestion de projets, canalise l'ingéniosité des membres de l'équipe, leur réactivité face à des nouveaux outils, leur créativité, leur facultés d'écoute et de communication, leur capacité à identifier une mauvaise direction technique ou fonctionnelle et à faire demi-tour.
Du coup Scrum excelle dans des projets où les qualités des individus sont essentielles, là où l'astuce est plus utile que la force, là où la valeur produite n'est pas proportionnelle à l'effort. Ces projets sont plus proches de la recherche que de l'industrie, du bureau d'étude que de l'usine. Ils sont souvent caractérisés par des risques assez élevés sur l'identification des besoins ou sur les technologies mises en œuvre.
En un mot, le cœur de métier de Scrum c'est l'innovation. Scrum est à son aise et se suffit à lui-même quand tout est nouveau, depuis les services rendus par le futur système jusqu'aux technologies à mettre en œuvre, parce que dans ce cas le software est essentiellement du Peopleware, livre devenu un classique dont je vous recommande la lecture.
Dans "Les sept pratiques des gens super efficaces", Stephen Covey relate une petite histoire dans laquelle un bucheron s'épuise depuis 5 heures à scier un arbre avec un scie mal affutée. Quand on lui fait remarquer qu'il irait certainement plus vite et serait moins fatigué s'il prenait le temps d'affûter sa scie, il répond "je n'ai pas le temps d'affûter ma scie, je suis trop occupé à m'en servir".
Transposé au développement, ça donne quoi ?
Vous en voyez d'autres ?
Cela dit, et c'est important, pour être juste avec le bûcheron comme avec les développeurs, il faut nuancer. Le gars a bien raison de ne pas affûter sa scie s'il n'en a plus que pour 3 minutes. Il l'affutera une autre fois.
De la même façon, il y a des cas ou les pratiques d'ingénierie à la XP sont inutiles voire n'ont pas de sens, j'y reviendrai un de ces quatre matins.
Pour être complet : je n'ai pas lu ce livre, je ne vous garantis donc pas qu'il vous aidera à réussir dans votre vie professionnelle, ni à être heureux dans votre vie personnelle, encore moins à gagner sur les deux tableaux. Mais ce type de bouquin contient souvent des conseils de bon sens qui justifient au moins une lecture critique à défaut de parvenir à les appliquer plus d'une semaine d'affilé.
Source : inpiré d'un article de Chad Myers "Speed Up Project Delivery with Repeatability".
PS : j'ai cherché sans succès un dicton/proverbe/citation équivalent en français. Vous en connaissez un ?
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 :
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.
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, ..." :
Les commentaires récents