Metodologie del ciclo di vita del software per le squadre One Man [chiuso]

Mi guadagno da vivere come "one-man" software per il noleggio di armi da fuoco "che lavora per lo più da casa, quindi muoio dalla voglia di ascoltare ciò che gli altri hanno da dire su questo.

Ecco alcune cose che ho trovato importanti:

• Come dice Denis, il controllo del codice sorgente è di vitale importanza, ma SVN non è l'unica opzione. Per lo più uso Perforce, e git è una buona alternativa. Mi piace un modello di sviluppo "principale"; che mi consente di fare esperimenti nei rami del codice, unirli alla linea principale quando funzionano e di eliminarli se non lo fanno.
• Uso un taccuino per le note e un programma per le attività di monitoraggio. Attualmente uso Redmine per quest'ultimo; prima ho usato Fogbugz. Mi piace anche Redmine perché ha una buona wiki incorporata, che posso usare per note persistenti e link a siti importanti.
• È anche fondamentale tenere traccia di ciò che sto facendo e impostare me stesso una sorta di limiti ragionevoli in modo da ottenere abbastanza risultati senza bruciare - vedi sotto.

Le mie altre tecniche si sono evolute nel corso degli anni e le ho modificate a seconda del progetto e del cliente. La gente mi paga per il codice di lavoro, non scherzando con il processo, quindi cerco di mantenere il processo leggero e fuori dalle facce dei miei clienti. Ma trovo che alcune tecniche Agile funzionino davvero bene per me:

• Uno dei miei attuali clienti tende a lasciar cadere delle grandi funzionalità da implementare e non mi disturba fino a quando non sono terminate. Quindi trovo che lavorare su quelli in Scrum Sprint sia fantastico. La mia ipotesi è che potrebbe funzionare per un progetto di un master a meno che il tuo consulente di ricerca non sia un maniaco del controllo.
• Il mio altro cliente corrente tende ad avere più emergenze di un tipo "smetti di lavorare su questo e aggiusta quello". Ho provato a farlo con Scrum e ho rinunciato dopo uno sprint. Quindi lo sto facendo usando Kanban, e funziona molto meglio.

L'altro trucco di 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 tu devi farlo per te stesso 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 inserendo, ma non mi piace così come qualcosa di più basato sull'obiettivo.

Alcuni 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 è al di fuori della portata di ciò che stai chiedendo.

Usa SVN sopra, versione tutto. Per il tracciamento, il notebook funziona per progetti più semplici, se necessario sono disponibili molte applicazioni di tracciamento dei bug e attività gratuite (Redmine è bello). Agile / XP / Integrazione continua / altri sarebbero un po 'eccessivo secondo me.

A parte il processo di personal software , non ho trovato molto su modelli di processo formali progettati per essere utilizzati da un singolo sviluppatore. La PSP è piuttosto pesante su documentazione e documenti (nella sua forma grezza, comunque), senza molto da dire per particolari tecniche di esecuzione di lavoro (invece, la PSP si concentra sulla raccolta di dati per trovare aree di miglioramento), ma è un inizio punto per lo sviluppo di un processo personale che puoi utilizzare su progetti di dimensioni medio-piccole.

Penso che la migliore linea d'azione sarebbe quella di seguire semplicemente alcune scelte appropriate (in base ai tuoi bisogni e al progetto) delle migliori pratiche ampiamente accettate da un certo numero 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 accettazione), integrazione continua, standard di codifica, Non ne hai bisogno e così via. Se non l'hai fatto, ti suggerisco di leggere codice completo e The Pragmatic Programmer e praticando i loro suggerimenti.

La cosa più importante del lavorare individualmente è che, a parte ogni restrizione imposta da forze esterne, dipende da te. Non è necessario ospitare nessuno che lavori con te, quindi è più facile scegliere le tecniche che ti consentono di lavorare nel modo più efficiente possibile. Nel corso degli anni, probabilmente hai capito come lavori meglio, quindi sarebbe un buon punto di partenza. Quindi applica le "migliori pratiche" conosciute per migliorare le tue abilità e tecniche.

Il ragazzo sta chiedendo metodologie specifiche e la gente sta rispondendo "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 convalida: Agile, Iterativo, Spirale, Cascata, XP, V-Model, TDD.