XA, eXtreme Agility by Adventy

Qu'est-ce que l'eXtreme Agility (XA) ?

XA (eXtreme Agility - Agilité extrême) est une méthode de gestion de projet, mais aussi un cadre de travail, visant l'industrialisation du développement et l'automatisation des tâches. Son objectif est très simple : optimiser le processus de développement et de qualité.

La réussite d'un projet en XA est liée étroitement à la qualité de découpage des fonctionnalités en tâches indépendantes. L'utilisation d'un framework AOP est fortement recommandée, car ce type de framework est parfaitement adapté à l'eXtreme Agility.

Le périmètre de XA se limite à l'équipe, constituée au moins d'un PO, un développeur et un testeur. S'inspirant des principes SoC et SOLID en programmation, une personne ne devrait pas tenir plusieurs rôles (PO, développeur, testeur) dans un même sprint, donc avoir plusieurs responsabilités. Cette configuration ne permet pas une maîtrise et une productivité maximales.

Pour un sprint donné, chacun doit se concentrer sur les tâches qui sont uniquement rattachées à son rôle. Cependant, rien n'interdit de changer de rôle aux sprints suivants, mais pas en cours de sprint.
Un sprint XA est limité au maximum à 3 semaines. La durée idéale observée est comprise entre une et deux semaines. XA encourage la livraison continue qui doit être automatisée, et être effectuée par exemple tous les lundi matins à la première heure.

L'objectif de XA est d'industrialiser chaque rôle, afin que le processus entier soit lui-même industrialisé. Un rôle est fidèle à son propre automatisme de bonnes pratiques (analyse, conception et production). Le perturber par une tâche étrangère provenant d'un autre rôle, risque de casser l'élan de sa productivité, et la reprise peut s'avérer pénible. L'être humain ne démarre pas au quart de tour. Il lui faut du temps pour qu'il se remémore le contexte de la tâche délaissée et de toute sa logique avant de pouvoir se relancer.

XA repose sur une architecture MVA et sur l'automatisme de chaque rôle. En résumé, cette méthode de gestion de projet automatise les compétences, les bonnes pratiques et le code.

Les points de blocage dans un projet agile

XA part du constat qu'il y a encore des points de blocage ou de ralentissement récurrents dans les projets agiles en général. Ces problèmes touchent :

1. la technologie : le choix de la technologie est crucial, car elle constitue les fondations du projet. L'utilisation de technologies hétérogènes complexifie l'environnement technique et nécessite donc plusieurs compétences techniques. La lourdeur de certains langages et/ou frameworks nuit à la performance applicative, ralentit le développement du projet, et impacte négativement le moral de l'équipe ;
2. la pratique de l'agilité : l'important n'est pas de connaître la théorie, mais bien de la pratiquer pour l'adapter à l'équipe et au projet. Malgré cette pratique, la réalité n'est pas ce qu'elle est. Certaines cérémonies sont ressenties comme étant pesantes, voire inutiles. La plupart des développeurs ne comprennent pas, ou ne se sentent pas concernés par ce qui se raconte au daily meeting. L'adhésion de l'équipe à la méthodologie est alors compromise. Le doute et la démotivation s'installent ;
3. le découpage des tâches : La complexité et la durée des fonctionnalités sont souvent sous estimées et sous évaluées. Au lieu d'être découpées en tâches plus simples à appréhender, elles font l'objet de tickets qui peuvent nécessiter un temps de développement (trop) long. L'avancement sur ce type de ticket est flou, et les tâches déjà traitées ne peuvent être testées ;
4. les compétences : la polyvalence est un pré-requis dans un projet agile, plutôt que la spécialisation. L'expertise n'est pas valorisée, ce qui a pour conséquence d'avoir une équipe moyenne qui fait du code moyen. L'autonomie est demandée, et donc chacun fait un peu ce qu'il veut, et non pas ce qu'il doit faire. Les profils juniors sont à peine ou pas assez encadrés, les expérimentés sont rarement bien sollicités selon leur expertise, et l'absence d'un leader technique met inévitablement le projet en péril ;
5. le turn-over : c'est un sujet délicat, mais fait partie de la réalité de l'entreprise. Le turn-over impacte énormément la vie d'un projet. Une ressource en moins peut faire basculer la dynamique de toute l'équipe, surtout si la ressource est très appréciée et est difficilement remplaçable.

