Je m'appelle Russ Martin et j'utilise Mendix pendant près de trois ans en tant qu'ingénieur logiciel senior chez Erie Insurance. Nous avons utilisé le Mendix plate-forme pour mener à bien plusieurs projets et ont connu un grand succès. J'aimerais partager les épreuves et les tribulations que nous avons rencontrées lorsque nous avons essayé de passer d'une cascade à une méthodologie de projet agile, ainsi que quelques conseils pour les surmonter.

Présentation de l'Agile à une équipe en cascade

Comme vous pouvez l’imaginer lors de la première introduction du concept d'agilité, il y aura des hésitations et des inquiétudes au début de votre équipe en cascade. C'est normal, car le changement est difficile pour beaucoup de gens, surtout lorsqu'il s'agit de passer à quelque chose d'aussi différent. Les deux plus gros obstacles que nous avons constatés ont été l'introduction des concepts de développement itératif et d'exigences continues.

Dans de nombreuses organisations en cascade, la tendance courante est de concevoir et de mettre en place l'intégralité du projet avant de commencer le développement. Si vous connaissez le modèle en cascade, vous savez que cela implique des mois de collecte des exigences et de sessions de conception avant même qu'une équipe ne puisse commencer à travailler sur le code. Cela crée également une déconnexion entre les disciplines, car l'équipe entière n'est pas impliquée dans ces sessions et nécessite également un transfert de connaissances. Ce processus crée une charge importante et prend beaucoup de temps. Un processus agile est un 180 complet par rapport au modèle en cascade. Lorsque l'on essaie de changer l'état d'esprit des gens pour aller à l'encontre de toute leur formation et de leur expérience antérieures, il y aura de l'appréhension. C'est normal et attendu.

Un processus agile est un 180 complet par rapport à la méthode en cascade. L'appréhension face à ce changement est attendue, voire normale.

Pour surmonter ce problème, j’ai constaté que montrer les avantages de la méthodologie agile aide les gens à voir sa valeur. Commencez par travailler sur une petite preuve de concept. Prenez une petite partie de votre application, ou une partie dont le remplacement devrait prendre beaucoup de temps, et voyez ce que vous pouvez accomplir en quelques semaines. Impliquez au moins une personne de vos différentes disciplines – analyste commercial, ingénieur logiciel, assurance qualité, etc. La raison en est que vous aurez besoin de personnes ayant des perspectives différentes dans votre coin pour influencer ce type de changement. Si vous pouvez amener plusieurs personnes à comprendre la nouvelle méthodologie, il est beaucoup plus facile d’obtenir l’adhésion du reste de l’organisation. Tirez également parti de l’expertise de l’équipe de direction. Mendix équipe. Ils ont l'expérience de ce type de changement de culture. En ayant une personne extérieure là pour répondre à vos questions, vous apportez un niveau de compréhension supplémentaire qui favorise l'adoption.

La clé de cette preuve de concept : LE TRAVAIL D'ÉQUIPE ! Vous allez certainement devoir affronter une bataille difficile. Votre équipe devra participer à un exercice de sprint zéro. C'est là qu'ils rassembleront quelques histoires pour décider de ce qu'ils veulent voir de l'interface utilisateur. En impliquant tous les membres de l'équipe, ils seront plus investis dans le résultat. Ils auront le sentiment d'avoir leur mot à dire dans le processus. Je ne peux pas souligner à quel point cela est important à long terme. Passer d'un processus lourd de documentation à une approche de fiches d'histoire est un concept étranger à de nombreux praticiens de la méthodologie en cascade. Soyez prêt à affronter la résistance des membres de votre équipe, c'est normal. N'oubliez pas que cette preuve de concept est davantage une expérience, un exercice de formation. Il ne s'agit pas d'un projet à part entière qui ira en production, ce qui contribue à apaiser les inquiétudes de nombreux sceptiques. N'oubliez pas du point de vue d'un développeur : si c'est le projet que vous prévoyez d'utiliser à long terme, c'est votre chance de contribuer à jeter les bases du projet complet et de gagner du temps à l'avenir.

La plupart des gens conçoivent trop avant même de commencer. Construisez une Ford avant de passer à une Mercedes Benz.

