La décision de la date de sortie avant de collecter toutes les exigences n'est-elle pas agile?

Je viens de commencer à lire le livre Applying UML and Patterns de Craig Larman. Je trouve cela très intéressant car il remet en question bon nombre de ce qui m'a été dit au travail. J'ai lu que les exigences ne sont pas entièrement collectées en une seule fois dans Agile et qu'il faut de nombreuses itérations pour terminer la collecte des exigences. Si tel est le cas, met-on en place un délai fixe, ce que je suis obligé de faire au travail, très peu agile, étant donné qu'il pourrait y avoir une nouvelle exigence révolutionnaire (ou une demande de changement se faisant passer pour une exigence) demain?

Il n'y a absolument aucun problème "Agile" à avoir une date de sortie fixe si vous êtes prêt à déplacer l'un des deux autres bords du "triangle de fer": les exigences pour ce qui doit être dans cette version, ou les ressources dont vous disposez . Vous ne pouvez pas résoudre les trois - et dans la pratique, le côté "ressources" du triangle est très souvent soit peu flexible ou inefficace à modifier.

S'il y a une nouvelle exigence majeure demain, c'est bien tant que l'entreprise est prête à accepter que cette exigence ne prenne pas la date de sortie - c'est-à-dire qu'elle passe à la prochaine version.

Je pense que le problème dans de nombreux camps Agiles est lié à l'échéance des mots. Le risque avec un délai est que vous supposez que vous savez ce qui doit être fait. Comme vous le faites remarquer, vous ne pouvez pas avoir de date limite pour un inconnu.

Ce qui est décrit dans la réponse de Philip est bien moins un délai qu'une contrainte. Nous pourrions dire que nous avons des fonds jusqu'en mars et que nous devons donc fabriquer le meilleur produit possible pendant cette période.

Pour donner une analogie, supposons que je vous demande d'aller à l'histoire de l'épicerie et d'acheter tous les produits d'épicerie pour la semaine et, avant de partir ou de regarder les prix, je veux que vous me disiez exactement ce que vous allez dépenser. De plus, vous serez pénalisé si vous vous trompez. Vous ferez exactement ce que les gens font avec les délais du projet - vous choisirez un nombre à l'extrémité supérieure de ce que vous pensez que la plage pourrait être parce qu'il a le plus faible risque d'être pénalisé. Maintenant, disons que je vous dis que c'est inacceptable et que vous devez acheter les mêmes choses que vous avez prévues, mais vous devez le faire pour 50 $ moins cher, sinon. Maintenant, que pouvez-vous faire? Vous pouvez refuser, vous pouvez simplement reporter l'argument jusqu'à ce que vous ayez fait vos achats, ou vous pouvez trouver un moyen de tromper la situation. C'est ce qui se passe dans de nombreuses organisations avec des délais fixés sur des inconnues.

Maintenant, voyant à quel point cette situation est malsaine, Agile dit simplement: "Si vous avez un budget, je peux vous promettre d'y participer et je vous donnerai les meilleurs repas possibles pour cette semaine dans cette contrainte." Ce qui est une conversation beaucoup plus saine à avoir.

L'agilité est une technique, pas un résultat. Par rapport à la tonte de pelouse, une itération est comme une ligne d'herbe que vous avez tondue. Si quelqu'un dit "tondez votre pelouse en 15 minutes" et que vous utilisez de manière agile, vous terminerez peut-être 30% à la fin. Ensuite, vous réitérerez un peu plus tard et le terminerez.

Vous pouvez avoir une date de sortie planifiée sans problème. Assurez-vous simplement qu'à cette date particulière, vous ne perdez pas de temps. Vous devriez avoir un produit qui pourrait être expédié à la fin de chaque sprint, mais en général, il n'y a aucun mal à le faire; c'est plus un objectif qui concentre le travail plutôt qu'une exigence. Si vous avez une date de sortie prévue, vous devez avoir un produit libérable à cette date.

Vous viserez généralement à avoir un produit non testé, mais, espérons-le, libérable quelque temps avant la date de sortie prévue, puis le produit est testé et les bugs corrigés jusqu'à ce que les normes de qualité soient respectées, puis il est publié sans aucune panique nécessaire. La version contiendra tout ce qui était prêt à ce moment-là.

Maintenant, il peut ne pas être évident pour votre patron que vous devez également planifier une deuxième date de sortie, avec plus de fonctionnalités réellement implémentées.