La taverne du testeur

Le manifeste « Fragile »

Le manifeste Agile est un outil simple, visuel et particulièrement puissant. Son objectif est pour moi assez similaire à celui des 7 principes du test: faire comprendre l’état d’esprit à adopter.

Pour rappel le manifeste Agile c’est:

D’ailleurs, je considère personnellement que le manifeste Agile est un peu comme les 7 principes, du bon sens!

Le manifeste est court, simple mais malheureusement pas assez efficace. Il permet de prioriser des actions à travers des valeurs, se fixer des objectifs mais aussi de boussole pour s’assurer que l’on est vraiment « Agile ».

Car oui, malgré sa simplicité apparente ce manifeste n’est pas toujours suivi ou est mal compris… ce qui entraine de nombreuses problématiques. Je vais explorer dans cet article 2 familles de dérives courantes que j’observe trop souvent lors de l’implémentation de l’Agile dans les équipes.

Le manifeste Agile ignoré

Par « manifeste Agile ignoré » je veux dire par là que 1 ou plusieurs valeurs de « droite » se retrouve mise en avant par rapport aux valeurs de « gauche ». Cette dérive est étonnamment assez fréquente et souvent lié à un fort historique cycle en V et une organisation avec de nombreuses personnes.

Concrètement cela revient à ce type de situation:

  • Les équipes se voient imposer des outils non adaptés ou contre productifs (mettre 8 heures à faire quelque chose qui prend 1 heure sans l’outil (et je l’ai malheureusement vécu personnellement)) car se sont des outils « groupe » ou alors les équipes doivent forcément passer par des processus longs (parfois plusieurs semaines), lourds et à forte inertie (à prévoir plusieurs semaines à l’avance) afin de pouvoir faire un déploiement en production
  • Les US se retrouvent à être des spécifications découpées! Au final, l’équipe Agile se retrouve à être une équipe de développement (car le tests est aussi souvent à part) qui développe de manière incrémentale mais en amont il y a une documentation exhaustive et en aval les tests…
  • La définition du contenu des sprints prévu à l’avance car cela a « été vendu au client pour cette date ». L’équipe se retrouve alors à ne plus être impliquée et totalement surchargée… ce qui induit de la mauvaise qualité et/ou des échecs des livraisons
  • Les demandes récurrentes de « visibilité » sur 6 mois ou 1 an, il faut savoir ce qui sera livré et quand!

Ces points peuvent vous paraitre totalement étrangers et dans ce cas tant mieux. Ils sont malheureusement assez fréquents dans des entités ou équipes qui se disent Agile.

Si vous faîtes face à ces problématiques ou problématiques similaires c’est que votre transformation Agile n’est pas finie et qu’il y a encore des efforts à faire au niveau de l’état d’esprit à avoir en Agile au sein des équipes et de l’entreprise.

Le manifeste Agile caricaturé

On est ici sur une « sur-interprétation » du manifeste. La partie droite disparait comme par magie. Les « plus que » ou « plutôt que » devient subitement « à la place de » ou « mais surtout pas ». Cela revient également à totalement oublier la phrase finale du manifeste:

 » Précisément, même si les éléments à droite ont de la valeur, nous reconnaissons davantage de valeur dans les éléments à gauche. »

Je vois de moins en moins ces dérives mais cela correspond à ce types de dérives:

  • L’équipe est totalement libre est fait ce qu’elle veut. Les outils changent régulièrement (ils peuvent dépendre du membre de l’équipe) et les processus sont inexistants ou ignorés avec, par exemple, l’absence de Defition of Done.
  • Seul le logiciel compte, il n’y a pas de documentation, pas de référentiel d’exigence, seules les US – souvent mal écrites – font foi. Au final la seule vraie connaissance est dans les têtes des membres de l’équipe… qui sont présents depuis le début du développement du produit.
  • Je n’ai pas encore été témoin d’absence de négociation contractuelle et donc pas de dérive de ce point de vue là pour moi! =)
  • Les équipes Scrum se retrouvent à avoir des sprints « mouvants » avec des US qui sont retirées ou ajoutées en court de sprint, doivent être livrées au milieu du sprint ou encore évoluent/changent en cours de sprint.

Ces points peuvent vous paraitre totalement étrangers et dans ce cas tant mieux. Ils sont malheureusement encore trop fréquents (particulièrement celui sur la documentation ou les sprints mouvants).

Dans le cas contraire, il reste encore du travail dans la transformation Agile et il est important de rappeler que l’Agile ce n’est pas l’anarchie mais une extrême rigueur nécessaire dans les processus de développements

Conclusion

Comme vous le vivez ou l’avez sans doute déjà vécu, les transformations Agiles ne sont pas un long fleuve tranquille. Le manifeste Agile est là pour guider ces transformations mais il m’arrive trop souvent de voir un manifeste Agile outragé, un manifeste Agile brisé, un manifeste Agile martyrisé… Bref un manifeste Agile bien trop fragile. Si l’on veut réussir à aller au bout de la transformation Agile il va falloir réussir à avoir un « Manifeste Agile libéré » et inébranlable.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

6 réponses

  1. Bonjour
    Je crois que j’ai vécu les deux à la fois.
    Manifeste ignoré parce que nous avions des outils imposés. Des processus longs définis par une seules et unique personne et qui ne reflétaient pas toujours le fonctionnement des équipes.
    Impossibilité de tester au cours du sprint : les tests ne pouvaient se réaliser qu’à la fin du sprint ;
    Manifeste caricaturé : pas de DOD ou pas de DOD suivi, des US déscopées au cours du sprint, d’autres ajoutées pour s’aligner sur les autres modules des autres équipes ayant finies et testées leurs US plutôt que prévu.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

culture générale

A la recherche de la qualité perdue: les raisons de la perte

Introduction C’est une histoire bien connue, une histoire que tout acteur du logiciel a vécue ou vivra. Cette histoire commence comme cela : Il était une fois une application nommée New-Soft. New-Soft était aimée de ses utilisateurs, choyée par son équipe de développement, une application faisant l’unanimité, bref, une application

Lire la suite »
culture générale

Ce que nous apprend la mythologie sur les tests: Cassandre

L’idée de cette série m’est venue suite à l’excellent article de Zoé Thivet. Présentation de la série Les mythologies ont de nombreux intérêts. Je note par exemple ces 2 points: l’intérêt historique permettant de comprendre ce que les personnes croyaient au moment où ces mythologies étaient des religions l’intérêt histoire

Lire la suite »