Introduction

En fonction de la taille de l’entreprise, les enjeux de l’agilité et des tests vont imposer différents outils et rôles qui vont être appréciés, voire nécessaires, pour débloquer les décisions.

Ce chapitre propose d’éplucher ces rôles et éléments de support rencontrés dans l’univers agile et de voir comment ces éléments de l’entreprise vont pouvoir faciliter la testabilité à l’échelle.

Rôles

1. Les équipes de composants et de fonctionnalités

En 1968, Melvin Conway publie dans le magazine Datamation un article qui montre comment une organisation se met en place et comment elle vient calquer sa structure avec celle du système qu’elle produit [Conway 1968] ; cet article est à l’origine de ce qui est appelé la "loi de Conway" :

« Les organisations qui conçoivent des systèmes […] sont contraintes de produire des designs qui sont des copies de la structure de communication de leur organisation. »

Les raisons de la présence de ces équipes de composants sont dues à des barrières telles que [Leffingwell 2018] :

la connaissance technologique - tel module est écrit en COBOL, Fortran…
des informations liées à la sécurité - tel autre module permet d’accéder à des informations confidentielles et seule cette équipe peut être habilitée,
des contraintes de réutilisation - un module donné est tellement utilisé que si n’importe qui vient le modifier sans en mesurer les impacts, il peut planter toute l’organisation,
la complexité sous-jacente d’un composant - les algorithmes utilisés ou la dette technique accumulée ont rendu le code particulièrement illisible, sauf pour les développeurs historiques.

Voici quelques problèmes liés à une organisation basée sur les équipes de composants [McGreal 2018].

Cycle de développement séquentiel - la publication d’une version va être impactée par la complexité structurelle (voir le modèle VATI de la théorie des contraintes [Cox III 2010] présenté à la section Pantesting appliqué au cycle de développement - Synchronisation des développements).
Gestion des dépendances, coordination et management de la complexité supplémentaires.
Travail sur des fonctionnalités à faible valeur ajoutée
Passage de relais, éparpillement de l’information et accumulation importante d’activités.
Client et globalité du projet perdus de vue.
Mesure du progrès opaque.
Équipes qui s’inventent du travail lorsqu’elles...

Budget au niveau de l’entreprise

« Pecunia nervus belli » (l’argent, c’est le nerf de la guerre) disait Cicéron. Voyons ensemble comment l’agilité vient bousculer ce qui est la colonne vertébrale des entreprises.

1. Budget traditionnel

Exemple de gestion de budget

Une administration rattachée à l’Etat s’était lancée dans l’utilisation de centres de services (CdS) dont une des équipes de réalisation fonctionnait en mode Scrum au milieu de toute cette structure de culture très pyramidale. Le périmètre fonctionnel du CdS périmètre variait en fonction des besoins réglementaires dictés par le gouvernement. Dans cette administration, les points de contact du CdS (les responsables de réalisation des domaines) tentaient d’établir le budget d’une fonctionnalité sur la base de quelques lignes qui venaient d’en haut et de veiller à la bonne réalisation de cette fonctionnalité par le CdS.

Cette approche embarque avec elle deux écueils :

l’expérience en matière de chiffrage et la capacité à partir à la pêche aux informations du responsable de réalisation,
l’évolution imprévue du besoin qui se révèle au fil des itérations avec un budget qui se montre trop limitatif et pousse le responsable de réalisation à demander une rallonge de budget, car le MVP n’a pas été atteint ni même pensé.

Les budgets sont décidés au plus haut niveau et octroyés de façon annuelle. Toute demande de rallonge est une lutte d’influence et de compensation entre les projets.

La façon classique de gérer un budget est [PMI 2013]

Planifier le management des coûts - Une attribution d’une enveloppe pour

une charte (ex. mission, durée, les hypothèses et contraintes du projet)
des outils et techniques
un niveau de précision
le format des rapports

Estimer les coûts - Une analyse prospective de la situation à venir avec notamment

