La fin a-t-elle un sens dans les méthodologies agiles?

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.

Je ne suis pas d'accord qu'un projet Agile n'a pas de plan initial.

D'après mon expérience, les analystes commerciaux ont passé pas mal de temps à travailler à des réunions de conception avec des clients et des développeurs pour établir une liste détaillée des exigences réalisables qui sont présentées sous forme de témoignages d'utilisateurs. Ceux-ci sont ensuite décomposés en tâches avec des estimations appropriées jointes par des développeurs expérimentés.

Une fois que les tâches les plus importantes ont été identifiées au début du sprint / itération, le codage peut commencer. Ce processus de sélection détermine la signification de l'itération dans le projet global ("Nous construisons le processus de connexion"). Divers membres de l'équipe entreprennent les différentes tâches nécessaires pour que cette histoire d'utilisateur se produise.

À la fin de l'itération, toutes les user stories de cette itération doivent être terminées, sinon vous êtes en retard . De même, le développement doit pouvoir s'arrêter à la fin de chaque itération et le produit libéré. Il peut ne pas être complet pour toutes les user stories, mais les user stories qui ont été demandées dans l'itération sont terminées et le produit peut fonctionner dans ces limites.

"tard" dans une méthodologie agile signifie la même chose que dans une méthodologie en cascade: les estimations étaient fausses, la portée était trop grande pour le temps imparti, des difficultés inattendues sont apparues, le client n'était pas assez réactif, les programmeurs sont devenus paresseux, les machines se sont écrasées, votre chien a mangé mon bytecode, etc.

vous en tirez des leçons et vous ajustez pour la prochaine itération

la différence est que cela peut se produire toutes les 2 à 4 semaines, donc les leçons sont tirées et le processus est ajusté rapidement

Oui, mais il ne faudra qu'un mois pour savoir que vous n'atteindrez pas la date d'échéance de votre projet final mythique de 9 mois au lieu de 9.

Votre raisonnement est basé sur l'hypothèse que des plans initiaux et des exigences détaillées pour les grands projets sont possibles. Je ne suis pas sûr qu'il y ait beaucoup de preuves à l'appui. Peut-être que toutes les histoires d'horreur sont juste anecdotiques? Tout développeur aimerait travailler avec des spécifications complètes et jamais changeantes avec lesquelles le client est entièrement d'accord et comprend.

Chaque fois que vous vous engagez, vous courez le risque d'être en retard. Cela vaut également pour l'agile.

Mais nous savons que vous ne pouvez pas prédire l'avenir, et nous savons que le client changera constamment d'avis, et nous convenons que c'est une bonne chose. Si nous acceptons cela, nous devons également accepter que tous les engagements sont à peu près toujours faux, ce qui, à son tour, rend la question du retard facile à répondre: nous avons toujours tort ( trop tôt ou trop tard). Tout est une question de suppositions, peu importe comment bien poli. Un tirage au sort.

C'est quelque chose que nous, les développeurs, devons simplement accepter, et de ce point de vue, essayer de trouver une autre façon de travailler, une manière dont le problème de retard est rendu beaucoup moins important. Un changement de perspective. Je pense que la façon de le faire est de se concentrer sur la livraison d'un logiciel fonctionnel dès que possible, avec une option de quitter lorsque le client est satisfait.

Et c'est à cela que sert l'agile. Une façon intelligente de gérer cette notion inconfortable que le retard est un fait et nous devons simplement y faire face du mieux que nous pouvons.

Par exemple, vous êtes en retard lorsque vous ne respectez pas les engagements que vous avez pris au début de l'itération en cours. Cela est attendu et vous devez en tirer des leçons et adapter votre processus afin de ne pas échouer lors de la prochaine itération. La meilleure façon de gérer cela est de garder les itérations aussi petites que possible.

Pour la planification à plusieurs itérations, autrement dit la planification des versions, vous utilisez la vitesse calculée à partir des itérations terminées et extrapolez les données pour prédire une date de publication future. Je recommande de James Shores article ou mon propre (plus court) pour plus de détails à ce sujet. Notez que ce n'est jamais un engagement solide et plus d'un "nous sommes certains à 80% que nous terminerons les prochaines fonctionnalités d'ici cette date". Cela peut (en quelque sorte) entraîner votre retard, mais l'engagement n'est qu'une probabilité, pas un fait.

Maintenant, cela correspond à la promesse de base de l'agilité: vous devriez toujours être prêt à publier un logiciel fonctionnel, complet ou non. Cela donne au client la liberté d'arrêter le développement quand il pense que le système est assez bon, ce qui peut arriver beaucoup plus tôt que prévu. Il encourage également à prendre le projet dans de nouvelles directions en se basant sur les véritables commentaires de la dernière itération.

Les points ci-dessus devraient être plus que suffisants pour que tout client ait le contrôle total du développement, et j'espère que cela répond à la question du retard dans les méthodes agiles.

Il existe deux types de «retard» dans SCRUM Agile>

1. Carryover - Stories non "Done" à la fin d'un sprint, les développeurs "s'engagent" à faire un PBI, donc quand ce n'est pas fait, il peut être considéré comme carry.

2. Feuille de route - En supposant que votre organisation dispose d'une feuille de route et en supposant qu'elle ait des dates, si les principaux livrables pour ces dates sont manqués, cela peut être considéré comme "en retard".