Come organizzare un progetto one-man? [chiuso]

Penso che il vero problema, a lungo termine, sia la motivazione, piuttosto che l'organizzazione.

1. Trova gli utenti e parla con loro. Visualizza il tuo progetto come una sorta di regalo (o prodotto vendibile) a quelle persone. (Anche qualcuno che rimbalza le idee è fantastico, anche se in realtà non sviluppano codice con te.)

   Avere questa motivazione sociale sarà molto più potente nel mantenere il progetto interessante nel lungo periodo rispetto alla mera curiosità personale.

2. Il tuo obiettivo dovrebbe essere piccoli frammenti di funzionalità utili. Mettilo su SourceForge o GitHub e considera il progetto come qualcosa che ha bisogno di una possibilità di sopravvivenza anche se sei colpito improvvisamente da una meteora.

   Questo porta a più versioni (che significano più feedback e entusiasmo da parte degli utenti) e anche maggiore probabilità che un'altra persona possa decidere di contribuire al progetto.

3. Scegli un obiettivo di apprendimento specifico per te. Quale tecnologia o tecnica ti aiuta a imparare il progetto? Se si scopre che la tecnica non è adatta all'area problematica, ti interesserà abbastanza almeno finire la versione 1.0 prima di metterla da parte?

   Esempi di tali obiettivi includono la scrittura di parser, protocolli di rete, aspetti dell'intelligenza del gioco, framework di apprendimento o toolkit, una nuova lingua, ecc.

Lo scenario peggiore significa che mancano tutte e tre le cose, dove fai ripetutamente una "riscrittura massiva" di uno strumento mai rilasciato che coinvolge codice che non trovi interessante per le persone che non sei sicuro esistano.

Quando ti viene un'idea per un nuovo progetto mentre lavori a un progetto, annotalo in un elenco di idee di progetto. Quindi torna al progetto corrente. Se il progetto è utile, non lasciarti distrarre da un nuovo progetto. Utilizza i seguenti passaggi solo se è un'idea eccezionale.

