Il y a une semaine c’est tenu le premier “meetup” de la communauté Software Craftsmanship. Et c’était bien.

Définitions

Tout d’abord un petit aperçu de ce qu’est le Craftsmanship au travers de ce qui nous être présenté jeudi soir.

L’agilité permet de faciliter la réussite d’un projet. Cependant, son application depuis ces dix dernières années a pu amener à une forte focalisation sur le processus, négligeant les autres valeurs comme la relation humaine et le logiciel opérationnel. Le Software Craftsmanship part de ce constat afin d’enrichir les principes agiles. Il met l’accent sur les compétences et même l’excellence individuelle afin d’apporter de la valeur au produit à réaliser. On trouve sur Paris beaucoup de communautés centrées soit sur les technologies, (Java, JavaScript, NoSql…) soit sur les processus (French Scrum User Group, conférence Agile France…). La communauté Software Craftsmanship se place dans un espace oublié pour réunir ces deux mondes. C’est une communauté où l’on parlera de technique de développement logiciel comme par exemple de TDD, de conception simple, de binomage… Si cette communauté devait s’attacher à développer un des 4 principes du manifeste agile, ce serait “working software”. Le mouvement aux Etats-Unis a écrit un manifeste software craftsmanship. Celui ci *compléte, explicite et renforce les valeurs *du manifeste agile. Ce qui donne :

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a* community of professionals*

Not only customer collaboration, but also* productive partnerships*

http://manifesto.softwarecraftsmanship.org/

Pour ceux qui n’ont pas suivi, Craftsman se traduit par artisan en français. Ce sujet n’a pas été abordé pendant cette soirée, mais pourra sans doute alimenter quelques discussions lors des soirées à venir.

Déroulé de la soirée

Cyrille Martraire est directeur technique chez Arolla et fondateur de cette communauté. Il nous a expliqué les raisons de son initiative : parmi les communautés naissantes, on distingue les techno centrée (Java,.net, web…) de celles qui seraient plus méthodologiques, autour de l’Agilité, du Lean… Néanmoins, ces deux tendances convergent sur le travailler mieux, autant au niveau technique que organisationnel ainsi que “simplement” se faire PLAISIR au travail. Il présente son initiative comme une troisième possibilité, sans appartenance à une technologie ou à un langage. Parmi les participants (moyenne d’âge autour de la petite trentaine, même si des personnes plus expérimentées étaient présentes), l’écrasante majorité était plus orientée java, même si les langages du web était également représentés. Un .net était également présent. Cyrille a très vite laissé la parole à Sandro Mancuso, fondateur de la communauté Software Craftsmanship de Londres, il y a un an. Celui ci nous a présenté son idée du métier de développeur, comment il évolue au sein des projets, notamment encadré par les méthodes agiles. Il en est venu assez naturellement à aborder la manière d’améliorer le travail personnel par les pratiques du software craftsmanship. La deuxième partie prévoyait intitialement un hands-on en TDD. Elle s’est transformée en papotage autour d’un excellent cocktail.

Ce qu’il m’en reste

Ce que j’ai retenu de cette session autant au travers de l’introduction de Cyrille que du talk de Sandro :

Le développement est un art qui requiert du temps, de l’expérience, de la pratique
Comment garantir à un projet que ce que vous amenez le fait avancer : écrire du code, vérifier que le résultat obtenu est bien celui attendu et vice et versa : c’est normal. Mais si vos tests sont automatisés, reproductibles et que votre code est lisible, maintenable, et compréhensible, ce que vous avez amené aujourd’hui et hier fonctionnera toujours demain, même si vous n’êtes plus là.
Les activités de test et de refactoring ne sont pas des tâches, mais des étapes indispensables, par conséquent votre PO ne peut pas les dé-prioriser.
L’importance de pratiquer : Comme pour conduire une voiture, au début on est paniqué, puis après on arrive à être naturel et à gérer plusieurs choses à la fois. Pour le TDD ou le pair-programming cela change fondamentalement notre manière de faire, de concevoir mais cela permet de reproduire et de s’améliorer régulièrement en partageant, en échangeant, en communiquant plutôt qu’en stagnant tout seul.
Tous les projets sont différents, mais les pratiques pour les faire aboutir ne sont pas si nombreuses, malgré les exigences métier : Sandro a d’ailleurs une fois de plus appuyé sur l’importance des pratiques XP telles que TDD & pair programming. Il a néanmoins nuancé son propos en prenant en compte un contexte organisationnel qui peut parasiter ou freiner l’application des pratiques XP, il se concentre alors sur celles du centre complètement déconnectées du contexte organisationnel qui vient parasiter leur essence.

D’autres remarques qui ne sont pas relatives à l’écriture du code, parce que ce n’est qu’une très petite partie de notre activité :

Être Craftsman c’est avoir une attitude positive : en se lamentant sur l’état du projet, quelle image donne-t-on aux débutants et aux collègues qui y contribue ?
Le Software Craftsmanship n’est pas une église ou une croyance mais la raison qui s’exprime au travers de l’expérience de chacun
Commentaire personnel : comme toute expérience qui s’exprime, tant que l’autre n’a pas fait son apprentissage, cet ensemble de pratique est difficile à accepter et apparaît uniquement comme de l’évangélisation, j’ai vu la lumière, je peux vous montrer le chemin et vous aider à y parvenir.
Sandro nous a bien fait part de son peu de considération pour les certifications. Il espère bien ne jamais voir reprise cette idée pour le Software Craftsmanship.
Travailler sur du code historique (legacy) c’est comme faire un puzzle 5000 pièces : trouver les angles, les bords, isoler des parties cohérentes afin d’y incorporer les bonnes pratiques
Prenez votre carrière en main : parce que comme un dentiste ou un médecin, on ne vous paie pas pour apprendre ou vous remettre à niveau. C’est par contre une activité indispensable : vous devez individuellement maintenir vos connaissances et compétences à un niveau d’employabilité afin de ne pas vous retrouver dans des impasses. Néanmoins, si votre employeur n’est pas capable de vous aider dans cette activité, essayez de faire changer les choses puis, si ça ne fonctionne toujours pas, allez voir ailleurs. Sandro a d’ailleurs fait un délicieux lapsus “Own your company” à la place de “Own your carrier” : pour continuer à évoluer et à vous épanouir vous devriez être votre salarié, posséder votre société …

Comme toutes communautés, elle ne vivra que par l’activité de ses membres.

Être développeur

Cette session m’a également beaucoup fait penser à la session du dernier Paris JUG sur “Être Développeur” : si vous voulez que votre projet réussisse, entourez-vous des bonnes personnes. L’une des autres idées de cette autre soirée était sur la limite d’âge : il n’y en a pas ! Être développeur à 40 ans n’est pas une tare, je dirais même plus que ce sont les bons, très bons qui sont toujours dans cette activité. Il faut néanmoins accepter de faire des missions plus aventureuses… Les Duchess vont d’ailleurs prolonger le débat.

Liens pour aller plus loin

Remerciements:

Crédits Photos: Cyrille
Avec la généreuse participation & gracieuse relecture de Etienne Charignon & Eric Le Merdy