Conduite de tests agiles pour SAFe et LeSS

45 €

isbn

: 978

-2-4

09-0

2727

-7

Conduite de tests agiles pour SAFe et LeSS Préface de trois grands experts du domaine du testCe livre pose la question du test lorsqu’une entreprise tente de se mettre à l’échelle avec une organisation agile en utilisant des fra-meworks existants tels que SAFe, LeSS ou encore Spotify. L’auteur y donne les connaissances fondamentales agrémentées de nombreux exemples, anecdotes, références bibliographiques et illustrations, pour appréhender le test agile à grande échelle, avec les pratiques du test qui en découlent, selon un modèle pensé par l’auteur lui-même.

Chaque chapitre, même le plus technique, intéressera autant le DSI, le manager, le Scrum Master et le Product Owner dans leur virage vers l’Agilité ainsi que le testeur qui ressent le besoin de s’adapter à ce nou-veau mode de développement pour fournir un logiciel de qualité.

Après un survol du modèle, l’auteur en présente les multiples facettes et ses applications dans les différents contextes du métier tels que la technique, les cycles de développements et les moyens de l’entre-prise tels que les rôles dans l’organisation, le budget, les outils, le système qualité, la gestion de la connaissance et la culture d’entreprise. Le dernier chapitre est consacré à la mise en œuvre concrète du modèle.

Christophe MOUSTIER débute son voyage dans le monde du déve-loppement logiciel dans les années 1980 et transforme ensuite sa passion en une profession, d’abord comme développeur certifié Java puis comme chef de projet. Il commence à tra-vailler avec les méthodes agiles dans une startup dès 2001 avec l’Extreme Programming et, depuis 2006, il s’intéresse plus particulièrement à la problématique du test et l’insertion de bonnes pratiques à l’échelle de l’entreprise. Aujourd’hui expert dans le domaine du test logiciel, il intervient dans de nombreuses entreprises pour les aider à changer leur vision du test et du rôle de chacun dans cette acti-vité du développement logiciel.

Pour plus d’informations :

Téléchargementwww.editions-eni.fr.fr

sur www.editions-eni.fr :

b Jeu de cartes « Pipeline cards »

b Challenge « 30 jours sur le Lean »

b Challenge « 30 jours sur le Software Craftsmanship »

Christophe MOUSTIER

Conduite de tests agiles pour SAFe et LeSS

Con

duite

de

test

s agi

les p

our S

AFe

et L

eSS

En téléchargement

Jeu et challenges

Préface de trois grands experts du domaine du test

+ QUIZ

1Table des matières

Préface

Avant-propos1. Pourquoi ce livre ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. À propos du titre de ce livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Pour qui est ce livre ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. Qui suis-je ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5. Comment lire ce livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.1 La revue Jackie Brown du test agile à l'échelle . . . . . . . . . . . . . . . . . . . 185.2 Modes de lecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3 Avertissement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapitre 1Pantesting

1. Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2. Testabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3. Panarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1 Le concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Panarchie et panarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Panarchie et résilience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4. Théorie des contraintes - TdC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5. Double boucle d'apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Les exemples à télécharger sont disponibles à l'adresse suivante :http://www.editions-eni.fr

Saisissez la référence ENI de l'ouvrage DPTESSAF dans la zone de rechercheet validez. Cliquez sur le titre du livre puis sur le bouton de téléchargement.

lcroise

Tampon

2pour SAFe et LeSS

Conduite de tests agiles

6. Pantesting en entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.1 Atelier « Panarchy » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2 Panarchie et tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Chapitre 2Pantesting appliqué au métier

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2. Testabilité des fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.1 Capture du besoin et génération des idées . . . . . . . . . . . . . . . . . . . . . . 47

2.1.1 Lean Canvas et compagnie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.1.2 25/10 Crowdsourcing pour dégager des idées d'un groupe . . . . 532.1.3 1-2-4-Tous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.1.4 EventStorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.1.5 User Story Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.1.6 Autres moyens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.2 Affinage des PBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572.3 User Stories - US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.3.1 Rédaction des US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.3.2 Vision de SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.3.3 Vision de LeSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.3.4 US et spécifications exécutables . . . . . . . . . . . . . . . . . . . . . . . . . 652.3.5 Estimation des US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.4 Macro-US. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722.4.1 Préparation des macro-US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722.4.2 Estimation des macros US. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

