Vorrei ottimizzare il modo in cui gestisco la mia lista di cose da fare. I miei compiti sono, per una grande parte, relativi alla codifica C++ ma includono anche letture, presentazioni, ricerche ... Ultimamente ho scoperto il comando @todo in doxygen, che è piuttosto interessante per la parte di codifica. Mi piacerebbe mantenere una chiara traccia di tutti i miei compiti in un unico grande strumento però. Qualche idea?
L'utilizzo di tag di attività in-code @todos o TODO: in-code è in genere una cattiva idea, soprattutto se fai parte di un team, poiché non è sempre facile da rilevare e potrebbe richiedere strumenti aggiuntivi (e non tutti i membri del team potrebbero utilizzare gli stessi strumenti). Inoltre dopo poche settimane (o giorni) ti dimentichi di loro fino a quando non verranno a morderti in fondo alla strada.
In generale, direi che il modo migliore per tenere traccia delle attività / TODO è con un tracker dei problemi (come JIRA, Bugzilla o Mantis o più soluzioni complete come trac o ospitate che vengono con repository privati come su BitBucket, GitHub o Assembla). Sembra pesante, ma se ne usi uno buono fa miracoli, principalmente perché ottieni cose come:
Gli ospitati hanno il vantaggio di poter accedere alle tue attività ovunque tu sia, purché tu disponga di una connessione Internet e puoi ancora esportare un elenco come testo quando prevedi di essere offline.
In caso contrario, le schede attività stanno diventando molto popolari con Scrum, Kanban e altre metodologie. Puoi utilizzare schede di attività dedicate * (come Trello), oppure puoi utilizzare un plug-in per un tracker di problemi (come GrassHopper per JIRA).
* virtuale o fisico, anche se preferisco quelli virtuali a scopo di backup ovviamente ... puoi sempre visualizzarli su un muro con un grande schermo o un proiettore economico
Abbiamo ancora alcuni tag di attività nella mia squadra, ma di solito sono solo promemoria di breve durata che lasciamo nel codice tra i commit o come avvertenze per un codice legacy molto interessante che trattiamo con molta attenzione. E per non perdere traccia di loro, abbiamo preimpostazioni per diversi IDE che ordinano di applicare la coerenza nella convenzione di denominazione dei tag attività e inoltre integriamo alcuni strumenti nella nostra build per rilevarli (per i progetti Java, Maven può produrre un report con tutti i tag task rilevati, che è utile rivederli e convertirli in attività effettive nel tracker dei problemi se ritenuto pertinente e tenere d'occhio FIXME urgenti / critici e cose del genere).
Un semplice file di testo vecchio usato come diario / diario funziona bene per tenere traccia sia delle cose da fare che di qualsiasi altra cosa su un progetto che vuoi ricordare. Provo ad aggiungere una linea o due ogni volta che prendo una decisione, noto qualcosa a cui voglio tornare più tardi, avere un'idea per un miglioramento, ecc. Alcuni elementi vengono chiamati con una prima parola come "BUG" o "TODO" . Tengo il mio in ordine cronologico inverso: inserisco gli elementi nella parte superiore del file.
Un diario di sviluppo non è in realtà un sostituto di un sistema di tracciamento dei bug. È più leggero - dato che ho quasi sempre il file aperto, aggiungere qualcosa è molto veloce. Ma non è così facile da cercare, non così organizzato, non così potente. È un log, non un database. Tuttavia, può essere un buon modo per aiutarti a diventare un po 'più organizzato. Se tutto ciò che ti serve in questo momento è un modo per evitare di dimenticare le attività, può essere uno strumento molto utile.
Molti IDE ti consentono di aggiungere un tipo di file o una regola di generazione che ignorerà un determinato tipo di file, così puoi aggiungere il tuo diario di progetto direttamente al progetto e averlo a disposizione tutto il tempo. Ricordati di controllarlo nel controllo della versione per conservarlo in sicurezza!
Quello che generalmente faccio è creare una sorta di file include che contiene solo commenti. Può essere bug, tutto, criteri di test, qualunque cosa. Questo viene incluso nel progetto e per ogni elemento ho una risoluzione, una data di risoluzione, le mie iniziali e, se necessario, una breve descrizione di ciò che stava causando il bug o un comportamento inaspettato.
Un paio di volte mi è stato risparmiato un sacco di tempo dopo, potendo tornare indietro e fare riferimento a quelle liste quando si verifica una situazione strana simile. Inoltre, puoi anche guardare il codice in quel progetto e tagliare / incollare una soluzione pronta (o quasi).
Io uso due sistemi quasi discreti per la maggior parte degli oggetti di Todo seguo il processo Getting Things Done e uso omnifocus per tenere traccia degli articoli. Sono d'accordo con il suggerimento del tracker di cui sopra. Personalmente uso redmine come mio sistema di tracciamento e quindi utilizzo l'integrazione MYLYN con i miei IDE per tracciare gli oggetti. Mi piace molto il modo in cui riesco a capire in modo specifico quali file sono stati toccati e mettere a fuoco tramite MYLYN.
I commenti TODO nel codice sono ancora in ordine (per progetti personali). Per qualsiasi altra cosa: una kanban board, migrata dalla scheda fisica a una basata su software self-made. Cerca in il mio blog per i dettagli. Ci sono anche molte opzioni online .
Leggi altre domande sui tag task-organization