In che modo le scadenze serrate e la pressione di programmazione influiscono sul TCO e sui tempi di consegna?

The number one cause of scheduling overruns is scheduling pressure.

Non sono d'accordo. La causa numero uno dei sovraccarichi di schedulazione è un programma che non riflette la realtà e in maniera eccessivamente ottimistica. La natura umana impone che alcune pressioni di programmazione siano una necessità assoluta. Solo un paio dei problemi che sorgono senza una certa pressione di programmazione sono problemi interessanti e "il migliore è il nemico di abbastanza buono". Noi tecnici preferiremmo molto lavorare sui problemi che ci interessano piuttosto che sul problema che deve essere risolto per portare il prodotto fuori dalla porta. Elimina le scadenze (ovvero la pressione programmata) e lavoreremo su questi problemi interessanti, a scapito del prodotto.

Un altro problema è che il prodotto deve essere "abbastanza buono". Non ha bisogno di essere perfetto. Ingegneri e scienziati vedono le ipotesi semplificative che non sono del tutto valide in alcune circostanze particolari. I progettisti grafici vedono problemi di aliasing che sono invisibili a tutti gli altri. I programmatori vedono le verruche nelle loro architetture che hanno un impatto zero sul comportamento del prodotto. "Il meglio è il nemico del buono abbastanza", il che significa che a volte dobbiamo vivere con quei problemi che non sono davvero dei problemi.

La mancanza di una pressione programmata porterà a un prodotto con un costo di proprietà molto elevato. Quali sono le cause dei sovraccarichi sono programmi scadenti. Questo può venire in una varietà di forme. Sottovalutare gli sforzi necessari, non tenere conto delle dipendenze, aggiungere persone a un progetto già in ritardo. Solo per citarne alcuni.

Tempo, qualità, risorse e il numero di funzioni sono tutti collegati. Puoi correggerne tre e ottenere l'ultimo come output del processo di pianificazione.

Il modo in cui la tua domanda è formulata implica che il tempo è la tua variabile, e gli altri tre (la qualità, le risorse e il numero di funzioni) sono tutti corretti. La domanda potrebbe trarre beneficio cambiando leggermente la prospettiva fissando il tempo ^* e lasciando che la qualità fluttui.

Ora la tua domanda diventa questa: "I vincoli temporali hanno un impatto negativo sulla qualità"? La risposta a questa domanda è un sonoro "Sì": la ricerca conferma che le persone fanno di peggio sotto pressione in matematica -related problems ^** che non hanno praticato estensivamente prima (cioè tentato cinquanta volte o più), quindi il padre del tuo amico ha ragione.

^** C'è un'ipotesi implicita qui che la programmazione è simile a fare matematica; Penso che questa ipotesi sia giusta.

the more scheduling pressure you have, the longer the delivery time and the more TCO?

Bene, qualsiasi pianificazione fatta dal manager senza discuterne con il lead tecnico è incline a questo. È ovvio che la pianificazione o le stime che NON sono basate su fatti sono inclini all'errore .

Inoltre, i gestori che evitano programmazione basata sull'evidenza sono anche verso il prossimo fallimento del loro progetto. Esistono numerosi studi su questo argomento e la pianificazione basata sulle metriche è il modo giusto per seguire .

Programmazione da destra a sinistra.

Qualcuno nella gestione pensa sempre di essere Steve Jobs con la sua famosa distorsione della realtà. Finché qualcuno nello sviluppo del prodotto non li educa, i manager non tecnici possono spesso avere una visione della programmazione tanto sofisticata quanto il film francese all'inizio > Le voyage dans la lune "(" Un viaggio sulla luna ") era per la scienza missilistica.

Il problema è in circolazione da un po 'di tempo. Fred Brooks parla della stima senza intestino in mitico Man-Month . Barry Boehm ne parla nelle sue proposte per un approccio alla gestione Theory-W . Più recentemente, Steve McConnell (autore di Codice completo ) mette a fuoco il concetto di problema della negoziazione di principio in "Come difendere una pianificazione impopolare" .

Agile spinge l'ambito dei progetti in un luogo in cui è altamente visibile. Il Agile Manifesto richiede "Collaborazione con il cliente per la negoziazione del contratto". Spero, inoltre, conferisca potere alle persone che sono ritenute responsabili. Il gioco di pianificazione evita gli stakeholder non tecnici che costringono gli sviluppatori a promesse fatte molto tempo fa che sono state invase da cambiamenti nei requisiti o nuove scoperte.

Se la tua organizzazione rifiuta l'agilità, ci sono ottimi metodi relativi alla calibrazione delle stime per rebaseline una pianificazione basata su valore ottenuto . Non penso che il valore guadagnato faccia un ottimo lavoro con alcuni dei veri problemi con la previsione, ma può aiutare a smentire le delusioni sulla velocità dei progetti e sull'arpeare le stime che abbiamo in qualche modo come fatti.

