Gestion des dépendances

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 :

• Communautés de pratique
• X-Teams
• le modèle Panarchy

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.

‍