Software Craftsmanship

Rendre agile une équipe qui fait du développement logiciel passe par la mise en place d’un framework agile et d’une acculturation, mais ce n’est pas suffisant. Comme le produit livré est constitué de code, il est important de s’intéresser à l’agilité du code lui-même et aux pratiques qui y mènent.

Notre approche.

Conservez votre code agile grâce à l’excellence technique

  • Vous avez transformé vos processus de travail pour être agile, mais en laissant de côté la transformation agile de votre code. Une partie de votre système d’information est trop legacy et pourtant vous devez le faire évoluer. Notre expertise « Software Craftsmanship » est là pour vous accompagner :
  • EFormation de vos équipes de développement au design logiciel évolutif, au refactoring, aux pratiques de développement qui empêchent de produire du nouveau code legacy (TDD) et être aligné avec les besoins métier (BDD, DDD)
  • ESensibilisation de vos managers à l’importance de l’excellence technique et à ses impacts
  • EParticipation active à vos chantiers de développement en y apportant des pratiques issues d’eXtreme Programming et du Software Craftsmanship pour toujours plus de qualité et d’agilité dans le code de vos applications
Christophe Godard

Christophe Godard

Manager de l'expertise

Tu es passionné ?
Nous aussi !

Alors rejoins-nous.

Nos autres expertises Be & Do Agile !

Pourquoi passer par un cabinet de conseil en Software Craftsmanship?

Qu'est-ce que le Software Craftsmanship ?

Qu’est que le Software Craftsmanship ?

Le Software Craftsmanship est un mouvement visant à positionner le travail de développeur comme un métier d’artisanat, en mettant en avant une culture de l’excellence technique, la qualité du code, le partage de connaissances au sein de communautés de professionnels pour s’améliorer en continu ainsi que la collaboration productive avec les utilisateurs des solutions logicielles.

Même s’il tire ses origines d’écrits et d’expérimentations qui datent de bien avant, ce mouvement est réellement né en 2008 lorsque Robert C. MARTIN (plus connu sous le nom d’Uncle Bob) a proposé d’ajouter une cinquième valeur au manifeste agile : « Crafstmanship over execution ». Cette cinquième valeur n’ayant pas été ajoutée au manifeste agile, des défenseurs de cette vision ont écrit le manifeste pour l’artisanat logicielle en 2009. Il complète le manifeste agile et décrit les 4 valeurs piliers du mouvement du Software Craftsmanship :

  • « Pas seulement un logiciel opérationnel, mais aussi un logiciel bien conçu »
  • « Pas seulement de l’adaptation au changement, mais aussi l’ajout en continu de valeur pour l’utilisateur, mais aussi pour le développeur »
  • « Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels »
  • « Pas seulement une collaboration avec le client, mais aussi un partenariat productif »

Partant de ce manifeste, le Software Craftsmanship est donc avant tout un état d’esprit et une façon de travailler. Afin d’assurer la qualité dans le code, un certain nombre de pratiques de développement ont émergées et sont fortement portées et diffusées par les communautés de Software Crafsmanship. Il est possible d’appliquer les principes du Software Craftsmanship sans faire de l’agilité. Toutefois, ils sont souvent appliqués ensemble car complémentaires.

Quel est le lien entre le Software Craftsmanship et l'agilité ?

Tous les développeurs ne se retrouvent pas dans la mouvance agile souvent du fait que ce mouvement ne met pas suffisamment le focus sur l’excellence technique et les pratiques d’ingénierie y amenant. Certains professionnels de l’agilité ne portent pas suffisamment d’importance à ces pratiques d’ingénierie.

Chez Invivoo, nous avons l’intime conviction qu’il ne peut pas y avoir d’agilité dans une organisation IT sans adopter les pratiques et les valeurs promues par le Software Crafsmanship. En effet, l’objectif de ces organisations est de construire des logiciels apportant de la valeur à ses clients au bon moment et pouvant s’adapter facilement aux changements. Dans cette industrie, la majeure partie des produits est constituée de code. Si l’on veut que ces produits logiciels s’adaptent facilement, il est nécessaire de s’armer avec des pratiques et des techniques qui permettent de garantir la flexibilité du code en permanence tout en ne dégradant pas la qualité de ce dernier.

