Blog ENI : Toute la veille numérique !
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée

Pantesting appliqué au cycle de développement

Introduction

La façon dont les activités de développement sont conduites est décisive dans la testabilité d’une solution. Chaque activité est une opportunité d’introduire des pratiques 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 la question du moment où se fait le test. Dans [Moustier 2019a], la question trouve des réponses, mais comment limiter (voire éviter) de générer un phénomène d’étagement des actions entre chaque équipe et le client ? En effet, il est facile de concevoir des équipes agiles qui livrent leur produit à une équipe d’intégration qui assemble les différentes parties pour livrer la solution complète pour des tests de bout en bout. Hélas, cet exemple décrit clairement une organisation de type B, voire A.

Loin d’apporter une baguette...

Rôle de la vision

Partir 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, vient résumer en quelques mots une direction dans laquelle on souhaite engager le plus de personnes possible, ou simplement une équipe. Pour faciliter cette transformation, l’adoption par les membres d’une organisation d’un objectif primordial est d’une grande 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 et donne une raison d’être, plutôt que de procéder à des actions mineures du niveau de la 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 un facteur qui permet à chacun de s’identifier dans une vision. Peu importe les critères, qui peuvent...

Cycles de développements de solutions Lean

Dans 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 niveau fournit une stratégie de développement de la solution adaptée au contexte du business ; en effet, une start-up ne connaît ni sa solution ni son marché, tandis qu’une solution mature développée dans une entreprise de grande taille est déjà assise sur un certain nombre de certitudes qui font d’elle un colosse aux pieds d’argiles (voir l’exemple de l’entreprise SpaceX, qui est venue bouleverser le marché de la mise en orbite de satellites qui était pourtant fortement établi) [Blank 2016].

Pour tenter de répondre à un contexte business changeant et Lean-agile, Geert Claes propose un tour d’horizon des cycles de solutions Lean en fonction de la maturité du modèle économique [Claes 2017]. Le schéma ci-dessous propose une déclinaison de sa vision enrichie du Lean UX.

images/04-IMG-01.png

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 de cycles de développement. Ces transitions sont comparables aux effets de mémoire qui se produisent en phase Ω.

Vous pouvez aussi vous représenter d’autres transitions en sens inverse et à tout moment, lorsque les retours d’expériences sont tellement significatifs qu’ils imposent parfois une remise en question (phase α) du modèle économique, qui subit alors une révolution.

Malgré leurs formes, ces différents cycles sont en fait des écocycles. Si on reprend la forme en selle de cheval d’un écocycle en 3D vue au chapitre Pantesting, il suffit de voir cette forme depuis le dessous (afin de conserver le sens d’évolution des cycles ci-dessus) pour voir une forme arrondie :

images/04-IMG-02.png

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éveloppement. Si on en croit...

Value Stream (courant de valeur)

Un Value Stream est un outil organisationnel qui matérialise les flux d’implémentation d’une solution qui apporte de la valeur à des clients [Leffingwell 2018].

Par le passé, il y a eu trois modélisations de la génération de la valeur métier [Blair 2017] :

  • la chaîne de valeur, plutôt orientée sur des aspects économiques,

  • le réseau de valeur, plutôt orienté sur les acteurs qui la réalise,

  • et le Lean Value Stream, qui initialement s’attache plutôt à optimiser les processus métier.

La notion de Value Stream peut être traduite par "courant de valeur" (ou "flot de valeur"), mais elle signifie littéralement "Ruisseau de Valeur" et [Tapping 2003] part de ce terme pour en faire comprendre la notion. Une organisation peut se comprendre comme une partie d’une rivière où chaque acteur interne se transmet la solution à transformer. Sur ce trajet, l’organisation doit tout faire pour que ce ruisseau ait le moins de méandres présents afin d’être la plus fluide possible vers le client final. Les pratiques Lean-agile sont là pour aider à réduire les méandres et fluidifier la création de valeur, notamment comme le propose la théorie des contraintes.

À la source de ces courants de valeurs, SAFe désigne une équipe "Lean Portfolio Management" pour gérer les Value Streams, qui va tenter de réguler les demandes en fonction [Leffingwell 2018] :

  • de l’alignement avec la stratégie de l’entreprise,

  • des budgets disponibles,

  • de la rentabilité d’une demande.

Cette approche permet d’éviter qu’une idée ne soit que le parfum du mois et a le bon goût de donner :

  • du sens aux équipes,

  • une gestion budgétaire compatible avec une organisation agile (voir chapitre Pantesting appliqué au support - Budget au niveau de l’entreprise).

Ainsi, la stratégie de l’entreprise se retrouve dans la moindre action de la solution qu’elle réalise.

Le Value Stream est le point de départ d’une catégorie de besoins semblables (des Epics). Ces Epics vont générer en cascade...

Planification à l’échelle

