Un développeur doit-il accepter une estimation de la charge de travail effectuée par une macro Excel?

12

Dans un nouveau projet, un ami devait écrire des tests où le temps nécessaire pour les écrire était calculé par une macro Excel écrite par son responsable non développeur.

Dans de telles circonstances, un développeur devrait-il accepter la responsabilité d'écrire et d'exécuter les tests dans le temps calculé? Les résultats de ces tests sont-ils fiables?

Pour information, mon ami a refusé d'être responsable des estimations qu'il n'avait pas faites, a demandé de réussir à travailler sur un autre projet, et a été remplacé par un oui-gars extrascolaire inexpérimenté.

project-management productivity testing

— Nelstaar
source

7

Que signifie «accepter» une «estimation»? Si vous estimez qu'il me faudra 30 jours pour faire quelque chose, que se passe-t-il si je "l'accepte"? Qu'importe le temps que vous estimez qu'il me faudra pour faire quelque chose? Vous pouvez estimer que je le ferai dans une minute pour tout ce que je veux, vous vous tromperez, pas moi.

— David Schwartz

2

@David Accepter une estimation signifie généralement revoir les estimations et assurer un consensus. Par exemple, si un outil d'estimation paramétrique est utilisé, demander aux ingénieurs de projet de revoir ces données pour assurer la cohérence, en utilisant peut-être une deuxième méthodologie telle que Delphi large bande.

— Thomas Owens

12

Cela ressemble à quelque chose qui devrait être envoyé à Scott Adams pour un dessin animé de Dilbert.

— MetalMikester

1

Tant qu'il y a un examen. Dans cet exemple particulier, il n'y en avait pas.

— Nelstaar

5

N'oubliez pas: une estimation, un engagement, un objectif et un plan pour atteindre un objectif sont quatre choses différentes. Assurez-vous que tout le monde est clair sur ce que sont ces choses et sur laquelle de ces quatre choses la sortie Excel est.

— nlawalker

14

