Équipe de fonctionnalités

Le concept d'équipe fonctionnalité 

Dans les années 60, Melvin Conway a étudié les comités et a établi un lien entre l'organisation et l'architecture [Conway 1968], qui a été popularisé sous le nom de "loi de Conway" :

"Toute organisation qui conçoit un système (défini au sens large) produira une conception dont la structure est une copie de la structure de communication de l'organisation."

Il est facile de voir que les organisations ont tendance à produire des équipes de composants (CT), notamment en raison de [SAFe 2018-41] :

• certaines connaissances sur une technologie donnée
• les données sensibles et les restrictions concernant leur accessibilité
• contraintes de réutilisation
• une complexité sous-jacente que seuls les développeurs historiques peuvent comprendre

Malheureusement, ces structures basées sur le CT rencontrent certains problèmes tels que [McGreal 2018].

• SDLC séquentiel avec des interactions complexes impactées par une structure de type VATI 
• forte Gestion des dépendances, coordination et gestion grâce à la structure organisationnelle
• travailler sur des fonctionnalités qui ont peu de valeur ajoutée pour l'entreprise
• Passage de relais, éparpillement de l'information et accumulation importante d'activités
• le client et la globalité du projet se dissipent dans la structure et finissent par être perdus de vue
• mesure opaque du progrès
• Les équipes inventent du travail pour elles-mêmes lorsqu'elles sont en attente
• faible niveau de qualité

Toutes ces contraintes justifient une organisation centrée sur les composants et axée sur les API, avec un inconvénient dramatique : les les Product Owners (PO) de ces équipes se retrouvent avec une vision commerciale relativement pauvre et un incrément de produit qui doit être intégré avec beaucoup d'autres composants et un processus de déploiement échelonné de type Waterfall "Développement → Intégration → Test du système → Déploiement", la structure en forme de A comme le premier inconvénient cité ci-dessus.

Note sur les équipes matricielles: Certains peuvent être contraints de créer des organisations basées sur des équipes matricielles. Ce modèle date des années 1950 ; ces équipes peuvent affecter temporairement certains de leurs membres à des équipes Scrum. Ce modèle présente un écueil : la présence non régulière d'une personne pour un besoin récurrent sera une source de perturbation pour l'estimation de la vélocité ou la gestion efficace du WIPsurtout si la ressource n'est pas immédiatement disponible, ce qui fait de cette configuration une mauvaise idée en termes de flux [Larman 2010].

En fait, lorsqu'une organisation démarre, elle est orientée vers le client et les gens s'organisent les uns les autres avec leur méthode de travail (WoW) dans une approche orientée réseau pour maximiser naturellement le flux de livraison dans un état d'esprit entrepreneurial [Kotter 2014]. Au fur et à mesure que l'entreprise réussit, la responsabilité des personnes doit devenir plus claire pour rendre les choses plus visibles, des experts sont recrutés et des départements créés ainsi que des procédures pour augmenter la productivité et une hiérarchie est installée. Si les managers au sein de la hiérarchie émergente ne connaissent pas l'Agilité d'Entreprise et ses implications sur la façon dont les choses doivent être conduites de leur côté, l'entreprise commence à s'organiser par fonctions et des silos apparaissent partout. Avec l'entreprise, la hiérarchie continue de croître tandis que l'esprit d'entreprise continue et se heurte à certains points, et à chaque fois, la hiérarchie gagnera [SAFe 2021-40]. Cette situation se poursuit jusqu'à ce qu'un "cygne noir" apparaisse et alors que les clients ont besoin d'un changement, l'organisation est coincée dans des querelles intestines. Cette situation est appelée "pièges organisationnels" [Argyris 2010] et est due à deux modèles réflexes que tout le monde possède :

• Modèle I: "raisonnement défensif" - protège l'individu du changement
• Modèle II: "raisonnement productif" - prévient les conséquences contre-productives de la pensée défensive.

‍