2.5 Enablers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3. Testabilité des exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . 78

4. Documentation liée à la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.1 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.1.1 Solution Intent de SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.1.2 CMDB d'ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.1.3 Living documentation - la documentation c'est le code . . . . . . 88

4.2 Pantesting lié à la documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5. DoD à l'échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92


6. DoR à l'échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7. Résumé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Chapitre 3Pantesting appliqué à la testabilité technique

1. Architecture agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991.1 Principes d'architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021.2 Autres visions sur les principes d'architecture agiles . . . . . . . . . . . . . 1091.3 Adaptation TOGAF à SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.4 Vision architecturale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121.5 Conception et partage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

2. Domain-Driven Design - DDD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212.1 Techniques de compréhension et de communication du domaine . . 1242.2 Techniques de préservation de l’intégrité du modèle . . . . . . . . . . . . . 1262.3 Conception dirigée par le modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1332.4 Processus de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1432.5 Exemple de combinaison SAFe-TOGAF-DDD . . . . . . . . . . . . . . . . . . 145

3. Model-Based System Engineering - MBSE. . . . . . . . . . . . . . . . . . . . . . . . . . 1473.1 Présentation du MBSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473.2 MBSE et cycle de vie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503.3 Du MBSE vers le PBSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533.4 MBSE et les tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

3.4.1 Model-Based Testing - MBT . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543.4.2 MBSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593.4.3 Pantesting et MBSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

4. DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644.1 Visions sur DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

4.1.1 Vision de Kim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644.1.2 Vision de SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654.1.3 Vision de Spotify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664.1.4 Vision de Barclays Bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664.1.5 Vision de Google - SRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

4.2 Le pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

4pour SAFe et LeSS


4.3 Continuous Testing - tester continuellement. . . . . . . . . . . . . . . . . . . 1894.3.1 État d'esprit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1934.3.2 Le CT c'est où on peut, dès qu'on peut ! . . . . . . . . . . . . . . . . . 1944.3.3 Le CT, ce n'est pas que l'automatisation . . . . . . . . . . . . . . . . . 1964.3.4 Automatiser en continu c'est apprendre en continu . . . . . . . . 1974.3.5 Automatisation et Craftsmanship dans l'équipe . . . . . . . . . . . 1984.3.6 Automatisation et autonomie. . . . . . . . . . . . . . . . . . . . . . . . . . 1994.3.7 Le temps d'exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2024.3.8 L'environnement d'exécution . . . . . . . . . . . . . . . . . . . . . . . . . . 2054.3.9 La portée du CT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2094.3.10 Un banc de test idéal (ou presque) . . . . . . . . . . . . . . . . . . . . . . 2114.3.11 Module de planification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2124.3.12 Manager de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2144.3.13 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2154.3.14 Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2164.3.15 Interface de pilotage logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . 2184.3.16 Interface de pilotage matérielle . . . . . . . . . . . . . . . . . . . . . . . . . 2184.3.17 Interface de pilotage d'outils externes . . . . . . . . . . . . . . . . . . . 2224.3.18 Interface de pilotage du banc . . . . . . . . . . . . . . . . . . . . . . . . . . 2234.3.19 Solutions sur étagère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

4.4 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2294.5 Transformation DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2324.6 Mesure de la maturité DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

4.6.1 Evaluation DevOps selon sa vision . . . . . . . . . . . . . . . . . . . . . . 2374.6.2 Évaluation DevOps selon SAFe. . . . . . . . . . . . . . . . . . . . . . . . . 2384.6.3 Évaluation DevOps selon Humble . . . . . . . . . . . . . . . . . . . . . . 2414.6.4 Métamodèle de maturité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2434.6.5 Évolution du pipeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2444.6.6 Évolution des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2464.6.7 Définition de la notion de maturité . . . . . . . . . . . . . . . . . . . . . 2504.6.8 Évaluation de la maturité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