Cela dépend de la façon dont ils se sentent sensibles au développeur et sur quelles données / logique ils sont basés. (ils peuvent être basés sur des données statistiques collectées sur plusieurs années sur le temps nécessaire - par ce développeur lui-même et / ou par d'autres - pour résoudre des tâches similaires dans le passé ... ou ils peuvent être entièrement basés sur ceux de son manager - correct ou incorrect - hypothèses.)

Idéalement, il devrait discuter avec son manager que l'on ne peut raisonnablement s'attendre à ce qu'il s'engage et prenne la responsabilité d'une tâche estimée par quelqu'un d'autre.

Refuser clairement de s'engager sur les estimations peut en effet entraîner son remplacement rapide, il est donc préférable d'avoir une approche plus douce et d'éviter la confrontation directe si possible.

— Péter Török
source

7

Vraisemblablement, la macro fonctionne sur une sorte de données d'entrée, ce n'est pas seulement un générateur de nombres aléatoires? Donc, pour répondre à votre question, nous devons savoir quelles sont les données d'entrée et ce que fait la macro. Sans cela, aucune réponse n'a de sens.

Ou, votre question concerne-t-elle vraiment l'acceptation d'estimations produites par un gestionnaire qui manque d'expérience pertinente? Dans ce cas, la réponse est non, vous (ou votre ami) devez produire leurs propres estimations et les soumettre au gestionnaire. Si les 2 chiffres ne correspondent pas, ils doivent travailler ensemble pour trouver la meilleure voie à suivre - peut-être accepter d'écrire moins de tests ou prendre plus de temps pour les écrire tous.

Le refus catégorique ne va aider personne, et travailler à une échelle de temps que vous ne pouvez pas respecter n'est pas amusant non plus, la solution consiste à adopter une approche professionnelle et à parvenir à un compromis qui permet au travail de continuer.

— Steve
source

Les tests sont découpés en sous-sous-parties (presque atomiques) et on obtient une petite estimation.

— Nelstaar

Je pense qu'en utilisant cette méthode, le testeur final ne voit pas / ne teste pas la situation dans son ensemble.

— Nelstaar

1

"Vraisemblablement, la macro fonctionne sur une sorte de données d'entrée, ce n'est pas seulement un générateur de nombres aléatoires" Il pourrait aussi bien être aléatoire car il n'y a aucun moyen de capturer CHAQUE variable qui rendrait un tel algorithme précis.

— maple_shaft

1

@maple_shaft: C'est pourquoi ils appellent cela une estimation - ce n'est pas (ou ne devrait pas être) censé être précis. Que vous estimiez à l'aide de certains calculs dans Excel ou avec un crayon et du papier, cela ne fait aucune différence. Utiliser Excel pour les estimations a beaucoup plus de sens que certaines autres «techniques» que j'ai vues en cours d'utilisation

— Treb

@Treb Les estimations devraient être aussi précises que le permettent les données fournies et l'état actuel du projet, compte tenu du cône d'incertitude.

— Thomas Owens

5

Certainement NON.

Un petit programme, même un grand programme compliqué, ne peut pas estimer la durée d'un travail de programmation. Voir Limites mathématiques de l'estimation logicielle pour les raisons. Un document plus long et évalué par les pairs, Large Limits to Software Estimation, est également disponible.

Je reconsidérerais également mon opinion sur le gestionnaire en question: pourquoi pense-t-il qu'une macro de feuille de calcul n'a pas été essayée dans le passé, étant donné que tout le reste a été essayé pour estimer la durée des tâches logicielles dans le passé.

— Bruce Ediger
source

1

Je n'ai pas (encore) lu ces articles dans leur intégralité, mais les méthodes paramétriques ont été largement utilisées pour estimer les projets logiciels à moins de 15% pendant plus de 20 ans, en supposant que les données d'entrée sont valides. De plus, des méthodes collaboratives telles que Delphi large bande peuvent (et ont été utilisées) pour confirmer la précision des modèles paramétriques. Voir Software Engineering Economics (Boehm) pour une discussion sur les méthodes paramétriques et l'application de la large bande Delphi aux projets logiciels (avec et sans modèles parémétriques également).

— Thomas Owens

Je suis d'accord avec Thomas. Bien que vous ne puissiez pas prédire avec précision chaque tâche pour un projet entier, au cours d'un projet et en utilisant des données historiques pour une organisation spécifique, vous pouvez obtenir dans le stade approximatif. Certaines tâches prendront plus de temps et d'autres plus courtes, mais à la fin, elles se résorbent en moyenne. Surtout si le projet est similaire à ceux déjà réalisés par l'organisation. Cela dit, les estimations ne peuvent pas expliquer de très mauvaises choses inattendues, comme le matériel / logiciel ne fonctionne pas comme annoncé, les nouvelles technologies sont beaucoup plus difficiles que prévu, les pénuries de développeurs, le manque de leadership et de gestion.

— Dunk

1

Vous devez lire et comprendre le document. Une simple macro de feuille de calcul n'a aucune chance d'estimer correctement. Les logiciels sont des mathématiques et les systèmes mathématiques sont parfois sujets à un petit problème connu sous le nom d'incomplétude. Je vous garantis que le manager en question se trompe lui-même et que les résultats de la macro ne sont pas en corrélation avec la réalité.

— Bruce Ediger

1

@Bruce: Ayant utilisé avec succès les formules (y compris les feuilles de calcul Excel) pour l'estimation de projet, je peux très certainement affirmer que ni Thomas, ni le directeur, ni moi-même ne nous trompons nécessairement. Comme je l'ai dit, chaque tâche individuelle va varier, mais au cours d'un projet, elle a tendance à s'équilibrer. J'ai trouvé que l'utilisation de formules (développées et modifiées au fil du temps) était beaucoup plus précise que les estimations individuelles des développeurs. En général, les développeurs sont trop optimistes ou trop pessimistes. Bien sûr, les formules ne fonctionnent que lorsque des données raisonnables sont fournies, la compétence est certainement un facteur.

— Dunk

J'ai lu ces journaux hier soir. Ils vont à l'encontre de plus de 40 ans de preuves en gestion de projets et de plus de 30 ans de preuves en gestion de projets logiciels. Voir iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf et sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

Pouah!

Il s'agit d'une gigantesque "odeur de travail". C'est une micro-gestion incroyable.

S'ils ne peuvent pas faire confiance à leurs employés pour donner une estimation, avec quoi ne vous font-ils pas confiance?

— ozz
source

1

99% des développeurs ne peuvent même pas proposer de mauvaises estimations basées sur quoi que ce soit d'objectif, sans parler d'estimations précises. Je ne vois donc rien qui indique une "odeur de travail" parce que quelqu'un d'autre a proposé une estimation. Surtout s'ils ont utilisé des données réelles pour justifier leurs chiffres. Si les gens sont tenus de respecter l'estimation de chaque tâche, c'est un problème d'odeur de travail. Cependant, si l'outil sous-estimait largement toutes les tâches, tous les développeurs manqueraient les estimations. OTOH, si tout le monde semble répondre à la plupart des estimations et qu'un autre développeur ne le fait jamais, c'est un problème d'odeur pour les développeurs.

— Dunk

@Dunk - ce que je veux dire, la micro-gestion à ce point dans le développement de logiciels est une "odeur de travail" et je ne voudrais pas y travailler.

— ozz

1

ce que vous appelez la microgestion est le seul moyen de faire des affaires dans de nombreuses industries. Si vous ne pouvez pas proposer des estimations de coût et de calendrier raisonnables pour les grands projets, votre entreprise aura du mal à obtenir des contrats. Contrairement à l'idéal agile, les clients de nombreux secteurs n'engageront pas des dizaines de millions de contrats de dollars s'ils ne savent pas ce qu'ils obtiendront finalement. Ils ne seraient pas satisfaits de l'idée que leur argent a disparu, ils ont un produit qui fonctionne, mais cela ne fait que 50% de ce dont ils ont besoin ou voulaient.

— Dunk

@dunk - Si vous êtes satisfait que la direction produise des estimations pour vous, allez-y. Je préfère que l'équipe de développement produise des estimations. Des estimations de gestion ludiques (ainsi que des demandes en constante évolution, toute une autre discussion) expliquent pourquoi de nombreux projets logiciels ne parviennent pas à être livrés à temps et dans le budget prévu. Je préfère faire confiance aux gens qui font le travail.

— ozz

Ce n'est pas une question de gestion qui fait des estimations ou de personnes qui font le travail qui arrive avec les estimations. Il s'agit de tirer des estimations de vos fesses ou d'essayer de baser vos estimations sur des données objectives. D'après mon expérience, en comparant les estimations de gestion aux estimations des développeurs, vous constaterez que les estimations de gestion ont tendance à entraîner des délais plus longs. Les développeurs ont tendance à être optimistes .....

— Dunk

3

Absolument pas.

Je vous promets que le gestionnaire n'est pas tellement trompé de penser que sa macro Excel peut prédire avec précision les estimations. Je ne discute même pas ce qui devrait être un fait bien connu qu'il y a trop de variables impliquées pour prédire avec précision quelque chose comme ça dans un algorithme. S'il a inventé un tel algorithme, il devrait le breveter et gagner des millions à mon avis.

Ce qui se passe vraiment ici, c'est que le gestionnaire utilise cette supposée macro Excel comme un déguisement à peine voilé pour cacher le fait qu'il force des attentes irréalistes et une pression indue sur ses développeurs.

Il sait que c'est BS et ne s'en soucie pas, c'est une excuse pour surcharger les ressources et essayer d'accélérer les choses en rendant tous ses développeurs "sans valeur" perpétuellement "TARD".

Ce manager ressemble à un imbécile exploiteur.

— maple_shaft
source

1

Eh, ce n'est pas parce que le gestionnaire génère des estimations pour les développeurs qu'ils sont inexacts et nous ne pouvons vraiment pas tirer cette conclusion sans plus d'informations. Si le gestionnaire est compétent, il doit reconnaître qu'il est réaliste ou irréaliste d'ajuster assez facilement les choses en conséquence.

— rjzii

1

@Rob, vous oubliez le point clé que l'OP a fait, qu'ils sont tenus à ces estimations (supposé strictement parce que le développeur précédent de l'équipe mentionnée "ne voulait pas être tenu aux estimations" et a été réaffecté). Il n'y a rien de mal avec les modèles d'estimation, mais ils devraient être une ligne directrice approximative et rien à "retenir les développeurs", ce que j'ai malheureusement vu la gestion faire à BEAUCOUP de personnes.

— maple_shaft

2

Ici, le problème était que ces estimations se déplaçaient directement dans la facture du client. Pourquoi certains gestionnaires continuent d'appeler cela des estimations?

— Nelstaar

@maple_shaft - Sans savoir quelles sont les estimations, il est difficile de dire si elles étaient déraisonnables et donc les objections à leur être tenues étaient valables. S'il s'agissait d'estimations justes (c'est-à-dire "Huit heures pour écrire Hello World"), il n'y a aucun problème à les respecter au-delà de la philosophie.

— rjzii

3

Dans un nouveau projet, un ami devait écrire des tests où le temps nécessaire pour les écrire était calculé par une macro Excel écrite par son responsable non développeur.

Il existe des modèles d'estimation paramétrique pour estimer le temps d'achèvement des projets, y compris les projets logiciels. Habituellement, l'estimation concerne le code de production, mais je ne vois pas pourquoi elle ne peut pas être extrapolée pour estimer le temps qu'il faudra pour écrire le code de test. Cependant, ces estimations sont aussi bonnes que les données qui y sont intégrées.

En supposant que la méthode utilisée est un modèle d'estimation valide et que les données sont exactes et valides, il n'y a aucune raison pour qu'une bonne estimation ne puisse pas provenir d'une macro Excel écrite par un gestionnaire non développeur.

Dans de telles circonstances, un développeur devrait-il accepter la responsabilité d'écrire et d'exécuter les tests dans le temps calculé?

Aucune estimation ne doit en aucun cas être acceptée aveuglément. Aucune estimation n'est jamais parfaite, quelle que soit la façon dont elle est générée. C'est à l'ingénieur d'examiner toutes les estimations, d'identifier les problèmes potentiels, d'évaluer leur impact et de discuter et d'affiner l'estimation selon les besoins.

Les résultats de ces tests sont-ils fiables?

Les tests ne valent que l'effort consacré à leur conception et à leur mise en œuvre. Si un testeur produit des tests de faible qualité, les défauts passeront par les tests et passeront à une phase ultérieure du projet. Il va de soi que la pression du calendrier entraînera des tests de faible qualité, donc si le temps est insuffisant pour concevoir les cas de test appropriés et ensuite les mettre en œuvre, les tests ne seraient pas aussi utiles.

— Thomas Owens
source

3

On dirait que vous posez deux questions différentes:

Les résultats de ces tests sont-ils fiables?

Excel est un outil comme tout autre avec lequel nous travaillons et le contenu des calculs ne devrait pas vraiment avoir d'impact sur les résultats de l'algorithme lui-même. Le fait que l'estimation provienne d'une macro Excel est sans importance pour savoir si les résultats du calcul (c'est-à-dire la validité de l'estimation) sont valides. Si vous avez de mauvaises hypothèses dans le modèle sous-jacent, peu importe ce que vous utilisez pour effectuer le calcul car les hypothèses sous-jacentes sont incorrectes.

Dans de telles circonstances, un développeur devrait-il accepter la responsabilité d'écrire et d'exécuter les tests dans le temps calculé?

Si l'exigence selon laquelle le développeur effectue le travail dans le délai indiqué est en contact avec eux, il n'y a pas grand-chose qu'ils peuvent faire pour contester cela tant que les estimations sont raisonnables. Ce qui nous amène au point suivant: si les calculs donnent un laps de temps raisonnable et sont similaires aux estimations que le développeur se donnerait alors il n'y a aucune raison de ne pas s'opposer aux délais donnés. En fait, cela pourrait fonctionner à l'avantage des développeurs, car ils pourraient être en mesure d'influencer les hypothèses utilisées dans le module, par opposition à un calendrier arbitraire.

Si les délais semblent irréalisables pour la quantité de travail requise, ils devraient évidemment soulever cette préoccupation et essayer de travailler avec le gestionnaire pour obtenir des délais plus réalistes, mais si les délais sont réalisables, ils auront du mal à s'y opposer.

En termes de gestion de projet et d'estimation des délais, oui, cela peut être fait mais cela dépend fortement de la nature du travail effectué. Vous allez probablement voir des estimations plus précises pour le temps requis pour écrire le code de test unitaire (en supposant que le développeur comprend le cadre et les a déjà écrit) que pour l'écriture de nouveau code par rapport aux cas d'utilisation du code de test en cours d'écriture pour.

— rjzii
source

Je suis d'accord que cette méthode peut / pourrait être utilisée tant qu'il y a un dialogue entre les acteurs du projet.

— Nelstaar

1

@Nelstaar - Presque tout ce que j'ai lu sur la gestion et l'estimation de projet implique un dialogue en cours et des ajustements au fil du temps. Habituellement, les estimations les plus fiables ont une probabilité qui leur est associée en ce qui concerne les chances de toucher la cible indiquée (c.-à-d. 90% de chances que la tâche prenne 8 heures).

— rjzii

2

Je ne veux pas minimiser les tests d'écriture, mais le projet a probablement déjà été écrit par plusieurs développeurs. Si les estimations sont basées sur ces données, elles peuvent être plus précises que ce que votre ami a supposé. Depuis que votre ami a quitté le projet, n'a fait aucune tentative pour créer des estimations opposées ou voir si elles pouvaient être complétées comme prévu, nous ne le saurons jamais.

Tout ce qu'il avait à faire était de passer un ou deux tests pour voir à quel point l'estimation était exacte et de retourner au gestionnaire avec une argumentation légitime. D'autres membres de l'équipe pourraient avoir fourni des commentaires sur la fiabilité des estimations ou les conséquences d'un retard. Parfois, un manager doit donner «quelque chose» à son patron pour que tout le monde soit content. Les développeurs y voient un faux sentiment de sécurité. Peut-être que s'il y avait un mouvement pour que les développeurs fournissent des estimations et montrent une volonté de faire avancer les choses, la direction pourrait développer plus de confiance.

Ce que je suppose, c'est que s'il pouvait terminer les tests en moins de temps, il n'en dirait rien. Là encore, s'excuser d'une pratique en laquelle il ne croit pas peut indiquer un haut niveau d'intégrité.

— JeffO
source

+1 pour avoir donné des commentaires lors de l'exécution des tâches concernant les estimations.

— rjzii

1

Réponse simple et courte:

Peu vous importe d'où vient l'estimation.

Ce qui vous importe réellement, c'est l'estimation elle-même. D'accord ou en désaccord et expliquez pourquoi et combien vous estimeriez. C’est le plus important.

— Clement Herreman
source

1

Vous devez vous soucier d'où vient l'estimation. Un modèle paramétrique avec des entrées valides et raisonnables, un générateur de nombres aléatoires, un étudiant en première année d'informatique, un ingénieur logiciel avec 5 ans d'expérience avec moins de 6 mois dans le domaine, et un ingénieur logiciel devenu chef de projet avec 25 ans d'expérience dans le domaine ont tous une capacité différente à produire une estimation efficace. Cela revient également à un commentaire que j'ai fait sur une réponse précédente au sujet de la responsabilité éthique / professionnelle d'un ingénieur logiciel de représenter, défendre et contester les estimations de manière appropriée.

— Thomas Owens

Exactement: le plus important est de discuter de l'estimation. J'approuverais volontiers l'utilisation de macros Excel si les estimations qu'il faisait étaient plus souvent justes qu'un ingénieur de 25 ans d'expérience. Ce qui est important, c'est l'estimation et l'explication qui y conduisent (charge de travail, ressources disponibles, difficulté), et non par qui ou quoi cela a été annoncé.

— Clement Herreman

Vous êtes d'accord avec moi pour dire que votre réponse est fausse? Compte tenu des mêmes intrants (tels que la charge de travail, les ressources, les difficultés, etc.), le qui est tout aussi important que le quoi et pourquoi. Cela revient à un facteur de confiance. Je fais plus confiance à COCOMO (créé et entretenu par certains esprits éminents de l'estimation des coûts logiciels) qu'à une macro Excel (réalisée par quelqu'un ayant une expérience et des connaissances limitées en estimation des coûts, et encore moins dans le domaine d'application). Il s'agit d'une vue d'ensemble pour établir la fiabilité de cette estimation.