Cette situation inévitable conduit l'entreprise à une organisation ambidextre [Maier 2015] qui mélange Hiérarchie & Connectivité, Modèle I & Modèle II selon la " Panarchie " de de Puydt qui propose la coexistence de plusieurs modèles de gouvernance en parallèle [de Puydt 1860] [Appelo 2010] (à ne pas confondre avec la Panarchie de Holling & Gunderson).

Maintenant, examinons les alternatives à ces équipes de composants [Moustier 2020] :

• No Team (NT): les participants sont auto-organisés, comme dans le développement de produits open source ; idéalement, il s'agit de holons (entité indépendante et autonome) dans un système holacratique [Moustier 2019a] [Mateleshkavo 2018] [Viðarsson 2017].

• Private Open Source Teams (POST): cette organisation repose sur l'implication des membres en mode open source sur certains composants. Les membres utilisent un backlog de composants commun [Ambler 2012] [Kniberg 2014-2]. Elle est particulièrement utile lorsqu'elle est appliquée sur des composants critiques pour l'entreprise et impactant plusieurs équipes.
• Les équipes produits (PT): elles prennent en charge l'ensemble du développement de la solution, y compris le marketing et les opérations. La limite de ce fonctionnement est la taille de la solution, qui est nécessairement modeste en termes de quantité de fonctionnalités [Burm 2016].
• Feature Teams (FT): elles prennent la responsabilité de quelques fonctionnalités sur tous les aspects techniques, ce qui constitue l'évolution naturelle des Product Teams lorsque la solution devient trop riche pour que toutes les équipes connaissent l'ensemble de la solution. Les FT sont proches des équipes en "I" ou en "T" selon le modèle VATI de la Théorie des Contraintes. On peut noter que ces équipes sont cependant soumises tôt ou tard à des formes de management matriciel mais simultanément [Rigby 2016] à des approches cadencées, synchronisées et incrémentales avec des cycles d'apprentissage courts pour une meilleure coordination.
• Les équipes chargées du parcours client (CJT) : il s'agit d'une extension des équipes chargées des fonctionnalités qui englobe la manière dont les clients utilisent la solution, de l'identification du problème à la mise en œuvre de nouvelles offres, qui font la différence dans l'environnement numérique [Burm 2016].

Cette organisation ambidextre peut alors être en mesure d'intégrer différentes structures d'équipe pour s'adapter à différentes situations et défis, tels que la maturité de l'équipe en matière de parcours client. Cette situation inévitable conduit à un panachage de structures au sein de l'organisation, conformément à la panarchie de Puydt :

• quelques équipes orientées vers les composants,
• une poignée d'équipes privées open source ,
• une bonne majorité d'équipes organisées autour des fonctionnalités, ou autour des parcours clients pour les équipes les plus matures.

L'autonomie de l'équipe étant cruciale pour réduire les délais, une organisation caractéristique basée sur l'équipe fait l'unanimité quel que soit le cadre [SAFe 2018-41] [Ambler 2012][Larman 2010] [Larman 2017] [Kniberg 2012] ; néanmoins, en examinant les situations, les avantages et les inconvénients, les ratios estimés à long terme sont les suivants :

• SAFe estime qu'il est approprié de maintenir environ 25% des équipes en mode composant.
• DAD propose des chiffres similaires avec 80-90% des équipes en mode fonctionnalité, à 10-20% en mode composant et 1-4% en mode privé open source [Ambler 2012].

‍

D'un TC à des formes d'équipes plus agiles, de nombreuses transformations devraient avoir lieu. Pour y contribuer, le Definition of Done (DoD) est extrêmement utile et lorsque l'équipe est en mesure de répondre pleinement au problème de l'entreprise, en co-création avec les partenaires techniques susceptibles de contribuer à la solution [Larman 2017]. Par conséquent, les CE se sentent responsables de la qualité du produit.

Il est également possible de laisser une équipe agile unique démarrer un composant jusqu'à ce que son résultat soit suffisamment bon pour que d'autres équipes s'approprient et pérennisent ce qui a été mis en place avant que la première équipe ne se " calcifie " autour de ce composant [Leffingwell 2018].

Une autre option pour passer du CT au FT et contribuer au changement de culture, vous pouvez [Larman 2010] [Moustier 2020] :

