Blog ENI : Toute la veille numérique !
Dernière chance (fin le 29/02) : -25€ dès 75€ sur les livres en ligne, vidéos... code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

Mise en place du Pantesting

Introduction

Après avoir montré comment le Pantesting est applicable aux aspects majeurs de l’organisation de l’entreprise autour de la solution, ce chapitre présente les éléments nécessaires à sa mise en place.

Démarrer

1. Vision pour le changement

Cette partie est essentielle [Leffingwell 2018] [Kotter 1996]. Voici la raison pour laquelle le changement de culture vers une agilité par le regard du test est indispensable.

Lors des multiples transformations digitales que j’ai pu voir, on peut régulièrement constater que les coachs se concentrent sur les pratiques agiles avec leurs cérémonies et les rôles, en introduisant parfois des ballons, des Lego, des briques Kapla et autres procédés qui permettent, certes, de montrer le déroulé des sessions, mais font passer au second plan les tests, alors même que la « qualité intégrée » est une des quatre valeurs chez SAFe [Leffingwell 2018].

La « 5e valeur de l’agile » rappelée dans la section relative au Software Craftsmanship (voir chapitre Pantesting appliqué à la testabilité technique - Du code propre avec le Software Craftsmanship) vient rappeler la nécessité de ne pas dissocier la qualité de l’agilité avec la formule

« Do the right things and do the things right »

Ce qui peut se traduire par « Faire les bonnes choses et faire les choses bien » :

  • Faire de bonnes choses : ce que propose l’agilité via la priorisation par la valeur ajoutée,

  • Faire les choses bien : ce que propose le Software Craftsmanship.

Mieux vaut tard que jamais, mais l’idée est évidemment d’intégrer au plus tôt la qualité dans la culture agile, quel que soit le niveau d’adoption de l’agilité par votre entreprise. 

En effet, les promesses de l’agilité sans une solution opérationnelle (principe #7 de l’agilité) pour le client peuvent se résumer à des post-it sur un mur.

2. Roadmap

Pour sa mise en place, SAFe propose une roadmap en dix étapes qui démarre par une situation de bascule. Ce point de départ mène à une série de formations avant d’identifier les flux de valeurs pour définir le premier train et le lancer [Leffingwell 2018].

Pour amener cette situation de bascule, on peut s’inspirer de l’intention du Software Craftsmanship et de la réelle application...

Maintenir et améliorer

Lorsque les premières équipes ont commencé à adopter les réflexes d’une X-Team, voici les différents axes qu’elles vont devoir adopter pour améliorer la qualité et l’agilité à l’échelle.

1. Diversifier les écocycles et les prioriser

Les différents chapitres précédents font apparaître l’extraordinaire pluralité et diversité des écocycles, tant sur leur taille que sur leur aspect et leurs impacts.

Ici, le manager peut identifier dans un Backlog d’améliorations environnementales (pour SAFe, ce sont des Enablers) les différents écocycles déterminés par ses pratiques de sessions Gemba, qui lui fournissent des éclairages en provenance des équipes. Ensuite, il peut s’aider des parties prenantes pour faire une estimation WSJF, comme pour SAFe, mais adaptée aux écocycles :

  • V = Impact sur valeur business qualifiée en termes de mise à disposition ou d’absence 

  • D = impact du délai de mise en place

  • R = risque ou opportunité pour le métier

  • C = coût de réalisation du changement - ce coût est évidemment plus élevé lorsque l’écocycle à perturber est de grande taille

images/06-IMG-05.png

Chacun des paramètres du WSJF est alors évalué par les parties prenantes à l’aide d’un simple jeu de cartes "Poker Planning". Le score le plus élevé donne une priorité.

Gouvernance des besoins

Dans la mesure où l’équipe se trouve être à la croisée des chemins entre :

- les besoins du métier (ajout de fonctionnalités),

- la dette technique (ex. le réusinage du code),

- l’amélioration du Pantesting (ex. doubles boucles d’apprentissage),

- la testabilité, le test en continu et les besoins techniques (ex. besoins d’infrastructure et chaîne de releasing),

seul le PO est à même de décider du retour sur investissement entre ces différents domaines. C’est pourquoi il est crucial de faire monter en compétence ce rôle sur ces aspects afin de ne pas voir une solution boiteuse devenir de plus en plus bancale.

2. Ajouter...