Quale dovrebbe essere la documentazione di progetto / ambito minima prima dell'inizio dello sviluppo?

when I make decisions based on assumptions [...] I get corrected

Quindi non fare tante ipotesi: chiarisci in anticipo, chiedi! Se la persona che devi chiedere non è sempre disponibile, prepara una lista di domande. E ripeti ogni volta che sorgono nuove domande, regolarmente, forse ogni giorno!

This process happens multiple times throughout a project [...] with broken windows all through it.

Quando migliora il tuo codice più volte, ovviamente dovrebbe diventare migliore, non peggio. Se il tuo codice peggiora, è quasi sempre un segnale che cerchi di aggiungere nuovi requisiti ai tuoi metodi e corsi esistenti ancora e ancora, senza alcuna ristrutturazione del tuo codice, finché non diventano troppo grandi o troppo complicati. Puoi evitarlo iniziando a refactoring più presto. Ogni nuovo requisito aggiunto dovrebbe essere un'occasione per ridefinire il codice lungo il processo in modo che il nuovo requisito possa essere aggiunto più facilmente. Se hai bisogno di ulteriore aiuto, troverai molte informazioni sul refactoring su questo sito.

what should be the minimal design/scope documentation I receive before I begin development

Il tuo equivoco qui è - "qualcun altro scrive tutte le informazioni per me, quindi inizio a codificare". Quando hai chiesto il tuo elenco di domande, scrivi le risposte e aggiungili alla specifica o alla documentazione di progettazione . Quindi attua ciò di cui sei sicuro, finché non si presentano nuove domande. È praticamente impossibile prevedere tutte le domande che avrai per chi scrive la documentazione di design / scope, quindi non aspettarti che lo faccia. Meglio vederlo come un processo incrementale. Quando non hai più domande e hai annotato tutte le risposte che hai ricevuto, la documentazione di design / ambito è completa.

Penso che il problema fondamentale sia nella comunicazione , non nella documentazione.

Inoltre, chiarire le esigenze del cliente e del business con il proprietario del prodotto / BA (o PM se non ci sono analisti aziendali) nella tua organizzazione attraverso una comunicazione efficace ti alleggerirà la vita e ti aiuterà molto buoni risultati con set di cambiamenti meno drammatici.

Come forse saprai, Agile Software Development ha come target gli obiettivi citati sopra e potresti trovare ulteriori informazioni da questo riferimento .

Ho scoperto che non esiste una risposta singola. Nessuna regola d'oro.

Ogni client e progetto richiede un diverso livello di specifiche.

Una cosa è vitale per tutti però - comunicazione . Per il meglio delle tue capacità, fai capire al cliente cosa stai facendo e perché. Assicurati di discutere ogni aspetto del sito web e di comprenderne ogni minima parte.

Ti consiglierei di fare quanto segue: - qual è l'obiettivo finale. - cosa fa questo sito - chi lo usa - Come questo sito aiuta l'azienda

Cerca di rispondere a queste domande prima ancora di pensare in termini di codice. Dopo aver compreso chiaramente ciò che il tuo cliente desidera / ha bisogno, ALLORA dimentica tutto e concentrati sull'implementazione.

Ho avuto clienti che mi hanno dato una breve conversazione di 5 minuti con exaplin per un sistema che impiegherà 2 mesi per essere visualizzato. E avevo specifiche scritte su 10 pagine che richiederebbero 2 giorni di sviluppo.

È importante ricordare che abbiamo uno scopo negli affari del cliente: creiamo qualcosa per loro e abbiamo bisogno di sapere COSA quella cosa è