4.7 Pantesting et DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

5. Du code propre avec le Software Craftsmanship . . . . . . . . . . . . . . . . . . . . 257

6. Architecture Decision Record - une pratique autour de la prise de décision architecturale . . . . . . . . . . . . . . . . . . . . . . . . 265

7. Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266


Chapitre 4Pantesting appliqué au cycle de développement

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

2. Rôle de la vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

3. Cycles de développements de solutions Lean . . . . . . . . . . . . . . . . . . . . . . . 2723.1 Design Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2743.2 Lean Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2783.3 Lean UX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

3.3.1 Identifier les hypothèses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2833.3.2 Créer un MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2833.3.3 Expérimenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2893.3.4 Feedback et analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2903.3.5 Lean UX à la sauce SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

3.4 Cycles de développements de la solution et Pantesting. . . . . . . . . . . 292

4. Value Stream (courant de valeur). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

5. Planification à l'échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2995.1 Contexte de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2995.2 Préparation du Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3025.3 PI Planning de SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

5.3.1 Préparation du meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3055.3.2 Déroulé du meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3075.3.3 Sessions de travail sur les fonctionnalités . . . . . . . . . . . . . . . . 3085.3.4 Identification des risques sur le PI . . . . . . . . . . . . . . . . . . . . . . 3095.3.5 Vote de confiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3105.3.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3115.3.7 Program Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

5.4 Alternative au PI Planning avec LeSS . . . . . . . . . . . . . . . . . . . . . . . . . 3145.5 Planification et Pantesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3165.6 Roadmap de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

6. Mêlée quotidienne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

7. Acceptation des PBI et de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3227.1 Tests pendant le sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

7.1.1 Commencer par les tests - la qualité intégrée à la conception 3237.1.2 Cas des ENF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3267.1.3 Tests induits par les dépendances à la réalisation . . . . . . . . . . 328

6pour SAFe et LeSS


7.1.4 Qui teste ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3317.2 Revue d'itération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

8. Synchronisation des développements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3378.1 Flux tirés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3378.2 Modèle VATI de la théorie des contraintes. . . . . . . . . . . . . . . . . . . . . 3408.3 Outils de synchronisation de la théorie des contraintes. . . . . . . . . . . 345

8.3.1 Le tambour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3468.3.2 Le tampon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3498.3.3 La corde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

9. Rétrospective à tous les niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3519.1 Meeting I&A de SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3529.2 Point de vue LeSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3539.3 Pratiques et principes sous-jacents. . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

10. Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Chapitre 5Pantesting appliqué au support

11. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

12. Rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35912.1 Les équipes de composants et de fonctionnalités . . . . . . . . . . . . . . . . 35912.2 Les communautés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36912.3 Le management agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

12.3.1 Vision historique du management . . . . . . . . . . . . . . . . . . . . . . 38312.3.2 Raisons d'une transformation inéluctable . . . . . . . . . . . . . . . . 38712.3.3 Propositions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39012.3.4 Les écocycles du management agile et Pantesting . . . . . . . . . . 41412.3.5 Spécificités du manager de test agile . . . . . . . . . . . . . . . . . . . . 431

12.4 Le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43612.5 Le fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

12.5.1 Sélection des fournisseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43912.5.2 Contractualisation agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44312.5.3 Suivi du fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

12.6 Les équipes distantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45312.6.1 Types de distance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45312.6.2 ChatOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454


12.6.3 Synchronisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46012.6.4 Organisation des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46212.6.5 Indépendance et séparation

entre les développeurs et les testeurs . . . . . . . . . . . . . . . . . . . . 46412.6.6 "Translocation" des équipes et des compétences . . . . . . . . . . . 46612.6.7 Rôle de l'empathie dans le Pantesting . . . . . . . . . . . . . . . . . . . 471

12.7 Les Ressources humaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47212.7.1 Généralités sur les RH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47212.7.2 RH et agilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47412.7.3 RH et Pantesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484