Prima di iniziare il nostro progetto, pianificalo. Cosa farà? Quanto sarà difficile da fare? Quali sono i conosciuti e gli sconosciuti? Che cosa potrebbe andare storto? Quanto tempo ci vorrà? [Ora puoi decidere se andare avanti o fermarti ora.] Mantieni il tuo piano. [Se stai lavorando a un progetto, metti da parte il nuovo progetto e vai avanti con l'altro progetto originale.]

Quando avvii il tuo progetto, configuralo come progetto separato nel tuo IDE. (Quindi non è necessario cancellarlo per avviare il tuo prossimo progetto.) Controllalo in qualche software di controllo della versione come nuovo progetto. (Ora puoi eliminarlo se trovi che si sta intromettendo in un altro progetto.) Verifica il tuo progetto ogni volta che lo fai facendo qualcosa in modo corretto. (Ora puoi tornare indietro se torni fuori pista.)

Tieni traccia dei problemi che si presentano nel tuo progetto. Questo può essere fatto con pochi file di testo all'interno del progetto. File come TODO, Changelog, README (possono includere bug e problemi noti) potrebbero essere appropriati.

Quando il tuo codice funziona, taggalo nel controllo della versione. Se ne vale la pena la condivisione.

Torna al tuo piano e vedi quanto hai fatto bene. Fai un documento di lezioni apprese per te stesso. Che cosa hai imparato, quanto hai stimato? Quali problemi hai perso? Quali problemi hai sopravvalutato? Qualcos'altro che ritieni importante.

Quando abbandoni un progetto, segui le lezioni apprese. Aggiungi una nota sul motivo per cui hai abbandonato il progetto.

Verifica le tue lezioni apprese una volta al mese o giù di lì. Con il passare del tempo puoi aumentare l'intervallo tra le recensioni.

Ecco un link a " Facendo Agile in un team di uno ". È una lettura interessante!

Inoltre, potresti voler considerare il motivo per cui le discipline del software dev che facciamo "al lavoro" sono importanti. Sono importanti solo se nella squadra ci sono 10 persone? No, sono importanti perché ti aiutano a pensare al tuo progetto.

Chi è il tuo pubblico di destinazione? (Se sei tu, allora fantastico - ma ricorda cosa volevi originariamente l'app per)

Se stai facendo un'interfaccia utente, pensa alle esigenze del tuo pubblico, quindi fai dei simulacri prima di entrare nello sviluppo dell'interfaccia utente più difficile.

Se stai osservando la tua logica aziendale, prova TDD o BDD. Pensa a come vuoi che la tua app funzioni prima di attaccarla. Considera di avvolgerlo in un'imbracatura come Fitnesse o simile. Se vuoi testare la tua app, il punto di partenza più semplice è all'inizio .

Dato il tuo commento, smetti di cancellare i tuoi progetti!

In genere non mantengo progetti che non sto sviluppando attivamente (o prevedo di sviluppare attivamente nel prossimo futuro) sul mio computer, ma i file di origine esistono in un repository SVN e tutto (inclusi i file di configurazione IDE) è eseguito il backup su un HDD esterno. Non risponde ai tuoi argomenti. Smetti di cancellare il tuo lavoro e concentrati sulla tua motivazione.

Se stai cercando un repository ospitato, consulta Google Code, SourceForge, GitHub e BitBucket. Carica i tuoi file, tienili da qualche parte, e quando hai un rinnovato interesse, trascinali. Sebbene tu possa renderli privati, puoi renderli pubblici se non ti vergogni di loro. Forse qualcuno sarà interessato a riavviare il tuo lavoro o a imparare dai tuoi esempi (specialmente se stai usando una libreria o un framework interessante).

Nel tempo, lavora sulla tua motivazione. Cerca di concentrarti su una cosa alla volta. Potresti non ottenere il tuo codice per la qualità di produzione, ma forse puoi ottenerlo con la qualità di esempio, o qualcosa che altre persone possono vedere per vedere le tue competenze, conoscenze, o per conoscere un particolare modo di fare le cose.

Prima di tutto, ci sono progetti e progetti. Se provi qualche tecnologia o libreria o altro, probabilmente crei un progetto nel tuo IDE, scopri se questa cosa è interessante per te o meno, e poi cancella il tuo progetto. Va bene, lo fanno tutti.

Un altro tipo di progetto è vero software / siti / ecc., che è business, dove quei "progetti", file, programmi sono solo strumenti, e lo sviluppo di cose così complesse richiede motivazione e gli obiettivi :

• cosa sviluppi (sito web / editor di testo / app mobile /...)
• per cosa ti serve (guadagna, raccogli alcune nuove tecnologie / contribuisci all'open source /...)
• quando faresti (quanto tempo dedichi il tuo progetto, per quanto tempo hai intenzione di farlo)

Ciò che sviluppi dovrebbe essere nuovo . Se vuoi creare solo un altro editor di testo perché pensi che alcune funzionalità richieste non siano disponibili, probabilmente non hai bisogno di farlo. Esistono centinaia di strumenti open source, che contribuiscono a uno di essi.

Anche se si crea un piccolo strumento monouso come uno script, è necessario specificare le cose elencate, sarebbe più facile risolvere il problema stesso.

Se sei bloccato a scrivere codice (ad esempio, riscrivi in modo massivo il tuo codice) probabilmente non sei abbastanza esperto per farlo. Fai un buon libro sull'ingegneria del software, sulla tua piattaforma (mac / web / etc), leggi il codice scritto da sviluppatori più esperti che fa cose simili. Ci sono molti posti in cui farlo ora (github, codice google, blog di programmazione, stackoverflow).

Non provare a risolvere un problema molto complesso (ad es. scrivere un compilatore o un sistema operativo) da zero, prima decomponilo in compiti più piccoli, spesso, qualcuno ha già creato librerie che ti aiutano a risolvere il tuo problema.

Hai mai pensato di chiedere a una persona cara quali realmente hanno bisogno di uno strumento web e quindi realizzarlo per lui o per lei?

Questo dovrebbe fornire la motivazione per finire e consegnare che è la parte difficile in questo. Inoltre, hai il vantaggio di supportare e mantenere l'applicazione se è utile alla persona amata. Se non è utile, puoi imparare dall'esperienza cosa può andare storto.