Les cartes mentales sont utilisées pour explorer, clarifier, expliquer ou planifier. Ils sont un moyen efficace de recueillir et de représenter des informations. Il peut s’agir d’informations que nous voulons apprendre ou de connaissances que nous voulons partager. Nous pouvons vouloir nous concentrer sur certains points, comme l’abstraction d’un nombre ou de détails. Alternativement, nous pouvons planifier notre travail à l’avance ou expliquer comment les choses fonctionnent en détail. Remue-méninges et recherche de liens entre différentes idées, résolution de problèmes et création de nouvelles idées, les cartes mentales sont un outil utile dans notre vie professionnelle ou personnelle. Ils vont bien au-delà du développement de logiciels et peuvent être utilisés dans toute entreprise humaine qui nécessite une réflexion critique et une prise de décision.
Une carte mentale peut être tout ce qui organise nos pensées – dessins, diagrammes, tableaux, mots-clés, images, graphiques, Wikipages, etc. Cela peut être fait avec un stylo et un papier, un marqueur et un tableau, ou en utilisant des outils de cartographie mentale comme Coggle, MindMeister, Ayoa, MindNote, XMind, etc.
Un certain nombre de groupes de logiciels avec lesquels j’ai travaillé ont réutilisé des cartes mentales pour publier des fonctionnalités. Les propriétaires de produits, les développeurs et les testeurs ont trouvé un moyen efficace d’éviter de manquer des cas d’utilisation et d’identifier des cas extrêmes. Cela a contribué à la clarification et à la désambiguïsation des exigences, à la testabilité et à l’exhaustivité. La réutilisation des cartes mentales a conduit à des discussions fructueuses, à des décisions éclairées et à un échange d’informations entre les équipes.
Méthode de développement utilisée
Il existe différentes méthodes de développement, comme la cascade, l’agile, le lean, la programmation extrême, le prototypage, le développement rapide d’applications, etc. Il existe également différentes saveurs pour différentes méthodes, tandis que des combinaisons hybrides peuvent également exister. Nous ne nous concentrerons pas sur la méthode, la saveur ou la combinaison qui est la meilleure, mais pour éviter toute confusion, nous devons préciser que cet article suppose une approche agile de toute l’équipe. Les équipes de développement contiennent (au moins) des développeurs et des testeurs, et le travail de l’équipe est divisé en missions. Chaque mission contient des fonctionnalités à publier. Pour chaque mission, un propriétaire de produit est affecté qui se concentre sur les décisions commerciales pour les clients.
Cartes mentales pour différents rôles dans un groupe de logiciels
Propriétaire du produit
Le propriétaire du produit aide les clients à définir les exigences fonctionnelles et non fonctionnelles. Après tout, ce rôle essaie de tirer le meilleur parti des équipes de développement dans chaque mission en remplissant toutes les exigences. Cela implique que tous les membres de l’équipe poursuivent un objectif commun, établissant des priorités afin qu’ils travaillent sur la fonctionnalité la plus appréciée. Des décisions sont également prises qui conduisent à un bon retour sur investissement par mission. Quelle est la valeur fournie par fonctionnalité ? Quelle fonctionnalité est la plus importante pour un ensemble de fonctionnalités donné ? Quelle fonctionnalité doit être développée en premier, laquelle en second et ainsi de suite. Qu’est-ce que le client a demandé ?
Une carte mentale d’un propriétaire de produit peut être par fonctionnalité, ou elle peut impliquer plusieurs fonctionnalités ou l’ensemble de la mission. Cela dépend de la taille de l’entité et de la portée de la carte mentale.
Taille
Pour analyser et expliquer de grandes fonctionnalités qui contiennent beaucoup de fonctionnalités, il faudra plus d’espace sur un tableau. Lorsque de nombreuses fonctionnalités importantes sont placées dans la même carte mentale, les choses peuvent devenir difficiles à comprendre. Lorsqu’une carte mentale contient des tonnes d’informations, il est facile de manquer des détails et les gens se découragent généralement de l’utiliser. Cependant, lorsque la portée d’une carte mentale est de décrire les fonctionnalités fournies au cours d’une mission entière, si de grandes fonctionnalités sont impliquées, des décisions prudentes devront être prises sur ce qu’il faut résumer.
Portée
Une carte mentale décrivant les interdépendances au niveau de l’entreprise entre différentes fonctionnalités n’inclura probablement que les fonctionnalités interdépendantes. Une carte mentale se concentrant sur une fonctionnalité et ses sous-fonctionnalités fera probablement abstraction de toutes les autres fonctionnalités. Une carte mentale axée sur les aspects de sécurité des fonctionnalités fournies ne décrira probablement que les fonctionnalités impliquées dans les cas d’utilisation de la sécurité. C’est le contexte qui doit être clarifié en ce qui concerne un Product Owner.
Développeur
Les développeurs ont besoin de clarté et d’exhaustivité sur ce qui doit être mis en œuvre. Ils décident comment écrire le code d’implémentation et leurs tests. Sur la base des cartes mentales du propriétaire du produit, ils peuvent créer leurs propres cartes mentales. C’est au développeur de décider quelles informations doivent être représentées (la portée de la carte mentale). Est-il utilisé pour clarifier les interdépendances de code ? Est-il utilisé pour expliquer comment les choses fonctionnent? Est-il utilisé pour décrire ce qui a été testé unitaire et ce qui ne l’a pas été ? Est-il utilisé pour demander des éclaircissements aux propriétaires de produits ? Est-il utilisé pour décrire des zones spécifiques du code qui nécessitent l’attention des testeurs ?
Cartes mentales entité-relation
Les entités et leurs relations sont un moyen fondamental d’analyser les systèmes logiciels. Les entités peuvent être spécifiques au domaine dans lequel nous travaillons, comme les factures pour les systèmes comptables, les articles dans les systèmes d’inventaire, les nœuds dans les systèmes de gestion de réseau ou les amis dans les réseaux sociaux. L’exploration des entités et de leurs relations dans une carte mentale a aidé les équipes de développement et de produit à s’aligner sur ce qui doit être développé. Il a également aidé les testeurs à identifier les cas extrêmes et à réfléchir avec les développeurs sur les goulots d’étranglement des performances.
Cartes mentales de transition d’état
L’identification des événements qui déclenchent des transitions entre états est une autre façon d’analyser les systèmes logiciels. Par exemple, un événement de connexion peut avoir déclenché la transition d’un état déconnecté à un état d’autorisation puis à un état connecté. Les états peuvent être directement contrôlés par l’interface utilisateur et faciles à identifier comme connecté/déconnecté. Ils peuvent également être subtils, déclenchés par le passage du temps (par exemple, les minuteries de notre système logiciel ont expiré) et sont incontrôlables par l’interface utilisateur, comme l’autorisation. Les cartes mentales décrivant les états et leurs transitions peuvent être utiles pour la mise en œuvre et le débogage. Ils peuvent également aider à identifier les cas extrêmes et à reproduire des bogues sporadiques.
Testeur
Ce rôle essaie de s’assurer que les bogues sont trouvés et corrigés avant de publier les fonctionnalités pour les clients. Après la sortie, les testeurs essaient de vérifier que l’évolution des fonctionnalités suit certains critères de qualité. Les testeurs créent et exécutent des tests (UI ou API) à partir des exigences. Les cartes mentales des propriétaires de produits ainsi que des développeurs pourraient être très bénéfiques. Un propriétaire de produit inclura les fonctionnalités qui doivent être publiées. C’est excellent pour la conception de cas de test dans les tests de boîte noire.
Certaines équipes de développement ont créé des cartes mentales pour décrire ce qui a été testé au niveau de l’unité. Cela indiquait aux testeurs ce qui avait été testé et ce qui ne l’avait pas été. Les testeurs peuvent augmenter les cartes mentales de développement pour donner un sens à ce qui doit être testé. Ici se trouvent les informations de test de la boîte grise.
Il y a eu des cas où les développeurs ont partagé des cartes mentales décrivant des zones de l’interface utilisateur qui nécessitaient l’attention des testeurs. Il s’agissait d’une autre source majeure d’informations sur les tests de la boîte grise. Sur la base de ce type de commentaires des développeurs, les testeurs pourraient concentrer leurs efforts de test.
Cartes mentales des écosystèmes
Un écosystème comprend l’environnement dans lequel vit notre logiciel, toutes les interfaces de notre logiciel et toutes les dépendances externes. Une carte mentale de l’ensemble de l’écosystème pourrait donner une image claire pour enquêter sur les connexions, les dépendances et les risques associés aux parties de notre système qui échappent au contrôle de notre logiciel.
Une équipe a utilisé des cartes mentales de l’écosystème qui décrivaient la façon dont leur logiciel se connectait au monde extérieur. L’accent a été mis sur les interfaces, les utilisateurs et les connexions aux systèmes intégrés.
Une autre équipe a utilisé une carte mentale de l’écosystème basée sur le déploiement. Il s’est concentré sur l’emplacement des composants qui composent leur système, tels que les bases de données, les fichiers de configuration et les exécutables, dans un déploiement de production.
Les cartes mentales des écosystèmes ont aidé les testeurs à concevoir leurs propres cartes mentales de tests positifs et négatifs. Ils ont également aidé les propriétaires de produits à obtenir une vue d’ensemble de leur logiciel et à envisager des cas d’utilisation qui auraient été manqués par rapport aux exigences. Les développeurs ont trouvé des cas extrêmes qui nécessitaient une attention particulière sur leur code.
Emballer
Les cartes mentales sont réutilisables, personnalisables et peuvent être mélangées et assorties selon nos besoins. Ils peuvent être un outil efficace pour échanger des informations et renforcer la confiance entre les équipes pour publier des fonctionnalités. Après tout, il s’agit de s’aligner sur l’objectif commun de rendre les clients heureux.