— Thomas Owens

Non non, je suppose que je ne suis pas assez clair. Ce n'est vraiment pas important qui a fait l'estimation. Ce qui est important, c'est l'exactitude de l'estimation. Chaque fois que j'obtiens une estimation, je la compare à ce que j'aurais estimée, puis j'en discute avec mon chef de projet si je suis d'accord ou non. Si leur argument est assez bon, je suis d'accord avec eux et j'accepte l'estimation. Voir? Je n'ai jamais parlé ni pensé à qui a estimé.

— Clement Herreman

Comment déterminez-vous l'exactitude si vous ne savez pas qui a estimé et quelles méthodes ils ont utilisées? Je pourrais donner les mêmes données à deux personnes - l'une est un étudiant en première année de génie logiciel qui suit actuellement son premier cours d'informatique et l'autre est un ingénieur logiciel senior avec 15 ans d'expérience et 5 dans le domaine. Les deux utilisent les mêmes méthodes d'estimation (n'oubliez pas - souvent, les entrées sont également des estimations). L'élève peut dire que cela prendra 6 mois avec une confiance de 95%. L'ingénieur principal peut dire que cela prendra 15 mois avec une confiance de 80%. Je ferais plus confiance à l'ingénieur principal.

— Thomas Owens

1

En théorie, un développeur ne devrait jamais accepter une estimation faite par une autre personne, peu importe comment elle a été établie. L'une des raisons est que donner une estimation plus longue que celle de votre gestionnaire est à l'aise avec expose immédiatement un problème d'horaire potentiel ou peut-être un malentendu sur la portée du travail à faire.

Les gens trouvent généralement l'estimation du temps de programmation encore plus difficile que la programmation elle-même, donc si votre gestionnaire peut écrire une macro Excel peut résoudre ce problème, il peut probablement construire une macro pour écrire le code (peu probable).

Maintenant, dans la pratique , si vous comprenez le travail et que les estimations semblent raisonnables, il est logique d'exprimer simplement une certaine inquiétude au sujet de la méthodologie en passant, mais d'accord provisoirement pour voir si vous pouvez les respecter. Plus tard, si le travail vous prend plus de temps que prévu, vous devez en informer le plus tôt possible vos gestionnaires. Soyez prêt à discuter des raisons exactes en fonction de votre expérience de mise en œuvre réelle. J'espère qu'à ce stade, votre gestionnaire ne sera pas déraisonnable et continuera d'insister pour que vous travailliez sur des estimations générées mécaniquement.

— PeterAllenWebb
source

-1

L'une des méthodologies de développement logiciel les plus récentes est agile , et l'un des cadres agiles bien connus est Scrum . Mais dans cette méthodologie, les développeurs (équipe Scrum) sont responsables du calcul du temps requis pour effectuer une tâche ou implémenter une user story.

Je dis définitivement NON . Car:

Un gestionnaire non développeur ne peut pas estimer le temps requis pour effectuer un travail
L'estimation du temps requis pour effectuer n'importe quel travail nécessite une certaine intelligence humaine, ce que Excel n'a pas
En acceptant de telles pratiques de travail, le gestionnaire s'habitue progressivement à remplacer les développeurs dans l'estimation des temps. Cela peut entraîner une catastrophe. Considérez ce scénario dans lequel votre responsable dit:

Je veux lancer un nouveau projet de vente de vélos en ligne et je sais qu'il faut 3 semaines à vous et à John pour le réaliser.

— Saeed Neamati
source

5

L'OP n'a aucune mention de l'équipe de son ami utilisant des méthodes agiles. Je ne pense pas que les règles agiles soient pertinentes pour les équipes utilisant d'autres méthodes (ou aucune méthode du tout). Le bon sens devrait cependant :-) De plus, il est évident que ce n'est pas Excel qui a décidé des estimations, il n'a exécuté que des calculs basés sur certaines hypothèses et données (inconnues de nous) (chacune pouvant être correcte ou incorrecte) . Si j'entre des estimations pour une tâche donnée par chacun des membres de notre équipe, puis que je configure Excel pour calculer la moyenne de celles-ci, Excel fait-il l'estimation?

