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

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.

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.

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.

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.

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 ...