Le retour aux fondamentaux

XA a pour ambition la résolution des points bloquants vus précédemment. Et pour cela, cette méthode va s'appuyer sur la logique et l'expérience suivantes : « Un professionnel n'excellera jamais dans son domaine s'il n'a pas d'outil ou les outils adéquats ». Cela signifie que la réussite est fortement dépendante des outils. Mais qu'en est-il pour XA ?

Pour que XA fonctionne au mieux, il lui faut évidemment que l'humain soit au coeur de la méthode : l'équipe. L'équipe, quant à elle, a besoin d'un langage de programmation qu'elle maîtrise, ainsi qu'un framework pour l'aider à développer le projet. Par conséquent, cela revient à dire que XA est dépendante du framework utilisé (si A est dépendant de B, et B de C, alors A est dépendant de C).

Aujourd'hui, très rare sont les projets qui n'utilisent pas de framework. Mais alors où est le problème ? Et pourquoi une équipe agile rencontre-t-elle autant de difficultés avec un framework ?
La réponse est, soit l'équipe agile utilise un framework complexe et/ou lourd, soit le framework n'est pas assez adapté à l'agilité et à l'équipe, ou soit les deux.
L'histoire montre que la méthodologie et la technologie sont 2 branches bien distinctes qui se développent indépendamment, alors que finalement tout est lié. Utilisé un framework (cadre de travail) simple et léger permet de faire baisser des barrières techniques. Par contre, si un framework n'est pas adapté à la méthode agile, alors son architecture doit être revue. En effet, c'est l'architecture qui dicte la manière de développer, ce qui implique que la pratique de développement imposée par le framework ne convient pas ou partiellement à la méthode agile, et par conséquent ne correspond pas à celle du développeur non plus.
Pour résoudre ce problème, il faut partir du développeur, et trouver le point commun entre tous les développeurs. Une chose qui semble bien difficile, mais la réponse est en fait très simple : les bases de la programmation.

Dans les grandes lignes, les bases de la programmation sont d'abord de connaître la syntaxe d'un langage, ses instructions, ses possibilités, et avoir un minimum de pratique. Dans les pratiques de base, il y a la création de fonctions pour un langage procédural, et la création de classes et de méthodes pour un langage orienté objet. Pour simplifier, un développeur sait créer une classe et une fonction/méthode. C'est le niveau débutant. Ajouté à cela, le framework MVC (architecture la plus répandue) est aussi une base adoptée dans le monde de l'entreprise, car aujourd'hui, plus personne ne développe sans framework.

Les problématiques de l'architecture MVC

Pour rappel, l'architecture MVC (Model - View - Controller) est un design pattern (bonne pratique) qui permet d'organiser le code source, et ainsi de séparer le code en 3 rôles :

1. le modèle (Model) : contient le code métier. Il accède aux sources de données en utilisant un ORM, un design pattern tel que le DAO, ou directement un driver de base de données ;
2. la vue (View) : partie visible retournée à l'utilisateur. Etant donné que la vue peut être une combinaison de HTML, CSS et Javascript, elle est plus technique qu'elle y paraît, surtout lorsque la page est complexe et qu'il faille gérer des événements asynchrones ;
3. le contrôleur (Controller) : traite les actions de l'utilisateur et sert d'intermédiaire entre le modèle et la vue. Par méconnaissance de ce rôle ou pour une question de facilité, le contrôleur est souvent amené à contenir un mélange de code métier, de code applicatif et de code transversal.

Chacun de ces rôles est une préoccupation (principe de SoC – Separation of Concerns) et a une responsabilité unique. Avec de la pratique et de l'expérience, il est aisé de voir que cette architecture peut être améliorée, afin d'encadrer et d'aider encore plus le développeur, et donc de lever des points de blocage.
Les mauvaises pratiques ci-dessous sont fréquentes et sont à bannir du MVC :

