L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

L'un des thèmes de l'Agile Tour Toulouse de cette année 2013 est le métier du développement logiciel et son évolution. Faisant partie des relecteurs amenés à jouer au "perfection game" sur les propositions soumises, j'en suis arrivé à me demander "Quels ingrédients pour que les sessions portant sur ce thème soient réussies ?"

Ma crainte, c'est que les sessions abordent des des sujets trop conventionnels ou trop consensuels. Des sujets sur les sempiternelles pratiques agiles (TDD, intégration continue...) ont leur place dans la conférence mais plutôt dans le thème dédié aux débutants ( "c'est décidé je commence demain"). Pour parler du métier du développement logiciel, il faut aller plus loin.

A cet instant, la seule grille de lecture qui m'apparait comme pertinente, c'est ce que j'appellerai "le jeu des No". Ce jeu consiste tout simplement à nommer un concept ou une pratique qui pourrait sembler être une bonne idée dans le développement logiciel agile et à le faire précéder par "No" car, à y regarder de plus près, ce n'est peut être pas une si bonne idée que ça.

Essayons avec quelques exemples :

• NoFramework - Qu'il s'appelle Rails, Play!, Grails ou je ne sais quoi d'autre, le framework est devenu une sorte d'élément incontournable dans le développement logiciel actuel parce qu'il permet de démarrer très vite. Mais permet-il d'aller très loin ? Au bout d'un certain temps ne devient-il pas un boulet que l'on traine, une contrainte qui dicte les choix techniques dont on aimerait se passer ?
  
  
• NoSprints - J'aurais pu aussi dire NoIterations mais cela impliquerait la suppression de toute nature itérative dans l'activité de développement, ce qui irait peut être un peu trop loin. En écrivant "no sprint" la cible est plus facile : ce sont les itérations de 2 ou 3 semaines dans Scrum qui sont visées. Et elles le méritent bien. Elles peuvent, dans certains contextes, aider à transiter vers l'agilité mais leur suppression apporte une forme de libération.
  
  
• NoEstimates - La suppression des estimations, c'est la suite logique de la suppression des sprints. Les développeurs sont mauvais pour faire des estimations et ils le seront toujours. A quoi bon continuer ? A travers les estimations, ce que l'on cherche vraiment c'est une certaine forme de prévision du futur. Pour cela, nul besoin d'estimer. La mesure du temps passé à produire de la valeur peut nous en apprendre beaucoup plus.
  
  
• NoTechnicalStory - En parlant de production de valeur, on ne pouvait pas passer à côté de l'arlésienne des "stories techniques", qui est, bien évidemment, un oxymore : une user story, c'est quelque chose que fait l'utilisateur et, par définition, cela n'est pas lié à la technique de développement. Si on se retrouve à vouloir mettre des éléments techniques dans notre backlog, c'est que l'on a loupé quelque chose. Ce n'est pas forcément mauvais car on apprend toujours de ses erreurs mais il ne faut pas que ça devienne une habitude. Ce que l'on veut prioriser dans un backlog, c'est de la valeur produit pas de la technique.
  
  
• NoState - C'est une des grosses tendances du moment. Que l'on parle du retour en force de la programmation fonctionnelle ou du phénomène big data, on parle de la même chose. Le fait de mémoriser un état, qu'il soit dû, localement, au changement de valeur d'une variable ou, à l'autre bout du spectre, aux modifications dans une base de données, pose problème. Deux sortes de problèmes en fait : la gestion des erreurs et l'optimisation via le parallèlisme. Peut-on imaginer une programmation sans états ?
  
  
• NoBranches - Je ne pouvais pas terminer cette petite liste sans citer mon petit favori : les branches dans la gestion du code source. Je le dis (à nouveau) : qui a besoin de plusieurs branches ? Ces branches cassent le flux, nous empêchent de savoir ce qui est fini ou pas, ne nous aident pas à aller vers une meilleure conception, et, par dessus tout, agissent comme un blocage mental qui nous inhibe dans la recherche de meilleures solutions pour gérer la variabilité d'un code source.

Merci Alfred et Pablo pour une discussion lors du dernier Agile France sans laquelle ce billet n'aurait pas vu le jour...