Afin de comprendre toutes les dimensions du mouvement du Software craftsmanship, nous allons nous intéresser à celui qui est au cœur de cette pratique : le craftsman. Quelles sont les qualités attendues d’un tel collaborateur et son impact sur la réalisation du projet ?
Les caractéristiques du craftsman
Dire qu’un craftsman possède d’excellentes compétences techniques semble une évidence. Cependant, aucun développeur, si bon soit-il, n’a la science infuse. Les compétences et les connaissances techniques requises pour développer une application dans de bonnes conditions doivent s’acquérir. Plusieurs facteurs peuvent alors rentrer en jeu.
La passion
La passion du métier est un premier facteur. Un craftsman est curieux, il communique autour de sa passion et apprend auprès des communautés de développeurs. Bien sur, tous les craftsmen ne sont pas nécessairement des blogueurs influents ou des organisateurs d’évènements techniques. En revanche, la plupart d’entre-eux consultent ces blogs et sont présents à ces “TechEvent”.
En quoi la passion est-elle nécessaire, me direz-vous ? Un développeur passionné aura tendance à s’impliquer et s’investir davantage. Ainsi, il souhaitera affiner et optimiser le code qu’il produit. Il suggérera des améliorations dans les méthodes de travail ou proposera des choix techniques plus judicieux que ceux qui étaient initialement prévus.
Cet intérêt pour les technologies pousse donc le craftsman à interagir et échanger avec d’autres développeurs passionnés et à acquérir de nouvelles connaissances au-delà du cadre de son projet actuel. Ce type d’échanges peut aussi avoir lieu au sein d’une même équipe d’un projet et contribue à la faire monter en compétence.
Le pragmatisme et le bon sens
Le pragmatisme est tout aussi important. Sans celui-ci, un développeur passionné peut rapidement se transformer en apprenti sorcier qui introduirait dans son projet des solutions et outils injustifiés. Quelle que soit la technologie, celle-ci implique toujours un coût d’entrée et un coût de sortie. Ainsi, ajouter un framework implique un coût pour son intégration et la formation de l’équipe à son utilisation. En toute circonstance, ces coûts doivent rester justifiés par les besoins du projet et non l’envie d’un développeur un peu trop passionné.
Il doit tempérer son envie de bien faire les choses avec un peu de bon sens sous peine de passer pour un fanatique qui appliquerait des méthodes de travail comme des dogmes. Ce type d’excès peut s’avérer dangereux pour le projet. En effet, appliquer une méthode de façon systématique peut en provoquer le rejet par l’équipe.
De plus, lorsqu’on utilise une solution technique ou une méthode de travail de façon systématique, il peut arriver que l’on perde de vue les raisons qui les justifient ainsi que les bienfaits qu’elles apportent. Par exemple, imposer des séances trop fréquentes de coding-dojo peut s’avérer trop coûteux ou encore, initier le refactoring d’une partie du code legacy d’un projet qui fonctionne et qui n’est pas destinée à évoluer est une erreur. Il ne faut jamais perdre de vue qu’un refactoring est un investissement : on améliore la qualité du code de façon iso-fonctionnelle afin de réduire les coûts d’évolutions et de maintenance de ce code.
L’implication et la place au sein du projet
Un développeur craftsman n’est pas seulement un collaborateur qui maîtrise les aspects techniques d’un projet. Il doit aussi être impliqué dans la conception fonctionnelle. En effet, le choix d’une solution technique doit toujours rester en accord avec le fonctionnel. Pour cela, le développeur ne doit pas se contenter du périmètre sur lequel il travaille actuellement. Il doit aussi avoir une vue d’ensemble du projet afin d’anticiper les difficultés auxquelles seront confrontées ses choix techniques. De plus, une communication régulière avec les représentants fonctionnels du projet (Product Owners) permettra de créer et de maintenir une relation de confiance avec le client. Sans celle-ci, il sera réellement difficile de proposer des tâches purement techniques telles que des refactorings ou le simple maintien des bonnes pratiques privilégiant la qualité au développement de nouvelles fonctionnalités. Le craftsman doit rester intransigeant sur la qualité et savoir dire “non” grâce à une légitimité acquise auprès du chef de projet ou du Product Owner.
Dans un second temps, il doit tout autant maintenir sa légitimité auprès des autres développeurs afin de leur transmettre plus facilement ses compétences. En effet, même si idéalement, tous les membres de l’équipe ont le même niveau de compétences, le craftsman doit rester un acteur de l’homogénéisation et de la montée des compétences. Pour cela, il doit régulièrement s’assurer que les connaissances techniques et fonctionnelles du projet restent bien partagées grâce à des ateliers, des dojos et des séances de pair-programming.
La semaine idéale du craftsman
Maintenant que nous avons décrit l’attitude type d’un craftsman, découvrons ensemble ce à quoi pourrait ressembler la semaine idéale pour ce développeur que nous nommerons ici Bob.
Lundi
En ce début de semaine, Bob participe à l’estimation des tâches de la semaine. Son expertise est mise à contribution pour éclaircir le contexte technique de chacune des tâches et en faciliter l’estimation par son équipe. Il aura au préalable pris connaissance des tâches et réfléchi aux solutions à proposer pour les accomplir afin d’en détailler les points de complexité. Une fois les tâches estimées, il apparaît que l’une d’entre elles nécessite l’intégration d’une bibliothèque dans la structure du projet. Bob se propose de rechercher et tester les différentes bibliothèques envisagées puis d’intégrer la solution retenue.
Mardi
Bob finit d’intégrer la librairie testée la veille et entame la réalisation d’une nouvelle tâche. Pour cette nouvelle mission, il propose à un de ses collègues de travailler avec lui en pair-programming. La fonctionnalité étant clairement définie, Bob propose de la réaliser en Test Driven Development. Ainsi, ils alternent entre l’écriture des tests, l’implémentation de la fonctionnalité et son refactoring. Au cours de cette séance, des échanges de connaissances techniques et fonctionnelles se créent : l’un étant à l’origine de la partie de l’application en cours de modification et l’autre proposant des design patterns ou API inconnues au premier.
Mercredi
Une anomalie a été relevée la veille. Bob décide alors de créer un test unitaire qui échoue pour isoler et reproduire le bug sur son poste de travail. Il constate alors que l’anomalie provient d’un module legacy du projet qui mérite d’être amélioré à cause de son manque de lisibilité et de robustesse. Il contacte le Product Owner du projet et lui propose de planifier au plus vite une tâche de refactoring iso-fonctionnel. En effet, en vue des nouvelles fonctionnalités qui devront être réalisées au cours des semaines suivantes, il met en évidence le gain de temps apporté par cette refonte. Le soir, Bob se rend à un Techevent afin de partager avec d’autres développeurs son expérience et les solutions techniques appliquées par chacun.
Jeudi
La réalisation d’une fonctionnalité complexe, prévue dans les semaines suivantes, nécessite une phase de conception. Bob lance une discussion autour de cette nouvelle fonctionnalité avec les autres développeurs de l’équipe. Inspiré par les retours d’expériences observés lors d’un Techevent et sur différents blogs, Bob propose et détaille deux solutions en plus de celles proposées par l’équipe. Finalement, ils retiendront la plus appropriée.
Afin de faciliter le partage des connaissances, Bob décide d’animer une séance de coding Dojo avec l’accord du chef de projet. Ce Dojo se tiendra durant le reste de la journée, dans le cadre de la réalisation d’une des autres tâches de la semaine.
Vendredi
Au cours du dernier après-midi de la semaine, Bob profite d’une après-midi “quartier libre” au cours de laquelle il peut se consacrer à des tâches techniques telles que l’écriture de tests unitaires manquants, la conduite d’un petit refactoring ou le Proof Of Concept d’une solution technique pour les fonctionnalités à venir du projet.
En conclusion
On pourrait croire que le craftsman est seulement attiré par les solutions techniques. En réalité, c’est un professionnel, pragmatique, qui est avant tout passionné par la solution au sens large. Il connaît très bien les besoins métier. Sa technicité est sa capacité à y répondre au mieux.
Sa qualité d’écoute et son sens du partage de connaissance lui permettent d’agir sur la qualité de travail de toute une équipe pour peu qu’il obtienne la légitimité nécessaire. Si il tient un rôle de leader auprès des autres développeurs, eux aussi passionnés, alors toute son équipe sera susceptible d’intégrer le mouvement craftsmanship.