13. Budget au niveau de l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48613.1 Budget traditionnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48713.2 Budget agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48913.3 Période de budgétisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49013.4 Flux des idées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49113.5 Équipe de budgétisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49213.6 Priorisation des idées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49313.7 Suivi du budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49413.8 Budget et Pantesting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

14. Outils et automatisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

15. Lean QMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50215.1 Description du Lean QMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50415.2 Transformation d'un système qualité existant. . . . . . . . . . . . . . . . . . 51715.3 OKR pour des métriques Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52115.4 Lean QMS et Pantesting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524

16. Gestion de la connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52616.1 Stratégies de gestion de la connaissance . . . . . . . . . . . . . . . . . . . . . . . 52616.2 Focus sur la transmission de la connaissance . . . . . . . . . . . . . . . . . . . 52916.3 Connaissance tacite et Ba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53016.4 Format de la connaissance tangible . . . . . . . . . . . . . . . . . . . . . . . . . . . 53416.5 Pantesting & gestion de la connaissance. . . . . . . . . . . . . . . . . . . . . . . 537

17. Culture d'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54117.1 Généralités sur la culture d'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . 54117.2 Pièges des organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54317.3 Propositions pour lutter contre ces pièges . . . . . . . . . . . . . . . . . . . . . 546

18. Résumé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

8pour SAFe et LeSS


Chapitre 6Mise en place du Pantesting

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

2. Démarrer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5512.1 Vision pour le changement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5512.2 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5522.3 Pièges de la roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554

3. Maintenir et améliorer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5593.1 Diversifier les écocycles et les prioriser . . . . . . . . . . . . . . . . . . . . . . . . 5593.2 Ajouter de la testabilité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5603.3 Gérer le Pantesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

3.3.1 ASCCR de Vance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5613.3.2 Double boucle d'apprentissage manageriale d'Augustine . . . . 5613.3.3 Niveaux de connexion inter-écocycle . . . . . . . . . . . . . . . . . . . . 562

3.4 Mettre en musique le Pantesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5623.4.1 Cartographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5623.4.2 Rôles dans le Pantesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5643.4.3 Métriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

Chapitre 7Annexes

1. Quelques abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

2. Valeurs et principes du manifeste agile et principes du test . . . . . . . . . . . . 570

3. Pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

4. Basiques du test agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5724.1 Principes du test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5724.2 Vision du test agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5724.3 Quatre quadrants du test agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5734.4 Valeurs du test agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5744.5 Manifeste du test agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5744.6 État d'esprit du Testeur agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575

5. Techniques de Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575


6. Pratiques Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5766.1 Challenge « 30 jours sur le Lean ». . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5766.2 Lean Software Development - les principes Lean pour le logiciel . . . 5786.3 Kaizen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

6.3.1 Les vingt règles Kaizen de Kobayashi . . . . . . . . . . . . . . . . . . . . 5816.3.2 Les dix règles Kaizen de Dobbs . . . . . . . . . . . . . . . . . . . . . . . . . 5826.3.3 Les douze défis Kaizen pour le test classique. . . . . . . . . . . . . . 582

6.4 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

7. SAFe vu d'en haut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5857.1 Pourquoi SAFe est-il le plus utilisé ? . . . . . . . . . . . . . . . . . . . . . . . . . . 5857.2 Les valeurs de SAFe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5857.3 Les dix principes de SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5867.4 Description sommaire et spécificités. . . . . . . . . . . . . . . . . . . . . . . . . . 588

7.4.1 Couches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5887.4.2 Meetings clés de SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5897.4.3 Le PI Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5897.4.4 ART Sync : PO Sync et Scrum of Scrum . . . . . . . . . . . . . . . . . 5907.4.5 Éléments d'idéation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5917.4.6 Rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5937.4.7 Estimations WSJF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5937.4.8 Story Points - la vision SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . 594

8. LeSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5958.1 Smaller LeSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5978.2 Huge LeSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598

9. Comparatif de modèles d'agile à l'échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

10. Crédits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601

11. Références bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653

269

Chapitre 4Pantesting appliqué au

cycle de développementPantesting appliqué au cycle de développement1. Introduction

