La stratégie Software Craftsmanship / Devops

Les craftsmanLe framing agile amène les équipes à se préoccuper de la qualité des produits ; et cela passe par la mise en place d’une stratégie software craftsmanship et d’une stratégie devops.

Le software craftsmanship

Le craftsmanship est une approche agile très axée sur la qualité technique des réalisations. La démarche fait suite à une longue période où la baisse des coûts et l’accélération des sorties (Time-To-Market) se faisaient au détriment de la qualité.

Ce mouvement craftsmanship est donc né pour remettre la qualité technique au centre des préoccupations des développeurs. D’ailleurs, il va même au delà en faisant référence à la qualité des produits artisanaux .

Un livre « software craftsmanship » est publié en 2001 pour différencier un développeur enfermé dans un monde industriel et un développeur agile. C’est en 2008 qu’on considère que le mouvement se lance vraiment avec la proposition d’une cinquième valeur au manifeste agile par Uncle Bob : « l’artisanat plus que l’exécution ».

Maintenant ce mouvement du craftsmanship se fait de plus en plus connaître ; des coachs craftsman apparaissent dans les grands groupes pour accompagner les équipes techniques à revenir vers des produits bien conçus.

Les 4 valeurs du software craftsmanship

Les craftsmen se voulant de ce mouvement agile ont écris les 4 valeurs du software craftsmanship :

•  1# Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
•  2# Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de valeur.
•  3# Pas seulement les individus et leurs interactions, mais aussi une communauté professionnelle.
•  4# Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.

« C’est-à-dire qu’en recherchant les éléments de gauche, nous avons trouvé que les éléments de droite sont indispensables. »

En effet en lisant ces quelques valeurs du software craftsmanship, nous voyons l’insistance qui est fait sur l’excellence technique ; par exemple avec le terme « des logiciels bien conçus ». En effet durant une dizaine d’année au sein des entreprises, l’excellence technique avait plutôt disparue au profit de l’accélération des mises en production. Aujourd’hui un grand nombre d’entreprises souffrent encore de cette période pas si ancienne.

Le mouvement software craftsmanship rappelle également l’importance de transmettre les connaissances grâce à la mise en place de communautés de pratiques.

L’XP revient avec le software craftsmanship

On peut indirectement revoir dans ce mouvement Software Craftsmanship, un retour de l’Extreme Programming qui se voulait mettre en avant l’excellence technique. Voici d’ailleurs comment le manifeste software craftsmanship est représenté :

• qualité technique : conceptions simples (DDD, OO), le refactoring régulier, tests de non régression (TDD), revue de code
• qualité fonctionnelle : tests de non régressions (BDD, ATDD)
• partage : pair programming
• adaptation : rétrospective/reflection, priorisation revue régulièrement, feedback réguliers
• rapprochement : avec les clients, squad

L’équipe va devoir ensemble définir les éléments qu’elle désire mettre en place pour s’assurer que la qualité technique sera bien pris en compte par l’équipe. Cependant, l’équipe devra savoir trouver le juste milieu entre la qualité nécessaire et la capacité de faire.

Attention cependant, si l’équipe ne maîtrise pas certaines des pratiques ci-dessus mais qu’elle désire expérimenter celles-ci, elle devra prendre en compte un temps nécessaire à l’apprentissage ; elle peut même envisager de se faire coacher par un coach craftsman.

L’équipe technique pourra alors créer un simple tableau pour définir les techniques qu’elle désire mettre en place ou qu’elle désire expérimenter comme ceci :

Le devops

L’histoire du devops commence en 2007. Patrick Debois connu pour être le fondateur de ce mot « devops », était administrateur système en tant que consultant sur un projet de migration de données pour le gouvernement Belge. Il était totalement impacté par le manque de cohérence et de communication entre les développeurs et les administrateurs systèmes.

Quelles seraient les solutions pour résoudre ce problème qui est loin d’être un cas isolé de ce projet ? C’était devenu pour lui un véritable sujet de réflexion sur lequel il voulait trouver des solutions.

En août 2008, il participe à une conférence agile de Toronto où il va découvrir le développeur Andrew Shafer qui voulait présenter un sujet qui l’inspirait : « Agile Infrastructure ». Malheureusement, Andrew Shafer n’avait pas déroulé son sujet car seul Patrick Debois était présent dans la salle.

Cependant, cela leur a permis de discuter ensemble autour de cette problématique qui ronge Patrick Debois depuis quelques temps. Ils vont finir avec cette discussion par créer l’Agile Systems Administration Group.

En juin 2009, Patrick Debois était dans l’incapacité de participer à une conférence qui l’intéressait vraiment : « 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr » de John Allspaw et Paul Hammond au velocity O’Reilly. Le sujet était exactement le type de retour d’expériences qu’il cherchait personnellement.

En exprimant sa frustration sur Twitter de ne pas avoir pu participer à cette conférence, il reçoit un message de Paul Nasrat qui sera le booster de cette histoire : « Why not organize your own Velocity event in Belgium? ».

Et tout va très vite car le 30 octobre 2009, ils réalisent une conférence appelée DevOpsDays qui fait référence à « développeurs » et « operational » (administrateur système). C’est au même moment même que le hashtag #DevOps fait son apparition et qu’il devient rapidement viral.

Devops aujourd’hui

A ce jour, le devops a pour objectif de rassembler les développeurs, les administrateurs systèmes et les métiers. Le mouvement devops a amené indirectement à l’arrivée d’outils permettant d’améliorer considérablement 2 éléments clés du développement logiciel :

• l’intégration continue
• la livraison continue/déploiement continue

L’évolution des outils lié à l’intégration continue ont permis d’améliorer considérablement les capacités de non-régression, d’approcher les métiers au produit livré (avec la BDD par exemple), d’augmenter la qualité des livraisons… Et les équipes n’ont aujourd’hui plus besoin d’équipes spécialisés pour une chaîne d’intégration continue de qualité.

L’évolution des outils de livraisons ont également énormément apportés aux entreprises : rapprochement des différentes expertises, une plus grande autonomie des équipes de réalisation, une capacité de livrer beaucoup plus régulièrement.

L’équipe va remplir le tableau précédent en définissant la stratégie devops que l’équipe désire mettre en place. L’équipe doit cependant s’assurer que les ajouts sont réalisables au sein de la structure. Si ce n’est pas le cas, elle mettra les pratiques dans la colonne “envisager” ; cela dans le but d’aller analyser si cela est possible dans le contexte actuel.