Trascorro molto tempo a lavorare su progetti in cui sono l'unico sviluppatore, project manager, designer, persona QT (Sì, lo so ... Bad!), E talvolta sono anche il cliente.

Ho provato di tutto per pianificare i progetti e gestirmi, dalla sola seduta e lavoro al freestyle fino a quando il progetto è stato realizzato per tutto il tempo necessario, fino a una versione per persona di mischia in cui ho tenuto un incontro di progresso con me stesso su uno -man brucia grafico ogni mattina (non scherzando).

Per quelli di voi che trascorrono molto tempo a lavorare da soli, qual è il modo migliore per organizzarsi, gestire progetti di grandi dimensioni (per una persona) e mantenere la produttività il più alta possibile?

Mantenere un elenco chiaro dei tuoi obiettivi è di vitale importanza. È facile per il creep di assumere un progetto autogestito. Anche l'approccio TDD "funziona quando funziona" è utile. Questo ti impedisce di diventare un perfezionista.

Una cosa che mi aiuta davvero è immaginare cosa direbbe un altro ingegnere o un project manager in una determinata situazione. Spesso sono in grado di "vergognarmi" per il cattivo codice o tornare in pista se il programma sta scivolando.

Ecco qua ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP si ridimensiona bene poiché è ottimale per piccoli team focalizzati.

• Puoi creare un foglio di calcolo per le richieste di funzionalità, assegnarle le priorità e scegliere quella più in alto.
• definire i criteri di accettazione (come appare fatto) e codificarlo in un test eseguibile
• Quindi definire le attività di ingegneria da eseguire
• Scrivi unit test, fai la cosa più semplice (YAGNI) e fai il refactoring continuamente. L'obiettivo è far passare il test di collaudo esterno
• Timebox per ogni sessione. Per un'efficace gestione del tempo, puoi anche guardare la tecnica Pomodoro .
• Utilizza il controllo versione e imposta un server CI / un file batch per creare un'installazione o un zip del tuo software
• Demo frequentemente. Instradare il feedback nel foglio di calcolo originale e ridistribuire

L'unica cosa che non puoi fare in una squadra di uno è PairProgramming.

Se lavori da solo. Ecco i consigli:

1. Fai il minor lavoro possibile a basso livello. Usa quante più librerie e strumenti possibile, includendo cose che pensi di poter facilmente programmare (non farlo, usa semplicemente la libreria).
2. Prendi l'approccio top-down. Codifica solo cose di cui hai veramente bisogno.
3. Quando vedi un problema in termini astratti, cerca su google e usa documenti di ricerca della comunità accademica che sono già stati dimostrati. Hai solo bisogno di codificare il loro algoritmo.
4. Progetta il tuo sistema in modo da poter cambiare liberamente le cose il più possibile. (incluso copia e incolla del codice da qui a lì). Lo scopo è farti risparmiare tempo quando ti rendi conto di aver fatto un errore. Cerca di ridurre al minimo la quantità di lavoro che devi buttare via quando commetti un errore. Un pezzo di codice che deve essere gettato via (anziché copia-incolla da qui e là) è l'equivalenza del tempo che hai perso scrivendo quel codice.
5. Esegui molti test automatici in modo da poter eseguire regolarmente test di regressione ogni volta che apporti una modifica
6. Separare le responsabilità del progetto (ovvero ridurre l'accoppiamento). Rendi le cose il più modulari possibile
7. Utilizzare un debugger per eseguire il debug e utilizzare la ricerca binaria per trovare il difetto.
8. Rifattorizza costantemente il codice per ridurre l'accoppiamento (esplicito) e l'esposizione ai metodi pubblici (accoppiamento implicito).
9. Niente. Questo è qui nel caso in cui riesco a trovare qualcosa di nuovo: P

Revisioni del codice.

Questi sono particolarmente utili in quanto spiegherai il codice a qualcuno che non ha lavorato allo stesso progetto, quindi non avranno nessuna delle tue ipotesi su come dovrebbe funzionare.

Avranno anche l'ulteriore vantaggio di condividere le conoscenze all'interno dell'azienda, quindi quando qualcun altro deve lavorare al progetto (a causa di persone impegnate altrove, malate, rassegnate o licenziate) non dovranno ricominciare da capo .

Ho realizzato la mia versione di Agile che si basa su storie, interazione con i clienti, rilasci frequenti e sviluppo test-driven. Uso una wiki per tenere traccia delle storie, coinvolgere il più possibile il cliente nella loro scrittura e fare in modo che il cliente lavori con me per stabilire le priorità e organizzare le pubblicazioni. Uso TDD per guidare la progettazione e l'implementazione. Ho impostato un server QA in cui il cliente può provare rilasci frequenti (a volte ogni giorno con lo sviluppo di nuove funzionalità) in modo da ottenere rapidamente un feedback. Raramente vado più di 3 iterazioni senza un rilascio al QA. Il cliente decide quando la versione del QA ha abbastanza funzionalità per essere pubblicata e se non è necessario sviluppare altre funzionalità dall'elenco.

Nella mia azienda il nostro gruppo lavora tutti sullo stesso progetto, ma su sezioni relativamente indipendenti. Una cosa che facciamo molto qui è quando qualcosa che fai sembra un po 'complicato, o sei a un bivio con più di un modo per implementare qualcosa, prendi qualcun altro e discuti i pro e i contro prima si procede. Se aspetti fino a quando non consideri che il tuo codice ha terminato di fare una recensione, di solito hai già investito troppo tempo per prendere in considerazione importanti cambiamenti architetturali, anche se certamente molti difetti vengono scoperti nelle revisioni del codice.

Inoltre, mi rendo conto che Test Driven Development è una piccola parola d'ordine satura di recente, ma può essere di grande aiuto per gli sviluppatori solisti perché fornisce un controllo di qualità mentre procedi e quando i test diventano difficili da scrivere sai che probabilmente hai bisogno di una ristrutturazione del tuo codice. Aiuta anche i manutentori successivi a non rompere accidentalmente il codice in modi difficili da rilevare.

Ti suggerisco quanto segue:

1. Sviluppo test-driven
2. Usa facilmente "TODO: nota qui" nel tuo codice quando vedi qualcosa che non sei in grado di fare immediatamente, e torna da loro quando hai tempo invece di rimanere su Facebook in attesa che il tuo client richiami
3. Scrivi il tuo codice come il tuo cliente lo acquisterà guardando il codice non solo il risultato, immagina il tuo cliente come presidente per una revisione del codice.
4. Compila il tuo codice di asserzioni

Vorrei poter dire di essere stato in grado di praticare ciò che predico il 100% delle volte, ma BDD sembra essere un buon approccio da adottare nella tua situazione:

Ecco un link con maggiori informazioni: http://en.wikipedia.org/wiki/Behavior_driven_development

Sono su una barca molto simile. Cerco di seguire i principi agili (oltre a capirli) il più possibile. Probabilmente non sto facendo le cose "correttamente", ma ho avuto un grande successo nei miei progetti cercando di seguire principi agili. Ci vuole un'enorme quantità di disciplina, dal momento che non c'è squadra per assicurarsi di non iniziare a prendere scorciatoie.

Trovo che l'uso di strumenti di formattazione del codice come ReSharper assicuri che, almeno visivamente, il codice sia facile da raccogliere per altri sviluppatori.

In termini di metodologie effettive, è difficile per un singolo sviluppatore attenersi a uno in particolare. Sono un consulente che generalmente lavora da solo e trovo che sia più facile per me e per il cliente utilizzare un processo agile. In genere cerco di convincere i miei clienti a inserire direttamente i loro requisiti in uno strumento come Trac (o lo farò, per loro conto). Questo non solo aiuta gli altri sviluppatori a identificare lo scopo del codice, ma anche a te stesso 3 mesi lungo la linea!

filosofia: XP / TDD + GTD

schema generale:

• intervistare le parti interessate
• prototipi di schermate, procedure dettagliate, prototipi di carta (se necessario)
• brainstorming di feature / story (con e senza stakeholder)
• brainstorming di test case (con e senza stakeholder)
• tempo di riflessione generale su design / architettura (se necessario)
• pianificazione dell'iterazione (con le parti interessate)
• iterazioni
• revisione del processo, formazione, pianificazione della manutenzione, ecc. (se necessario)

Qualsiasi metodologia appropriata sarà di aiuto, indipendentemente dal numero di persone coinvolte nel progetto. Quindi scegline uno alla volta e scopri come applicare e mappare il tuo dominio e misurare i loro successi.

Forse più interessante è chiedere quali metodologie non buttare via perché c'è solo 1 persona che lavora al progetto.

E quello chiave che mi colpisce è il controllo del codice sorgente (Sì, è uno strumento, ma fa parte del flusso di lavoro, quindi anche un processo). Le persone potrebbero essere tentate di dare questo passaggio perché non "hanno bisogno di supportare più persone modificando il codice contemporaneamente".

Ironia della sorte, trovo che una soluzione di controllo della versione distribuita come GIT sia migliore per un individuo che qualcosa come SVN.

Se è un codice da buttare potrebbe essere in grado di essere un po 'trasandato con metodologie, ma qualcosa di importante e direi che il tuo modo di trattarlo come un progetto di gruppo con una persona è molto bello e disciplinato.

Scrivi il tuo codice per il prossimo ragazzo a leggere, non tu ... sii gentile con lui / lei. Anche il codice "butta via" rimane per sempre.

Agile

caratteristiche, storie e casi di test sono molto più istruttivi di una documentazione più formale, e una serie di test di lavoro è migliore nel dimostrare come usare qualcosa o come funziona qualcosa rispetto a qualsiasi quantità di alberi morti

È anche più semplice trasferire il lavoro tra le iterazioni.

Come consulente io stesso, suggerirei di trovare un modo affinché ci siano sempre almeno due sviluppatori per ogni incarico.

Concordo sul fatto di essere agile e di lasciare una traccia agile di storie e prove che altri possono seguire, ma non credo che o altri processi o metodologie rimarranno attaccati mentre le persone lavorano da sole.

Penso che le revisioni del codice siano un buon inizio, ma mi piace quando è reso informale e divertente, come fare una revisione del codice di coppia o accoppiare la programmazione per affrontare un determinato problema / problema o qualche miglioramento (ad esempio, cambiare il codice legacy per soddisfare i nuovi standard di codifica ). A volte due set di occhi sono meglio di uno ed è anche divertente, sento che condividere e discutere sembra più aperto. Potresti anche fare un pranzo formale / informale e discutere sessioni per parlare di ciò che hai fatto individualmente o in gruppo, ad esempio menzione di un nuovo modello che hai usato o di nuove tecnologie su come è stato risolto un problema?