La façon dont les activités de développement sont conduites est décisive dans latestabilité d'une solution. Chaque activité est une opportunité d'introduire des pra-tiques de test et en améliore l'efficacité.La difficulté à laquelle le test agile à l'échelle est confronté est due :– aux cadences de mise en œuvre des besoins des clients– à la quantité d'éléments produits tels que les besoins, le code ou les documents– aux activités et compétences décloisonnées des organisations pleinement agiles de

type C [Nonaka 1986], car tout est effectué « en même temps », ce qui pose laquestion du moment où se fait le test. Dans [Moustier 2019a], la question trouvedes réponses, mais comment limiter (voire éviter) de générer un phénomène d'éta-gement des actions entre chaque équipe et le client ? En effet, il est facile de conce-voir des équipes agiles qui livrent leur produit à une équipe d'intégration quiassemble les différentes parties pour livrer la solution complète pour des tests debout en bout. Hélas, cet exemple décrit clairement une organisation de type B, voireA.

Loin d'apporter une baguette magique, cette section donne des éléments pour s'appro-cher de cet idéal.

lcroise

Tampon

© E

diti

ons

ENI -

All

righ

ts r

eser

ved

270pour SAFe et LeSS


2. Rôle de la visionPartir dans la bonne direction est le premier point à observer pour arriver à bon port.La vision, qu'elle soit pour une entreprise, une solution, un besoin ou une idée, vientrésumer en quelques mots une direction dans laquelle on souhaite engager le plus depersonnes possible, ou simplement une équipe. Pour faciliter cette transformation,l'adoption par les membres d'une organisation d'un objectif primordial est d'unegrande aide : celui-ci donne une direction, une source de motivation et de cohérence,ainsi que de cohésion.Cet objectif aide à la prise de décision sur des choix que chacun est amené à faire etdonne une raison d'être, plutôt que de procéder à des actions mineures du niveau dela maintenance.Cet objectif doit [Bradford 1984] :– refléter l'objectif central pour un groupe de personnes,– être faisable,– être difficile, mais stimulant,– être porteur d'un sens supérieur.D'autres auteurs, comme [Kotter 1996], aiment aussi ajouter des critères tels que :– imaginable,– désirable,– concentré,– flexible,– communicable.Selon Simon Sinek, commencer par le "Pourquoi" de l'objectif [Sinek 2011] est aussi unfacteur qui permet à chacun de s'identifier dans une vision. Peu importe les critères,qui peuvent être multipliés ([Appelo 2010] en propose 15 autres), ce qui importe, c'estque ces critères arrivent à faire naître de l'inspiration, créer du sens, ne pas intimiderni démoraliser ou proposer trop de directions [Heathfield 2019], et surtout que touss'en rappellent !Pour construire la vision, on se base sur ce que l'organisation fait pour ses clients, surses compétences et ce sur quoi elle s'engage. Il ne faut pas hésiter à faire plusieurs pro-positions pour vote et affinage en atelier, les mélanger, laisser reposer quelques jours.Les quelques propositions restantes peuvent alors être exposées à d'autres équipessans hésiter à modifier, si nécessaire, la vision résultante. Son partage en sera d'autantplus pertinent pour toutes les personnes qui côtoient cette organisation. On peut aus-si se reporter à la section sur la "Planification à l'échelle" où un atelier sur la vision estproposé.

271Pantesting appliqué au cycle de développementChapitre 4

Beaucoup de confusions peuvent planer sur les notions de vision, mission, objectif,but ; ce qui nous intéresse ici, c'est l'intention, et surtout le système qui conduit uneorganisation dans une direction.

AstuceLes buts sont pour les perdantsScott Adams, le célèbre dessinateur humoriste de Dilbert, a un regard pertinent sur leconcept de vision [Adams 2013] : "Les buts sont pour les perdants", car si on étudie lespersonnes qui réussissent, elles suivent plutôt des systèmes, c'est-à-dire des attentesgénérales ; par exemple, perdre 10 kg est un but tandis que mieux manger est unsystème.

