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
la source
la source
Réponses:
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.
la source
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.
la source
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é.
la source
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?
la source
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.
la source
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.
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 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.
la source
On dirait que vous posez deux questions différentes:
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.
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.
la source
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é.
la source
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.
la source
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.
la source
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:
la source