In che modo tempistiche rigide e pressioni di programmazione influiscono sul TCO e sui tempi di consegna?

Il padre di un amico, che è un responsabile dell'ingegneria del software, ha affermato con enfasi: "La causa numero uno di pianificazione dei sovraccarichi è la pressione programmata".

Dove sta la ricerca? Una moderata pressione di pianificazione è corroborante, oppure il manager che ho citato è giusto o sbagliato, oppure è una questione di "maggiore è la pressione di pianificazione che hai, maggiore è il tempo di consegna e più TCO?" È una di quelle cose in cui idealmente l'ingegneria del software funzionerebbe senza programmare la pressione, ma praticamente dobbiamo lavorare con i vincoli delle situazioni del mondo reale?

Qualsiasi link alla letteratura di ingegneria del software sarebbe apprezzato.

La causa numero uno dei sovraccarichi di pianificazione è la pressione di pianificazione.

Non sono d'accordo. La prima causa della pianificazione dei sovraccarichi è un programma che non riflette la realtà e in modo eccessivamente ottimistico. La natura umana impone che una certa pressione di programmazione sia una necessità assoluta. Solo un paio di problemi che sorgono senza una certa pressione sulla pianificazione sono problemi interessanti e "il migliore è il nemico del abbastanza buono". Noi tecnici preferiremmo di gran lunga 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 deve 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 alias invisibili a tutti gli altri. I programmatori vedono le verruche nelle loro architetture che non hanno alcun impatto sul comportamento del prodotto. "Il migliore è il nemico del bene", il che significa che a volte dobbiamo convivere con quei problemi che non sono realmente problemi.

La mancanza di una pressione programmata porterà a un prodotto con un costo di proprietà molto elevato. Ciò che provoca sovraccarichi è una cattiva pianificazione. Questo può presentarsi in una varietà di forme. Sottovalutare gli sforzi necessari, non riuscire a tenere conto delle dipendenze, aggiungere persone a un progetto già in ritardo. Solo per citarne alcuni.

Tempo, qualità, risorse e numero di funzioni sono tutti collegati. È possibile risolverne uno qualsiasi e ottenerne 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 funzionalità) sono tutti fissi. La domanda può trarre vantaggio dal cambiare leggermente la prospettiva fissando il tempo ^* e lasciando fluttuare la qualità.

Ora la tua domanda diventa questa: "I vincoli temporali influiscono negativamente sulla qualità"? La risposta a questa domanda è un "Sì" clamoroso: la ricerca conferma che le persone fanno di peggio sotto pressione su problemi di matematica ^** che non hanno mai praticato ampiamente 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 questo presupposto sia giusto.

più pressione di pianificazione hai, più lunghi sono i tempi di consegna e più TCO?

Bene, qualsiasi programmazione fatta dal manager senza discuterne con il capo tecnico è incline a questo. È ovvio che la programmazione o le stime NON basate su fatti sono inclini al fallimento .

Inoltre, i manager che evitano la pianificazione basata sulle prove si stanno muovendo verso il prossimo fallimento del loro progetto. Esistono numerosi studi su questo argomento e la pianificazione basata su metriche è il modo giusto di seguire.

Programmazione da destra a sinistra.

Qualcuno nel management pensa sempre di essere Steve Jobs con la sua famosa zona di distorsione della realtà. Fino a quando qualcuno nello sviluppo del prodotto non li educa, i manager non tecnici possono spesso avere una visione della programmazione sofisticata come il primo film francese "Le voyage dans la lune" ("A Trip to the Moon") era per la scienza missilistica.

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

Agile spinge l'ambito dei progetti in un luogo in cui è altamente visibile. Il Manifesto Agile richiede "Collaborazione del cliente sulla negoziazione del contratto". Spero anche che autorizzi le persone ritenute responsabili. Il gioco di pianificazione evita che parti interessate non tecniche costringano 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'agile, ci sono ottimi metodi relativi alla calibrazione delle stime per ridisegnare un programma basato sul valore guadagnato . Non credo che il valore guadagnato faccia un ottimo lavoro con alcuni dei reali problemi con la previsione, ma può aiutare a dissimulare le delusioni sulla velocità dei progetti e sull'arpionamento delle stime che abbiamo in qualche modo fatti.

Si dice che prima inizi a scrivere codice, più tempo impiegherà. La pressione programmata può avere l'effetto di forzare il cambiamento della metodologia. A volte è da cascata a "codice come l'inferno". Ciò può avere un impatto negativo sulla qualità, per non parlare del morale quando i lavoratori non possono fare del loro meglio e i loro colleghi e futuri manutentori li vedono nel loro peggio, non nel loro meglio. In un ambiente come questo, un certo grado di caos può essere controllato con il controllo del codice sorgente, build e test giornalieri (o integrazione continua e unit test), revisioni del codice, utilizzando un team esperto e altamente qualificato, resistendo alla tentazione di aggiungere personale tardi il progetto e il vecchio standby, lavoro straordinario.

Altre volte il cambio di metodologia potrebbe essere da cascata a incrementale iterativo. La mia esperienza è stata che il management è stato lento ad abbracciare Agile. Ma poi dopo un po 'ci fu una nuova gestione che era più favorevole nei confronti di Agile. Il time boxing può essere come un budget: può costringerci a pensare al miglior uso di una risorsa limitata. Scrum ha due time box: uno è ogni giorno per il feedback tra i membri del team, l'altro è mensile per lo sprint attraverso l'elenco di burn down.

Licenza Creative Commons: vedi http://en.wikipedia.org/wiki/File:Scrum_process.svg

Non hai bisogno di documentazione sull'ingegneria del software. Probabilità concettuali e statistiche, da studente universitario, sono tutto ciò che serve.

Una stima è proprio questo, una stima. Non è preciso, non è garantito. Per qualsiasi stima, c'è una probabilità che tu lo scarichi o lo colpisca sul naso, e qualche probabilità che tu lo superi.

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

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

Non è possibile eliminare completamente l'incertezza. Ci sarà SEMPRE una certa probabilità di superamento. Potrebbe essere piccolo, la probabilità che l'Iran dia fastidio al tuo edificio per uffici, ma è ancora lì. Il meglio che puoi fare è guardare TUTTO e ridurre l'incertezza il più possibile. Una volta fatto ciò, se sei fortunato, avrai un programma con una piccola incertezza e una probabilità del 50% su ogni lato.

Ora, pensaci: se estendi il programma, diminuisce la probabilità che tu ti scarichi o colpisca esattamente il programma. Il totale deve ancora arrivare al 100%. Dove va quella probabilità? Risposta, va nella probabilità di superamento.

La divisione General Dynamics / Fort Worth l'ha imparato nel modo più duro. Hanno fatto la loro stima iniziale per lo sviluppo dell'F-16C / D e l'hanno inviata nella catena alimentare. Qualcuno più in alto arbitrariamente ne tagliò un anno e lo mandò all'Aeronautica. Di conseguenza, GD / FW era in ritardo di un anno per i test di volo e l'Aeronautica militare NON era contenta. (Si noti che "un anno di ritardo" era in base al programma rivisto, il che significa che il programma originale era GIUSTO SU TARGET.)

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

Tuttavia, se la pressione non è realistica o se la comunicazione tra dirigenti e tecnici non funziona correttamente, sì, esiste il rischio che la pianificazione della pressione si traduca in cattiva qualità e / o consegna tardiva.

Uno sviluppatore esperto saprà che non dovrebbe produrre la soluzione perfetta, ma piuttosto una soluzione che sia abbastanza buona . Quindi la stima fornita da 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 quindi si hanno diversi mesi per testarlo ed eseguirne il debug come attività secondaria per lo sviluppo di altri moduli più di routine. (Si può lasciare che il modulo maturi per diversi mesi fino a quando non è abbastanza buono quindi non c'è bisogno di cercare di farlo bene fin dall'inizio.) Trovo questa strategia molto efficace, ma avete bisogno di un manager che si fida di voi e vi permetterà di mantenere un progetto aperto per mesi. Un altro manager (diffidente) potrebbe spingerti a finire quel modulo il più presto possibile (non importa se dovrai ripararlo in seguito e se questo approccio alla fine costerà 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 versioni, è meglio dedicare un po 'di tempo alla progettazione, per evitare una riscrittura estesa del codice per le versioni successive. (In questo caso, veloce e sporco non è abbastanza buono perché il tempo di sviluppo totale nelle tre versioni è maggiore.)

In conclusione, penso che una cattiva comunicazione tra management e tecnici e la mancanza di una comprensione comune di ciò che è abbastanza buono per il progetto in corso possa portare a un'eccessiva pressione di programmazione, con conseguente cattiva qualità / consegna in ritardo.

Non c'è mai abbastanza tempo per farlo correttamente la prima volta, ma c'è sempre abbastanza tempo per ripararlo in seguito.