Tandis que les buts sont rigides, les systèmes sont flexibles et mènent à la curiosité, à demeilleures façons de réaliser les choses et développent les compétences. Toutefois, lesobjectifs restent pertinents, pourvu qu'ils soient restreints, simples et prédictibles.

Par ailleurs, en matière de buts, ne pas atteindre un objectif est un échec tandis qu'enmatière de systèmes, ce n'est qu'une tentative pour converger vers un résultat fiable.Le succès n'est qu'une question de chances combinées aux compétences.

Exemple de vision d'une équipe de SAVVoici une vision possible pour une équipe de SAV :« Nous sommes ceux qui maintiennent la réputation de MyCorp en matière dequalité et fiabilité en testant de façon proactive tous nos produits ».Pour aider à structurer sa vision, [Tichy 2004] propose une structure narrativepercutante en quatre parties.– Idée : on expose l'idée– Valeurs : cette idée conduit à des valeurs– Energie : l'ensemble des valeurs sollicitées doivent faire vibrer le lecteur par sa

cohérence et sa pertinence– Précipice : la fin du texte doit laisser le lecteur comme au bord d'un précipice

dans lequel il est forcément engagé

Si on reprend l'exemple de l'équipe de SAV :– Idée : « En plus de toute action corrective, nous voulons maintenir au plus haut

la réputation de nos produit…/… »– Valeurs : « …/… par une approche proactive centrée sur la qualité intégrée au

plus tôt afin de prévenir les défaillances et démontrer la fiabilité de nos produits.… /… »

– Energie : « …/… Nous allons sans relâche partager, traquer dans les moindresrecoins du produit et de l'organisation toute opportunité d'amélioration. … /… »

– Précipice : « …/… Tel est l'engagement de l'équipe de SAV et celui deMyCorp. ».

© E

diti

ons

ENI -

All

righ

ts r

eser

ved



3. Cycles de développements de solutions LeanDans les approches liées à l'agilité, au-delà des frameworks liés à la gestion des équipes,on trouve aussi des cycles de développements de solutions. Cette vision à haut niveaufournit une stratégie de développement de la solution adaptée au contexte dubusiness ; en effet, une start-up ne connaît ni sa solution ni son marché, tandis qu'unesolution mature développée dans une entreprise de grande taille est déjà assise sur uncertain nombre de certitudes qui font d'elle un colosse aux pieds d'argiles (voirl'exemple de l'entreprise SpaceX, qui est venue bouleverser le marché de la mise enorbite de satellites qui était pourtant fortement établi) [Blank 2016].Pour tenter de répondre à un contexte business changeant et Lean-agile, Geert Claespropose un tour d'horizon des cycles de solutions Lean en fonction de la maturité dumodèle économique [Claes 2017]. Le schéma ci-dessous propose une déclinaison de savision enrichie du Lean UX.

Figure IV-1 : Cycles de développements de solutions Lean en fonction du modèle économique

Sur ce schéma, on peut noter en pointillés les transitions possibles entre les types decycles de développement. Ces transitions sont comparables aux effets de mémoire quise produisent en phase Ω.


