Agilité sous contraintes

Dans l'environnement où j'interviens actuellement, je suis une nouvelle fois confronté à la prise en compte de contraintes "culturelles".

Ça veut dire quoi ?

Tout d'abord, les projets sont soumis à de fortes contraintes qualité. Cela implique une véritable créativité en matière méthodologique, pour faire converger les exigences du référentiel société et la souplesse nécessaire à l'agilité. Cela génère bien des frustrations au sein des équipes de développements qui ont déjà fort à faire avec les pratiques d'ingénierie agiles. Alors puisque la plupart du temps on a pas le choix, autant les assumer de façon intelligente.

Ces exigences sont par définition obligatoires. Mais elle ne sont pas forcément incompatibles avec l'agilité. Il serait regrettable d'oublier qu'elles sont nées d'un effort de capitalisation de plusieurs dizaines d'années d'expériences industrielles et qu'elles ont aussi apporté leur pierre à l'édifice d'amélioration continue de la qualité logiciel.

Lorsqu'une exigence est visiblement en contradiction avec une démarche agile, une solution consiste souvent à satisfaire une exigence de plus haut niveau.

Exemple (simplifié) :

"le design doit être décomposé en unités distinctes et les exigences doivent être tracées avant de démarrer le codage" Exprimer ainsi, cette exigence est clairement incompatible avec Scrum par exemple. Mais comme cette exigence provient elle même d'une exigence de plus haut niveau, "le design doit être justifié et tracé indépendamment du processus employé", rien n'empêche alors de fournir les justifications de façon itératives au fur et à mesure que la conception émerge ou de les fournir lors de la livraison de release (choix à faire avant le 1ère itération).

Toute l'intelligence des décideurs qui ont à respecter une démarche agile et des exigences qualité fortes réside alors dans la bonne interprétation de ces dernières. Ainsi, je pense qu'il est possible de réconcilier les deux en gardant à l'esprit que c'est produit qui prime et non le process. Certes, les équipes continuent à subir les activités de traçabilités ou de métrologies mais ils doivent aussi considérer cela comme la livraison de valeurs pour ce type de clients. D'expérience, mieux ils sont sensibilisés et moins ils le subissent. Le Scrum master a une position clef pour cela.

Heureusement, les référentiels accueillent progressivement les approches itératives en se détachant du choix d'un processus en particulier (cycle en V le plus souvent), bref, en laissant plus d'autonomie sur le procédé de fabrication et en focalisant les exigences sur le produit. Mais leur inertie est importante et pour accueillir complètement l'agilité, la route est encore longue ! J'y participe...

Dans des prochain billets, j'évoquerai d'autres types de contraintes.