Uno sviluppatore dovrebbe accettare una stima del carico di lavoro eseguita da una macro di Excel?

Dipende da quanto ragionevoli guardano allo sviluppatore e da quali dati / logica sono basati su. (potrebbero potrebbero essere basati su dati statistici raccolti in diversi anni su quanto tempo è stato richiesto - da questo sviluppatore stesso e / o da altri - per risolvere compiti simili in passato ... o loro < em> potrebbe essere basato interamente sulle supposizioni del suo manager, corrette o errate.)

Idealmente, dovrebbe discutere con il suo manager che non ci si può ragionevolmente aspettare che si impegni e si assuma la responsabilità di un compito stimato da qualcun altro.

Rifiutarsi chiaramente di impegnarsi nelle stime può effettivamente portare alla sua pronta sostituzione, quindi è meglio avere un approccio più morbido ed evitare il confronto diretto se possibile.

Presumibilmente la macro funziona su una sorta di dati di input, non è solo un generatore di numeri casuali? Quindi, per rispondere alla tua domanda, dobbiamo sapere quali sono i dati di input e cosa fa la macro. Senza questo nessuna risposta è priva di significato.

Oppure la tua domanda riguarda davvero l'accettazione delle stime prodotte da un manager che manca di esperienza rilevante? In questo caso la risposta è no, tu (o il tuo amico) dovresti produrre le loro stime e inviarle al manager. Se le 2 cifre non coincidono, devono collaborare per capire il modo migliore di procedere - magari accettando di scrivere meno test o magari impiegare più tempo per scriverle tutte.

Il rifiuto del bianco non aiuterà nessuno, e lavorare in un lasso di tempo che non puoi soddisfare non è affatto divertente, la soluzione sta nel prendere un approccio professionale e arrivare a un compromesso che permetta al lavoro di procedere.

Sicuramente NO.

Un programma di piccole dimensioni, anche un programma ampio e complicato, non è in grado di stimare quanto tempo impiegherà un lavoro di programmazione. Vedi Limiti matematici alla stima del software per i motivi. È inoltre disponibile un documento più lungo con revisione tra pari, Grandi limiti alla stima del software .

Vorrei anche riconsiderare la mia opinione sul gestore in questione: perché crede che una macro di foglio elettronico non sia stata provata in passato, dato che tutto il resto è stato provato a stimare la durata dell'attività software in passato.

Ugh!

Questo è un gigantesco "odore di lavoro". Questa è un'incredibile micro-gestione.

Se non possono fidarsi dei propri dipendenti per fornire una stima, con che altro non si fidano di te?

Assolutamente NO.

Vi prometto che il manager non è così illuso di pensare che la sua macro di Excel possa prevedere con precisione le stime. Non sto nemmeno discutendo di quello che dovrebbe essere un fatto ben noto che ci sono troppe variabili coinvolte per prevedere con precisione qualcosa di simile in un algoritmo. Se ha inventato un tale algoritmo, dovrebbe brevettarlo e fare milioni secondo me.

Ciò che sta realmente accadendo qui è che il manager usa questa presunta macro Excel come un travestimento sottilmente velato per nascondere il fatto che sta forzando aspettative irrealistiche e indebita pressione sui suoi sviluppatori.

Sa che è BS e non gli interessa, è una scusa per prenotare le risorse e cercare di fare le cose più velocemente facendo in modo che tutti i suoi "inutili" sviluppatori perpetuamente "LATE".

Questo manager sembra uno stronzo sfruttatore.

In a new project, a friend had to write tests where the time required to write them was calculated by an Excel macro written by his non-developer manager.

Ci sono modelli di stima parametrica per stimare i tempi di completamento dei progetti, compresi i progetti software. Di solito, la stima è per codice di produzione, ma non vedo perché non possa essere estrapolata per stimare quanto tempo ci vorrà per scrivere il codice di test. Queste stime sono valide solo come i dati che vengono inseriti in esse,

Supponendo che il metodo utilizzato sia un modello di stima valido e che i dati siano accurati e validi, non c'è motivo per cui una buona stima non possa provenire da una macro di Excel scritta da un gestore non sviluppatore.

In such circumstances, should a developer accept the responsibility to write and run the tests in the calculated time?

Nessuna stima dovrebbe mai essere accettata ciecamente, in nessuna circostanza. Nessuna stima è mai perfetta, indipendentemente da come viene generata. Spetta all'ingegnere esaminare tutte le stime, identificare potenziali problemi, valutarne l'impatto e discutere e perfezionare la stima secondo necessità.

Are the results of these test trustworthy?

I test valgono solo quanto lo sforzo di progettazione e implementazione. Se un tester produce test di bassa qualità, i difetti passeranno attraverso i test e lo faranno in una fase successiva del progetto. È ovvio che la pressione programmata porterà a test di bassa qualità, quindi se il tempo non è sufficiente per progettare i casi di test appropriati e quindi implementare tali casi, i test non sarebbero altrettanto utili.

Sembra che tu stia facendo due diverse domande:

Are the results of these test trustworthy?