À partir d’une situation où on a une idée sur les grosses activités, on peut commencer à mettre en place une "planification". En agilité, ce mot sonne un peu comme une insulte, notamment après des décennies de Waterfall où le chef de projet détenait la clé du processus qui fixait, après études et réflexions prospectives, les objectifs à atteindre, les moyens nécessaires, les étapes de réalisation et les méthodes de suivi (en s’appuyant sur des tests qui étaient réduits au minimum).

Ici, ce terme galvaudé doit plutôt être pris sous son sens d’une intention, une idée, et non un programme défini dans le temps.

Cette section présente les éléments de planification liée à l’agilité à l’échelle.

1. Contexte de la solution

Le contexte dans lequel une solution est proposée est tout aussi important que les plans souhaités par l’organisation. SAFe montre les impacts d’un contexte sur les priorités, les fonctionnalités et les ENF. Ces impacts induisent des contraintes et des opportunités concernant [Leffingwell 2018] :

  • l’équilibre entre les budgets alloués sur les Epics en cours (voir chapitre Pantesting appliqué au support  - Budget au niveau de l’entreprise),

  • le contenu des itérations présentes et à venir,

  • la visibilité architecturale et les options qui doivent être figées (voir chapitre Pantesting appliqué à la testabilité technique - Architecture agile),

  • l’activation de fonctionnalités,

  • les enjeux pour le test, notamment par le "Context-Driven Testing" [Bach 2006] [Moustier 2019a] (voir chapitre Mise en place du Pantesting).

C’est pourquoi capturer le contexte présent et à venir de la solution est important à tous les niveaux, et chaque partie d’une organisation doit être capable de transmettre sa situation dans son écocycle, notamment lorsque son système est en

  • passe de devoir se réorganiser à la suite de contraintes externes (stade α),

  • recherche de solutions, où l’incertitude...

Mêlée quotidienne

Au-delà de l’action de facilitation que le Scrum Master peut mettre en œuvre, l’équipe doit se rappeler que c’est avant tout son meeting et elle doit tout faire pour le rendre efficace, avec des astuces comme traditionnellement répondre aux trois questions :

  • Qu’ai-je fait ?

  • Que vais-je faire ?

  • Quelles sont mes difficultés ?

Il n’est pas rare de voir une personne écouter patiemment ses collègues en attendant son tour, mais l’essence de ce meeting se retrouve dans le "Andon" du Lean : signaler tout élément qui est une menace pour la réalisation de l’objectif du sprint et mobiliser les efforts pour corriger le problème [Monden 1994] [Moustier 2019a] ; pour cela, [Yip 2016] propose d’utiliser un tableau des blocages (aussi appelé "Kaizen Newspaper" - les nouvelles du Kaizen), qui liste, pour chaque problème :

  • ses occurrences

  • les actions à court terme

  • les contre-mesures pour le moyen ou long terme

  • le statut

Il faut garder en mémoire que la mêlée est un bon moment pour lever une alerte (Andon), mais toute alerte doit être levée dès que possible.

Pour améliorer la prise en main de ce meeting par l’équipe, s’il doit y avoir un facilitateur du meeting, on peut faire tourner...

Acceptation des PBI et de la solution

Une fois que les Product Backlog Items (PBI) d’une solution sont définis et planifiés dans une itération, leur validation est la première vérification à réaliser sur la solution. À l’échelle d’une entreprise agile où des dizaines d’US de plusieurs équipes sont empilées aux centaines d’US des itérations précédentes, les petits soucis peuvent facilement s’accumuler et devenir problématiques au niveau de la solution sans que l’on s’en aperçoive avant la publication.

Cette section propose quelques directions pour réduire l’entropie des anomalies et éviter un effet papillon capable de déclencher une catastrophe pour vos clients et votre entreprise.

1. Tests pendant le sprint

C’est parti ! Chacun à une idée de ce que les équipes doivent accomplir. Les développeurs vont implémenter chaque US en essayant d’atteindre les critères d’acceptation de chacune, c’est-à-dire la DoD commune à l’équipe et les spécificités de l’US à réaliser. Cependant, au niveau macroscopique, on a :

  • des problèmes de zones d’ombre sur les parties que la technique a finalement masquées, ce qui génère des retards dans la détection d’anomalies

  • un potentiel phénomène d’amplification des problèmes qui peuvent apparaître avec la fréquence d’utilisation ou les enjeux fonctionnels

  • des exigences non-fonctionnelles à réaliser et implémenter

a. Commencer par les tests - la qualité intégrée à la conception

Pour cela, une première stratégie peut être attribuable à l’état d’esprit Kaizen poussé par la culture Lean, et en conséquence l’Agile qui prend le contrepied des choses : là où le test est traditionnellement réalisé à la fin, avec le TDD et l’ATDD, on commence par l’ingénierie des tests pratiquement en même temps que la rédaction des spécifications. Ce mélange des genres est expliqué par [Rainsberger 2014] : lorsque les cycles de développement...

