Les équipes composantes sont une réalité et elles existent à des fins spécifiques. Dans les programmes sur lesquels j’ai travaillé, certaines équipes de composants travaillaient sur des couches d’architecture spécifiques telles que les validations de niveau intermédiaire et la génération des PDF en un clic pour refléter les écrans.
Ils ont été formés parce que les solutions prévues au niveau de ces couches nécessitaient d’énormes explorations de différents outils, sources ouvertes, approches de conception, etc. avant que ces couches ne puissent répondre au découpage vertical de l’application pour produire un incrément. Donc, essentiellement, ces équipes comprenaient des PME, des architectes ou des ingénieurs seniors pour un effort concentré sur une solution en couches qui n’était pas possible autrement dans le cadre de l’équipe technique qui se concentre principalement sur l’incrément fonctionnel.
Les équipes de composants peuvent être de courte durée. Dès qu’ils fournissent les solutions pour le composant que les équipes de fonctionnalités peuvent utiliser en toute confiance, l’équipe peut être dispersée et les membres se déplacent vers les différentes équipes principales pour prendre en charge à partir de là.
Les dépendances des équipes de fonctionnalité sur les équipes de composants ajoutent des éléments d’incertitude et de risques à la livraison. Par conséquent, le succès des équipes de composants est d’une importance primordiale pour le programme. Plus que leur capacité à fournir une solution à temps, l’impact global qu’ils ont est important, c’est-à-dire une solution adaptée à l’objectif, la qualité du code, une assistance rapide aux équipes dépendantes, l’alignement avec des feuilles de route plus larges, la modification du plan d’action au fur et à mesure que le besoin se fait sentir, et rester innovant au cœur.
Bien que les compétences techniques ne soient jamais un problème pour ces équipes car les PME en font toujours partie, l’état d’esprit même pour créer l’impact susmentionné sur la livraison globale détient la clé.
Voici les principaux attributs de l’état d’esprit d’une équipe de composants percutante issue des tranchées.
1. Cela arrivera, continuez
Développer une solution qui n’existe pas ou qui doit être modifiée pour s’adapter aux couches de l’architecture est une énorme responsabilité. Au début, la bonne solution peut ressembler à un rêve lointain pour un certain nombre de raisons telles que le temps pris dans la sélection et la disponibilité des outils, les échecs du prototype initial, le manque d’idées, la solution bloquée sur un point unique qui nécessite une exploration importante ou l’aide de sources ouvertes s’ajoutant au retard, aux problèmes d’infrastructure, etc.
Les équipes de composants réussies que j’ai vues, ne vous laissez pas emporter par les revers de la situation ; ils comprennent les défis inhérents à la technologie avec laquelle ils travaillent et restent déterminés à faire le travail. Ils relèvent les défis au quotidien, font preuve de persévérance, ont une attitude de ne jamais dire de mourir, sont ouverts aux discussions et s’adressent aux personnes dont ils ont besoin d’aide.
Le soutien au leadership, les sessions par des coachs agiles et le toilettage par des PME expérimentées jouent un bon rôle pour aider les équipes à développer cet état d’esprit qui assure le résultat souhaité à long terme.
2. Le travail d’équipe gagne la bataille
Parfois, les membres de l’équipe font de nouvelles découvertes qu’ils appliquent localement pour faire fonctionner le code efficacement, mais ne sont pas nécessairement signalés aux autres. De cette façon, les membres de l’équipe finissent par développer leurs solutions uniques pour les mêmes problèmes ou développent parfois une expertise sur des problèmes uniques, créant un certain nombre de PME au sein d’une même équipe qui doivent se contacter pour faire fonctionner le code. Le temps perdu dans les interactions et la communication se traduit ici par du gaspillage.
Les équipes de composants percutants comprennent que c’est une bonne idée d’explorer les idées séparément, mais avant cela, elles doivent se répartir le travail entre elles là où cela est nécessaire, identifier le travail qu’elles doivent explorer conjointement, partager les apprentissages avec les autres en temps opportun et acceptez de réfléchir régulièrement à ces idées pour les aligner sur la solution plus large. Étant donné que la solution appartient à une couche architecturale, chaque changement dépend les uns des autres, il faut donc que toute l’équipe reste sur la même page d’apprentissage et d’expertise en permanence.
J’ai remarqué ces problèmes dans les équipes et pour moi, le coaching d’équipe a fait des merveilles où les équipes ont pu identifier collectivement les défauts de leurs façons de travailler lors des séances de coaching et ont convenu d’une stratégie pour y faire face à l’avenir. De plus, le coaching a développé le bon état d’esprit au sein de l’équipe pour résoudre eux-mêmes ces types de problèmes.
3. La communication est une responsabilité
Une communication active avec les équipes dépendantes concernant l’état d’une solution en couches, les déploiements dans les régions de test et la réponse aux requêtes est la clé d’une livraison incrémentielle fluide au fil des itérations.
En s’alignant sur la version ou le plan PI, les équipes de composants savent ce qu’il faut fournir à chaque itération et avec qui sont les dépendances, et quelles équipes de fonctionnalités en dépendent. Mais le plan est toujours sujet à changement lorsque la réalité entre en jeu. Ces équipes doivent donc compter sur leur capacité à communiquer et à collaborer activement et efficacement. Un autre aspect de la communication est la communication entre les équipes et la communication avec diverses parties prenantes, y compris les clients, ce qui favorise les éléments de transparence et de confiance.
Les équipes de composants percutantes que j’ai vues développent leurs modèles de communication au fil du temps, les améliorent régulièrement et les pratiquent religieusement car elles comprennent que la communication n’est pas un choix mais une responsabilité sérieuse.
Les sessions rétrospectives offrent un espace essentiel à ces équipes pour revenir sur leurs styles de communication et leurs lacunes, afin d’identifier les actions correctives. Les commentaires des équipes dépendantes et des parties prenantes alimentent davantage le besoin d’amélioration continue.
4. Retravailler c’est très bien
L’intégration de composants avec d’autres couches architecturales exige un remaniement et une refactorisation continus du code, ce qui est parfois très fatiguant et peut finir par être démotivant pour les équipes normales. Mais les équipes de composants savent bien qu’à moins que le composant ne soit entièrement adapté à l’architecture, le travail n’est pas terminé et jusque-là, il n’y a pas non plus de période de repos.
Un état d’esprit de service est souhaité par ces équipes pour demander de l’aide et revenir rapidement autant de fois que nécessaire car personne d’autre ne pourrait faire son travail.
5. Être innovant maintient la course
Une intégration réussie avec d’autres couches architecturales ne signifie pas que le code fonctionnerait bien en production ou que l’utilisateur final serait satisfait des performances ou de l’expérience utilisateur.
Les équipes de composants percutantes gardent les options prêtes en fournissant la meilleure solution tout en travaillant sur d’autres options pour traiter la possibilité de « et si ». J’ai vu que les clients modifieraient les exigences dans les revues d’itération ou que le code serait cassé en raison de problèmes de performances avec les données en direct ou que l’utilisateur final se plaindrait de certains problèmes. Il incombe aux équipes de réparer ce composant dans un délai donné. Par conséquent, après avoir exploré les domaines d’amélioration possibles à l’avance ou identifié les autres options de solution possibles côte à côte, les garderait en tête du jeu et permettrait l’architecture dépendante pour le meilleur moment pour commercialiser.
La bonne culture inculquée par les PME avec le soutien de la direction aide l’équipe à s’adapter à l’état d’esprit consistant à penser à l’avance dans le jeu et à rester prête avec les options.
6. Pilotez avec des pratiques d’ingénierie
Les équipes percutantes adoptent les pratiques d’ingénierie qui les aident à tirer parti de l’intelligence collective des équipes, offrent un avantage en matière de qualité et de vitesse, et leur permettent de rester au courant des derniers événements dans le monde technologique. La programmation en foule, la programmation en binôme, le TDD et l’intégration continue sont quelques-unes des pratiques couramment adoptées par les équipes de composants. Ils explorent en permanence de meilleures façons de travailler sur des plates-formes open source et assurent la liaison avec la communauté mondiale pour des pratiques éprouvées à essayer.
Des équipes composantes pourraient être formées au fur et à mesure des besoins et n’importe qui pourrait avoir l’opportunité d’en faire partie. Avoir compris et assimilé le bon état d’esprit se reflète dans les comportements et le style de travail des équipes qui garantissent le bon impact sur la solution et donc sur la valeur globale de l’entreprise.