Comment pouvons-nous *fixer* des délais, pour nous permettre de les respecter efficacement, de manière agile ?[fermé]

Question

Fermé. Cette question est hors sujet.Il n’accepte actuellement pas de réponses.

---

Vous souhaitez améliorer cette question ? Mettre à jour la question alors c'est sur le sujet pour le débordement de pile.

Fermé il y a 2 ans.

Je travaille dans une équipe qui a travaillé de manière cohérente et assez réussie selon une approche agile, et cela a très bien fonctionné pour le projet actuel jusqu'à présent, pour notre travail initial, à mesure que nous construisons progressivement le produit.

Cependant, nous passons maintenant à la phase suivante, et la direction tient à ce que nous fixions nous-mêmes des délais précis, pour lesquels nous serons en mesure de faire une démonstration et de vendre cela à de vrais clients, de l'ordre de plusieurs mois. .

Nous avons un important retard assez bien organisé pour chacun des éléments de fonctionnalité que nous aimerions inclure, et une bonne idée de la priorisation de ces éléments de fonctionnalité individuels.

La solution naïve consiste à obtenir la liste minimale d'histoires qui fourniraient un produit démontrable, à les estimer toutes individuellement, puis à les additionner et à les combiner avec notre vitesse pour obtenir une date et annoncer que nous ferons une démonstration à partir de là.Cela ne laisse cependant aucune marge de manœuvre et semble susceptible d’entraîner une crise folle à mesure que nous approchons de l’échéance, ce que je veux désespérément éviter.

En guise d'amélioration, j'aimerais ajouter un certain ratio d'histoires facultatives pour agir soit comme des améliorations de contingence, soit comme des améliorations bonus, en fonction de la façon dont nous progressons, mais nous n'avons aucune idée du ratio qui serait raisonnable, ni si c'est le cas. l’approche standard.

Je suis également préoccupé par le fait de devoir estimer l'ensemble de notre retard d'un seul coup, car cela semble prendre beaucoup de temps, et il semble probable que nous découvrirons plus d'informations dans les mois précédant cette histoire. ce qui affectera nos estimations.

Existe-t-il des approches recommandées pour gérer la fixation de délais afin de permettre un processus de développement agile ?La plupart des informations que j'ai vues semblent concerner la gestion de la situation une fois que vous avez un délai fixe à respecter.Je serais également intéressé par toute littérature pertinente ou article de blog intéressant traitant de cette question.

Answer 1

Concernant la littérature :le meilleur livre que je connaisse concernant l'estimation dans les logiciels est "Software Estimation :Démystifier l'art noir" par Steve McConnel.Il couvre votre cas.De plus, il décrit la différence entre estimation et engagement (fixer un délai, en d'autres termes) et explique comment dériver de manière fiable le second du premier.

Answer 2

La solution naïve consiste à obtenir la liste minimale d'histoires qui fourniraient un produit démo, d'estimer tous ceux-ci individuellement, et de les additionner et de combiner avec notre vitesse pour obtenir une date, et annoncer que nous démorions à partir de ce moment.Cela ne laisse aucune marge de manœuvre, et semble susceptible de se traduire par un crunch fou alors que nous montons à la date limite, que je veux désespérément éviter.

C'est la solution que j'ai utilisée dans le passé.Votre estimation initiale va être un peu erronée, alors ajoutez un peu de répit via quelques sprints supplémentaires avant de fixer votre date de sortie.Si vous êtes en retard, vous pouvez rattraper le retard.Sinon, votre backlog produit vous offre des fonctionnalités supplémentaires que vous pouvez inclure dans la version si vous le souhaitez.Cela dépendra cependant de votre mesure de vitesse pour l’équipe.Ajustez votre marge en fonction de la précision que vous estimez de cette mesure pour l'équipe actuelle.Une fois que vous avez une version cible, vous pouvez revenir en arrière pour voir si vous avez des contraintes de ressources connues qui pourraient affecter cette version.

Answer 3

L'approche que vous décrivez est probablement correcte.Vous souhaiterez peut-être estimer toutes les fonctionnalités souhaitables et hiérarchiser les éléments de l'interface utilisateur (car les investisseurs et les clients ne voient essentiellement que l'interface utilisateur brillante), puis votre date limite sera cette date d'achèvement estimée ;puis ajoutez un peu de répit en mettant à l'échelle vos estimations.Utilisez le rapport entre la productivité actuelle et votre pire période pour créer une estimation pessimiste.Vous pouvez utiliser ce même ratio pour mettre à l'échelle des estimations plus courtes (par ex.pour votre estimation à l'ensemble minimum de fonctionnalités).