Accueil > Divers, Forums et Salons, Java EE, Méthodes Agiles > Quand Agile rencontre Craftsmanship

Quand Agile rencontre Craftsmanship

Faisant suite à un premier article sur le lieu, l’ambiance de la conférence, puis un second sur une approche psychologique de l’Agile, le clap de fin de la série de retours de l’Agile Tour Paris 2014 se fera autour de l’artisanat logiciel.

logo

 

L’artisanat logiciel, aussi connu sous le nom du Craftsmanship

Il est temps d’aborder le second grand axe qui a retenu mon attention lors de cet Agile Tour Paris, une conférence dont le sujet est le « beau code » : Travailler avec l’existant ou comment s’en débarrasser, présentée par un développeur quelque peu expérimenté (15 ans !), Sam Cranford.

Pour débuter, on pourrait se demander ce qui se cache derrière ce nom barbare, le Craftsmanship ? Je vous le donne en mille : le sauveur des temps modernes, le justicier des plateaux de dev, qui combat les méchants avant qu’ils n’atteignent leur apogée : le terrible Blue Screen Of Death ! Rien que ça !

Blue Screen Of Death

Blue Screen Of Death

 

Plus sérieusement, c’est un développeur (leader technique, architecte, ces noms fonctionnent aussi) qui possède l’amour du travail bien fait. Tel l’artisan façonnant son œuvre à la main, il prendra du recul face au plat de spaghettis, nommé le « code existant » comme le dirait si bien Sam Cranford.

Sam Cranford -  Travailler avec l’existant ou comment s’en débarrasserEt, plutôt que de le laisser à la merci des bugs et autres « features », il va le retravailler pour le rendre beau. A quoi ça sert ? C’est ce que nous allons découvrir tout au long de cette conférence.

Sam rentre en scène. Avec son t-shirt arborant une célèbre distribution Linux, son accent fortement américanisé et ses slides teintés d’humour, on se sent rapidement à l’aise. L’amphithéâtre au complet deviendra très attentif pendant toute la prochaine heure. Son discours s’articulera autour d’un fil rouge qui pourrait se résumer par l’arrivée d’un développeur expérimenté, typé artisan du code, au cœur d’un nouveau projet.

 

Etape 1 : le constat

Dans un premier temps, ce développeur arrive et, avec une certaine consternation, découvre :

  • Un code existant, avec une histoire riche de bonnes intentions, mais dont l’état actuel est proche de l’usine à gaz
  • Une équipe existante fermée au changement et composée de Bioman© et de « Bozo Bit »
  • Un client qui a plus de bras que la déesse Shiva elle-même pour distribuer les évolutions
  • Un produit dont les principales discussions tournent autour d’une stabilité aléatoire et de ces fonctionnalités manquantes, dont les temps de développement s’allongent toujours plus

 

Rule Bolberg

Rule Bolberg

 

Etape 2 : la compréhension

Ce développeur pose alors la question : « Mais comment en êtes-vous arrivés là ? »

Le projet est victime du cercle vicieux des manques : de temps, de connaissances, d’organisation, d’évolution, de tests, de passion.

Résultat : l’équipe travaille « à l’arrache » pour rattraper le retard. Plus aucun membre n’a alors le temps de faire de la veille technologique. On ne parle même plus de réaliser des tests. Elle perd toute sa motivation. Le tout pendant que les demandes s’accumulent et que le stress augmente.

 

Etape 3 : la solution. Enfin le début plutôt.

Cette constatation faite, le développeur retrousse ses manches, prend son courage à deux mains et annonce fièrement « Il faut que ça change ! ». Sam (le conférencier et non le développeur !) nous expliquera maintenant les étapes qu’il est nécessaire d’évaluer pour y arriver.

On ne peut pas changer d’équipe : c’est un fait. Ce n’est pas du ressort du développeur. Il faut donc trouver les moyens d’injecter les bonnes pratiques, mais sans trop déranger.