Synchronisation des développements

1. Flux tirés

D’un sprint à l’autre, les besoins peuvent évoluer ; ils nécessitent donc une repriorisation régulière avant d’être proposés en sprint Refinement et sprint Planning. Pour fluidifier les délais d’attente, le PO peut utiliser différentes stratégies.

Tandis que pousser les tickets vers la production crée un amoncellement de tickets et donc du stock.

images/04-IMG-21.png

Figure IV-21 : les besoins sont poussés

tirer le besoin évite cette accumulation. Cette approche est un changement d’état d’esprit qui marque une bascule typiquement Lean-agile, où on part d’un planning espéré prédictif pour aller vers une planification adaptative basée sur les contraintes et des cycles de livraison courts.

images/04-IMG-22.png

Figure IV-22 : les besoins sont tirés

La stratégie qui consiste à avoir des flux tirés correspond au principe SAFe #6 : « Visualiser le travail en cours, réduire la durée des activités et la longueur des files d’attente »).

D’autres frameworks utilisent cette approche :

Ce principe de réduction de la longueur des files d’attente correspond au principe Lean sous-jacent qui consiste à avoir de faibles quantités de stocks afin d’éviter les excès et les gaspillages ; les fondements théoriques sont posés par [Little 1961].

images/X-icone.png

Exemple de flux tiré

Sur la chaîne d’assemblage d’un produit, sur une palette de cartons d’emballage, un petit papier rose dépasse légèrement, coincé à mi-hauteur de la pile de cartons. Lorsque l’opérateur prend l’emballage qui libère le repère, c’est en fait un bordereau, qu’il peut alors envoyer au service d’approvisionnement pour avoir une autre palette.

Ce bon de commande est situé à une hauteur qui permet une livraison sur le poste d’emballage juste à temps et qui limite le stock du nombre de palettes entreposées à côté de l’opérateur.

images/I-icone.png

Délais...

Rétrospective à tous les niveaux

L’équipe doit régulièrement lever la tête et comprendre comment s’améliorer. Dans cette optique, une rétrospective est essentielle, et une fois que le point organisationnel a été fait au sein de chaque équipe au moment de la rétrospective, il est nécessaire de voir comment les choses peuvent être améliorées au niveau du système.

  • Plus le problème est détecté tôt, plus il est simple de le traiter (voir « la théorie des vitres brisées » exposée au chapitre Pantesting appliqué à la testabilité technique - DevOps).

  • La vision systémique d’un problème implique son partage.

Pour cela, tous les modèles d’agilité à l’échelle intègrent une rétrospective interéquipe régulière (en plus de la rétrospective d’équipe) pour tenter de résoudre les problèmes systémiques.

Pour la mise à l’échelle de l’amélioration, on s’appuie généralement sur la rétrospective Scrum avec des pratiques, souvent gamifiées, comme on peut les trouver sur

Ensuite, on procède à un Scrum of Scrum, où un ambassadeur de chaque équipe remonte ses points [Kniberg 2012].

SAFe formalise un peu plus les choses avec deux meetings.

  • Un meeting hebdomadaire ou plus fréquent (voir Scrum of Scrum) qui réunit tous les Scrum Masters durant le sprint.

  • Un autre meeting, situé en fin de PI, qui s’intitule « Inspect & Adapt » (inspecter et adapter - souvent écrit I&A) [Leffingwell 2018].

1. Meeting I&A de SAFe

Voici comment SAFe imagine le meeting I&A (Inspect & Adapt) [Leffingwell 2018] :

Qui participe

  • Les équipes agiles

  • Le RTE

  • L’architecte système/solution

  • Le Product Management, les responsables métier et autres parties prenantes

Quand

Juste avant le PI Planning

Pour faire quoi

  • Phase...

Résumé

Le Pantesting aide à identifier, sur chaque phase du cycle de génération de la solution, les points d’attention pour maximiser la qualité :

  • en prenant conscience :

  • des moments où des bouleversements émergent (phases Ω) ; d’autres écocycles peuvent alors intervenir ou doivent être provoqués (phases α),

  • des allers-retours d’exploration induits par l’agilité entre les phases α de réorganisation et K d’accumulation, avant livraison de la solution (phase Ω),

  • des connexions entre les écocycles pour tirer le meilleur parti des liens identifiés tels que le marché, les clients actuels, d’autres équipes et les communautés de pratiques, etc. avec le mode de collaboration de chaque écocyle..

  • en faisant son possible pour :

  • permettre à chacun d’être acteur dans les écocycles auxquels il prend part avec les connexions afférentes,

  • introduire dans la solution des éléments de testabilité à tous moments et en fonction de différents points de vue (sécurité, dépendances, utilisations, etc.),

  • raccourcir l’écocycle de génération de la solution afin de voir au plus tôt les instabilités, par exemple avec :

  • des flux de production de PBI tirés ou améliorés...