Le concept de gestion des dépendances
"Les silos sont mauvais". Les silos sont des regroupements d'activités ou de personnes qui ne se soucient pas de ce qui se passe ailleurs. Cette mentalité de "péquenaud" est le véritable mal. En effet, si les User Stories (US) doivent être INVEST [Wake 2003] [Moustier 2019-1] et les tests "FIRST" [Tekguard 2018] [Moustier 2019-1] (dans les deux cas, le " I " signifie " isolé "), mais pour des questions d'efficacité, les personnes doivent communiquer, conformément au manifeste agile [Beck 2001], pour permettre la collaboration et les interactions.
En fait, les silos se forment naturellement parce que les gens aiment ça, mais en se concentrant sur ce que vous faites, vous ne voyez pas les problèmes dans leur contexte [Taylor 2017]. D'un autre côté, les silos sont également utiles pour
- il est facile à gérer
- elle crée un sentiment d'appartenance
- il suscite la confiance
- il permet de se concentrer
Par conséquent, les silos ne sont pas entièrement mauvais à condition que l'organisation doive lutter contre l'effet de silo par une " bonne et fréquente ventilation " [Novkov 2016].
Par exemple, les équipes peuvent être organisées par composants ou par fonctionnalités, mais si elles n'ont pas de liens étroits avec d'autres équipes, elles ne feront que dériver de l'objectif global. De toute évidence, la synchronisation avec des équipes qui n'ont aucune relation est sans doute inefficace. C'est pourquoi la gestion des dépendances est cruciale. Ces dépendances peuvent être facilement repérées en termes de fonctionnalités, d'où le Program Board avec SAFe [SAFe 2021-32] qui met en évidence les liens entre US et les équipes.
Dans un Program Board, les lignes rouges entre US ou Enablers représentent les interactions attendues entre les équipes qui sont déclenchées notamment lors des réunions de synchronisation hebdomadaires (SAFe nomme ces réunions "ART Sync" [SAFe 2021-14]). Suivant la loi de Conway, le parallèle entre les organisations et l'architecture est simplement inévitable [Conway 1968] ; c'est pourquoi il est pertinent de jeter un coup d'œil à la conception pilotée par le domaine (DDD) qui stipule notamment [Vernon 2016] [Evans 2004] [Moustier 2020]
- une langue omniprésente - cela permet de partager des équipes différentes grâce à une même langue.
- une "carte du contexte" - elle fournit différents types de relations d'un point de vue systémique; à partir de ces types de relations, le degré d'interaction peut être adapté [Moustier 2020].
Il existe d'autres outils qui peuvent fournir une bonne ventilation :
Quelle que soit l'astuce impliquée, l'idée est d'éviter les retards et les divergences entre les équipes liées. Cette attention particulière profite aux "flux de valeur", c'est-à-dire à la "série d'étapes qu'une organisation utilise pour mettre en œuvre des solutions qui fournissent un flux continu de valeur à un client" [SAFe 2021-18].
Impact sur la maturité des tests
L'utilisation de dépendances connues est particulièrement utile pour les tests. Supposons que vous sachiez, d'après le conseil d'administration du programme, que l'équipe A doit fournir un certain US à l'équipe B qui doit fournir quelque chose de plus important à l'équipe C :
- L'équipe A peut effectuer des "tests locaux de bout en bout" (qui sont en fait proches des tests de composants) dès que cela est possible.
- Une fois que l'équipe A a livré les USà l'équipe B, la seconde équipe peut effectuer des tests d'intégration, puis des tests plus larges de bout en bout.
- Naturellement, l'équipe C fera de même à un niveau plus large.
Cet exemple simple met en évidence le côté social de la testabilité: B peut ne pas savoir si A a bien fait son travail si B ne sait pas comment la testabilité les USfait par A ou est réellement bien fait.
En pensant en termes de flux de valeur, B n'attendrait pas A ; en fait, il essaierait d'anticiper l'intégration à venir (en ce qui concerne la carte de contexte, A et B peuvent également collaborer pour définir éventuellement le travail à effectuer par A). Dans ce contexte, il est clair que A et B devraient se concerter régulièrement pour synchroniser leur propre évolution par rapport à l'autre équipe. C'est ce que suggère le modèle Panarchy [Gunderson 2002] avec des niveaux progressifs de synchronisation entre les équipes. Dans ce modèle, les équipes sont des sous-systèmes appelés "écocycles". Chaque écocycle connaît des phases de changement α, r, K et Ω. Ces adaptations devraient progressivement conduire à l'intégration des changements des écocycles liés dans leur propre écocycle avec des taux plus élevés jusqu'à ce qu'ils soient synchronisés [Moustier 2020].
Lorsqu'il s'agit de plusieurs équipes reliées entre elles, la synchronisation peut être résolue simplement par une approche synchronisée et cadencée [SAFe 2021-7] qui est en fait basée sur la théorie des contraintes (ToC) [Moustier 2020]. Cela permet de définir la manière dont les connexions doivent être régulées au mieux pour éviter le coût des retards et la dépense d'énergie supplémentaire pour forcer les écocycles fusionnés.
Ces connexions offrent en faitL'apprentissage en double boucle des opportunités [Argyris 1977][Smith 2001][Moustier 2020] de guider la dépendance vers sa bonne direction. Cela évite d'avoir deux équipes qui construisent un pont de chaque côté d'une rivière avec un résultat mal aligné [Evon 2016]. La synchronisation peut être facilitée grâce aux X-Teams avec quelques ambassadeurs qui sont envoyés au sein d'autres équipes pour assurer un alignement juste à temps.
En fait, la combinaison de
- testabilité
- panarchie
- apprentissage en double boucle
- et ToC
est connu pour construire le modèle Pantesting, un modèle de test agile à l'échelle [Moustier 2020].
C'est la responsabilité des managers d'agir comme des jardiniers afin de laisser émerger cette gestion de la dépendance par les personnes. Tout comme dans la pensée Lean/Agile, "Une telle responsabilité ne peut être déléguée" - W. E. Deming [SAFe 2021-36].
Le point de vue d'Agilitest sur la gestion des dépendances
La gestion des dépendances est en fait cruciale lorsqu'il s'agit d'automatiser des scripts de test. Automatiser des scripts de test tout seul est une mauvaise habitude. Il est facile de comprendre qu'il est fortement recommandé de se mettre en contact avec les autres personnes dont dépend votre script afin de déterminer les changements qui peuvent avoir un impact sur votre conception de test, qu'il s'agisse de
- des caractéristiques qui ne manqueront pas d'être modifiées ou qui ne seront peut-être pas prêtes à être testées
- des widgets pour interagir avec
- les données commerciales pertinentes à injecter dans les tests
- etc.
Afin d'augmenter la robustesse du script, lorsqu'il s'agit de petits changements sur le widget, Agilitest introduit un certain état d'esprit de l'approche Lean telle que Jidoka [Monden 2011] grâce à des heuristiques qui devinent le bon widget à utiliser à partir de critères prédéfinis. Néanmoins, l'outil n'est pas capable d'interagir entre les personnes, surtout celles avec lesquelles il existe des dépendances, qu'elles soient tacites ou explicites [Nonaka 1998]. C'est votre responsabilité.
Pour découvrir l'ensemble des pratiques, cliquez ici.
Cartes connexes
Pour aller plus loin
- [Argyris 1977] : Chris Argyris - " Double Loop Learning in Organizations " - Harvard Business Review - SEP/1977 - https://hbr.org/1977/09/double-loop-learning-in-organizations
- [Beck 2001] : Kent Beck etal. - " Manifeste pour le développement Agile de logiciels " - 2001 - http://agilemanifesto.org/iso/fr/manifesto.html
- [Conway 1968] : Melvin Conway - " How do Committee Invent ? " - magazine Datamation - 1968 -http://www.melconway.com/Home/Committees_Paper.html
- [Evans 2004] : Eric Evans - FEV 2004 - "Domain-Driven Design : S'attaquer à la complexité au cœur du logiciel" - ISBN : 9780321125217
- [Evon 2016] : Dan Evon - JUIN 2016 - "Cette photo montre-t-elle un pont mal aligné ?" - https://www.snopes.com/fact-check/misaligned-bridge-photo/
- [Gunderson 2002] : Lance H. Gunderson & C. S. Holling - " Panarchie - Comprendre les transformations des systèmes humains et naturels " - Island Presse - ISBN 1-55963-857-5
- [Moustier 2019-1] : Christophe Moustier - JUIN 2019 - " Le test en mode agile " - ISBN 978-2-409-01943-2
- [Moustier 2020] : Christophe Moustier - OCT 2020 - " Conduite de tests agiles pour SAFe et LeSS " - ISBN : 978-2-409-02727-7
- [Nonaka 1998] : Ikujiro Nonaka & Noboru Konno - 1998 - "Le concept de `Ba' : Construire une base pour la création de connaissances". - https://www.semanticscholar.org/paper/The-Concept-of-%E2%80%9CBa%E2%80%9D%3A-Building-a-Foundation-for-Nonaka-Konno/355bd3020ebad1f2a92c9ebefdd619bc0d87c7b5
- [Novkov 2016] : Alexander Novkov - JUL 2016 - "Ne brisez pas vos silos - repoussez la mentalité du silo" - https://www.infoq.com/articles/break-silos-ventilators/
- [SAFe 2021-14] : SAFe - FEV 2021 - "Incrément de programme" - https://www.scaledagileframework.com/program-increment/
- [SAFe 2021-18] : SAFe - FEV 2021 - "Value Stream" - https://www.scaledagileframework.com/value-streams/
- [SAFe 2021-32] : SAFe - FEV 2021 - "Planification de l'IP" - https://www.scaledagileframework.com/pi-planning/
- [SAFe 2021-36] : SAFe - FEV 2021 - "L'esprit Lean-Agile" - https://www.scaledagileframework.com/lean-agile-mindset/
- [SAFe 2021-7] : SAFe - FEV 2021 - "Principe n°7 - Appliquer la cadence, se synchroniser avec la planification inter-domaines" - https://www.scaledagileframework.com/apply-cadence-synchronize-with-cross-domain-planning/
- [Smith 2001] : Mark K. Smith - 2001 (mis à jour en 2005) - "Chris Argyris : théories de l'action, apprentissage en double boucle et apprentissage organisationnel" - www.infed.org/thinkers/argyris.htm
- [Taylor 2017] : Paul Taylor - FEB 2017 - "Pourquoi nous aimons le travail en silo et ce qu'il faut faire à ce sujet" - https://paulitaylor.com/2017/02/10/why-we-love-silo-working-and-what-to-do-about-it/
- [Tekguard 2018] : Tekguard - NOV 2018 - "F.I.R.S.T Principes des tests unitaires" - https://github.com/tekguard/Principles-of-Unit-Testing
- [Vernon 2016] : Vaughn Vernon - JUIN 2016 - "Domain-Driven Design Distilled" - ISBN : 9780134434995
- [Wake 2003] : Bill Wake - AUG 2003 - "Investissez dans les bonnes histoires et les tâches SMART" - https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/