Ce qui empêche le mise en place d'une transformation agile

Cela fait plusieurs fois que je trouve ce genre d'article sur les réticences à la mise en place de l'agilité, les coachs agiles, comme un peu frustrés par l'empêchement, y donnent leur leçon d'agilité. 

Je pense plutôt que c'est le fait de la société actuelle de ne pas vouloir être agile les coachs en agilité ne pourront rien y faire.

Car il y a une réelle volonté farouche de freiner l'agilité parfois même inconsciente.

Mise en place de l'Agilité en entreprise

Avant même de lire l'article, je le ressens ainsi car l'agilité prône la liberté des acteurs de l'entreprise. Je peux constater que ce n'est pas le cas sur le terrain, ce n'est pas la volonté de certains que de donner de la liberté dans leurs entreprises, croyez-moi ils ont un management totalement différent.

D'autres cadres de travail en agilité, comme SAFe, prône la dilution de la responsabilité vers les équipes. Là encore pour le "petit chef à l'ancienne du management franco/français", c'est exactement le contraire qu'il recherche. Il veut des outils pour mieux contrôler, mieux cornaquer ses équipes et cela, ce n'est pas tout Agile.

Alors regardons ensemble :

Siècle Digital - 5 caractéristiques empêchant la mise en place d'une transformation agile

Dans cet article, j'ai ressenti une grande maîtrise de l'exercice, de l'agilité vécu sur le terrain et le recul nécessaire à la compréhension.

L'agilité se définit comme une culture et des valeurs permettant d'être performant dans un environnement complexe. La direction doit s'impliquer dans le passage à l'agilité sinon point d'agilité.

Les quatre verbes : livrer, communiquer, réfléchir, s'améliorer.

L'agilité chez les éditeurs de logiciel doit être naturelle, intégrée dans l'ADN de l'entreprise. Le logiciel est une chose complexe à produire qui se modifie constamment et doit franchir des marches technologiques aléatoires pour continuer à exister sans quoi il se fige, se sclérose et meurt. 

Le point 3 : On parlait des indicateurs KPI, voilà un écueil de l'agilité la capacité de production comme indicateur. On connait des entreprises qui sont organisée avec leur service Qualité accouplé à la production et qui ne résonne qu'en indicateur, la vélocité comme indicateur du bon fonctionnement d'une équipe met continuellement l'équipe dans le rouge.

Et bien voilà, moi je ne n'ai pas besoin d'aller plus loin car je sais qu'il n'y a plus de culture d'entreprise, les entreprises ne cultivent plus, stressées par la mondialisation, elles ont totalement abandonné l'idée de la création d'une culture d'entreprise.

Voilà, nous venons de voir rapidement les freins à l'instauration de l'Agilité dans l'entreprise.

CQFD !

Le TDD (Test Driven Developement) par la pratique

Alors le TDD est certainement le sujet qui fait couler le plus d'ancre dans le domaine du développement logiciel c'est dernières années avec cette question de base : Faut-il faire du TDD ?

Test Driven Development
Test Driven Development

Il s'agit des Tests et de faire des Tests de façon à ce que ces Tests Drivent (dirigent) le Développement. Les pratiques du TDD sont pratiqués autour d'outils comme les Frameworks de Tests Unitaires

Au delà de TDD, je trouve "Crafts" avec "Craft Developer, software craftsmanship (l'artisant du logiciel).

Wikipédia - Software craftsmanship

Vous trouverez l'historique de la méthode Software Craftsmanship, vous découvrirez également l'Uncle Bob (Robert Cecil Martin) qui en 2008 proposa une cinquième valeur au Manifeste Agile :

"craftsmanship over execution" En français: "l'artisanat plus que l'exécution".

Cette fois lorsque l'on évoque l'amélioration continue, il s'agit de l'amélioration des humains qui deviennent meilleurs en partageant leurs pratiques, en travaillant conjointement et de manière collaborative. Ainsi chaque développeur devient artisan développeur en améliorant ses compétences et en devenant soucieux de délivrer de la vraie valeur.

On remarque l'imbrication du TDD de l'Agilité et de Crafts pour mener vers une méthode logicielle complète et globale, coder comme art de vivre. Le Software Craftsmanship est complémentaire à l'Agilité.

Ils ont tous les deux un manifeste, une somme de travaux réunie dans un document cours et réalisé par les meilleurs professionnels du domaine.

D'après ChatGpt voici les grands principes Software Craftsmanship :

  1. Code propre, facilement compréhensible, bien structuré et maintenable en suivant les principes SOLID.
  2. Test Driven Development (TDD), les artisans logiciels écrivent d'abord des tests automatisés avant de coder la fonctionnalité correspondante.
  3. Pair programming : Deux programmeurs travaillent ensemble pour favoriser l'apprentissage mutuel, le partage des connaissances, l'amélioration des compétences et la qualité du code.
  4. Amélioration continue : Les Softwares Craftsmanship participent à des communautés, assistent à des conférences et partagent leurs connaissances avec d'autres développeurs.
  5. Livraison régulière et itérative : Chercher à fournir des fonctionnalités de manière régulière et fréquente, en se basant sur les commentaires des utilisateurs.

Collaboration et communication : avec les clients, les utilisateurs et les membres de l'équipe.

► Pour une présentation de la méthode TDD :

Blog de Jean-Baptiste Vigneron - TDD ou le développement piloté par les tests

Dans un développement classique on ajoute du Code et puis on ajoute de Test permettant de tester ce code. Dans la méthode TDD on écrit d'abord le Test puis le code qui doit vérifier ce Test.

► Pour en terminer avec cette question de ; faut-il faire du TDD, je vous laisse avec le Podcast de Benoit Gantaume :

Artisan Développeur - TDD sous stress avec Khaled Souf

Et voilà, en partant de TDD, on est passé par l'Agilité, on a poursuivit avec Crafts et Software Craftsmanship, nous avons fait un tour des nouveautés sur les méthodologies modernes de développement logiciel.

N'hésitez pas à commenter.

Programmation et principe SOLID

Pour créer un bon code source, il est souhaitable d'utiliser les principes de la méthode SOLID, voici donc les cinq principes à utiliser absolument (au minimum) dans l'écriture de votre code source :

Single responsability : Une classe pour une seule responsabilité

Open/close : Ajouter de nouvelles fonctionnalités sans modifier la classe grâce à l'abstraction et au polymorphisme en créant des classes de base pour factoriser du code commun à tous les objets

Liskov principe de substitution : Les classes génériques (ou dérivées) peuvent être remplacées par leur classe de base

Interface : Principe de ségrégation d'interface, on ne doit pas dépendre de fonctions dont on n'a pas besoin. On doit définir des interfaces qui n'obligent pas à implémenter des fonctions dont on n'a pas besoin. Il vaut mieux créer plusieurs interfaces et les objets plus complexes devront implémenter plusieurs de ces interfaces

Dependency injection : Les classes de haut niveau ne doivent pas dépendre des classes de bas niveau, les abstractions ne doivent pas déprendre des détails. En créant des interfaces comme des contrats de fonctionnement.

Il y a plein d'autres choses à voir pour écrire du code réutilisable mais avec SOLID, on a un moyen mnémotechnique qui permet d'aborder cinq sujets profonds pour développer du code source.