Quali sono i maggiori colli di bottiglia nello sviluppo di grandi progetti? [chiuso]

Diciamo che la mia azienda doveva sviluppare una replica di MS Word (solo come esempio). Quale sarebbe il collo di bottiglia nel processo di sviluppo, supponendo che si disponga di infiniti contanti e di un'organizzazione come Microsoft? In altre parole, quali sono gli ostacoli più comuni nello sviluppo rapido di questo software? Supponiamo che tutte le specifiche siano a posto e che l'organizzazione funzioni perfettamente, quindi ci concentriamo sullo sviluppo del software fino a quando il prodotto non sarà pronto per la spedizione. Alcune alternative potrebbero essere: - Scrivere il codice - Scrivere test - Testare manualmente il prodotto finale - Riscrivere il codice a causa della cattiva progettazione in primo luogo - Progettare il codice - Revisione del codice fatta da sviluppatori esperti - Progettazione della GUI - Riprogettazione della GUI basata su alpha / feedback utenti beta - Elaborazione feedback degli utenti - In attesa di feedback utenti alpha / beta

Utilizzare i riferimenti nella risposta o dichiarare la propria esperienza sull'argomento.

Nella mia esperienza il principale "collo di bottiglia" è il processo di apprendimento . Quando la tua ipotetica azienda si propone di sviluppare la prossima Microsoft Word, c'è un enorme divario tra ciò che devi sapere e ciò che effettivamente conosci. La dimensione del divario dipende da molti fattori, può essere nella tecnologia o nel dominio. Hai toccato alcuni di questi problemi nella tua domanda, ad esempio design, feedback degli utenti, ecc. Microsoft Word è in sviluppo da oltre 30 anni, quindi tra storia, codice, strumenti e persone c'è molta conoscenza dietro di esso.

Quindi, se dovessi provare a farlo, proverei ad assumere le persone migliori con esperienza nel settore, sia tecnico che gestionale. Prova a leggere tutta la letteratura disponibile sul campo. Proverei anche a ottenere il feedback dei clienti il ​​più presto possibile. Il problema più grande sono le cose critiche che non conosci e che potresti scoprire molto tardi nel tuo processo.

Questo, a proposito, non è unico per i progetti software. È vero per ogni progetto su larga scala in cui stai cercando di fare qualcosa di nuovo. Ad esempio, guarda il Boeing Dreamliner. Ci sono molti libri scritti su questo. Il mese dell'uomo mitico è uno.

Supponiamo che tutte le specifiche siano a posto e che l'organizzazione funzioni perfettamente.

Hai assunto i due maggiori "colli di bottiglia" nei processi di sviluppo del software (dalle mie esperienze personali).

Anche nel tuo ipotetico mondo perfetto, ci sono alcuni problemi che posso vedere:

Probabilmente il più importante, dal mio punto di vista, è trattare con i clienti. Nella mia esperienza, l'azienda deve confrontarsi con clienti che spesso cercano di cambiare il progetto mentre è in fase di sviluppo. In alcuni casi, hanno cercato di inoltrare una richiesta di modifica come correzione di bug per evitare di dover pagare denaro. Questo può portare a molta burocrazia che può ritardare un progetto o portare a rapidi hacking di codice che si sviluppa in debito tecnico più in basso. Ho letto e sentito parlare di squadre che affrontano questi problemi con la stessa facilità con cui si respira, e vorrei davvero essere in uno di loro :)

Il secondo problema è la mancanza di un modello di dominio adeguato. Eric Evans ne fornisce una buona copertura nel suo libro: Domain Driven Design . La mancanza di un buon modello di dominio porta ad alcuni dei problemi evidenziati nella risposta di Glenn, come il tentativo di individuare un bug. Senza un modello di dominio pulito, può essere necessario tempo per esaminare / eseguire il debug del codice per isolare e risolvere un problema. Direi che un buon modello di dominio semplifica notevolmente la vita e il debug, ancor più quando si mantiene e si estende l'applicazione più avanti.

I problemi che ho menzionato sopra non comportano problemi immediati, ma se è necessario mantenere questo prodotto per un lungo periodo di tempo, potrebbero tornare a perseguitare te e il tuo team.

Non sono sicuro di cosa intendi per "organizzazione che funziona perfettamente", ma anche in un'organizzazione fantastica, il più grande collo di bottiglia in qualsiasi progetto considerevole è la comunicazione. Mythical Man Month sottolinea come, man mano che il team di progetto cresce, esplodono le combinazioni di comunicazione, garantendo quasi errori e informazioni mancanti.

Da quello che ho visto finora al lavoro, una grande fonte di colli di bottiglia proviene semplicemente da bug e dall'errore umano che li ha creati. Basta pensare al tempo necessario per eseguire il debug del codice, trovare una soluzione al problema e quindi ripetere il test della nuova soluzione. Ora immagina se quella correzione ha causato un altro bug sottile. Può essere un grande flusso di dolore e quindi rallenta lo sviluppo in generale.

Penso che Brandon Moretz abbia la migliore risposta. Ma voglio aggiungere che ottenere la prima versione da un grande progetto non è poi così difficile. Personalmente non ho mai mancato di farlo.

Quello che non sono riuscito a fare è stato creare la prima versione in modo tale che la seconda, la terza versione ecc. E / o correzioni di bug e / o miglioramenti minori delle funzionalità possano essere consegnati in modo tempestivo.

Sì, sono d'accordo con quanto sopra e devo seguire i modelli software. Per quanto ne so, le cose principali sono:

1. Gestione del tempo 2. Efficienza del team e gestione del team 3. Coordinamento nel team e 4. Migliore comprensione con il cliente

Se abbiamo i quattro precedenti, possiamo spostarci in un nuovo mondo con successo e molti miglioramenti in termini di personalità e software. Ciò porta a buoni rapporti con il cliente e il cliente darà gli ordini senza pensarci.

Difetti latenti, nei requisiti, nella progettazione, nell'implementazione, nella distribuzione ... Come nelle cose che è rotto ma non si è ancora trovato. Immagina lo sviluppo del software se ogni nuovo bug fosse causato dalle modifiche più recenti.