C'è un detto che prima si inizia a codificare, più tempo ci vuole. La pressione del programma può avere l'effetto di forzare il cambiamento della metodologia. A volte è da cascata a "codice come l'inferno". Questo può avere un impatto negativo sulla qualità, per non menzionare il morale quando i lavoratori non possono fare del loro meglio e i loro pari e futuri manutentori li vedono nel loro peggio, non nel loro meglio. In un ambiente come questo, un certo grado del caos può essere controllato con controllo del codice sorgente, build e test giornalieri (o integrazione continua e test unitario), revisioni del codice, utilizzando un team esperto e altamente qualificato, resistendo alla tentazione di aggiungere il personale in ritardo il progetto e il vecchio standby, straordinario.

Altre volte la modifica della metodologia potrebbe essere da cascata a incrementale iterativa. La mia esperienza è stata che la gestione è stata lenta ad abbracciare Agile. Ma dopo un po 'c'è stata una nuova gestione che è stata più favorevole nei confronti di Agile. Il time boxing può essere come fare il bilancio: può costringerci a pensare al miglior uso di una risorsa limitata. Scrum ha due intervalli di tempo: uno è giornaliero per il feedback tra i membri del team, l'altro è mensile per lo sprint attraverso l'elenco di burn down.

LicenzaCreativeCommons-vedi link

Non è necessaria la documentazione di ingegneria del software. La probabilità concettuale e le statistiche, da undergrad, sono tutto ciò di cui hai bisogno.

Una stima è solo questa, una stima. Non è preciso, non è garantito. Per ogni stima, c'è una certa probabilità che la si svincolerà o la si colpirà sul naso, e alcune probabilità che la scavalcerai.

Probabilità 101: p (underrun o hit esattamente) + p (overrun) = 100%.

Una pianificazione basata su una stima ha esattamente le stesse caratteristiche.

Non puoi eliminare completamente l'incertezza. Ci sarà SEMPRE una probabilità di sovraccarico. Potrebbe essere piccola, la probabilità che l'Iran metta a fuoco il tuo edificio per uffici, ma è ancora lì. Il meglio che puoi fare è guardare TUTTO e ridurre l'incertezza il più possibile. Una volta che lo hai fatto, se sei fortunato, avrai un programma con una piccola incertezza e una probabilità del 50% su ciascun lato.

Ora, pensaci: se si inserisce la pianificazione, la probabilità di sviare o colpire esattamente la pianificazione diminuisce. Il totale deve ancora arrivare al 100%. Dove va questa probabilità? Rispondi, va nella probabilità di sovraccarico.

Divisione General Dynamics / Fort Worth ha imparato questo nel modo più duro. Hanno fatto la loro stima iniziale per lo sviluppo di F-16C / D e l'hanno spedito nella catena alimentare. Qualcuno più in alto ne ha arbitrariamente tagliato un anno e lo ha mandato all'Aeronautica. Come risultato diretto, GD / FW era in ritardo di un anno per il test di volo, e l'Air Force NON era felice. (Nota che "un anno di ritardo" era secondo il programma modificato, il che significa che il programma originale era GIUSTO PER L'OBIETTIVO.)

Penso che una certa quantità di pressione in un progetto sia OK perché aiuta a mantenere la concentrazione.

Tuttavia, se la pressione non è realistica, o se la comunicazione tra la direzione e il personale tecnico non funziona correttamente, sì, c'è il rischio che la pressione di pianificazione porti a cattiva qualità e / o consegna tardiva.

Uno sviluppatore esperto saprà che non è previsto che produca la soluzione perfetta, ma piuttosto una soluzione abbastanza buona . Quindi la stima fornita da un tale sviluppatore rifletterà già la loro comprensione di ciò che è abbastanza buono per un particolare progetto.

Ci sono molti fattori che influenzano la definizione di abbastanza buono.

Ad esempio, quanti mesi dura il progetto? Se il progetto dura un anno, è possibile scrivere un prototipo di quel modulo particolarmente difficile piuttosto rapidamente all'inizio del progetto e poi si hanno diversi mesi per testarlo e debuggarlo come attività secondaria per lo sviluppo di altri moduli di routine. (Puoi lasciare il modulo maturo per diversi mesi fino a quando è abbastanza buono in modo da non doverlo riprovare fin dall'inizio.) Trovo questa strategia molto efficace ma hai bisogno di un manager che si fidi di te e ti permetterà di mantenere un progetto aperto per mesi. Un altro (diffidente) manager potrebbe spingerti a finire quel modulo il prima possibile (non importa se dovrai ripararlo più tardi e se questo approccio alla fine richiederà molto più tempo in totale).

Un altro esempio: il progetto è per un prodotto che avrà una sola versione. Quindi puoi provare a farlo rapidamente e fare affidamento su test approfonditi per garantire che il prodotto funzioni come previsto (veloce e sporco abbastanza buono ). D'altra parte, se il prodotto avrà due o tre rilasci, meglio dedicare del tempo a progettarlo, per evitare una riscrittura estesa del codice per le versioni successive. (In questo caso, rapido e sporco è non abbastanza buono perché il tempo di sviluppo totale delle tre versioni è maggiore.)

In conclusione, ritengo che una cattiva comunicazione tra persone di gestione e tecnici e la mancanza di una comprensione comune di ciò che è abbastanza buono per il progetto possa portare a una pressione eccessiva di programmazione, con conseguente cattiva qualità / consegna tardiva.

Non c'è mai abbastanza tempo per farlo correttamente la prima volta, ma c'è sempre abbastanza tempo per sistemarlo più tardi.