Traiter avec le développement de logiciels n'est pas la chose la plus propre et la plus facile. Il englobe une myriade de questions, techniques et non techniques. L'aspect technique est sûrement beaucoup plus complexe et nécessite des compétences pointues, mais en même temps peut être géré d'une certaine manière, en utilisant les bonnes tactiques et les bons outils. Le monde non technique, en revanche, a beaucoup plus de degrés de liberté. Il a la même variabilité et imprévisibilité que la nature humaine. Comme pour tout autre processus de fabrication de produits, un certain nombre de bonnes pratiques ont été mises en place et testées depuis les premières années de l'aventure du développement logiciel. Les méthodologies agiles sont un ensemble de différentes façons de faire face principalement à l'extrême variabilité des exigences, ainsi qu'au manque de concentration sur les objectifs les plus importants pour livrer le produit final. Parfois, ces méthodologies vont au-delà de leur objectif initial et le résultat net est loin d'être idéal. Scrum fait partie de ces méthodologies. Il est davantage décrit comme un cadre. Il est basé sur un ensemble de base de principes, de règles, d'événements et de rôles. Nous expliquons dans cet article comment ce cadre peut être utilisé avec jugement et flexibilité et éviter certaines interprétations strictes qui pourraient être loin d'être idéales. Introduction très brève à Scrum Les reposent sur les principes généraux suivants, définis dans le soi-disant « Manifeste Agile » : méthodologies Agiles "Individus et interactions sur processus et outils" "Logiciel de travail sur une documentation complète" "Collaboration client plutôt que négociation de contrat" "Répondre au changement en suivant un plan" (Source : ) Manifeste Agile Selon le Manifeste Agile, dans les déclarations ci-dessus, alors que les éléments de droite sont importants, ceux de gauche le sont davantage. Du point de vue du processus de développement, les méthodologies agiles impliquent toutes un processus itératif et incrémental au lieu du modèle Waterfall classique : l'ensemble du développement est constitué d'un certain nombre d'étapes incrémentales, et chaque étape est constituée des mêmes phases qui caractérisent tout un projet Waterfall : un recueil d'exigences, une analyse, une conception et un codage. C'est-à-dire que chaque étape représente un incrément dans l'ensemble du développement et peut être considérée comme un projet à part entière. La méthodologie peut être vue comme une déclinaison particulière des principes ci-dessus. Scrum est un cadre dans lequel une équipe peut utiliser ses propres processus pour développer un produit logiciel spécifique. Il se caractérise essentiellement par , et . Scrum des rôles des événements des artefacts Les sont : rôles : elle peut comprendre des analystes, des développeurs, des testeurs, et en général tout type de professionnel impliqué dans le projet. Il est censé fonctionner de manière auto-organisée dans les limites des sessions de planification Scrum. L'équipe : il coordonne tous les processus Scrum, organise les réunions, etc. Le Scrum Master : il a la responsabilité du produit. Il gère le soi-disant , qui contient toutes les fonctionnalités requises exprimées de manière claire. Il peut en discuter avec l'équipe, recevoir de l'aide de celle-ci, mais il en est le seul responsable. Le Product Owner Product Backlog sont : Les événements : représente un incrément unique dans le développement itératif. Il a généralement une durée de deux semaines à un mois. Le Sprint : c'est une réunion d'une durée maximum de 4 heures pour les Sprints de deux semaines et de maximum huit heures pour les Sprints d'un mois. Il est organisé et programmé par le Scrum Master et inclut l'équipe et le Product Owner. Lors de cette réunion, un certain nombre de fonctionnalités du sont sélectionnées, évaluées et discutées pour être développées dans le Sprint actuel. Les fonctionnalités sont sélectionnées en fonction de leur priorité. Sprint Planning Product Backlog : ce sont des réunions quotidiennes d'une quinzaine de minutes maximum. Ils sont planifiés par le Scrum Master. Lors de ces réunions, chaque membre de l'équipe décrit ce qu'il a fait pour mettre en œuvre les tâches en cours, les problèmes survenus et comment surmonter les difficultés éventuelles. Le Scrum master s'occupe de la planification et de la coordination de ces réunions et de leur bonne exécution. Daily Scrum Meetings : c'est une réunion à la fin du printemps en cours. Cela prend deux heures pour les Sprints de deux semaines et quatre pour les Sprints d'un mois. Il est organisé par le Scrum Master et les participants sont l'équipe Scrum, le Scrum Master, le Product Owner et toutes les parties prenantes requises selon la décision du Product Owner. L'augmentation actuelle est discutée. Ce qui s'est bien passé et ce qui s'est mal passé est décrit, et à la fin, le Product Backlog est mis à jour si nécessaire. La Sprint Review : c'est une réunion d'une heure pour les Sprints de deux semaines et de deux heures pour les Sprints d'un mois. Elle a lieu juste après la revue de Sprint et avant la prochaine planification de Sprint. Au cours de cette réunion, basée sur l'expérience de la dernière itération, toutes les actions d'amélioration et de qualité du produit final sont discutées et planifiées pour le prochain Sprint. La Rétrospective Sprint sont : Les artefacts : c'est un document évolutif contenant toutes les exigences du produit. Chaque élément est appelé User Story et possède des attributs tels que la description, l'ordre, l'estimation et la valeur. Les éléments d'ordre supérieur sont plus clairs et plus détaillés. Product Backlog : il contient les éléments du Product Backlog sélectionnés pour le prochain Sprint combinés avec le planning nécessaire. Sprint Backlog : comme nous l'avons dit plus haut, une User Story est un élément du Product Backlog. Une User Story suit une structure textuelle commune : " <type d'utilisateur>, <effectuer une tâche>, <je puisse atteindre un objectif>. Elle doit également avoir un certain nombre de critères d'acceptation, chacun avec le schéma suivant : <une condition préalable>, <l'utilisateur effectue une tâche> <un changement d'état du système se produit>. User Story En tant que je veux afin que Étant donné Lorsque Alors : c'est un graphique dans lequel l'axe horizontal représente le temps et l'axe vertical la quantité de travail restant à faire pour chaque étape dans le temps. La quantité de travail peut être mesurée par ce qu'on appelle . Le Story Point est une unité de mesure du travail qui prend en compte toutes les variables pouvant influencer le travail de développement, telles que les compétences, la complexité, les outils, etc. Burn-Down Chart les Story Points : il s'agit de l'incrément total jusqu'à présent, c'est-à-dire la somme des éléments complétés jusqu'à présent plus tous les autres éléments déjà complétés dans les itérations précédentes. Incrément du Product Backlog Ne confondez pas Scrum avec une certaine forme de doctrine Vous pouvez considérer les éléments énumérés ci-dessus comme une base sur laquelle un ensemble de professionnels peut fonctionner. Ils peuvent être vus comme un outil utile mais ce qui apporte vraiment la cohésion, l'intercommunication et l'efficacité dans un projet, ce sont les personnes elles-mêmes. Le fait est que, même avec toutes ces prescriptions strictement suivies et tout l'engagement du Scrum Master, un projet peut sombrer dans le chaos et échouer lamentablement. En effet, les gens confondent souvent les règles, les méthodologies et les cadres avec une sorte de moteur divin censé conduire les humains sur la bonne voie. C'est un défaut psychologique courant. Une considération très importante est que la réalité est différente des théories, et c'est un animal très complexe et sauvage. Si vous pensez que vous pouvez l'apprivoiser avec une liste de règles et de modèles, vous êtes voué à l'échec. Le véritable objectif de Scrum est de minimiser la quantité de "bruit de fond" dans le processus de développement et d'améliorer la concentration sur les choses les plus importantes. S'il est utilisé avec la bonne flexibilité et la modestie, il peut être efficace pour le faire. Dans la section suivante, je décris un cas d'utilisation réel, dans lequel j'ai fait un voyage dans le monde de Scrum. C'était un voyage de personnes inexpérimentées, moi y compris, désireuses d'adopter les principes agiles de manière cohérente pour la première fois. De nombreux projets dans lesquels j'ai travaillé auparavant ont été réalisés de manière itérative mais sans toute la cérémonie d'un véritable framework agile. Un vrai cas d'utilisation On parle ici d'un cas d'usage réel, dans lequel une adoption loin d'être stricte du framework Scrum avait été faite. Le projet portait sur un système logiciel visant à retracer toutes les activités d'un laboratoire d'anatomopathologie, depuis la collecte des échantillons de tissus et leur traitement en différentes étapes jusqu'à la distribution finale des lames de tissus. Le système devait également être intégré dans des phases spécifiques avec des machines d'automatisation externes, par des pilotes logiciels spécifiques. J'ai participé à ce projet en tant qu'architecte logiciel. J'ai dû collaborer avec le chef de projet afin de définir les principaux problèmes et de concevoir un plan d'architecture de base. Si vous suivez les principes Agiles à l'extrême, penser à l'architecture en amont n'est pas la meilleure des choses. Même la conception architecturale est vue dans un scénario itératif. Dans la plupart des situations, cependant, vous avez toujours besoin d'une base de départ et vous devez en discuter avec toutes les parties prenantes impliquées. J'ai abordé cette étude architecturale préliminaire en essayant d'avoir une séparation claire des contextes, dans une approche structurée basée sur , et . Suivre une telle approche est important pour avoir une séparation claire des problèmes, et aussi pour personnaliser la discussion en fonction du type particulier de parties prenantes. des vues des points de vue des perspectives Une partie de l'architecture discutée était en effet la phase de développement et son organisation. L'entreprise elle-même n'avait pas encore adopté de méthodologies agiles. Néanmoins, en accord avec le manager et les autres personnes impliquées, nous avons voulu combler cette lacune et nous avons choisi de nous inspirer du cadre méthodologique Scrum. Nous n'étions pas du tout formés à Scrum, mais nous étions tous conscients de ses bases. Les principales directives que nous avions en tête pour le projet, à la fois méthodologiques et techniques, étaient : Un ensemble basique de pratiques à suivre, pour se focaliser sur l'objectif partiel et global dans une démarche itérative (Scrum dans notre décision finale). Suivi des activités/sources par des outils d'automatisation. Approche couplée à . Behavior Driven Development des tests unitaires et d'intégration Pratiques Scrum Étant motivés par la nécessité d'appliquer un cadre méthodologique solide mais contraints par notre manque de compétences approfondies, nous avons choisi de reprendre certaines des principales règles de Scrum sans aller trop loin. Tout d'abord, une approche itérative était très importante dans notre esprit. Scrum couvre cela à travers les soi-disant Sprints, que nous pouvons considérer comme des unités de travail itératives. Chaque est censé couvrir un nombre choisi de fonctionnalités du backlog et a une durée spécifique. Sprint Nous avons choisi deux semaines pour la durée de nos sprints. Avant de commencer la vraie affaire, nous avons mis en place un Sprint numéro zéro conventionnel d'une semaine pour faire des travaux préliminaires et des tâches d'organisation. Dans ce Sprint préliminaire, nous avons également écrit la version initiale du backlog, avec toutes les fonctionnalités listées par priorité. Nous n'avons pas adopté une méthode particulière pour évaluer les efforts des tâches, juste une discussion normale entre les membres de l'équipe. Au début de chaque , comme pour les règles Scrum, nous discutions du travail déjà effectué, évaluions tous les problèmes rencontrés, et choisissions les fonctionnalités à implémenter dans le à venir. Sprint Sprint Le chef de projet jouait le rôle du Product Owner, épaulé par un expert du domaine. Cela avait du sens dans la situation spécifique car il n'y avait pas de vrai chef de produit impliqué, et le chef de projet lui-même avait toute la connaissance des exigences du client. Quant au Scrum Master, je l'ai fait pendant un certain temps, puis j'ai passé le rôle à un autre collègue, même si nous n'étions pas tous les deux complètement formés à cela. Notre équipe était hétérogène avec des personnes travaillant dans différentes villes. Nous avons alors été obligés d'organiser une version virtuelle des réunions debout en programmant des appels Skype tous les jours à la même heure. Les réunions duraient environ 15 minutes. Certains membres de l'équipe ont une certaine forme de résistance à cela, peut-être parce qu'ils l'ont interprété comme une forme de contrôle, ce qui n'est pas le cas. Nous avons passé du temps à leur faire prendre conscience du vrai sens des réunions quotidiennes : une brève discussion entre coéquipiers pour se concentrer sur les principaux enjeux, améliorer la communication et trouver des moyens d'améliorer et de faciliter le travail de tous. Pendant un moment, ils n'ont cessé de dire que c'était une perte de temps et une source de distraction par rapport au vrai travail mais au final, nous avons réussi à les convaincre. Suivi des activités/sources par des outils d'automatisation Outre les pratiques méthodologiques, nous avions également besoin d'outils pour résoudre ces principaux problèmes : Gestion des versions du code, suivi de ses modifications et partage de celles-ci au sein de l'équipe. Suivi des activités et résolution des bugs : ce qui doit être fait, qui est affecté à quoi et le statut de celui-ci. Faire correspondre les modifications du code source avec les activités. Le flux d'informations dans un projet est bien trop complexe pour ne s'appuyer que sur des pratiques méthodologiques pour le contrôler. Vous avez besoin d'une solide base d'outils pour faciliter le travail. Plus vous automatisez de tâches, plus vous pouvez vous concentrer sur des choses importantes et produire un meilleur produit. Pour la gestion des versions de code, nous avons utilisé Git car c'est le choix le plus naturel. Git peut être utilisé de différentes manières et nous avons personnellement adopté comme modèle de workflow. Gitflow Pour suivre les activités, nous avons utilisé , qui est une plate-forme générale destinée à la gestion de projet. Redmine Pour traiter la troisième préoccupation, nous avons intégré notre référentiel Git à Redmine de manière à ce que les commits Git puissent être liés à des tickets Redmine spécifiques en utilisant un code d'identification de problème dans le commentaire de commit. De cette façon, nous avions une cartographie complète entre les activités et les unités de travail Git. Approche Behaviour Driven Development couplée à des tests unitaires et d'intégration Nous étions fortement disposés à fonder notre processus de développement sur une approche axée sur le comportement. BDD s'accorde très bien avec Scrum et en général avec les principes Agiles, notamment dans la partie qui concerne la communication. Il permet d'écrire des scénarios de test dans un format compréhensible par des personnes non techniques et, avec les bons outils, donne un rapport visuel de l'état actuel. Il dessine les limites logiques du produit et force le travail de développement à l'intérieur de ces limites. Les tests fonctionnels BDD n'étaient que la couche externe de l'ensemble de l'instrumentation de test. Nous avons également utilisé des tests unitaires et d'intégration. Afin de ne pas être submergé par la complexité d'un tel environnement de développement, nous devions utiliser les bons outils et fonctionnalités d'automatisation. Les principales technologies impliquées étaient : : intégré à Cucumber l'application Spring Boot avec les services REST Autres outils de test : bibliothèques , et Spring Boot pour prendre en charge les tests d'intégration. JUnit Mockito La carte mentale suivante montre un résumé des éléments discutés ci-dessus : Considérations L'adoption de Scrum, même de manière légère et flexible, en valait-elle la peine ? La réponse est oui. Soyons clairs cependant, nous ne pouvons pas le voir comme la solution à tous les problèmes, et s'il est adopté sans comprendre son esprit même, il pourrait même être préjudiciable. L'essence d'une méthodologie est d'offrir un schéma d'esprit collectif pour faire travailler les gens ensemble avec un maximum de partage d'informations et d'engagement, mais si les gens se concentrent sur le respect des règles d'une cérémonie exotique au lieu du travail réel, le but initial disparaît. Une analogie sportive Vous pouvez mieux comprendre ce qui a été dit ci-dessus avec une analogie sportive. Tout le monde n'aime pas le football, mais presque tout le monde a au moins une idée minimale de son fonctionnement. C'est d'abord un jeu collectif. Deux équipes s'affrontent sur un terrain de jeu essayant de lancer une balle dans un but. Pour accomplir cette tâche apparemment simple, ils doivent mêler initiatives individuelles et stratégies et tactiques collectives. Ces stratégies et tactiques sont enseignées à l'avance par l'entraîneur et représentent un pourcentage important du temps total consacré aux séances d'entraînement. Pour être vraiment efficaces, les règles collectives décrites ci-dessus suivies par les footballeurs doivent être exécutées sans effort, et sans même penser qu'elles existent. Ils doivent être automatiques, comme les gestes pour conduire une voiture par exemple. Une exigence de base pour atteindre cet objectif est qu'ils doivent être suffisamment simples pour être entièrement absorbés par tous les joueurs dans le temps limité nécessaire à la préparation du championnat. Si vous vous concentrez sur la cérémonie Scrum plutôt que sur le vrai travail, vous finissez par apporter le chaos au lieu de l'ordre. D'autre part, si vous suivez une approche plus pragmatique, en étant flexible et même en vous débarrassant de toutes les choses qui, dans notre expérience spécifique, ne fonctionnent pas, vous pouvez en tirer le meilleur parti. Vous pouvez même penser à reporter certaines approches Scrum si vous les trouvez difficiles à suivre, puis essayer de les introduire dans une phase ultérieure. Gérer les gérants Insistons sur un concept : les méthodologies agiles et Scrum en particulier, ne peuvent fonctionner que si les membres de l'équipe sont disposés à l'adopter ou au moins conscients de ses avantages. Cela ne peut pas fonctionner s'il n'est introduit que par les managers d'une entreprise pour suivre l'agitation générale et dire au monde extérieur : "Vous voyez ? Nous sommes agiles !". Soyons clairs : si l'objectif est uniquement marketing, il serait préférable de faire semblant de suivre ces méthodologies. Il n'est pas nécessaire d'introduire dans les processus internes une charge qui n'a qu'un but promotionnel. Morale de l'histoire : les méthodologies agiles ne peuvent avoir un impact positif que si elles sont adoptées par les ingénieurs avec les managers et pas seulement imposées par les managers. La plupart des managers, en particulier ceux qui n'ont pas de formation technique, ne savent rien de l'impact d'une méthodologie sur le cycle de vie d'un projet logiciel, contrairement aux ingénieurs, en particulier les ingénieurs seniors. Des années d'expérience valent mieux que les meilleurs livres et les meilleurs cours. De plus, d'après mon étrange expérience dans les entreprises italiennes, les organisations sont souvent dictées par une culture qui semble provenir d'une sorte d'héritage médiéval. Dans ce contexte, les rôles de Scrum Master et même de Product Owner pourraient être simplement considérés comme une source d'autorité dans un cheminement de carrière, plutôt que comme des rôles opérationnels. J'ai expérimenté cette dure réalité récemment, pour dire la vérité. Normalement, ces gens n'ont pas la moindre idée de ce que sont les principes mêmes d'une méthodologie et ne cessent de harceler les gens avec des règles qu'ils ne comprennent même pas. Dans ces environnements horribles, Extreme Programming et Scrum ne sont que des titres dénués de sens. Dans ces contextes les managers sont des sources d'entropie à traiter, et pour atteindre un niveau de productivité décent l'équipe doit gérer son propre travail et même les managers, pour réduire leur mauvaise influence. D'où le titre de cette section : "Gestion des Managers". Équilibre entre la méthodologie, les pratiques de test, les activités de suivi et les outils associés Dans le cas d'utilisation décrit dans cet article, nous avons parlé de méthodologie mais aussi de stratégies de test, de suivi des activités et des outils utilisés pour les soutenir. Les meilleurs cadres méthodologiques ne peuvent pas résoudre à eux seuls tous les problèmes complexes liés au développement de logiciels. En effet, BDD, qui couvre les tests fonctionnels, est un moyen très efficace de partager la connaissance de la logique du système logiciel en cours de développement. Cela crée un lien fort entre tous les membres de l'équipe et le Product Owner, et améliore la concentration sur les aspects les plus importants du projet. Ainsi, il couvre une partie des problèmes que Scrum est censé couvrir. Les tests unitaires et d'intégration, en revanche, sont plus impliqués dans les processus internes des développeurs de logiciels, mais indirectement, ils facilitent la gestion des changements, se couplant bien avec l'approche itérative de Scrum. Conclusion Le développement de logiciels est une question complexe, même dans des projets minimes gérés par un seul développeur. Si un projet a besoin d'une équipe pour être développé, un certain nombre de problèmes d'organisation se posent. Les méthodologies agiles sont une tentative pour résoudre ces problèmes, mais elles ne seraient vraiment utiles que si elles étaient prises comme un grain de sel et en évitant toute forme de grossissement insensé.
