Est-ce mal d'utiliser Agile alors que les exigences des clients ne changent pas du tout?

J'ai vu beaucoup de messages récemment disant que l'une des principales raisons pour lesquelles Agile est utilisé est que les clients changent souvent les exigences.

Cependant, supposons que les clients ne changent pas souvent les exigences . En fait, les clients ont des exigences fermes mais peuvent être un peu vagues (mais rien de déraisonnablement vague), mais j'utilise quand même Agile.

La raison pour laquelle j'emploie Agile est que le logiciel est suffisamment complexe pour qu'il y ait des détails, des problèmes que je ne reconnaîtrais pas avant de les affronter. Je pourrais faire une approche de planification lourde à grande échelle comme une cascade, mais cela prendrait quelques mois pour finaliser toutes les signatures de conception de haut niveau et de codage de bas niveau. Il existe cependant une conception architecturale très spécifique et fixe pour le système.

Ma question est: Serait-ce considéré comme mauvais, codage cowboy, anti-pattern, etc.? Doit-on utiliser la cascade et planifier autant que possible dans les moindres détails avant de commencer à coder lorsque les exigences sont stables au lieu de cette mentalité «faisons-le» dans Agile?

EDIT: Le point principal ici est le suivant: nous NE POUVONS PAS blâmer les clients pour l'évolution des exigences. Supposons que les clients nous ont signalé un problème très concret, donnez-nous une liste de souhaits dans des détails très raisonnables et laissez-nous tranquilles (c.-à-d. Que les clients ont leurs propres choses productives à faire, ne les boguez plus. fin lorsque vous avez un prototype fonctionnel minimum). Serait-il mal d'utiliser Agile dans ce scénario?

Serait-ce considéré comme mauvais, codage cow-boy, anti-modèle.

Réponse courte: non. Faire «agile» correctement ne signifie pas «pas de planification», cela signifie ne pas trop analyser les choses.

l'une des principales raisons pour lesquelles Agile est utilisé est que les clients modifient souvent les exigences.

C'est une déclaration trop simplificatrice. La «modification des exigences» concerne également l'évolution de la compréhension de l'équipe des exigences. Et il s'agit de la façon dont les priorités du client concernant l'exigence changent lorsqu'il voit effectivement quelques versions du logiciel.

En fait, "agile" fonctionne le mieux à mon humble avis exactement dans la situation que vous décrivez - le client a une bonne connaissance de ses besoins globaux, vous pouvez en rédiger un plan général, remplir votre carnet de commandes avec de nombreuses "user stories" et avoir déjà suffisamment d'informations pour choisir la bonne architecture du système. Les courtes itérations d'une stratégie de développement agile contribueront alors à rendre les «exigences vagues» plus précises, avec beaucoup de retours si vous allez toujours dans la bonne direction. Il vous donnera également des informations précoces sur les efforts et les coûts réels (ce que vous pouvez toujours échouer dans une approche en cascade, même si vous connaissez en détail chaque exigence).

Utiliser l'agilité dans cette situation est toujours une très bonne idée. L'agilité présente de nombreux avantages, dont un seul est la rétroaction régulière du client et la capacité de répondre aux exigences changeantes comme vous le mentionnez.

L'une des principales raisons de l'échec des projets en cascade est le problème `` presque terminé '' - tester des tas de bogues produits à la fin, laissant un produit non libérable et aucune idée s'il a besoin de deux jours ou de deux ans pour corriger les bogues en suspens. Agile supprime entièrement ce risque. Si un projet agile est en cours d'exécution, vous pouvez toujours fournir une version de travail qui:

A) Prouve au client que vous êtes presque là grâce aux démos ("Toutes ces histoires sont faites, nous pouvons faire les dernières si vous le souhaitez") et un peu plus de temps obtiendra exactement ce qu'il veut.

B) Potentiellement, c'est assez bon pour qu'ils soient de toute façon heureux et libérés.

Pour moi, supprimer ce risque d'échec complet est une raison suffisante pour qu'une entreprise passe à un processus de développement agile, la capacité de créer de meilleurs logiciels qu'initialement prévu est la cerise sur le gâteau. Comme mentionné dans d'autres réponses, ces exigences «concrètes» sont encore étonnamment malléables.

Agile est idéal si vous avez besoin d'une boucle de rétroaction fréquente avec le client. Cela peut être dû au fait que les exigences changent fréquemment, mais cela peut également être dû à d'autres raisons.

D'un autre côté, Agile peut fonctionner aussi bien si les exigences sont entièrement stables et que le client ne s'attend qu'à une seule livraison big-bang, mais vous devrez peut-être adapter les choses un peu pour la quantité d'implication que le client attend d'avoir pendant la projet. Cela signifie que le rôle de Product Owner doit être rempli au sein de votre propre organisation et que cette personne doit avoir suffisamment de mandat du client pour prendre des décisions.

Vous pouvez toujours diviser la grande version en versions plus petites (sprints) et demander des commentaires à votre client. De cette façon, vous êtes sûr de faire la bonne chose et le client peut suivre vos progrès.

S'il y a quelque chose qui ne va pas, vous pouvez offrir à votre client la possibilité de vous corriger plus tôt, ce qui est très bien. Il vaut mieux corriger vos erreurs le plus tôt possible, plutôt que de lui montrer une connerie à la fin et essayer de la réparer quand vous ne savez même pas par où commencer.