1. Commencer à partir d'un CT et le conserver pendant un certain temps, puis répartir les membres de l'équipe entre les CT existants (ou des équipes plus axées sur le client).
2. Partager les éléments du Backlog de produit (PBI) concernant le composant entre le CT existant et ses anciens membres.
3. Diminuer la taille du CT jusqu'à ce qu'il se dissolve

Lorsqu'une équipe passe d'une CT à une FT, en termes de Panarchie, cela signifie que l'écocycle de l'équipe et celui de l'entreprise fusionnent. Ceci peut être facilité grâce aux X-Teams.

Impact sur la maturité des tests

Le terme "Feature" sur un FT comporte deux aspects

1. Technologie : une telle équipe est capable de gérer les technologies requises pour fournir la fonctionnalité - cela conduit les équipes à élever les membres à des personnes de niveau T-Shape.
2. Sur le plan commercial : Pour fournir la bonne fonctionnalité, une telle équipe se rapproche des utilisateurs finaux et du domaine auquel ils ont affaire - les X-Teams et le langage omniprésent devraient aider à incarner l'état d'esprit du CE.
3. Organisation : il arrive qu'une fonctionnalité ait du sens pour plusieurs équipes, notamment parce qu'elle est vaste ou parce que toutes les équipes ne se tournent pas vers le CE.
   
   

La troisième situation est la plus difficile à gérer et ressemble à ceci : disons que votre système a différents "points de contact" (TP) (A, B et C dans le schéma ci-dessous), des applications verticales qui traitent certaines parties des objets que le système gère. Les User Stories (US) de chaque équipe sont évidemment orientées vers le client et ces TPs interagissent pour répondre à un cas d'entreprise. Les testeurs de C peuvent avoir besoin de tests de bout en bout avec des données circulant de A à B et à C. Cette situation oblige les testeurs de C à connaître certaines des fonctionnalités de B et A. 

‍

Pour permettre à C d'effectuer ses tests, il dispose de différentes options graduées qui devraient progressivement gagner en autonomie, puis en fluidité :

• Étape 0 - C ne sait rien de A et B : C se moque des comportements et des données de B.
• Étape 1 - C ne sait rien de A et B : C aura besoin de l'aide d'autres équipes pour découvrir et exécuter les actions requises.
• Étape 2 - C est capable d'exécuter certaines fonctionnalités du TP précédent : C exécutera des tests seul sur les fonctionnalités connues et demandera l'aide d'autres personnes pour des cas spécifiques.

Alors que l'étape 0 impliquera au moins des harnais de test, l'étape 1 et les suivantes requièrent l'état d'esprit de la X-Team. Cette étape 1 permettra à C de découvrir et d'apprendre à jouer avec les parties précédentes, au moins sur les fonctionnalités les plus faciles et les plus courantes.

L'étape 2 est une amélioration continue qui donne progressivement plus de liberté à C. Cette liberté peut être apportée par une formation, une documentation disponible ou mieux encore, des scripts automatisés qui exécutent les actions requises. Tous ces éléments sont en fait abordés dans l'aspect social de la testabilité.

Le point de vue d'Agilitest sur cette pratique

L'impact immédiat du CE avec Agilitest est l'intégration de l'automatisation au sein du CE, pendant le Sprint. Cette configuration pousse l'équipe à tout faire en même temps, en fusionnant éventuellement les écocycles de développement et d'automatisation des tests et en constituant une équipe de travail autour de chaque US, en effectuant des tests de bout en bout dès que possible. Si l'automatisation des tests ne peut avoir lieu pendant le sprint, le Dark Launch sera le plus utile pour éviter de livrer des produits de mauvaise qualité.

Lorsqu'il s'agit d'effectuer des tests de bout en bout sur plusieurs sites, même si Agilitest n'est pas conçu pour la RPA pure, certains de nos clients utilisent l'outil pour automatiser certains de leurs processus. Cette petite modification peut être d'une certaine utilité pour faciliter la testabilité à travers plusieurs CE.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍

‍