Le manifeste agile a pour quatrième valeur : Responding to change over following a plan ce que l'on peut traduire par "s'adapter au changement plutôt que suivre un plan ".
D'aucun considère alors que le changement du besoin est naturel et ne doit pas être contré. Si effectivement le changement doit être accueilli de façon positive par l'équipe je pense néanmoins que cet accueil doit être limité et surtout que le changement doit être accompagné.
Ainsi la valeur d'adaptabilité au changement ne doit pas être un argument et une excuse pour donner à l'équipe des stories qui ne sont pas abouties et finies en terme de réflexion. On voit bien trop souvent des "A définir" dans la liste des exigences liées à des stories, ou encore, alors que le développement est à 80% réalisé, avec des échanges actifs entre équipier et donneurs d'ordres (ou PO quand on a la chance d'en avoir un) et donc théoriquement pas d'effet tunnel, un beau matin une demande de temporisation apparaît sur la story puis une redéfinition majeure de celle-ci avec pour conséquence de devoir :
- ré-estimer la complexité de l'item
- jeter le travail réalisé (bien trop souvent c'est 100% du travail qui disparaît)
- repartir sur un item avec le questionnement inévitable et maintenant on est sûr que c'est bon?
et bien souvent tout ceci s'accompagne d'un magnifique c'est pas grave on est en méthode agile non? ....
Dans ce genre de cas j'ai bien envie de répondre que non, on est en méthode larache. En effet je trouve toujours aussi incongru et ce quelle que soit la méthode suivie, de ne pas correctement définir ce qui doit être fait, et si on s'est trompé de corriger de façon cavalière le besoin sans se préoccuper des conséquences sur le travail de l'équipe.
Que l'on ne se trompe pas, il ne s'agit de refuser pas le changement en soit, ni l'idée que l'équipe ait un peu plus de travail à fournir pour atteindre le besoin réel, mais je n'accepte pas que la charge porte uniquement sur celle-ci. Autant un changement mineur, ou apporté avant la phase de développement et correctement intégré dans le sprint ne me gène pas et est même souhaitable vu que le but est de fournir une solution viable pour l'utilisateur final, autant le changement non accompagné et assumé (retrait d'un nombre de point de complexité équivalent au périmètre du sprint, report de la story à un sprint ultérieur ....) me semble être une incompréhension majeure du concept d'agilité .
Et vous le changement c'est comment?
category:
- Nicolas's blog
- Log in or register to post comments