Un concept que nous avons utilisé pour mettre en avant ce que nous essayions de faire était le suivant : « Nous n’avons pas besoin d’une Mercedes Benz pour aller du point A au point B. Nous devons simplement y arriver. Développons donc la Ford. Ensuite, une fois que nous serons sur la route, nous pourrons nous concentrer sur les améliorations que nous souhaitons apporter à notre véhicule. » Ce concept s’est avéré utile, car la plupart des gens veulent un produit fini. Ils veulent sur-concevoir avant même d’avoir commencé. Commencer à une échelle plus petite permet à vos développeurs de développer la « Pinto », un produit minimum viable qui fait le travail. Montrez ensuite à quelle vitesse vous pouvez mettre à niveau votre véhicule vers la « Cadillac », un produit à part entière avec des caractéristiques et des fonctionnalités améliorées. Cela permet à vos utilisateurs de monter dans la Pinto et de donner leur avis, après quoi vous pouvez leur montrer à quel point il est facile de développer ces nouvelles fonctionnalités.

Passage au travail de projet

En supposant que tout s’est bien passé avec la preuve de concept et que vous avez maintenant le feu vert pour le projet complet, vous pouvez examiner certains éléments que vous pouvez intégrer à votre projet pour faciliter la transition.

Du point de vue de l’analyste d’affaires et de l’assurance qualité, il existe plusieurs éléments que vous pouvez exploiter pour favoriser davantage le processus de compréhension. Nous avons trouvé que les « sessions amigos » étaient extrêmement utiles au début. Une session amigos est une réunion impromptue entre les développeurs, les analystes et les testeurs pour examiner les cartes attribuées à un sprint spécifique. Cela permet à tous les participants de se mettre d’accord sur ce qui est en cours de développement pour chaque carte et offre la possibilité de poser des questions spécifiques sur le travail. Ces réunions doivent être informelles et se dérouler dans un format ad hoc avant le développement. Ensuite, une fois le développement terminé, organisez une autre session amigos pour examiner le codage terminé. Cela permet à chacun de revoir le travail au fur et à mesure de son achèvement. En même temps, cela donne aux développeurs la possibilité de montrer à quelle vitesse ils peuvent s’adapter aux éléments qui doivent être modifiés. Par exemple, un analyste souligne une exigence manquante lors d’une révision finale amigos. Cela permettra au développeur d’effectuer le changement sur place et d’afficher le code corrigé à l’écran, prouvant ainsi aux membres de l’équipe l’adaptabilité de la base de code et le temps de réponse rapide aux demandes de changement. Cela permet aux autres de comprendre ce que vous pouvez faire avec la plateforme. L’objectif n’est pas de les faire durer éternellement. Au début, les évaluations des amis doivent avoir lieu jusqu’à ce que tout le monde se sente à l’aise avec le nouveau processus. À ce stade, vous ne devriez avoir besoin d’utiliser cette technique qu’à la fin du développement de la fiche d’histoire.

Du point de vue de l’assurance qualité, le principal avantage d’Agile est le développement piloté par les tests.