1. dans le modèle : le développeur confond modèle et contrôleur, et de ce fait, le code métier se retrouve au niveau du contrôleur au lieu du modèle. Le modèle est aussi, et doit être le seul point d'accès aux sources de données. Cependant, dans la pratique, il arrive de trouver des accès aux sources de données depuis le controller, voire même depuis la vue ;
2. dans la vue : les langages HTML, CSS et Javascript sont utilisés. Il devient alors évident qu'un développeur côté serveur ne sera pas très à l'aise dans cet environnement technique. Et même si ce n'était pas le cas, créer un code spaghetti est tellement tentant, sans compter qu'il peut aussi y avoir du traitement métier écrit avec un langage du côté serveur (ex : PHP, Java, etc.) ;
3. dans le contrôleur : il échange avec le modèle, puis communique les données à afficher à la vue. En principe, le contrôleur ne contient que très peu de code, mais ce n'est souvent pas le cas, car le développeur y met le code métier pour ne pas à devoir créer un modèle.

En plus de ces mauvaises pratiques, le code n'est pas testable unitairement, et probablement pas réutilisable non plus.

Pour répondre aux défauts de l'architecture MVC, il y a l'AOP (Aspect Oriented Programming - Programmation Orientée Aspect). Ce paradigme est une technique de programmation basée sur le SoC, invitant à la programmation modulaire pour favoriser la transversalité et la réutilisation de code. De cette technique, l'architecture MVA (Model - View - Aspect) est née.

La solution de XA : AOP et MVA

XA propose d'industrialiser tout ce qui peut être industrialiser, de la méthode au code. Pour arriver à un tel résultat, il faut d'abord que le cadre de travail (framework) puisse le permettre. C'est le rôle du framework AOP fondé sur l'architecture MVA.

Qu'apporte la nouvelle architecture MVA ?

Côté modèle :

Son rôle est amélioré par rapport à celui du MVC. Dans le MVC, le modèle et le contrôleur sont assez mal utilisés et confondus. L'architecture MVA propose les solutions suivantes :

1. dans le MVA, le modèle et le contrôleur sont fusionnés pour ne former plus que le modèle, et ainsi le problème est résolu ;
2. le contrôleur existe toujours, mais a été automatisé. Le développeur n'a plus à l'utiliser, ni à s'en soucier. Le contrôleur sert toujours d'intermédiaire entre le modèle et la vue, en plus de gérer les fonctionnalités natives et transversales en toute transparence, telles que les transactions, l'internationalisation, et la communication entre toutes les couches ;
3. l'accès aux source de données n'est possible que depuis le modèle, et il n'est pas autorisé d'y accéder depuis la vue ou les autres couches, du moins nativement ;
4. l'action de l'utilisateur est (doit être) découpée en sous-tâches par le principe de SoC. Chaque sous-tâche gère sa propre préoccupation et devient indépendante, et donc réutilisable. Concrètement, une sous-tâche correspond à une méthode de classe, soit un aspect, ce qui est largement à la portée de tout développeur ;
5. les méthodes obtenues ont chacune leur responsabilité. Elles n'ont pas de dépendance entre elles (sauf les propriétés de classe), et sont donc facilement testable unitairement.

Côté vue :

En faisant appel aux principe de SyC (Sort your Code) et de SoC (Separation of Concerns), chaque langage (CSS, HTML, Javascript) possède son propre fichier de vue, et par action utilisateur (ou par requête HTTP). Un fichier de vue est facultatif s'il n'y a aucun code. Cette pratique apporte les solutions suivantes :

1. les langages côté client ne sont plus mélangés. Le code est plus clair et plus simple à comprendre ;
2. les fichiers de vue sont sous forme de module, et par conséquent peuvent être réutilisés dans d'autres vues ;
3. le code des fichiers de vue peut être généré dynamiquement à l'aide d'un langage côté serveur (ex : PHP, Python, Java) ;
4. quant au CSS, il n'y a plus besoin de préprocesseur CSS tel que LESS ou SASS.

