Pianificazione della funzionalità di un nuovo progetto prima di iniziare

Dipende quasi sempre dal progetto.

In una biblioteca ben delimitata, diciamo un parser. Sarebbe di grande aiuto pensare a ogni singola parte della libreria, andando in profondità in "Come sarebbe il parser tracciare linee / colonne e in che modo uno scope sarebbe in grado di accedervi" non sedersi e iniziare a digitare, specifichi la cosa alla morte, farlo in questo modo è davvero divertente e facile da programmare (tutto ciò che devi fare è digitare, non pensare al volo).

Tuttavia in un sito web o in un'app non puoi davvero farlo perché, come hai detto, cambia sempre e, a meno che tu non sia di una squadra, la presentazione di ogni funzione e sottofunzione (app e storie?) è solo un promemoria di cosa fare Quello che dovresti davvero pianificare è una funzione di base generica che non cambia o set di regole. Ad esempio in un sito di e-commerce, hai le cose intuitive di base come, indirizzi utente, carte di credito, inseguitori di spedizione, ecc., Ma quello che dovresti pianificare è come funzionano questi dettagli, come quello che accadrebbe quando un indirizzo di spedizione era sbagliato ma l'articolo era già stato spedito, o se un dettaglio dell'articolo era sbagliato, ora devi fare in modo che il tuo sistema controlli gli ordini che sono accaduti prima della correzione dei dettagli e invia un'email ai clienti. Cose come queste devono essere esaminate e ordinate prima di avviare il tuo sistema, perché a volte qualcosa che pensi non abbia importanza se la aggiungi successivamente ti farà cambiare l'intera cosa.

Ovviamente tutto ciò è basato sulla mia esperienza e opinione, ma dai tempi in cui ho applicato questa semplice pianificazione, ha reso il processo di sviluppo molto più semplice, lontano da errori perfetti ma molto meno numerosi e ripensamenti.

Spero che questo aiuti.

Sembra che tu stia confondendo i requisiti con il design. Non si pianificano i requisiti, si osservano i requisiti (desideri, richieste, caratteristiche necessarie) e quindi si crea un piano tecnico che risponde a tali requisiti.

Non si crea una 'app' o qualsiasi altra unità tecnica per implementare un requisito. Cerchi di riconoscere la logica più ampia dietro la raccolta di requisiti e poi costruisci qualcosa. Come quando molti requisiti riguardano i dati dell'utente, probabilmente si vuole mantenere una collezione di oggetti utente ed essere in grado di memorizzarli in qualche modo. Quindi crei il tuo archivio dati utente. Ciò porterà a un design che si adatta al tuo dominio del problema. Le sorprese potrebbero ancora apparire, costringendoti a ripensare il tuo design, ma con a pochi requisiti dovresti essere in grado di rispondere alla domanda "di cosa stiamo parlando qui" e iniziare a lavorare con quello.

Sebbene il livello di dettaglio varia da progetto a progetto, una specifica e una road map sono per me essenziali. Questo può essere molto formale o meno, ma dovrebbe sempre seguire una struttura per garantire che i passaggi non manchino, come nel tuo esempio di e-commerce.

1. Dichiarazione di ciò che il progetto intende fare fondamentalmente: nel caso di un sito di e-commerce questo è vendere una merce - Manca nel tuo esempio
2. Cosa deve fare per ottenere quanto sopra? Livello superiore.
3. Cosa non deve fare, vincoli normativi, ecc.

Anche a questo livello possiamo individuare alcune cose che al tuo esempio manca di vendere qualcosa che abbiamo bisogno di averlo a disposizione, quindi abbiamo bisogno di un modulo di controllo delle scorte, se vendiamo merci che sono limitate a età o luoghi specifici o vietato in alcuni dobbiamo gestirlo, abbiamo bisogno di sicurezza per assicurarci che non ci venga sottratto e che i dati degli utenti siano al sicuro - questo uscirà dal passaggio 3 in tempi abbastanza brevi.

Questo può essere iterato sul numero desiderato di volte per ottenere il livello di dettaglio richiesto.

Uno abbiamo deciso di cosa abbiamo bisogno siamo in qualche modo per definire i criteri di accettazione e possiamo iniziare a dividere la funzionalità richiesta e desiderata in ciò che dobbiamo avere per una prima versione e cosa può essere fatto in seguito e abbiamo sia una specifica che l'inizio di un piano.

Tieni presente che un piano è non un programma sono cose molto diverse nonostante ciò che ogni project manager che abbia mai incontrato dice . Dal piano e la stima e la programmazione delle specifiche possono essere generati, ma questa è una serie di abilità molto diversa.