Cela découle de certaines des réponses et des commentaires sur une autre question ( celle-ci ).
J'ai travaillé principalement avec des projets en cascade et même si j'ai travaillé sur des projets ad-hoc qui ont adopté des comportements agiles et ont lu pas mal sur l'agile, je dirais que je n'ai jamais travaillé sur un "bon" projet agile .
Ma question est la suivante: le concept de "retard" a-t-il un sens en agile, si oui, alors quoi?
Mon raisonnement est qu'avec agile, vous n'avez pas de plan initial et vous n'avez pas d'exigences détaillées au départ. Vous pouvez avoir un objectif de haut niveau à l'esprit et une date théorique qui lui est attachée, mais les deux peuvent changer (potentiellement massivement) et aucun n'est certain.
Donc, si vous ne savez pas exactement ce que vous allez livrer fondamentalement jusqu'à ce que vous le livriez et que l'utilisateur l'accepte, et si vous n'avez pas de calendrier au-delà du prochain sprint, comment pourriez-vous être en retard d'une manière qui a réellement un sens?
(Évidemment, je comprends qu'un sprint peut dépasser, mais je parle au-delà de cela.)
Juste pour être clair, je suis (personnellement) satisfait de l'hypothèse selon laquelle des projets en cascade (même relativement grands) sont possibles en raison du fait que je les ai vus et que j'y ai été impliqué - ils ne sont ni faciles ni courants, même mais ils sont possibles.
Il ne s'agit pas de frapper agile, c'est de me faire comprendre. J'ai toujours vu les avantages de l'agile comme n'ayant rien à voir avec les délais ou les budgets (ou plutôt seulement indirectement), c'est avec la portée - l'agile offre plus près de ce qui est vraiment important plutôt que ce que l'équipe de projet pense est important avant eux '' ai rien vu.