Comment tenir compte des tâches modifiées ou oubliées dans un devis?


10

Pour gérer les estimations au niveau des tâches et les rapports de temps, j'ai utilisé (à peu près) la technique décrite par Steve McConnell dans le chapitre 10 de Software Estimation. Plus précisément, lorsque le moment est venu pour moi de créer des estimations au niveau des tâches (juste avant le début du codage sur un projet), je détermine les tâches à un niveau assez granulaire de sorte que, dans la mesure du possible, je n'ai pas de tâches avec un seul point, 50 % de confiance estimé supérieur à quatre heures. De cette façon, le processus d'estimation des tâches aide à construire le logiciel tout en m'aidant à ne pas oublier les tâches lors de l'estimation. Je propose également une plage d'heures possible pour chaque tâche, et en utilisant les calculs statistiques que McConnell décrit avec mes données d'exactitude historiques, je peux générer des estimations à d'autres niveaux de confiance si vous le souhaitez. J'ai l'impression que cette méthode fonctionne assez bien pour moi. Nous sommes tenus de mettre les tâches et leurs estimations dans TFS pour le suivi, donc j'utilise les estimations au pourcentage de confiance qu'on me dit d'utiliser.

Cependant, je ne sais pas quoi faire quand j'oublie une tâche, ou je dois finir par faire un travail qui ne correspond pas parfaitement à l'une des tâches que j'ai estimées. Bien sûr, il est préférable d'éviter cette situation, mais comment tenir compte des tâches oubliées / modifiées? Je veux avoir les meilleures données historiques possibles pour m'aider avec de futures estimations, mais pour l'instant, je calcule simplement si j'ai fait l'estimation de confiance à 50% et si je l'ai fait dans l'estimation à distance.

Je serai heureux de clarifier ce que je demande si nécessaire - faites-moi savoir ce qui n'est pas clair.



Je pense que je vais devoir donner un exemple de la façon dont je fais ces calculs ainsi que le problème que j'essaie de résoudre. Je n'ai pas le temps pour le moment, mais j'y arriverai dès que possible.
Andrew

Dans la mêlée, vous ne donnez pas d'estimation de temps; vous donnez des points d'histoire, qui donnent aux autres une idée. Vous ne dimensionnez pas non plus de bas en haut. Vous n'avez pas besoin de - la vitesse est une chose vague.
Job

@Job Nous ne sommes pas une boutique de mêlée pour le moment. De plus, contrairement à ce qu'un autre répondant a suggéré, j'ai constaté jusqu'à présent que les estimations ascendantes ont amélioré ma précision d'estimation, en grande partie en réduisant considérablement le nombre de tâches oubliées lors de l'estimation au niveau de la tâche.
Andrew

@blueberryfields - multiplier seulement par 50% devrait suffire, au moins dans une entreprise avec de nombreux niveaux hiérarchiques, où chacun ajoute son propre facteur de surestimation.
mouviciel

Réponses:


6

Le livre Waltzing With Bears: Managing Risk on Software Projects (par DeMarco et Lister, les auteurs de Peopleware) a une approche formidable à cela. Voici ma réinterprétation:

Faites une estimation "tout se passe parfaitement". Bien sûr, tout se déroule rarement parfaitement, ce qui a peu de chances de se produire, par exemple 0,1%. En d'autres termes, un seul projet sur mille se déroulera parfaitement comme prévu. C'est ce que la plupart des gens utilisent comme «estimation», ce qui est évidemment fou.

Au lieu de cela, nous devrions considérer les estimations comme des distributions de probabilité. Cette estimation du «monde parfait» est le point le plus à gauche de la distribution de probabilité de l'estimation.