Excel è uno strumento come qualsiasi altro con cui lavoriamo e ciò su cui sono stati scritti i calcoli non dovrebbe davvero avere un impatto sui risultati dell'algoritmo stesso. Il fatto che la stima provenga da una macro di Excel è irrilevante se i risultati del calcolo (vale a dire la validità della stima) sono validi o meno. Se si hanno ipotesi errate nel modello sottostante, non importa ciò che si usa per eseguire il calcolo poiché le ipotesi sottostanti non sono corrette.

In such circumstances, should a developer accept the responsibility to write and run the tests in the calculated time?

Se il requisito che lo sviluppatore fa il lavoro nel tempo indicato è nei loro contatti, allora non c'è molto che possano fare per argomentarlo finché le stime sono ragionevoli. Il che porta al punto successivo: se i calcoli stanno dando una quantità ragionevole di tempo e sono simili alle stime che lo sviluppatore darebbe a se stessi, non vi è alcun motivo per non opporsi alle scadenze date. In effetti, potrebbe funzionare a vantaggio degli sviluppatori in quanto potrebbero essere in grado di influenzare le ipotesi utilizzate nel modulo in contrasto con una tempistica arbitraria.

Se le tempistiche sembrano impossibili per la quantità di lavoro richiesta, ovviamente dovrebbero sollevare questa preoccupazione e provare a lavorare con il manager per ottenere timeline più realistiche, ma se la tempistica è fattibile avranno difficoltà a opporsi a loro.

In termini di gestione del progetto e di tempistiche di stima, sì, può essere fatto ma dipende in gran parte dalla natura del lavoro svolto. Probabilmente vedrai stime più accurate date per il tempo necessario per scrivere il codice di test unitario (supponendo che lo sviluppatore comprenda il framework e le abbia scritte prima) di quanto tu possa scrivere un nuovo codice contro i casi d'uso in cui viene scritto il codice di test per.

Non voglio eseguire il down-play dei test di scrittura, ma il progetto ha probabilmente avuto diversi sviluppatori prima di scriverli. Se le stime si basano su questi dati, potrebbero essere più accurate di quanto ipotizzato dal tuo amico. Dal momento che il tuo amico ha lasciato il progetto, non ha fatto alcun tentativo di creare stime opposte o vedere se potevano essere completate come previsto, non lo sapremo mai.

Tutto quello che doveva fare era completare uno o due test per vedere quanto accurata fosse la stima, e tornare al manager con un argomento legittimo. Potrebbero esserci altri membri del team che potrebbero aver fornito feedback sull'affidabilità delle stime o sulle conseguenze del ritardo. A volte un manager deve dare "qualcosa" al suo capo per rendere tutti felici. Gli sviluppatori vedono questo come un falso senso di sicurezza. Forse se ci fosse un movimento per gli sviluppatori di fornire stime e mostrare la volontà di fare le cose, la gestione potrebbe sviluppare più fiducia.

Quello che immagino sia, se fosse in grado di completare i test in meno tempo, non direbbe nulla al riguardo. Quindi, di nuovo, scusarsi da una pratica in cui non crede, può indicare un alto livello di integrità.

Risposta facile e breve:

Non ti interessa da dove proviene la stima.

Ciò che realmente ti preoccupa è la stima stessa. Accetto o non essere d'accordo e spiega perché e quanto tu valuteresti. Questo è il più importante.

In teoria, uno sviluppatore non dovrebbe mai accettare una stima fatta da un'altra persona, indipendentemente da come sia arrivata. Uno dei motivi è che dare una stima più lunga di quanto il tuo manager sia a suo agio, espone immediatamente un potenziale problema di pianificazione o forse un equivoco sullo scopo del lavoro da svolgere.

Le persone in genere trovano la stima del tempo di programmazione ancora più difficile della programmazione stessa, quindi se il tuo manager può scrivere una macro di Excel può risolvere il problema che , probabilmente può costruire una macro per scrivere il codice (improbabile ).

Ora, nella pratica , se capisci che il lavoro e le stime sono ragionevoli, ha senso esprimere semplicemente qualche preoccupazione sulla metodologia di passaggio, ma poi acconsenti provvisoriamente a vedere se riesci a soddisfarli . Successivamente, se il lavoro ti richiede più tempo delle stime, dovresti attirare l'attenzione dei tuoi dirigenti il prima possibile. Siate pronti a discutere le ragioni esatte in base alla vostra effettiva esperienza di implementazione. Speriamo che a quel punto il tuo manager non sarà irragionevole e continuerai a insistere per lavorare su stime generate meccanicamente.

Una delle più recenti metodologie di sviluppo del software è agile e uno dei framework agili ben noti è scrum . Ma in questa metodologia, gli sviluppatori (scrum team) sono responsabili del calcolo del tempo richiesto per eseguire un'attività o implementare una user story.

Sicuramente dico NO . Perché:

1. Un gestore non sviluppatore non può stimare il tempo richiesto per eseguire un lavoro
2. La stima del tempo necessario per svolgere qualsiasi lavoro richiede una certa intelligenza umana, che Excel non ha
3. Accettando queste pratiche di lavoro, il manager si abitua progressivamente a sostituire gli sviluppatori nella stima dei tempi. Ciò può provocare una catastrofe. Considera questo scenario in cui il tuo manager dice:

I want to start a new project for selling bicycles online and I know that it takes 3 weeks for you and John to accomplish it.