Agile, cascade et changements d'exigences

10

Quelqu'un at-il eu ce problème d'un projet défini comme «Agile» étant dépassé par des changements d'exigences? Je travaille sur un projet de développement qui se déroule en 4 semaines Sprint mais il y a toujours des changements entre ces Sprints. Est-il toujours défini comme Agile alors? Je pense que c'est une sorte de sous-processus Agile - Les exigences d'un processus Agile devraient être définies au début d'un sprint et revues vers la fin. Ai-je raison là-dedans? Veuillez me faire part de vos expériences dans ce domaine.

agile requirements

— Aravind A
source

«Les exigences changent» est un terme vague. Le changement est-il dû au fait que le client a réellement changé d'avis au sujet d'une exigence approuvée? Qu'est-ce qui a déclenché ce changement? Si cela continue, vous devez réexaminer la façon dont vous collectez les exigences. Aucune méthodologie SE ne pourrait répondre au manque de collecte appropriée des exigences.

— NoChance

@Emmad Les changements d'exigence se produisent pendant l'UAT lorsque les utilisateurs estiment que la convivialité pourrait être améliorée par certains moyens. Cela provoque une accumulation de problèmes de pré-production. Ce n'est certainement pas Agile.

— Aravind A

@Aravind A: UAT arrive à la fin du sprint, n'est-ce pas? Ensuite, toutes les nouvelles idées / modifications qui surviennent pendant l'UAT devraient normalement devenir des histoires pour le prochain sprint (si vous utilisez des sprints).

— sleske

Peut-être que ce que @sleske suggère fonctionne pour vous, mais aussi, la facilité d'utilisation peut être prototypée à l'avance si l'utilisateur a des exigences exceptionnelles. Parfois, dans les projets limités par les ressources, vous devez contrôler vos ambitions d'utilisateurs.

— NoChance

9

Les exigences d'un processus Agile doivent être définies au début d'un sprint et revues vers celui-ci. Ai-je raison là-dedans?

Non, cela dépend de la nature du projet (et du processus).

Il existe certains modèles de développement agile où les exigences sont censées être fixées pendant un sprint et ne devraient changer que pour le sprint suivant (un exemple important est Scrum).

Cependant, il existe également des processus où les changements peuvent se produire presque à tout moment (tant que le client accepte les retards et le travail supplémentaire que le changement entraîne). Kanban est souvent utilisé pour gérer ces workflows (bien que Kanban puisse également être combiné avec Scrum).

Le modèle que vous suivez dépend des détails de chaque projet.

Alors oui, si le client estime qu'il a besoin de pouvoir constamment changer les exigences, alors un processus agile peut s'adapter à cela. Cependant, le client doit être conscient des conséquences des changements constants et comprendre qu'il ralentira le projet.

Cela se résume aux principes du manifeste agile - «Les individus et les interactions sur les processus et les outils» et «Répondre au changement en suivant un plan».

— sleske
source

Ne rend pas le processus ouvertement agile? Je veux dire, jusqu'où peut aller l'Agilité? Si un développeur remplit une exigence pour la première fois, il y aura forcément une demande la prochaine fois. Je pense que c'est l'un des nombreux problèmes qui provoquent la qualité du code.

— Aravind A

@AravindA La qualité du code doit être une préoccupation distincte et quel que soit le nombre de fois que le code change, l'équipe doit se concentrer sur les mêmes normes de qualité du code à tout moment. En fait, la qualité du code est plus importante car les exigences et le code changent constamment.

— maple_shaft

2

@maple_shaft a raison - la qualité est (au moins surtout) orthogonale au changement d'exigence. Donnez-moi une demande: je commence à écrire du bon code. Si j'ai fini, et que j'obtiens une nouvelle demande, ou à moitié fait et que j'obtiens un changement, je commence à (ré) écrire du bon code. Après avoir mis en évidence l'impact sur le calendrier / engagement / etc.

— sdg

Les modifications des exigences qui ont une grande influence sur l'architecture du système entraîneront des retards importants ou des compromis sur la qualité. C'est pourquoi vous devriez faire une bonne vieille analyse en cascade (qui peut aussi être itérative) où vous essayez de réduire le risque d'apparition "soudaine".