— Péter Török

3

1 et 2 sont manifestement faux. Les modèles d'estimation paramétrique sont largement acceptés dans la gestion de projet logiciel et le sont depuis plus de 20 ans, et toute personne ayant une formation en gestion de projet (ingénieur logiciel ou non) peut être formée pour utiliser ces outils, en supposant qu'ils (ou, de préférence, les ingénieurs de projet) ) sont en mesure de fournir des estimations précises des intrants.

— Thomas Owens

3

-1 - Cela ne répond pas à la question, comporte des erreurs évidentes ("... les dernières méthodologies de développement logiciel sont agiles"), et ne semble rien ajouter de pertinent. Je ne sais pas à quoi servaient les votes positifs ou la réponse acceptée.

— Morgan Herlocker

1

nous ne savons certainement pas à la question si l'estimation paramétrique est la norme dans cette entreprise et / ou si elle est basée sur une bonne histoire de leur entreprise; si tel est le cas, autant que je déteste le dire, il est imprudent de refuser de faire son travail conformément aux procédures opérationnelles acceptées par l'organisation (sans suivre une voie raisonnable de questionnement).

— StevenV

2

@Thomas Je suis d'accord, je pense simplement qu'il y a trop de choses que nous ne savons pas sur la situation pour répondre catégoriquement Oui ou Non. En tout cas, un refus catégorique sans une bonne discussion pour s'assurer que la situation et le raisonnement sont compris est rarement un bonne évolution de carrière.

— StevenV