Un waterfall itératif n'est pas agile

Au cours des deux dernières années, j'ai remarqué une tendance inquiétante – et ce, dans des équipes du monde entier.

Il s'agit de la tendance à créer un processus en cascade itératif et à l'appeler ensuite « agile ».

Une cascade itérative

Dans un sprint, quelqu'un (peut-être un Business Analyst en collaboration avec le [Product Owner](/fr/product-owner/ "Product Owner)) essaie de déterminer ce qui doit être développé.

Parce qu'on veut être agile, on travaille avec des User Stories. Mais au lieu de traiter les User Stories comme des supports pour des conversations ultérieures, chaque User Story devient un petit document de spécification de trois à cinq pages – et j'en ai certainement déjà vu de plus longs.

Ces mini-spécifications/User Stories documentent presque tout ce qui peut venir à l'esprit à ce sujet.

Comme il faut un Sprint entier pour découvrir et documenter tout cela, un deuxième Sprint est consacré au design de l'interface utilisateur de la User Story. Parfois, l'équipe essaie d'être un peu plus agile (du moins dans l'esprit) et commence le travail de design juste avant que la mini-spécification d'une User Story ne soit entièrement rédigée.

Beaucoup de membres de l'équipe considèrent cela comme risqué, car les spécifications ne sont pas encore complètement saisies. Mais bon, c'est là que l'agilité entre en jeu.

Les développeurs reçoivent alors deux documents. L'un montre clairement à quoi la User Story doit ressembler à la fin, et l'autre fournit tous les détails pertinents sur le comportement de la Story.

On ne peut commencer à coder que lorsque ces deux artefacts sont terminés. Dans certaines entreprises, ce sont les développeurs qui imposent cette façon de travailler. Ils ont l'attitude de développer tout ce qu'on veut – mais on ferait mieux de leur dire exactement ce dont on a besoin au début du Sprint.

Certaines organisations vont encore plus loin et font travailler les testeurs une itération derrière les développeurs. Cela semble se produire parce que les User Stories d'une équipe deviennent plus volumineuses quand chaque Story doit disposer d'une mini-spécification et d'un design UI complet avant que le code puisse être écrit.

Heureusement, la plupart des équipes comprennent que développeurs et testeurs doivent collaborer dans la même itération, mais elles n'étendent pas cette théorie à une équipe entière qui collabore.

Cela conduit au processus suivant

Une première itération est consacrée à l'analyse. Une deuxième itération (qui peut légèrement chevaucher la première) est dédiée au design de l'expérience utilisateur, et la troisième itération est destinée au codage et aux tests. Ce n'est pas agile. Cela pourrait être le premier pas d'une organisation vers l'agilité. Mais ce n'est pas agile.

C'est une cascade itérative.

Dans le développement traditionnel en cascade, une équipe effectue toute l'analyse pour l'ensemble du projet tout au début. Ensuite, toute la conception du projet est abordée. Puis tout le code du projet est écrit. Enfin, tous les tests du projet sont réalisés.

Dans le processus itératif en cascade décrit précédemment, l'équipe procède fondamentalement de la même manière, sauf que chaque story est traitée comme un petit projet à part entière. D'abord, toute l'analyse de la story est terminée, puis la conception de cette story, ensuite tout le code est écrit et tout est testé. C'est un processus itératif en cascade, pas un processus agile.

Dans un processus agile, idéalement, tous les travaux seraient terminés exactement au même moment. L'équipe terminerait donc en même temps l'analyse du problème et la conception de la solution, ainsi que le code et les tests pour cette solution. Les quatre disciplines (et d'autres que je n'ai pas mentionnées dans cet exemple) seraient donc terminées exactement au même moment.

C'est un peu naïf de croire qu'on peut y arriver à 100 %. (Parfois, c'est possible.) Cela peut cependant être un objectif vers lequel une équipe travaille.

Une équipe devrait toujours essayer d'accomplir autant de travail que possible simultanément. Toutes les réflexions préalables (analyse, conception, etc.) devraient être menées le plus tard possible, ne pas être trop détaillées, tout en permettant que le travail puisse être terminé pendant l'itération.

Si tu traites tes User Stories comme de petits documents de spécification, arrête. Commence plutôt à voir chaque story comme un espace réservé pour une conversation. Tu peux tout à fait ajouter quelques notes aux stories sur des points que tu ne veux pas oublier lors de la prochaine discussion. Ces notes devraient cependant être optionnelles et non une étape nécessaire dans un processus séquentiel. Cela préserve l'agilité et empêche le processus de devenir une cascade.

Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en français.

Gestion des parties prenantes

=> Découvre les meilleurs conseils et astuces de Roman Pichler sur la gestion des parties prenantes

Definition of Done : simple et pourtant complexe

=> Découvre comment la Definition of Done t'aide dans ton travail agile.

Comment se déroule une Sprint Review ?

=> Tu trouveras ici un exemple d'agenda pour la Sprint Review