Metodologie del ciclo di vita del software per squadre individuali [chiuso]

Sto costruendo un sistema software per il mio progetto di master e stavo cercando consigli su metodologie particolari che sarebbero adatte a un "team di un uomo" ...

Mi guadagno da vivere come una "pistola software a noleggio" individuale che lavora principalmente da casa, quindi muoio dalla voglia di sentire ciò che gli altri hanno da dire al riguardo.

Ecco alcune cose che ho trovato importanti:

• Come dice Denis, il controllo del codice sorgente è vitale, ma SVN non è l'unica opzione. Uso principalmente Perforce e git è una buona alternativa. Mi piace un modello di sviluppo "mainline"; che mi permette di fare esperimenti nei rami del codice, unirli nella linea principale quando funzionano e spazzarli via se non lo fanno.
• Uso un quaderno per appunti e un programma per il monitoraggio delle attività. Attualmente uso Redmine per quest'ultimo; prima di allora, ho usato Fogbugz. Mi piace anche Redmine perché ha un wiki integrato davvero buono, che posso usare per note persistenti e collegamenti a siti importanti.
• È anche fondamentale tenere traccia di ciò che sto facendo e impostarmi una sorta di limiti ragionevoli in modo da fare abbastanza senza esaurirmi - vedi sotto.

Le mie altre tecniche si sono evolute nel corso degli anni e le ho modificate in base al progetto e al cliente. Le persone mi pagano per il codice di lavoro, non per scherzare con il processo, quindi provo a mantenere il processo leggero e lontano dai volti dei miei clienti. Ma trovo che alcune tecniche Agile funzionino davvero bene per me:

• Uno dei miei attuali clienti tende a rilasciare grandi funzionalità su di me da implementare e non mi infastidisce fino a quando non hanno finito. Quindi trovo che lavorare su quelli negli Scrum Sprint sia fantastico. Suppongo che potrebbe funzionare per un progetto di master a meno che il tuo consulente di ricerca non sia un maniaco del controllo.
• L'altro mio cliente attuale tende ad avere più emergenze di un tipo "smetti di lavorare su questo e risolvi quel". Ho provato a farlo con Scrum e ho rinunciato dopo uno sprint. Quindi lo sto facendo usando Kanban, e funziona molto meglio.

L'altro motivo per cui devi lavorare da solo è che non hai nessuno che ti dica cosa fare o quando, o se stai facendo abbastanza, o quando smettere di lavorare perché hai fatto abbastanza - quindi devi fare quello per te. Personalmente preferisco Scrum perché posso tenere traccia di come sto andando di fronte ai miei obiettivi di sprint. Per i progetti Kanban, posso solo tenere traccia di quanto tempo sto impiegando, ma non mi piace così come qualcosa di più basato sugli obiettivi.

Alcuni miei amici giurano su Pomodoro come un modo per tenerli concentrati sui compiti e tenere traccia dell'efficienza personale, e sto pensando di provarlo.

Ho anche un processo formale per rilasciare codice ai miei clienti per assicurarmi che quello che stanno ottenendo sia "giusto", ma probabilmente non rientra nello scopo di ciò che mi stai chiedendo.

Usa SVN sopra, versione tutto. Per il tracciamento, Notebook farà per progetti più semplici, se necessario hai molte applicazioni gratuite di tracciamento di attività / bug (Redmine è interessante). Agile / XP / Integrazione continua / altri sarebbero un po 'eccessivi secondo me.

A parte il processo del software personale , non ho trovato molto sui modelli di processo formali progettati per essere utilizzati da un singolo sviluppatore. La PSP è piuttosto pesante per la documentazione e le scartoffie (nella sua forma grezza, comunque), senza molto da dire per particolari tecniche sull'esecuzione del lavoro (invece, la PSP si concentra sulla raccolta dei dati per trovare aree da migliorare), ma è un inizio punto per lo sviluppo di un processo personale che è possibile utilizzare su progetti medio-piccoli.

Penso che il miglior modo di agire sarebbe semplicemente quello di seguire alcune best practice scelte in modo appropriato (in base alle tue esigenze e al progetto) ampiamente accettate da una serie di modelli di processo. Dai un'occhiata ai metodi per tenere traccia del lavoro svolto / lavoro rimanente, gestione dei requisiti, controllo della versione, test (in particolare test di unità e collaudo), integrazione continua, standard di codifica, Non ne avrai bisogno e così via. Se non lo hai fatto, ti suggerisco di leggere Code Complete e The Pragmatic Programmer e di mettere in pratica i loro consigli.

La cosa più importante del lavoro individuale è che, a parte qualsiasi restrizione imposta da forze esterne, dipende tutto da te. Non è necessario ospitare altri che lavorano al tuo fianco, quindi è più facile scegliere tecniche che ti consentano di lavorare nel modo più efficiente possibile. Nel corso degli anni, hai probabilmente capito come lavori meglio, quindi sarebbe un buon punto di partenza. Quindi applica "best practice" conosciute per migliorare le tue abilità e tecniche.

Il ragazzo chiede metodologie specifiche e la gente risponde "usa il software X / Y". NON è una questione di strumenti, in realtà ci sono molte metodologie e sembra che non ci sia ancora un rapporto di validazione per loro: Agile, Iterative, Spiral, Waterfall, XP, V-Model, TDD.