— MaR

@sles Merci pour l'explication. Je pense que je comprends maintenant. Je pense que je vais devoir en savoir plus sur Agile.

— Aravind A

12

Je pense que la question que vous devriez vous poser est la suivante: pourquoi êtes-vous dépassé par les modifications des exigences? Les causes courantes incluent:

Les développeurs n'ont pas (suffisamment) de contacts avec les utilisateurs finaux et ne peuvent donc pas comprendre les besoins des utilisateurs. Au lieu de cela, ils traitent les exigences comme un cube Rubik abstrait - ils suivent les lettres des exigences sans même essayer de comprendre leur esprit
Quelqu'un (par exemple du marketing) ajoute des exigences qui n'ont pas de sens pour l'utilisateur final (mais qui sonnent bien par exemple sur une brochure). Il y a donc une bataille entre les "vraies" exigences et les "autres" exigences qui se battent aux dépens des développeurs
La portée du projet n'est pas définie ("Eh bien, si vous implémentez un traitement de texte de toute façon, ne pourriez-vous pas simplement ajouter un petit module qui fait notre comptabilité de paie? Oh, et Bill de l'autre équipe de développement a demandé à quel point ce serait difficile faire pour que le traitement de texte compile aussi du code C ++? ")

Quel que soit le problème racine, vous devez y remédier. Le noyer sous des couches de "Agile" (ou toute autre méthodologie) ne fonctionnera pas.

— nikie
source

@nike Merci. C'est exactement ce que je pensais. Votre troisième point s'inscrit dans mon scénario. Certains clients profitent simplement du travail «Agile» en pensant que c'est une solution miracle pour accélérer le travail.

— Aravind A

9

Dans Scrum au moins, qui semble être le processus Agile le plus populaire avec les types de gestion de nos jours, la portée d'un Sprint est fixe. Si votre backlog de sprint change pendant le sprint, ce n'est pas Scrum, c'est le chaos. Le backlog de sprint doit être créé au début du sprint et rester fixe jusqu'à la fin du sprint (auquel moment vous créez un nouveau backlog de sprint pour le sprint suivant).

Si votre Product Backlog change pendant un sprint, ce n'est pas grave. Les changements deviennent simplement un nouveau travail priorisé, estimé et sélectionné comme toute autre exigence pour le prochain sprint. Si les exigences changent tellement que le Product Owner doit régulièrement annuler le sprint, vous avez des problèmes avec un «T» majuscule.

Peut-être avez-vous besoin de sprints plus courts?

— Adam Jaskiewicz
source

+1 pour avoir besoin de sprints plus courts. Réduisez à 2 semaines et voyez si cela aide.

— John

1

4 semaines, cela semble en effet assez long pour un sprint, surtout sur un projet qui souffre de l'instabilité des exigences.

— Carson63000

7

Pour la raison des programmeurs, il est préférable que les exigences ne changent pas pendant une révision / sprint.

Dans votre situation, il existe deux options évidentes:

sprints plus courts
amener le client à accepter de ne pas modifier les exigences lors d'une révision / sprint, sauf si la révision / sprint entière est annulée et replanifiée

Je recommande fortement les deux .

— Steven A. Lowe
source

3

Le principal problème est que vous croyez que vous utilisez Scrum mais vous ne le faites pas. En particulier, votre propriétaire de produit ne le suit pas. Dans Scrum, un sprint est une zone sûre et aucune modification des user stories validées ne peut être effectuée à moins que le sprint en cours ne soit annulé. Il est de la responsabilité de Scrum master de faire respecter cela. Si cela ne fonctionne pas dans votre environnement, c'est un problème de processus = vous n'utilisez pas Scrum.

Le changement le plus simple que vous puissiez faire (si vous voulez suivre Scrum) est de raccourcir votre sprint - une semaine par exemple. Les sprints de 4 semaines ont été considérés comme une option dans les premiers jours de Scrum, mais aujourd'hui, il est courant de 1 à 2 semaines et 3 semaines sont considérées comme la limite supérieure. 4 semaines, c'est très long dans un environnement changeant.

— Ladislav Mrnka
source