Côté tisseur d'aspect :

La particularité de l'AOP est le tisseur d'aspect. Il y en a un par action utilisateur. Le tisseur d'aspect exécute de façon séquentielle les méthodes définies dans le modèle. Sa grande force est de pouvoir insérer un traitement (appel de méthode) avant ou après un autre traitement. La suppression ou le remplacement d'un traitement est tout aussi permis.

Le tisseur d'aspect est un fichier déclaratif, c'est-à-dire qu'il n'y a aucun code. Cette technique permet un traitement automatisé du fichier. Par conséquent, le test unitaire sur le tisseur d'aspect n'a aucun sens. Les tests unitaires ne s'appliquent que sur les méthodes du modèle uniquement.

Les rôles définis par XA

Les acteurs d'un projet en XA sont identifiés par leur rôle. Chaque rôle correspond à une responsabilité précise afin d'en limiter le champs d'action. Un rôle est donc spécialisé pour répondre à un besoin bien ciblé. Ce schéma améliore la productivité et met l'accent sur l'expertise contrairement aux autres méthodes agiles.

Les rôles principaux qui se dégagent dans un projet en XA sont :

1. le client : tout débute par le client. Le client n'est pas considéré comme acteur dans un projet XA, mais il est important de le mentionner pour donner la raison d'être de l'équipe XA.
   Le client est le représentant des utilisateurs finaux. C'est lui qui est à l'origine du produit à développer. Le client définit et priorise les fonctionnalités. Il est responsable de la validation des fonctionnalités en recette, ainsi que celle du produit final. Il est en contact direct avec le PO seulement, afin de ne pas perturber les autres membres de l'équipe XA ;
2. le PO : le PO est la tête pensante de l'équipe XA. Il est formé sur le produit par le client, et le représente. Il planifie avec le client la livraison des fonctionnalités. Le PO n'est pas un profil technique mais fonctionnel, bien que cela puisse aider. Le pré-requis est la connaissance du produit. Le PO est un tisseur d'aspect, et sa responsabilité est multiple :
   • il recueille les besoins auprès du client ;
   • les fonctionnalités sont priorisées ;
   • une de ses plus délicates tâches consiste à analyser puis à découper les fonctionnalités en aspects. Un aspect est une fonction/méthode sans dépendance dans le but d'être réutilisable dans d'autres fonctionnalités ;
   • l'aspect obtenu est décrit dans un ticket de façon détaillée afin qu'il n'y ait aucune interprétation possible. Le ticket d'aspect sert de spécification détaillée, mais également de documentation ;
   • le PO doit aussi créer un autre ticket pour le tissage des aspects, qui y définit les aspects composant la fonctionnalité. Ce ticket de tissage des aspects lui est affecté, alors que les tickets d'aspect sont à destination du développeur ;
3. le développeur : le développeur est un créateur d'aspect et est l'élément productif de l'équipe XA. Il prend un ticket d'aspect et écrit le code source qui répond à la problématique de l'aspect, ainsi que les tests unitaires. Ni plus, ni moins. En effet, le plus gros du travail a déjà été réalisé par le PO, c'est-à-dire le découpage des fonctionnalités en aspects. L'eXtreme Agility industrialise le travail du développeur :
   • dans un projet agile traditionnel, les points bloquants sont souvent causés par l'incompréhension fonctionnelle ou des fonctionnalités trop complexes à mettre en oeuvre. Avec XA, ce n'est plus le cas. Celui qui connaît le mieux le produit, c'est le PO. Ce dernier devient le facilitateur fonctionnel en décomplexifiant les problématiques, puis en découpant les fonctionnalités en aspects ;
   • l'aspect est une notion simple et élémentaire à comprendre pour le développeur, puisque cela correspond à une fonction/méthode. De ce fait, un nouveau développeur intégrant l'équipe XA sera immédiatement opérationnel, même sans avoir eu connaissance du fonctionnel, du produit ou de l'application ;
   • le développeur ne se concentre uniquement que sur une seule préoccupation (aspect) à la fois. A ce niveau, les points bloquants deviennent extrêmement rares. Le périmètre de difficulté est réduit au développement d'une fonction/méthode. Le travail s'en trouve donc simplifié. Le développeur gagne du temps, ce qui lui permet d'écrire les tests unitaires ;