un échéancier du projet
un calendrier des ressources
un registre des risques
les estimations au regard de différentes techniques (ex. par analogie ; basées sur l’historique ;...

Outils et automatisation

[Bach 2015c] intègre dans la vision d’automatisation tout type d’outil qui vous libère de toute une série d’actions manuelles, ce qui rend pour lui la question d’automatisation des tests une sorte d’aveuglement conceptuel, car l’acception courante ne semble vouloir voir que la question d’exécution d’actions sur le système à tester. C’est pourquoi les éléments partagés dans cette section n’adressent pas que l’assistance à l’exécution des tests, mais aussi tout type d’outil qui automatise tout ou partie d’une activité, manuelle ou non.

À partir de cet élargissement, la question de l’outillage est aussi accentuée par la quantité industrielle d’éléments auxquels les gens dans l’organisation sont confrontés, pas tant parce qu’elle est agile, mais surtout parce qu’il y a une grande quantité de personnes impliquées.

L’outillage doit venir soutenir :

la quantité d’éléments à gérer (pour les stocker et les retrouver),
la simplicité de traitement (pour réduire une séquence d’actions manuelles à une seule action),
la rapidité de traitement (pour traiter plus vite une grande masse d’éléments).

Mais une fois outillée, l’activité a besoin de gagner en fiabilité, sinon :

soit une grande quantité de problèmes sont passés sous silence, voire générés,
soit chaque non-conformité implique une intervention humaine pour une opération spécifique qui permet le traitement par l’outil.

Ainsi, l’outillage doit favoriser la vigilance au bon niveau [Bach 2015c] en traitant de façon automatique un maximum d’actions sur des situations prévues, mais surtout, tenter de gérer l’imprévu.

Cette automatisation dotée d’une certaine capacité à l’autonomie se nomme Jidoka [Monden 1994] [Larman 2010] [Moustier 2019a] dans le jargon Lean, et remonte à 1902, lorsque Sakichi Toyoda (le fondateur de Toyota) a mis au point un dispositif pour arrêter automatiquement son métier à tisser lorsque le fil se casse....

Lean QMS

Lorsque l’entreprise est de grande taille ou si elle est soumise à des contraintes réglementaires, elle doit disposer d’un référentiel qualité qui conserve et entretient son savoir-faire. De façon traditionnelle, tout ceci est conservé dans une structure documentaire qui enregistre [ISO9001] :

la politique qualité et ses objectifs,
un manuel qualité qui permet d’accéder à l’intégralité de la documentation,
les procédures (qui incluent l’ingénierie et les activités d’assurance qualité),
les documents nécessaires à l’organisation pour assurer de façon efficace son fonctionnement et le déroulement des processus,
les traces des activités (appelés « Enregistrements Relatifs à la Qualité » - ERQ - dans la culture ISO ou « artefacts » dans la littérature logicielle).

La masse documentaire générée est en miroir avec un cycle d’amélioration continu pour former un système de management documents qualité / mise en œuvre des processus documentés nommé « Système de management de la qualité » (en anglais « Quality Management System » - QMS).

Figure V-35 : QMS selon [ISO9001]

On peut noter que :

cette vision est en apparence très hiérarchisée (la direction porte la responsabilité),
le client ne semble pas participer à la réalisation de la solution,
la boucle de réalisation ne semble qu’être destinée à améliorer le système qualité,
la documentation du système qualité doit refléter l’organisation des quatre phases plus la gestion du système de sorte à tout décrire, ce qui a pour effet de générer une masse documentaire colossale, soumise à un contrôle de gestion de configuration.

Au-delà du texte normatif qui compte une quarantaine de pages, la réalité montre un système documentaire très élaboré, avec une pyramide de documents standardisée par [ISO10013].

Figure V-36 : Exemple de pyramide documentaire de l’ISO9001 selon [Abuhav...

Gestion de la connaissance

1. Stratégies de gestion de la connaissance

La gestion de la connaissance est un vaste sujet, trop souvent limité à la gestion de ses artefacts, les outils pour les gérer et les pratiques autour de ces outils. La gestion de la connaissance doit évidemment être reliée à la stratégie de l’entreprise ; par exemple, [Harper 2019] identifie quatre composants.

Les acteurs - ils vont s’organiser pour nourrir le système et surtout faire le lien avec la stratégie de l’entreprise.
Un cycle en sept étapes :

1 - Créer la connaissance au quotidien
2 - Identifier la connaissance qui est critique pour la stratégie et les opérations
3 - Collecter la connaissance en vue de la partager
4 - Passer en revue la connaissance pour évaluer sa pertinence, sa justesse et son applicabilité
5 - Partager la connaissance au travers de la documentation, des posts informels et des activités collaboratives
6 - Accéder à la connaissance en allant la chercher ou par des mécanismes où le système fait des propositions d’informations telles que les notifications
7 - Utiliser la connaissance pour résoudre des problèmes plus rapidement et prendre des décisions de façon plus rationnelle

Du contenu sous toutes ses formes et stocké sur un système accessible.
Une stratégie pour orienter la connaissance vers des cas du métier.

À partir de ce découpage, Harper fournit un outil d’évaluation de la maturité pour estimer la pertinence de votre système de gestion de connaissance.

De son côté, [Maier 2007] répertorie une approche fondée sur la dualité « stratégie de codification » / « stratégie de personnalisation ». La première stratégie s’occupe de la documentation et de l’institutionnalisation de la connaissance explicite ; le système de gestion de la connaissance joue alors un rôle de conteneur. La deuxième stratégie, dite de personnalisation, s’intéresse aux liens entre les sachants et les utilisateurs de la connaissance, qui deviennent des experts en recherche de connaissance.

Chacune de ces stratégies est alors déclinée...

Culture d’entreprise

1. Généralités sur la culture d’entreprise

Qu’elle soit poussée par le besoin de test, de Lean, d’agilité ou de DevOps, cette facette de l’entreprise qui existe depuis que l’entreprise existe est évidemment la plus complexe et la plus puissante. Ses multiples aspects sont notamment [Beatty 2018] :

une force intense et invisible qui se perpétue d’elle-même ;
une représentation directe de la pensée de groupes ; nous nous comportons et nous agissons en accord avec la vérité telle que nous la percevons ;
ce qui se passe lorsque les managers sont absents ;
les règles et les normes tacites qui nous disent comment prendre les décisions au quotidien ;
comment nous agissons sous la pression ;
la glue qui maintient l’organisation.

Dans le domaine de la culture d’entreprise, la citation la plus célèbre est attribuée à Peter F. Drucker :

« La culture mange de la stratégie au petit déjeuner »

De cette image communément admise, [Tye 2013] décline 12 points et interrogations susceptibles de vous permettre d’évaluer la robustesse de la culture de votre organisation :

Thème	Question
Les gens sont attachés à une culture et non une stratégie	Comment la fidélité bilatérale est-elle attendue et reflétée dans votre culture - et que pouvez-vous faire pour renforcer cette fidélité ?
La culture offre de la résilience dans les moments difficiles - ce qui peut tuer une organisation avec une culture faible rend une organisation avec une grande culture encore plus forte	À quel point votre culture est-elle difficile et résiliente ? Les collaborateurs sont-ils unis avec l’entreprise en cas de crise ?
La culture est plus efficace qu’une stratégie - tandis qu’une crise éclate, les gens peuvent faire front quoiqu’il arrive, la culture adresse quelque chose de plus profond	Comment pouvez-vous favoriser un niveau plus élevé d’alignement avec vos stratégies opérationnelles, et de service rendu à la clientèle ?
La culture crée un facteur différenciateur - deux entreprises peuvent vendre la même...

Résumé

Dans une organisation, souvent très complexe, les différents rôles vont contribuer

à générer la solution avec des X-Team pour que chacun devienne le plus autonome possible tout en prenant soin de ses connexions, avec les différentes parties de l’entreprise mais aussi tout type d’acteur, y compris externe, capable de l’aider dans la réalisation de ses besoins ;
à faciliter

la génération de la solution

en proposant un environnement sécurisant favorable à l’innovation,
en décentralisant la prise de décision,
en favorisant la qualité intrinsèque de la solution.

les connexions entre les écocycles afin d’assurer que les équipes

soient sensibles aux variations des écocycles dont elles dépendent (clients, marché, équipes, experts, etc.),
puissent développer leurs compétences et créer des leaders.

la mise en place d’un environnement propice à ces connexions (le Ba), notamment par

une approche de type Kaizen pour une amélioration continue, Yokoten pour la diffusion de l’amélioration et les OKR pour piloter le progrès,
des communautés de pratiques,
un apprentissage en double boucle,
des outils capables de s’adapter aux évolutions des écocycles,
un système qualité basé...

Pantesting appliqué au support