La phrase semble incohérente, « piloter par le contrôle », c’est comme finir avant d’avoir commencer, et pourtant c’est ce que nous faisons depuis longtemps.
Les mécanismes du cycle en V sont fondés sur le contrôle et le suivi de projet, pas du produit. C’est assez comique de voir comment un processus normalement fabriqué pour avoir de la visibilité, n’en apporte en fait aucune, il faudra attendre la fin pour voir si le logiciel produit répond aux besoins du client (et surtout du marché). RUP non plus n’apporte pas grand-chose de plus à mon sens, il n’a que découper dans le temps ce principe là, mais la trame reste, voir la phase de construction.
En cycle en V, les exigences et les scénarios de tests sont gérés par 2 processus bien séparés.
Les exigences sont faites pour satisfaire le niveau supérieur. En parallèle, des tests sont décrits pour contrôler ce niveau d’exigence. Il n’y a pas de lien, ni de vérification entre les différents niveaux de tests.
Par définition, les tests sont écrits après les spécifications. Ce qui fait que les tests ne sont connus et utilisés que sous forme contrôle à posteriori. Les tests sont une sanction.
Les exigences, majoritairement écrites sous forme documentaire, voir avec des outils de type Doors, ne peuvent que retranscrire le comportement statique du besoin. La spécification s’apparente la plus part du temps à un catalogue de règles de gestion, qui pense-t-on, mises bout à bout, vont produire un logiciel.
A l’inverse, les scénarios de tests décrivent l’aspect dynamique et cinématique du besoin : L’approche opérationnelle. Ce que l’utilisateur réel va vraiment pouvoir faire.
Encore une fois, les tests étant fournis après comme contrôle du travail fini, les équipes de développement n’ont donc que l’aspect statique et ne connaissent pas le mode opératoire du logiciel qu’ils sont en train de produire.
Le développement est donc piloté par la seule information à caractère statique de se que sera le logiciel et sera sanctionné par un contrôle à postériori.
C’est le pilotage par le contrôle. Incohérent par nature !
La réponse Agile est : « Test first »
La aussi, ce que l’on reproche aux méthodes Agiles est leur manque visibilité à long terme. Et c’est heureusement là qu’elles pourraient bien au contraire vous surprendre.
La grande différence réside dans la construction du backlog.
En agile, nous utilisons les user stories : Une définition succincte mais précise des possibilités offertes à l’utilisateur, leur moyen de vérification, ainsi que les critères d’acceptance. Dans ce cas, les scénarios de tests sont fournis comme (seuls ou en complément) des spécifications en entrée de sprint. Des exigences plus fines de type règles de gestion peuvent être définies au cours de la réunion de planification de sprint.
Le développeur est ainsi « formé » à l’utilisation de ce qu’il va produire. Il connait les objectifs à atteindre. La chaine de construction se répète tout au long du process jusqu’à l’écriture du code de test avant le code lui-même (TDD), qui participe au maintient de la qualité du logiciel (Intégration continue, tests automatisés).
L’approche est donc radicalement différente.
Agile propose un pilotage par les objectifs.
Traçabilité passive vs active.
Le cycle de production des exigences et des tests est par construction séparé et disjoint dans le temps.
Le lien entre les deux process est la traçabilité. Traçabilité « active », puisqu’il faut à chaque étage tirer les liens des éléments avals vers ceux amonts. Il n’y a pas moyen de savoir à priori combien d’exigences avales vont être nécessaires pour couvrir celle amont. D’où, je pense, une inutilité sur ce point de la matrice de traçabilité, puisque même si la matrice montre qu’une exigence amont est liée par une ou plusieurs exigences avales, rien ne garantie que la couverture est totale. Pour cela, il faudra faire une relecture.
A la différence, le mécanisme de construction du backlog (Feature è user story è tâche) peut s’apparenter à une décomposition hiérarchique et arborescente du besoin et propose une traçabilité « passive ». Le backlog (et ceux des sprints) est auto suffisant. Chaque niveau est produit en réponse au niveau supérieur, le nombre d’éléments du niveau inférieur est connu à l’avance (en début de sprint, avant l’implémentation).
En utilisant les outils appropriés (Type Eclipse Mylyn), cette traçabilité peut aller jusqu’aux pièces de code, sans que le développeur ne se rende compte qu’il est en train de faire de la traçabilité. C’est la traçabilité passive.
Le backlog sert au pilotage du projet, à sa construction, à son suivi, sert aussi de release note. C’est n’est pas qu’un outil de suivi de projet, c’est bien le référentiel des exigences, référentiel structuré.
L’agilité en combinant « pilotage par l’objectif » et « traçabilité passive », vous permet donc de savoir quels sont les éléments définis du produit à réaliser, quels sont ceux produits validés, ceux encore à produire. Avec en plus une grande souplesse dans le changement, pour s’adapter aux besoins du client et du marché.
3 commentaires:
avec le cycle en V, non seulement les tests sont une sanction (ce qui est une conséquence) mais ils sont un ré-interprétation des spécification (ce qui est selon moi LA cause de tous les maux). Faits ainsi, ils laissent s'installer le principe du téléphone arabe qui devrait pourtant être exclu de tout domaine professionnel.
C'est effectivement une des conséquences du double process. La double interpretation du besoin.
(pardon pour la faute d'orthographe dans mon précédent commentaire) et je voulais rajouter que je considère ton billet comme un écrit fondateur dans l'approche de la mise en place de démarche Agiles... et qu'il devrait être cité maintes fois.
Enregistrer un commentaire