4. le testeur : le rôle du testeur est important, mais est souvent négligé par manque de ressource ou de budget. Le testeur est une personne généraliste, qui connaît la technique sans avoir les compétences d'un développeur, et est formé sur le produit sans être PO. Sa force dans le projet repose sur sa rigueur et son sens aiguë de la qualité :
   • le testeur est l'oeil objectif de l'équipe XA. Il contrôle le travail du PO et du développeur, et alerte dès qu'une incohérence ou une erreur est rencontrée ;
   • il vérifie les tests unitaires livrés par le développeur. Et si besoin, il rédige les cas de test manquants, puis les notifie au développeur afin que ce dernier puisse compléter les tests unitaires. Les tests unitaires sont de portés aspect (fonction/méthode) ;
   • le testeur contrôle la cohérence du tissage des aspects créé par le PO. Il s'assure également que la fonctionnalité produit le résultat attendu. Ces tests sont de portés tisseur d'aspect (assemblage des aspects = action utilisateur = requête HTTP), et sont automatisés de la même manière que les tests unitaires.

Dans un projet en XA, il est assez fréquent de voir le PO assumer aussi le rôle de testeur. En effet, qui mieux que le PO peut savoir ce qu'il faut tester et le résultat souhaité. Dans ce cas, à quoi sert alors le testeur ?
Le testeur doit être une personne à part entière, en plus du PO et du développeur, pour les 3 raisons évidentes suivantes :

1. le développeur teste déjà implicitement son code, en plus du test unitaire. Lui demander de retester ses livraisons ou le travail d'un autre développeur n'a aucun sens, puisque les tests unitaires témoignent déjà de l'existence d'un test minimum. De plus, le développeur ne peut pas être totalement objectif sur la qualité et le bon fonctionnement de son code. Il a sa propre logique de test, et suivra toujours le même chemin pour faire ses tests. Même avec la meilleure volonté, il peut oublier des cas de test, par habitude ou par manque de temps ;
2. le PO ne va pas tester chaque aspect individuellement. Cette tâche appartient au développeur. Ce que le PO va tester, c'est la fonctionnalité entière (action utilisateur), après avoir tisser les aspects. Dans ce cas de figure, le schéma est identique à celui du développeur qui teste son propre code. Le PO ne sera pas non plus objectif sur le fruit de son travail ;
3. le testeur est la dernière barrière avant la mise en production. Il décharge le développeur et le PO des tests plus approfondis afin de permettre à ces derniers de faire ce qu'ils savent faire de mieux. De façon objective, le testeur apporte son expertise de la qualité et son expérience de l'OWASP. De plus, il est capable de compléter et d'automatiser les tests. S'il y a vraiment une faille dans une fonctionnalité, le testeur est le plus apte à la trouver.

La philosophie de XA

L'eXtreme Agility doit respecter certaines valeurs. Ce sont ces valeurs fondamentales qui maintiennent l'équilibre fragile entre les différents membres de l'équipe, le produit et le client :

