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

Nella mia esperienza il principale "collo di bottiglia" è il processo di apprendimento . Quando la tua ipotetica società si propone di sviluppare il prossimo Microsoft Word, c'è un enorme divario tra ciò che devi sapere e ciò che sai realmente. La dimensione del divario dipende da molti fattori, potrebbe essere nella tecnologia o nel dominio. Hai toccato alcuni di questi problemi nella tua domanda, ad es. 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 a ingaggiare le persone migliori con esperienza nel dominio, sia tecnico che gestionale. Prova a leggere qualsiasi letteratura disponibile sul campo. Cercherò anche di ottenere il feedback dei clienti il prima possibile. Il problema più grosso sono le cose critiche che non conosci e 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 provando a fare qualcosa di nuovo. Per esempio. guarda il Boeing Dreamliner. Ci sono molti libri scritti su questo. Il mese di Mythical Man è uno.

Let's assume that all specifications are in place and the organization is working perfectly.

Hai assunto che i due "colli di bottiglia" più importanti nei processi di sviluppo del software non esistano (dalle mie esperienze personali).

Anche nel tuo mondo ipotetico e perfetto, ci sono alcuni problemi che riesco a vedere:

Probabilmente il più importante, dal mio punto di vista, è trattare con i clienti. Nella mia esperienza personale, l'azienda deve fare i conti con i clienti che spesso cercano di cambiare il progetto mentre è in fase di sviluppo. In alcuni casi, hanno tentato di fornire una richiesta di modifica come soluzione per evitare di dover pagare denaro. Ciò può portare a un sacco di burocrazia che può ritardare un progetto o portare a un attacco rapido di codice che si sviluppa in un debito tecnico più in basso. Ho letto e sentito parlare di gruppi che affrontano questi problemi con la stessa facilità con cui respirano, e sono sicuro che vorrei essere in uno di loro:)

Il secondo problema è la mancanza di un modello di dominio appropriato. Eric Evans fornisce una buona copertura su questo 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 cercare di individuare un bug. Senza un modello di dominio pulito, può essere necessario molto tempo per eseguire il debug del codice per isolare e risolvere un problema. Direi che un buon modello di dominio rende la vita e il debug molto più semplice, ancor più quando si mantiene e si estende l'applicazione più avanti.

I problemi che ho menzionato sopra non producono problemi immediati, ma se hai bisogno di 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 "l'organizzazione funziona perfettamente", ma anche in una fantastica organizzazione, il collo di bottiglia più grande in qualsiasi progetto consistente è la comunicazione. Mythical Man Month indica come, man mano che un team di progetto cresce, le combinazioni di comunicazione esplodono, quasi garantendo errori e informazioni mancanti.

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

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.

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

Sì, sono d'accordo con quanto sopra e deve seguire i modelli del software. Come per mia conoscenza, le cose principali sono:

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

Se abbiamo i quattro precedenti, allora possiamo passare a un nuovo mondo con successo e molti miglioramenti in termini di personalità e software. Ciò porta a un buon rapporto con il cliente e il cliente darà gli ordini senza pensare a noi.

Difetti latenti, requisiti, progettazione, implementazione, distribuzione .... Come in cose così rotti, ma devi ancora trovarlo. Immagina che il software di sviluppo fosse ogni nuovo bug causato dalle modifiche più recenti.