Flashback : BreizhCamp – Jour 3
En complément de l’article de Guillaume Membré sur la 9ème édition du Breizhcamp, je vous propose de vous faire un retour sur la dernière journée. Avec des conférences techniques et non techniques, cette journée a été très enrichissante, remplie de retours d’expérience.
Développeurs et agilité : la guerre est déclarée ?
par Cécilia Bossard,et Jean Paliès
Il s’agissait de faire un état des lieux sur le ressenti de l’agilité entre deux populations : les développeurs et le reste. Le résultat est assez violent : c’est la guerre.
Mais pourquoi parle-t-on de guerre alors que l’un des principes de l’agilité est l’amélioration continue pour tous, le partage, la communication ?
La réponse est assez simple : l’agilité a été détournée.
D’un côté nous avons les développeurs qui clament leur ras-le-bol, on voit même apparaître un mouvement “Programming MotherFucker”, car il y a beaucoup d’intentions, mais très peu de promesses tenues et ils perdent de plus en plus en autonomie.
De l’autre, nous avons les managers et les responsables projets qui se sont appropriés l’agilité pour en faire un processus dans lequel tout est cadré, tracé et finalement les sujets non secs sont poussés. De plus, le choix d’aller vers l’agilité est porté par la direction, car historiquement “ça marche” et chez les autres sociétés cela a été très profitable.
On fait même du business sur l’agilité : mise en place de certifications, des audits, certains parlent de perversion.
Comment sommes-nous arrivés à une telle situation ?
- peut-être que nous avons oublié les douze principes du manifeste agile
- peut-être que cela n’est pas applicable sur tous les projets, à cause des contraintes liées au planning et au budget.
- peut-être que nous avons perdu cette autonomie, cette liberté de choisir
- peut-être que l’on continue à fonctionner sur une hiérarchie pyramidale
Martin Fowler définit le développeur comme un artisan, et la programmation comme un art. On ne force pas un artisan à travailler avec des outils qu’il ne connaît pas. Il va utiliser les enseignements de ses pairs et de ses maîtres. Tout comme l’artisan, l’équipe de développement appliquera les bonnes pratiques qu’elle aura définies, elle se remettra en question et devra réfléchir aux différentes manières de devenir plus efficace.
On comprend alors que l’équipe se doit d’être autonome et auto-organisée, et qu’elle ne doit pas hésiter à expérimenter.
À quoi est due la dérive ?
Pour montrer l’avancement des sujets auprès de sa direction, il faut objectiver l’équipe, il faut mettre en place des indicateurs et il faut les matérialiser.
Mise en place des indicateurs
Les indicateurs ont été mis en place pour répondre aux besoins d’amélioration continue et d’apprentissage, en voici quelques exemples:
- point de complexité
- point de vélocité
- lead time
- des rapports de type burnup ou burndown
Tout ceci repose sur des outils comme Jira, un très bon outil pour un Product Owner ou pour des chefs de projets. Pour les développeurs, cela peut-être utilisé comme support de création de tâches.
⇒ Cela peut représenter beaucoup de processus ou de contraintes pour une équipe de développeurs, des promesses non tenues.
Le rôle du scrum master détourné
Définir des objectifs est un acte tout à fait normal, mais est-ce normal d’objectiver le scrum master (assurer une date de mise production). Il doit être garant du bon fonctionnement du rituel et de l’avancement des sujets. Il ne doit pas se comporter en chef de projet ni imposer ses priorités.
Ne plus être force de proposition
La dévalorisation des sujets techniques, ces sujets sont traités uniquement quand il y a le temps.
Le développeur ange ou démon?
Mais attention, le développeur est aussi responsable de cette dérive “on parle de développeur roi”. Certains se servent de l’agilité ou des principes de l’agilité pour obtenir des passe-droits:
- rajouter des cards Jira dans un sprint déjà en cours,
- livrer à tout bout de champ
Le changement c’est agile, non ?
Comme on peut le voir, il y a plusieurs causes et plusieurs acteurs responsables de cette divergence.
Ce que j’ai apprécié dans cette présentation c’est qu’elle met en avant les divergences des différents acteurs et qu’elle remet l’accent sur les principes fondamentaux de l’agilité.
Pour réussir dans cette démarche, il faut travailler ensemble sans restreindre la liberté des uns, mais tout en respectant le travail des autres.
Il faut que l’équipe partage la même définition de l’agilité. Mais surtout, il est important de se remettre en question afin de savoir où on en est dans l’agilité.
Architecture Hexagonale Level 2 : Comment bien écrire ses tests
par Julien Topçu, Jordan Nourry
Le but de ce live coding était de montrer l’importance des tests dans une architecture hexagonale. Cette démonstration reposait sur une application Spring Boot écrite en Kotlin.
Mais avant de commencer, nous allons définir ce que c’est une architecture hexagonale.
Il s’agit d’un pattern d’architecture qui est apparu dans le milieu des années 2000. Il repose sur la séparation de l’application de trois couches :
- Application (ce qui est visible à l’utilisateur final)
- Domain (couche qui porte toutes les règles de gestions)
- Infrastructure (couche qui assure la connexion aux dépendances externes)
Cette séparation est très importante, car elle permet d’assurer une meilleure évolutivité du code, une meilleure maintenance, une meilleure lisibilité…
De plus, elle nous assure aussi de réaliser des tests plus facilement. On est capable de tester chaque fonctionnalité plus facilement sans charger toutes les dépendances.
Dans ce type d’architecture, nous avons quelques patterns de tests qui pourraient être mis en place pour tester ces différentes couches :
- tests unitaires
- tests d’intégrations (vérifie les interactions entre différents composants)
- tests de composants (permet de tester une fonctionnalité de bout en bout)
- tests de contracts (permet de tester les services qui sont exposés)
- tests de e2e (permet de vérifier le comportement de l’application en effectuant des tests de bout en bout)
À travers ce live coding, les speakers nous ont montré qu’il était facile de faire des tests sur cette architecture sans charger toutes les dépendances
Ils ont présenté les frameworks suivants: Cucumber, AssertJ, Spring Rest Docs, Spring Cloud Contract et Karate.
Outils pour les ComponentTests et les ContractTest
Spring Rest Docs est une librairie intéressante, car elle permet de générer de la documentation au format Asciidoc à partir des tests réalisés sur les controllers “REST”. Ce qui permet de garantir que la documentation générée est toujours à jour et correspond au comportement réel de l’API.
Spring Cloud Contract est une librairie qui permet d’utiliser le pattern “Consumer-Driven Contract”. Elle va permettre de vérifier que le contrat passé entre le consommateur de services et le fournisseur est initialement respecté. Les tests sont donc portés à la fois chez le fournisseur de service et chez le client.
À travers les tests, le fournisseur doit s’assurer que le service implémenté correspond bien aux attentes du consommateur. Si ce n’est pas le cas alors le test échoue et le build aussi.
Côté client, on vérifie que le contrat n’a pas changé. Cela se fait par l’importation d’un stub que le fournisseur aura généré grâce à la librairie Spring. En effet, Spring Cloud Contract permet de générer un stub à partir du build du fournisseur. Cet artifact se retrouvera par la suite sur le nexus, ce qui donnera la possibilité au client de charger la dernière version et de s’assurer du bon fonctionnement.
Outils pour les tests e2e
Karate est un outil permettant de réaliser un enchaînement de tests sur les API Rest, et il s’intègre totalement avec des outils de déploiement continu comme Jenkins. C’est une très bonne alternative aux autres solutions comme Rest Assured, car il est assez simple de prise en main et permet à une population autre que les devs de faire des test e2e.
Liens:
