La risposta breve è che la costruzione del software viene fatta nello stesso modo in cui si mangia un elefante, un morso alla volta fino a quando non ci si strozza.
Quasi tutto il software può essere riassunto nella cosa più semplice che si suppone debba fornire, il valore più alto che si intende riempire. Spesso ci si riferisce a questo come al livello dei 50.000 piedi.
Penso che i Project Manager amino usare questo termine perché amano immaginarsi in un bombardiere ad alta quota che sta per sganciare indiscriminatamente morte fiammeggiante. Se vi trovate in una riunione a 50k piedi e tirate fuori qualcosa che è un po' più basso in altitudine che, non a caso, manda tutto a puttane, sarete rapidamente istruiti a tornare sopra l'hard deck.
Ma ogni progetto inizia con un... che cazzo è questa cosa?
Quindi all'inizio dovete avere una buona idea di cosa sia. Nella mia esperienza, più complicata è la spiegazione della cosa al livello più alto, più alta è la possibilità che sia un fallimento. Se l'elevator pitch per l'idea della cosa è già esperienza di scope creep sei nei guai.
Quindi la prossima domanda è, quali sono le cose che dobbiamo fare per fare la cosa?
Queste sono le caratteristiche. La mia raccomandazione è di mantenere queste cose il più breve possibile. Ogni singola cosa dovrebbe essere esaminata, misurata, testata, punzecchiata, pungolata, ignorata, incendiata, reincarnata e ripulita prima di decidere davvero che dovrebbe essere una caratteristica per il prodotto 0.
Costruite la cosa minore che potete, ma non meno.
È davvero difficile. Tutti, me compreso, possono eccitarsi e iniziare a dire "e questo? Potremmo fare questo? E non sarebbe il massimo? Se lo facciamo, tutti quei ragazzi che ci prendevano in giro alle scuole medie se ne pentiranno"
Basta con queste stronzate. Scoprite cos'è la cosa al suo interno e costruitela. Si chiama Minimum Viable Product se vuoi essere così.
Prendi una di queste caratteristiche e poi dici. Quali cose ho bisogno di fare per far funzionare quella cosa. Continuate a farlo a ritroso fino a quando non avrete una bella lista di tutte le piccole cose che dovete fare per fare quella cosa. Ognuna di queste piccole cose dovrebbe essere fattibile in pochi giorni, non più di una settimana.
Qualcuno probabilmente dirà, Mark, subdolo bastardo, stai diventando tutto Agile con me.
No.
Non mi interessa quale sia la tua particolare religione della metodologia software, devi suddividere quello che stai per fare in pezzi di dimensioni ridotte. Anche quando eravamo a cascata costruivamo merda un po' alla volta.
In parte è solo psicologia.
Vai a costruire Word. Cosa, eh...ah...hmm.
Vai a costruire una finestra di dialogo che ti permetta di salvare un file sul disco rigido. OK.
Lo sviluppo del software è tutta una questione di astrazioni e devi arrivare al punto in cui sei concentrato su un piccolo pezzo e il resto è scontato. Quando costruisco la mia finestra di dialogo per il salvataggio dei file, non so dove o come verrà usata, sto solo costruendo una finestra di dialogo.
Pezzo per pezzo l'elefante si fa mangiare il culo.
Quindi quello che ti sto suggerendo è che forse stai lasciando che la complessità dell'intera cosa si metta sulla strada della piccola cosa. Fai la piccola cosa e poi la prossima piccola cosa e poi integra queste due piccole cose in una cosa più grande. Sciacquare, ripetere.
Ora, alcune cose richiedono molto più pensiero e qualche diagramma e forse anche qualche documento e se stai lavorando con altre persone incontri e discussioni. Non posso dirvi come fare tutto questo perché fate semplicemente quello che deve essere fatto per la cosa su cui state lavorando in quel momento.
Posso dire che molto viene fatto su una lavagna in questi giorni e viene cancellato perché niente di tutto ciò sembra durare, era un pensiero che ci ha fatto passare al successivo. Una volta ero un vero bastardo per avere certi tipi di documenti di design e ora sono molto meno irragionevole al riguardo.