On commence par la technique. Les équipes sont composées d’ingénieurs, il faut en exiger du professionnalisme. Appliquer les concepts simples « la duplication c’est mal » ou les principes SOLID. Pour être dans un environnement propice à ces bonnes pratiques, il est conseillé de suivre le « Test de Joël » dont voici quelques exemples sur les 12 questions qui le constituent :

  • Utilisez-vous un système de gestion de version ?
  • Une application pour le suivi d’anomalies est-elle mise en place ?
  • Le code commun est-il soumis à une compilation quotidienne ?

La technique seule ne suffit pas, il faut également accompagner humainement son équipe pour lui donner envie de changer. Il est nécessaire de travailler avec la Direction pour que les développeurs se sentent respectés et écoutés. Il faut apprendre aux membres de son équipe à favoriser l’honnêteté dans les interactions plutôt que cultiver les promesses non tenables. Il ne faut jamais accepter les échéances irréalisables de manière à entretenir un rythme soutenable, tel le marathonien face à la longue épreuve qui l’attend. L’ambiance est également un facteur de motivation très importante, il faut bannir les remontrances personnelles afin de favoriser les réactions d’équipe, l’unicité de celle-ci.

 

Etape 4 : la consolidation

Maintenant que les outils sont mis en place et que l’équipe retrouve un peu de souffle et d’envie, comment s’en sort-on ?

Les tests, voici le nerf de la guerre. Ce sont eux qui vont permettre le succès des développements réalisés. Leur automatisation sera la clé de la maintenance dans le temps, luttant activement contre les régressions et prônant en permanence un logiciel stable et utilisable.

L’équipe étant maintenant à l’écoute des bonnes pratiques, on peut passer aux choses sérieuses et favoriser le refactoring du code : réorganiser le projet pour qu’il soit compréhensible de tous et cohérent. Supprimer le code mort, simplifier les fonctionnalités en les découpant atomiquement.

Tout cela porte un nom, c’est la dette technique. Il ne faut pas la cacher mais au contraire la partager pour mieux l’isoler et la réduire. Pour se faire, la mise en place de revues de code contribuent à :

  • contenir cette dette technique dans le temps
  • partager les bonnes pratiques entre développeurs de tout niveau
  • former l’équipe efficacement et de façon collaborative

LaHierarchieParfaiteLa hiérarchie étant également de la partie dans cette évolution, il faut tenter de se rapprocher de l’idéal : une hierarchie « flat » où tout le monde est sur un pied d’égalité pour favoriser le travail d’équipe et l’implication de chacun.

Enfin, à l’heure actuelle, il ne faut plus lésiner sur le matériel. Investir dans des machines performantes se montrera un retour sur investissement des plus appréciables (combien vaut une journée d’un développeur expérimenté par rapport au coût seul de sa machine ?).

Et surtout, se focaliser sur l’important : un logiciel stable et maintenable, des clients contents, un quotidien épanouissant et de l’excellence technique. C’est à ça que l’on peut prétendre quand les valeurs de l’agile rencontrent les craftsmenship.

Conclusion

La conférence touche à sa fin. Difficile de contredire Sam face à l’ensemble de ces conseils tous plus bons les uns que les autres. Néanmoins, en seulement 1h de temps, le flot d’informations est énorme et difficile à appréhender.  J’étais parti pour développer dans cet article chacune de ses parties, mais celui-ci serait devenu aussi important qu’illisible : trop d’infos tue l’info. Je ne m’en tiendrai donc qu’à ce seul retour d’informations en espérant que cela attisera votre curiosité. Les points de passage du GPS sont rentrés, à vous de réaliser votre propre parcours pour les atteindre, Google est votre ami 😉

Pour clôturer cette série d’articles dont le contenu ne représente qu’une infime partie de la richesse d’une telle journée, je ne pourrais que vous conseiller de participer à un évènement agile. On en ressort la tête pleine de nouvelles idées, avec un regard nouveau sur ses tâches quotidiennes. Un second enseignement que j’en tirerais serait de se diriger vers la découverte de l’inconnu, voir du méconnu, c’est, je trouve, le moteur le plus enthousiasmant de ces conférences. Rien de tel pour entretenir la passion et continuer d’aller au boulot avec envie non ? 😉 Alors… bonnes conf’ !

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


7 + six =