Vous pouvez aussi vous représenter d'autres transitions en sens inverse et à toutmoment, lorsque les retours d'expériences sont tellement significatifs qu'ils imposentparfois une remise en question (phase α) du modèle économique, qui subit alors unerévolution.Malgré leurs formes, ces différents cycles sont en fait des écocycles. Si on reprend laforme en selle de cheval d'un écocycle en 3D vue au chapitre Pantesting, il suffit devoir cette forme depuis le dessous (afin de conserver le sens d'évolution des cycles ci-dessus) pour voir une forme arrondie :

Figure IV-2 : Cycles de développements de solutions Lean du point de vue panarchique

Ainsi, le modèle d'écocycle se calque, comme par magie, sur un cycle de développe-ment. Si on en croit le modèle, la connectivité avec d'autres écocycles doit croître avecla maturité du modèle économique, et plus on est dans le problème, plus il faut de larésilience, qui s'accroît notamment par des tests afin d'en apprendre davantage sur lapertinence de la solution.Ce que nous enseigne le modèle panarchique est cette double nécessité de constitu-tion de connexions avec d'autres écocycles et d'impératif d'expérimentation par letest.

© E

diti

ons

ENI -

All

righ

ts r

eser

ved



3.1 Design ThinkingLe Design Thinking (démarche inspirée par la conception) est une méthode de gestionde l'innovation qui trouve ses racines dans les années 1970 à 90 avec les travaux de[McKim 1980] et [Faste 1993]. C'est une approche de l'innovation par observationdirecte de ce que veulent les utilisateurs et le marché. Elle est constituée de différentesétapes, depuis la compréhension jusqu'au prototype et au test, avec des allers-retoursentre les activités.Voici la liste des activités identifiées du Design Thinking, avec quelques pratiquesassociées.– L'empathie

– Utiliser des personae [Moustier 2019a]– Générer une carte d'empathie [Gray 2009]

Carte d'empathieDave Gray [Gray 2009] propose un outil popularisé par Alex Osterwalder[Osterwalder 2010] et décliné notamment par [Boukobza 2017]. Cet outil est utilepour tenter de découvrir un maximum de choses sur les besoins de « l'autre » et seglisser dans la peau des clients.Pour cela, il faut organiser une session de brainstorming avec des clients de diffé-rents segments de marché que l'on souhaite adresser avec la solution. On peutaussi utiliser ce type d'atelier pour caractériser un type de client, pour mieux sereprésenter une persona, avec des informations complémentaires telles que sasituation maritale, sa classe de revenus, etc. [Moustier 2019a].

Le schéma ci-dessous est dessiné sur un tableau blanc et les personnes présentesremplissent chaque cadran à l'aide de post-it dans l'ordre des questions.

Figure IV-3 : Carte d'empathie


– La définition (du problème et de ses conditions d'acceptation)– Utiliser le framework « Hooked » inspiré de [Eyal 2014] pour maximiser les

chances de viralité de la solution [Lewrick 2018] (voir l'avertissement "BurnOps",plus bas dans ce chapitre pour en comprendre les mécanismes et les dangers).

– Identifier les fonctions les plus critiques (ex. à partir de benchmarks, de sonexpérience, voire des idées les plus saugrenues pour se démarquer de la concur-rence) [Lewrick 2018].

– Utiliser un format tel que QQCOQP*, un « Elevator pitch » (courte descriptionpartageable le temps d'un voyage dans un ascenseur), le format des Epics de SAFeou le Lean Canvas (voir plus bas).

(* au lieu de QQQOCP, je préfère dire "QQCOQP", prononcez cela en imitant JohnnyHallyday dans ses toilettes… l'effet mnémotechnique est bien plus fort! Mais si vouspréférez la version érudite, cela s'appelle "l'hexamètre mnémotechnique de Quintilien")

– 1-Ce que je vois dans mon environnement - À quoi cela ressemble-t-il ? Qu'est-ce qui est autour de moi ? Qui sont mes alliés et amis, les détracteurs etennemis ? Quelles sont les offres auxquelles je suis exposé ? Quels problèmesest-ce que je rencontre ?

– 2-Ce que j'entends (ce qui peut m'influencer) - Que disent mes amis ? Quim'influence réellement et comment ? Quels sont les supports et canaux quim'influencent ?

– 3-Ce que je pense et ressens réellement - Qu'est-ce qui est vraiment importantpour moi? Qu'est-ce qui m'émeut ? Qu'est-ce qui me tient éveillé la nuit ? Quelssont mes rêves et aspirations ?

– 4-Ce que je dis et fais (ce que je peux dire ou comment je peux me comporteren public - Attentions aux dissonances cognitives) - Quelle est mon attitude?Qu'est-ce que je pourrais dire aux autres ?

– 5-Mes points de douleur - Quelles sont mes plus grandes frustrations ? Quels sontles obstacles que je rencontre entre ce que je recherche et ma situationactuelle ? Quels sont les risques que j'encours ?

– 6-Mes bénéfices - Qu'est-ce que je souhaite réellement ? Comment je mesurele succès ? Quelles stratégies vais-je employer pour atteindre mes objectifs ?

Documents

Conduite de tests agiles pour SAFe et LeSS