De la même façon, ne s’intéresser qu’aux aspects techniques pour rendre une organisation IT agile n’est pas suffisant. Il est aussi nécessaire d’apporter des cadres méthodologiques, une nouvelle culture plus orientée produit avec toutes les pratiques et outils qui permettent l’application de cette culture au quotidien.

Pour toutes ces raisons, dans l’industrie logicielle, l’agilité et le Software Craftsmanship sont pour nous indissociables et autant utiles l’un comme l’autre pour rendre une organisation plus d’agile dans sa globalité.

Quelles sont les principales pratiques d'ingénierie logicielle pour rendre le code agile ?

Un produit logiciel peut être facilement adaptable dans le temps si le code sous-jacent a une architecture évolutive, s’il est testable et testé pour garantir sa qualité au cours du temps et si son « ownership » est partagé par l’ensemble de l’équipe de développement. Ces caractéristiques permettent d’arriver à un code que l’on peut qualifier d’agile.

Le Software Craftsmanship prône l’utilisation d’un certain nombre de pratiques agnostiques à tout langage ou écosystème et qui amène à avoir un code agile. Parmi ces pratiques, on peut trouver les suivantes :

 

  • Le Pair Programming et le Mob Programming (plus récemment appelé « Ensemble Programming ») qui consistent respectivement à travailler en permanence en binôme ou en équipe entière. Ces approches ont la vertu de développer le partage de l’ownership du code au sein de l’équipe. Ainsi, telle partie du code n’est pas la propriété d’un membre de l’équipe, mais de l’ensemble de l’équipe. La maîtrise de l’ensemble du code est bien plus partagée. De plus, cela permet un regard plus critique sur le code produit, un partage des bonnes pratiques, et ainsi une culture de l’excellence technique plus présente
  • La revue de code qui, au même titre que le Pair Programming, mais dans une moindre mesure, permet d’améliorer l’ownership du code par l’ensemble de l’équipe
  • La bonne connaissance et la veille permanente de l’équipe sur les bons principes de design et d’architecture du code amenant à ce que l’on appelle le clean code. Parmi ces derniers, on peut citer les principes SOLID dans le cadre d’un développement orienté objet ou l’architecture hexagonale garantissant une bonne isolation entre le code métier et le code technique, et ainsi une meilleure évolutivité du code
  • La pratique du TDD (Test Driven Development) consistant à construire le code de notre produit logiciel à partir des tests en respectant le cycle suivant : Développement d’un test échouant / Développement du code minimum pour faire passer le test / Refactoring de l’ensemble du code produit. Le TDD a une double vertu : faire émerger un design de code simple, évolutif et testable (à condition de maîtriser les principes de design de code) et prévenir toute régression le plus tôt possible
  • La pratique du BDD (Behavior Driven Development) consistant à spécifier un besoin métier sous la forme d’exemples écrits en langage naturel et compréhensible par tous les intervenants d’un projet : de l’expert métier au développeur, ces exemples servant aussi au développement des tests d’acceptance. Le développement du produit logiciel est ainsi guidé par les comportements métiers attendus de celui-ci. La pratique du BDD est souvent liée à celle du TDD avec ce que l’on appelle le double loop TDD où la boucle de réalisation d’un test d’acceptance inclut plusieurs boucles de TDD
  • La pratique du refactoring en continu qui consiste à remanier très régulièrement la structure interne du code pour le rendre plus simple, maintenable et évolutif sans détériorer la fonctionnalité qu’il est sensé assuré. Cette pratique permet de limiter la production de code legacy. Elle nécessite une bonne connaissance et un apprentissage de l’équipe des techniques de refactoring et des code smells (c’est-à-dire les mauvaises pratiques de code)
  • Le DDD (Domain Driven Design) qui rassemble des patterns stratégiques et tactiques pour mieux appréhender le domaine métier sous-jacent à un produit logiciel et remettre ce métier au cœur de la conception et du développement