Quali tecniche di progettazione e pianificazione sono le più adatte per i singoli progetti?

Consiglierei di concentrarmi su un piccolo progetto alla volta. Se sono complessi, probabilmente vorrai passare un po 'di tempo a pensare prima, in modo da poter penetrare nel dominio del problema, almeno nella misura in cui hai un'idea di come risolvere il problema centrale.

Una volta che hai capito bene, e spesso piccoli schizzi sono un buon modo per arrivarci, inizia a implementare il codice fin dall'inizio con i test unitari, in cui ogni test esprime il risultato desiderato o la capacità del codice di gestire input difettoso o incompleto.

Per una squadra di un solo uomo, la maggior parte delle metodologie standard sono esagerate, ma il principio può ancora essere applicato, anche se su scala molto più ridotta. Non consiglierei di passare troppo tempo su bellissimi diagrammi, gli schizzi disegnati a mano andranno bene. E poiché sembra che tu stia cercando di imparare cose nuove sulla programmazione, non preoccuparti del ciclo di vita.

Guarda un approccio Agile. Inizia prendendo piccole sezioni verticali di ciò che vuoi ottenere e lavorando su quelle in un processo iterativo (un'iterazione che è un lasso di tempo che potrebbe essere piccolo come un giorno o un mese). Più piccola è l'iterazione, più rapido è il feedback su ciò che è stato ottenuto. In tutti i casi, quali sono i requisiti di una cosa all'inizio sono normalmente molto diversi da ciò che sono alla fine e ogni sforzo che metti nei diagrammi, nei flussi di lavoro ecc. È uno sforzo inutile.

Il processo agile è molto soggettivo e si differenzia da un team all'altro ed è troppo ampio per essere discusso qui senza perdere la concentrazione, ma ti suggerisco di leggere uno dei numerosi siti web dedicati.

Mi associo alla stessa idea di cui parla Martin Fowler quando si tratta di diagrammi e documentazione - in pratica solo ciò che ha senso e usali quando possono trasmettere idee ai tuoi clienti e compagni di squadra - che sono entrambi (a questo tempo) TU.

Ho fatto la stessa cosa - ho creato progetti sul lato oa casa. E il seguente mi ha aiutato, si spera, a prendere quello che ti piace - lasciare il resto:

1) Sono ancora abbonato alla vista datacentrica del software di costruzione. I dati (per le app aziendali) sono ancora re. Quali sono i dati e quali sono le relazioni: costruisci un ERD e comprendi il tuo "business" (per la mancanza di un termine migliore).

2) Scrivi una lista di alto livello di "Storie" - le cose che vuoi che la tua applicazione faccia. è possibile utilizzare un approccio individuale agile e dare la priorità a loro e lavorare su di essi in ordine di priorità. Per prima cosa, per esempio: occorrerà registrare gli errori, l'impianto idraulico dei dati, l'infrastruttura dell'interfaccia utente, i servizi di appartenenza (ecc.) Prima di eseguire i moduli principali.

3) Layout di un buon design di alto livello. Non deve essere elaborato, ma metterlo su carta e riferirlo occasionalmente. A volte può aiutarti a vedere la foresta tra gli alberi quando lavori su dettagli precisi in seguito.

3) Costruisci i tuoi moduli principali. Segui le buone pratiche. Qui non tratterò troppi dettagli: sai cosa sono (ad esempio, test delle unità, separazione sui problemi, ecc.)

4) Provalo - OK ... questa è la parte difficile da solo. Prendi un amico o due (mia moglie è un grande tester - benedica il suo cuore). Compra loro la pizza per il loro tempo. Ma devi avere qualcuno che non lo fai, sai troppi trucchi e i tuoi amici sono bravi tester.

5) Crea un piano per l'implementazione o la distribuzione. Il marketing e la distribuzione non sono normalmente la nostra tazza di tè ... quindi potresti voler chiedere aiuto anche con questo.

Enjoy!