Faites ensuite une estimation "si les choses se passent comme ça pour des projets similaires comme celui-ci". Cette estimation vous aide à prendre une "vue extérieure" ( http://wiki.lesswrong.com/wiki/Outside_view ), en échappant à l'erreur de planification ( http://wiki.lesswrong.com/wiki/Planning_fallacy ).

Ensuite, faites une estimation "Je suis sûr à 90% que nous aurons terminé par X". Soyez très, très sûr que vous voulez dire sûr à 90%. En d'autres termes, vous vous attendez à prendre plus de temps que cette estimation une seule fois pour dix projets que vous réalisez.

Nous pouvons maintenant utiliser votre première estimation comme estimation de probabilité de 0,1% et votre deuxième comme estimation de probabilité de 50% (saison au goût) et la troisième comme estimation de 90%, ce qui vous donnera une belle courbe.

Supposons que vos estimations de 0%, 50% et 90% étaient le 1er mai, le 1er juin et le 1er août, alors votre courbe d'estimation ressemblerait à ceci:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Notez comment la croissance de la probabilité ralentit au fil du temps. Si quelqu'un vous a demandé une estimation de 99,9% dans ce scénario, ce pourrait être le 1er janvier de l'année suivante.


Merci d'avoir répondu. La méthode que j'ai utilisée me permet déjà de faire ce que vous semblez proposer, mais elle prend également en compte (indirectement, en utilisant un pourcentage d'exactitude historique) mon succès passé avec mes estimations afin de générer le pourcentage- estimations confiantes souhaitées. Ce que je demande, cependant, est de savoir comment incorporer les tâches manquées dans cette précision historique lorsque la précision est essentiellement calculée en fonction de la fin ou non d'une tâche dans la plage que j'ai utilisée pour mon estimation d'origine.
Andrew

@Andrew, si je vous comprends bien, les "tâches manquées" sont représentées par la probabilité de moins de 100% d'être accomplies à un moment donné. Si vous avez fait beaucoup de projets comme celui en cours, votre courbe va rapidement passer de 0% à (disons) 90%. C'est parce que vous avez une grande confiance qu'il y a peu de tâches manquées. Si vous avez une faible confiance, alors la pente sera beaucoup plus progressive. Cela vaut pour n'importe quelle raison, non seulement des tâches oubliées, mais aussi d'autres facteurs de risque.
Benji York

Oui, les tâches manquées sont couvertes globalement par les plages de niveaux de tâche, qui figurent dans les niveaux de confiance que je donne. Je calcule ces niveaux à l'aide d'une méthode que McConnell propose dans le chapitre 10 de Software Estimation, comme je l'ai déjà dit. Je me demande principalement comment je prends en compte ces tâches manquantes ou modifiées dans les rapports d'heures TFS ainsi que comment inclure ces heures lors du calcul de ma précision historique.
Andrew

5

En un mot - la contingence.

La contingence est le montant que vous ajoutez pour «d'autres choses» - les choses que vous ne pouvez pas expliquer ailleurs dans votre estimation. SMc le couvre-t-il dans l'estimation de logiciels? Je ne me souviens pas et ma copie est au travail (je suis en vacances pour répondre à cela - comme je suis triste) ...

Quoi qu'il en soit, de manière générale, il y a trois types de contingence que je recommanderais d'examiner:

1) Risque spécifique au risque - c'est là que vous identifiez un risque spécifique et ajoutez un certain temps pour couvrir le dépassement potentiel qui y est lié. La première chose à préciser ici est ce qu'est un risque - c'est quelque chose qui peut arriver, qui aura un impact négatif sur le projet, qui est hors de votre contrôle .

Cette dernière partie est critique - ce n'est pas seulement "les choses prennent un peu plus de temps que je ne le pensais", c'est "le module de planification tiers que l'on nous a dit que nous devons utiliser car c'est une norme d'entreprise qui n'est peut-être pas à la hauteur". La façon dont vous calculez la quantité de risques à ajouter est le pourcentage de chances que le risque puisse se produire, exprimé sous forme décimale (donc 50% = 0,5), multiplié par l'impact de ce risque (dans l'exemple, par exemple, vous devez écrire manuellement CRON au lieu d'utiliser le planificateur et cela prendra 10 jours, ce nombre est de 10 jours).

Donc, s'il y a 50% de chances que votre risque se concrétise et qu'il faudra 10 jours d'efforts pour le contourner, si vous le faites, vous ajoutez 5 jours. Additionnez toutes les valeurs de tous les risques identifiés sur le projet et ajoutez-les au total.

2) Shit Happens Contingency - La meilleure description que j'aie jamais entendue, même si elle n'est pas élégante. C'est un projet informatique, ça se passe. Cela ne se passe jamais comme vous le pensez, les choses prennent plus de temps, vous manquez, etc. Généralement, la contingence SH sera comprise entre 10% (minimum absolu) et 25% (mais peut être plus élevé), 15% étant à peu près typique, le niveau exact dépendant du niveau d'incertitude et du risque général (déplacement des poteaux de but, exigences incertaines, etc.) ).

