È bene iniziare con un sottoinsieme di requisiti semplice e quindi estendere il programma?

La risposta generale è: dipende: -)

Nella maggior parte dei casi, il primo approccio va bene. Questo è simile al metodo Agile, che funziona bene in molti progetti reali. Soprattutto con i requisiti che cambiano frequentemente - che è un dato nella maggior parte dei casi -, non c'è molto motivo per provare a fare Big Design Up Front.

In alcuni casi, il secondo approccio potrebbe essere migliore. Posso pensare

• app essenziali per la vita in cui non c'è spazio per la sperimentazione e i requisiti devono essere estremamente ben definiti all'inizio del progetto,
• applicazioni critiche per le prestazioni in cui è necessario comprendere l'intera immagine e progettare le strutture dati e gli algoritmi con attenzione fin dall'inizio, al fine di garantire le prestazioni necessarie.

Si noti che non esiste tuttavia un ampio divario tra i due approcci: i progetti agili iniziano assemblando un sistema di scheletri (dopo solo la quantità necessaria di analisi e progettazione) che è in grado di dimostrare qualcosa, per quanto semplice o banale, che il sistema funziona fino alla fine, quindi aggiunge gradualmente più funzionalità. Mentre le app critiche per le prestazioni o per la vita, una volta che i requisiti e la fase di progettazione sono stati eseguiti e implementati, lo scheletro (di solito molto più robusto e dettagliato) del sistema, può anche aggiungere funzionalità individuali in modo incrementale (a seconda della timeline e delle risorse disponibili).

“Make things as simple as possible, but not simpler.”

È buono quando si avvia il programma in modo semplice e poi lo si estende gradualmente.
I grandi progetti iniziano sempre con qualcosa, e con l'approccio agile penso che tu sia sulla strada giusta.

Una cosa che dovresti assicurarti è che non dipendere dalla semplicità iniziale .

Diamo un'occhiata al tuo esempio.

1) Try to make the program able to transfer 1 file
2) Try to make the transfer into a queue
3) Try to implement multi-threading

Durante la seconda iterazione, definirai le classi più importanti per il programma.
Creerai le astrazioni per i file, probabilmente rimettendo l'astrazione di base del server dalla prima iterazione e il gestore del trasferimento stesso. Dovrai anche creare una sorta di GUI che permetta di lavorare con più file e legare questo frontend al backend.

Dopo questa fase, la modifica dell'API di base sarà difficile . Per questo motivo, assicurarsi di non dover riprogettare l'intero sistema alla terza iterazione. Quando fai il secondo iteration design, mantieni le cose semplici e abbastanza flessibili (sei fortunato quando sai che cosa cambierà ma non è sempre così).

In pratica, questo di solito significa ridurre le dipendenze con Inversion of Control pattern , interagendo con il back-end (e all'interno anche il back-end) utilizzando le interfacce e separando i diversi pezzi di logica in moduli indipendenti che possono essere successivamente sostituiti facilmente.

Personalmente proverei a fare il secondo metodo perché il primo modo tende a finire con grandi riprogettazioni per implementare il prossimo bit di funzionalità e soddisfare tutti i requisiti. Penso che alla fine ti ritrovi con un design migliore invece di qualcosa che è insieme accartocciato che non è coerente, ma solo di lavoro.