Abandonner Agile, passer à waterfall - Est-ce bien ?

Question

Je travaille dans un environnement Agile et les choses sont arrivées à un point où le client pense qu'il préférerait Waterfall en raison des échecs (c'est ce qu'il pense) du scénario Agile actuel. La raison qui les pousse à penser ainsi est l'immense quantité de changements au niveau de la conception qui se produisent à la fin des sprints et que nous (les développeurs) n'avons pas pu terminer dans le temps imparti.

Comme d'habitude, on se blâmait l'un l'autre. De notre point de vue, les changements annoncés à la fin étaient trop nombreux et les modifications de la conception et du code étaient trop importantes. Le client, quant à lui, se plaint que nous (les développeurs) ne comprenions pas pleinement les exigences et proposions des solutions qui ne correspondaient pas à ce qu'il voulait. (comme s'ils nous avaient demandé de dessiner un tigre, et que nous avions dessiné un chat).

Ainsi, le client a estimé (pas nous) que le processus Agile n'est pas correct et qu'il veut passer à un mode Waterfall qui, à mon avis, serait désastreux. Pour la simple raison que leur niveau de satisfaction dans un mode Agile n'était pas suffisant, alors comment vont-ils tolérer le résultat après avoir passé tant de temps pendant la phase de conception d'un développement Waterfall ?

Veuillez nous faire part de vos suggestions.

Answer 1

Tout d'abord, demandez-vous si vous vraiment à faire de l'Agile ? Si c'est le cas, vous devriez déjà avoir livré au client une grande partie des fonctionnalités utilisables qui ont satisfait à ses exigences au cours des premiers sprints. En théorie, les "dégâts" devraient être limités au dernier sprint où vous avez découvert que vous deviez apporter des modifications importantes à la conception. Dans ce cas, vous avez prouvé votre capacité à livrer et vous devez maintenant dialoguer avec le client pour planifier les changements nécessaires.

Cependant, compte tenu de votre description, je soupçonne que vous êtes tombé dans le piège du développement sur un cycle de deux semaines sans réellement livrer en production à chaque fois et que vous avez une date de fin fixe en tête pour la première vraie version. Si c'est le cas, vous faites vraiment de la cascade itérative sans analyse/conception des besoins en amont - un mauvais endroit où se trouver en général.

La cascade complète n'est pas nécessairement la réponse (il y a suffisamment de preuves pour montrer quels sont les problèmes avec elle), mais une certaine quantité de planification et de conception en amont est généralement préférable dans la pratique à l'éthique Agile "pure" de l'architecture émergente (qui correspond à une approche Lean en fait). Les grands projets ne peuvent tout simplement pas espérer obtenir une base architecturale stable et sensée s'ils commencent à bidouiller du code en espérant que tout se passera bien au bout d'un certain nombre de sprints.

En plus de ce qui précède, un autre problème courant avec l'Agile "pur" est la gestion des attentes du client. Agile est vendu comme une chose merveilleuse qui signifie que le client peut reporter ses décisions, changer d'avis et ajouter de nouvelles exigences comme bon lui semble. CEPENDANT, cela ne signifie pas que la date de fin / le budget / l'effort requis reste fixe, mais les gens semblent toujours manquer cette partie.

Answer 2

Les méthodologies de développement agiles sont particulièrement appropriées lorsque les exigences ne sont pas claires et que vous pouvez être amené à modifier la conception à des stades ultérieurs du projet. L'approche cascade est moins appropriée dans ce cas. L'approche cascade est appropriée pour les projets qui sont bien compris et lorsque les exigences sont peu susceptibles de changer pendant la durée de vie du projet. Il ne semble pas que ce soit le cas ici.

Quelle est la durée de vos sprints ? Une autre approche pourrait consister à réduire la durée des sprints - au moins au début du projet. Livrez plus souvent de nouvelles versions au client et discutez des changements avec lui. Si vous ne faites pas ce qu'il veut, cela apparaîtra plus rapidement et vous perdrez moins de temps à mettre en œuvre des solutions qui ne répondent pas aux exigences du client.

Answer 3

Je ne sais pas quel type de magasin vous gérez, il m'est donc difficile de vous faire de bonnes recommandations. Je peux cependant vous proposer deux principes directeurs :

1. Si vous avez une mauvaise communication avec le client, aucune méthodologie de développement ne pourra vous sauver.
2. La façon dont un chef organise sa cuisine ne regarde pas le client, du moment que le repas est bon.

Answer 4

On dirait que vous avez sérieux des problèmes de gestion de projet et d'architecture/conception, et il semble que vos communications soient également rompues. Fondamentalement, je ne pense pas que le fait de changer votre méthodologie de développement va résoudre tout cela, et c'est donc la mauvaise chose à faire (même si cela peut restaurer la confiance du client).

Je serais particulièrement préoccupé par le déplacement vers Waterfall, puisque vous choisissez de saisir les exigences une seule fois (ce qui, nous le savons, vous pose problème), sans possibilité d'apport. Cette rigidité est bonne pour les objectifs de livraison inflexibles, mais elle est complètement inappropriée ici où vous avez des changements tout le temps - c'est agile !

• À court terme, je prendrais du recul et vérifierais à nouveau vos exigences à ce stade avec eux. Renégociez et confirmez votre situation actuelle par rapport à celles-ci.

• À moyen terme, j'ouvrirais davantage la communication avec le client - j'essaierais de l'impliquer dans une mêlée quotidienne pendant un certain temps (jusqu'à ce que vous rétablissiez la confiance, puis vous pourrez être plus flexible).

• À long terme, vous devez vous inquiéter de la façon dont vos chefs de projet et vos développeurs principaux ont réussi à vous mettre dans cette situation. Si le client est irrécupérable, c'est une chose (mais c'est toujours au PM de gérer cela, donc vous n'êtes pas absous). Il n'est pas raisonnable de se plaindre d'avoir trop de changements, cela signifie simplement que vous vous êtes trompé dans la détermination des exigences (qui est un dialogue, pas un monologue) ou que vous devez avoir des sprints plus nombreux, mais probablement plus courts.

Par-dessus tout, je ne vois pas comment le passage à la cascade peut être correct. Cela ne règle rien directement et je ne vois que l'exacerbation des problèmes que vous avez déjà soulignés.

Avertissement : je ne suis pas vraiment capable d'avoir un point de vue équilibré sur la cascade, car je ne l'ai jamais vue fonctionner efficacement et je pense qu'elle est complètement dépassée pour les projets d'entreprise.

Answer 5

Le développement agile ne vous dispense pas de la charge que représente l'élaboration d'une conception que vous et le client comprenez de la même manière. La méthode Agile permet simplement d'élaborer la conception par petites étapes et non en une seule fois. Et, dans le cas d'un client difficile, l'élaboration d'un design approprié prend du temps.

Je consacrerais donc plus d'efforts à m'asseoir avec le client, avec un tableau blanc, pour déterminer ce qu'il veut vraiment. Je ne pense pas qu'il soit vraiment important dans ce cas que le processus de développement soit agile ou en cascade.