Si votre PM n'accepte pas la contingence SH (et c'est possible, il pourrait ne pas avoir d'expérience des projets informatiques ou être un optimiste aveugle), alors ajoutez-le simplement à tous les montants individuels. S'il sait ce qu'il fait, il aura son propre journal des risques et vous aimera pour avoir pensé à ce genre de choses. Certes, s'il a une qualification PM (comme PRINCE2), il le saura.

3) Contingence de changement - C'est là que vous êtes à peu près sûr que le client apportera des modifications mais ne voulez pas que ce soit un point de discorde. Ajoutez X jours ou X% et cela va dans un pot pour les changements que le client soulève. Il y a deux façons de le gérer: soit vous leur en parlez et c'est à eux de dépenser, soit vous ne leur en parlez pas.

La première façon est la meilleure, mais nécessite un client assez éduqué et juste - les choses sont classées comme des changements et il peut dépenser son pot comme bon lui semble (en fonction de votre estimation des choses à mesure qu'elles se présentent).

La deuxième façon, vous mentionnez que c'est un changement, mais ne cherchez pas à lui faire payer un supplément. Vous devez noter toutes les choses que vous dépensez, donc si cela arrive au point où il s'épuise et vous devez retourner auprès du client et demander plus de temps ou d'argent et ils disent "attendez, je" Je paie bla bla bla "vous pouvez signaler toutes les choses qu'ils ont déjà changées et que vous n'avez pas facturées comme signe que vous n'êtes pas totalement déraisonnable. Cela ne fonctionne pas toujours mais cela renforce presque toujours votre main dans les discussions.

Aucun de ces trois ne couvre spécifiquement les choses que vous avez oubliées, mais je pense qu'entre elles, vous comblerez beaucoup des lacunes que vous avez.


Merci pour votre réponse. Vous soulevez des points intéressants. J'intègre déjà ces trois éléments de diverses manières dans mes estimations. Votre premier type, j'ai trouvé, peut généralement être articulé et associé à une ou plusieurs tâches. Le deuxième type est simplement incorporé dans mes estimations de plage de niveau de tâche: je ne suis pas autorisé à avoir un élément supplémentaire pour cela (nous en avons débattu, et pour l'instant, c'est la politique de notre équipe). Pour le troisième, les clients internes acceptent que les changements augmenteront notre estimation, et les clients externes l'ont par écrit, donc nous ne sommes pas censés considérer les changements.
Andrew

Quant à savoir si McConnell couvre les éventualités, ma copie est également au travail, donc je devrais vérifier. Je pense que ce que je demande, c'est comment tenir compte des tâches manquantes / modifiées lors du calcul des données d'historique pour informer la prochaine estimation ainsi que où attribuer les heures dans TFS, car une tâche d'urgence n'est normalement pas autorisée dans notre groupe.
Andrew

0

Lorsqu'on vous demande une estimation pour une tâche, donnez une estimation haut de gamme à l'équipe et ayez une estimation basse pour vous-même, ce faisant, vous aurez toujours le temps, une fois la tâche accomplie, de travailler sur quelque chose que vous auriez oublié de mentionner en premier lieu.


Merci d'avoir répondu. Les gammes que je propose font, dans leur ensemble, tendent à me laisser suffisamment de temps pour ajouter des tâches oubliées sans manquer l'estimation de l'ensemble du projet. Ma question concerne davantage l'utilisation de ces informations dans la procédure de calcul que j'utilise dans le livre McConnell.
Andrew

0

Craignez-vous qu'en ajoutant les tâches supplémentaires, vous fausserez votre précision historique? Ou pensez-vous que le fait de ne pas inclure les tâches supplémentaires faussera la précision?

Je pense que pour le meilleur du projet, les tâches devraient être entrées dans le système de suivi. Je suis sûr que le chef de projet sera en mesure de fournir une explication appropriée à la direction pour les écarts ...


Je pourrais simplement attendre demain et vous le dire en personne. :) Je suis plus préoccupé par l'inexactitude de l'historique si les tâches supplémentaires ne sont pas incluses. De toute évidence, manquer une tâche lors de l'estimation de la tâche est un "échec" en ce qui concerne la précision - mais quel chiffre de précision? Celui que j'utilise réellement dans un sens quantitatif est de savoir si les performances réelles de ma tâche pour chaque tâche se situaient dans la plage prévue. L'autre mesure, plus qualitative, est la fréquence à laquelle je respecte mes estimations ponctuelles à 50% de confiance. Trop loin ou moins de 50%, et je devrais ajuster le «jugement d'expert» pour les futures estimations de 50%.
Andrew
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.