1. la simplicité : le MVA (Model - View - Aspect) est une architecture qui sépare naturellement les préoccupations pour devenir des aspects. Concrètement, un aspect est une fonction/méthode. Le développeur traite aspect par aspect, donc fonction/méthode par fonction/méthode, ce qui réduit considérablement sa compréhension à une seule problématique à la fois. Et rien n'est plus simple pour un développeur, que d'écrire du code séquentiel dans une fonction/méthode. L'utilisation d'un framework AOP est donc indispensable dans un projet en XA ;
2. l'autonomie : l'autonomie est un pré-requis, ce qui signifie que chaque membre de l'équipe sait ce qu'il a à faire, et au moment où il doit le faire. Le PO connaît le produit, et indique au développeur les aspects à créer. Le développeur implémente les fonctions/méthodes, puis les livre avec les tests unitaires. Si un nouveau développeur est intégré à l'équipe, il lui est juste demandé de savoir développer une fonction/méthode. C'est la base de la programmation. La connaissance fonctionnelle du produit n'est que facultative. De ce fait, le nouveau membre de l'équipe est immédiatement opérationnel, et est donc autonome ;
3. le partage : la veille, la connaissance et l'expérience forment les 3 piliers du savoir. Ce partage permet de hisser techniquement les moins expérimentés vers le haut, mais aussi l'occasion pour les plus expérimentés de faire de la pédagogie, et de connaître les points techniques bloquants et/ou les incohérences fonctionnelles. Cette dynamique encourage l'échange, la communication et la motivation, aussi bien techniquement qu'humainement. Dans une équipe en XA, il y a toujours un leader technique qui veille au respect des normes de développement, à la faisabilité et à la solution technique, ainsi que la montée en compétence technique de l'équipe ;
4. l'entraide : c'est l'esprit d'équipe. Ce n'est pas un individu qui avance seul, mais tous les membres de l'équipe. Tout le monde avance, ou c'est personne : principe binaire, du tout ou rien. Qu'un développeur avance beaucoup plus vite qu'un autre n'a aucune importance. Les échecs, comme les succès sont partagés. La clé du succès ne réside pas seulement dans la technique, mais aussi grâce à une équipe soudée, dans laquelle chacun est à l'écoute des uns et des autres, et peut s'épanouir à son rythme, dans un environnement agréable et de bienveillance ;
5. la qualité : cette notion de qualité désigne la qualité de code, la performance et la fiabilité du produit. La qualité est le résultat des 4 premières valeurs de XA citées précédemment (simplicité, autonomie, partage, entraide). Le projet s'appuie sur un framework AOP qui simplifie à la fois le développement et la gestion de projet. Par ses qualités humaines et techniques, l'équipe n'a plus qu'à mettre la main à la pâte, mais de façon plus sereine. Le rôle de chacun est bien défini, ainsi que son périmètre d'action. Les tâches sont claires, précises et en plus faciles, ce qui laisse le temps de faire mieux, donc de la qualité et des tests unitaires.

Conclusion

L'AOP (Aspect Oriented Programming - Programmation Orientée Aspect) est une technique de programmation qui a bousculé les habitudes de développement. C'est un retour aux sources de la programmation : l'envie de faire plus simple, plus léger, plus modulaire, plus réutilisable, tout en améliorant la qualité.

Ce paradigme de programmation, par sa pratique, influence :

1. la méthode agile : c'est ainsi qu'est née XA (eXtreme Agility - Agilité eXtrême). Partant du principe que le code est industrialisable et les tests unitaires automatisables, alors la méthode de travail devait aussi l'être. Le PO (Product Owner), le développeur et le testeur sont les composants de la gestion de projet, chacun spécialisé dans une tâche précise ;
2. le modèle « as a Service » (en tant que Service) : à son tour, XA est devenue les fondations de AaaS (Aspect as a Service - Aspect en tant que Service). Le PO devient client en consommant les aspects, et le développeur est un fournisseur d'aspects à la demande.

La qualité humaine et l'expertise sont au coeur de XA. Accepter la différence entre les membres de l'équipe, et la dure réalité du monde de l'entreprise, c'est ce que les membre d'une équipe XA doivent surmonter. Mais c'est également la seule voie qui permet à chacun de s'améliorer et d'être meilleur, aussi bien techniquement qu'humainement. C'est ça, la philosophie de l'eXtreme Agilty.

Si certains sont moteur dans la prise de décision et anticipent les enjeux de demain, d'autres sont déjà à demain et préparent les enjeux du lendemain. L'expérience a montré que la majorité n'a pas toujours raison. Produire plus vite et avec qualité, a toujours été le Graal. Pour l'atteindre, êtes-vous de ceux qui suivent la foule, ou de ceux qui pensent qu'il faut emprunter une autre voie, et tenter celle de XA pour exploiter le potentiel de toute une équipe et enfin passer à la vitesse supérieure ?

Qu'est-ce que l'AOP Qu'est-ce que le MVC ?