Du point de vue de l'assurance qualité, le principal avantage de l'agilité est le développement piloté par les tests (TDD). Le TDD est un processus bien connu utilisé au sein de la communauté informatique. En utilisant le Module de tests unitaires disponible dans le Mendix Dans l'App Store, les développeurs peuvent créer plusieurs tests unitaires liés à chaque sprint de développement. Le module de test unitaire vous permet également d'exécuter des rapports à chaque déploiement, indiquant si les tests unitaires réussissent ou échouent (et vous aide en tant que développeur à vous assurer que vous n'avez pas créé de nouveau défaut). Cela permet à l'équipe d'assurance qualité de voir que le code est stable et que le code précédemment testé fonctionne toujours. Bien sûr, ils voudront faire leurs propres tests, comme ils le devraient. Mais cette méthode permettra de comprendre que la base de code n'est pas dégradée à chaque sprint terminé. C'est important car ils testeront selon un calendrier itératif plutôt qu'une seule fois à la fin d'un projet. Tout ce que vous pouvez faire pour leur faire savoir que leurs efforts de test n'ont pas été vains est une énorme victoire à long terme.

Du point de vue des développeurs, nous avons constaté que les revues de code étaient cruciales pour la réussite de tout projet. Le raisonnement est simple : plus il y a de personnes qui examinent le code, moins il y a de risques d'erreurs. Cela permet également de mettre en œuvre des normes et des processus de codage pour les développeurs, dont tous les membres de l'équipe peuvent tirer parti. Le fait de pouvoir voir ce que les autres ont fait pour rendre le codage plus efficace peut augmenter votre délai de mise sur le marché. Cela sera également très utile pour les personnes qui s'adaptent lentement à l'agilité. Pourquoi ? Parce qu'elles savent que vous faites tout ce que vous pouvez pour vous assurer que votre équipe crée un code solide et contribuera à réduire le nombre de défauts trouvés dans le système. Moins vous développez de défauts, plus votre équipe se sentira à l'aise avec cette nouvelle approche agile.

Qu'en est-il de la gestion ?

La direction ne se préoccupe pas des détails pratiques du développement de l'équipe, et elle ne devrait pas le faire. Elle se préoccupe davantage des ressources, de la rapidité et de la qualité. Comment pouvons-nous leur fournir quelque chose de concret pour leur montrer que nous développons un excellent système qui est facile à entretenir ? Je recommande vivement d'utiliser le Mendix Outil de gestion de la qualité et de la sécurité.

Nous avons pu fournir des mesures du système avant d'apporter des modifications à la base de code. En procédant ainsi, nous avons pu facilement montrer qu'une idée que nous souhaitions mettre en œuvre apportait de la valeur en augmentant notre score AQM.

AQM exploite l'utilisation de la complexité McCabe en analysant le code validé dans votre référentiel pour déterminer une note sur une échelle de 1 à 5. Pour ceux qui ne connaissent pas la mesure de complexité McCabe, il s'agit d'une mesure logicielle utilisée pour indiquer la complexité d'un programme. L'outil AQM décompose votre base de code en huit catégories différentes. Ces catégories sont également très utiles du point de vue du développement. Elles vous permettent de voir que votre équipe crée des éléments qui ne sont pas trop complexes et qui sont faciles à entretenir. Cela est également utile lors de l'intégration de nouveaux développeurs. Cela permet à l'équipe de voir le niveau de compréhension du développeur et vous permet de signaler facilement où il a pu coder de manière incorrecte. Cela donne l'occasion de leur apprendre la bonne façon de structurer les microflux en fonction des normes de votre organisation.

Et qu'en est-il de la direction ? Nous savons tous que la direction préfère les rapports courts, concis et précis qui fournissent des graphiques faciles à lire à utiliser lors des réunions. L'outil AQM propose plusieurs options de création de rapports qui donnent un aperçu du code en cours de développement. Cela s'est avéré très utile dans notre organisation. Nous avons pu fournir des mesures du système avant d'apporter des modifications à la base de code. En procédant ainsi, nous avons pu facilement montrer qu'une idée que nous voulions mettre en œuvre apportait de la valeur en augmentant notre score AQM. Cette approche nous a également permis de supprimer certains de nos microflux les plus enfreignants en montrant une mesure avant et après à la direction.

AQM vous permet de voir que votre équipe fabrique des articles qui ne sont pas trop complexes et qui sont faciles à entretenir.

Vous pouvez également configurer l'équipe de direction avec des identifiants d'utilisateur afin qu'ils puissent accéder à ces indicateurs et les utiliser dans les discussions au sein de l'organisation. N'oubliez pas : plus vous offrez de confort aux gens, plus l'adhésion sera facile.

Aller de l'avant

Il s'agit d'une approche de haut niveau que j'ai fournie pour vous aider à changer la culture de votre organisation. Sachez que tout ne se passera pas sans heurts. Il y aura de nombreux hauts et bas tout au long du processus. N'oubliez pas que cela en vaudra la peine à la fin. L'utilisation de ces éléments aidera tout le monde à mieux comprendre et à se sentir à l'aise dans le nouveau processus. La cohérence dans la répétition du processus est très utile pour les gens. Plus vous transmettez de choses à votre équipe à chaque sprint, plus elle verra les fruits de son travail. Ces étapes ont considérablement aidé notre équipe de développement à comprendre que l'approche agile peut être extrêmement efficace.