Uso di un tracker dei problemi come un singolo programmatore [chiuso]

Dico che dipende. Se stai lavorando su un piccolo progetto che è rientrato per rimanere piccolo, potresti essere bravo con un elenco di attività. Io uso Wunderlist per alcune cose. I progetti tipici sono cose come la creazione di sistemi di blog che seguono un approccio "fai questo dalla a alla z".

Per progetti di cui penso (o spero) diventino grandi, uso un gestore di problemi o una scheda in stile Kanban.

Mentre stavo usando Atlassians Jira molto in passato ho scoperto che era totalmente esagerato anche quando lo usavo con il mio team di 5 persone. Penso che tali sistemi siano utili quando si lavora a livello aziendale poiché si hanno molte opzioni da personalizzare, ma non per team piccoli e agili.

Oggi uso Trello.com per cose orientate al compito, anche per problemi. Funziona piuttosto bene nella mia attuale squadra super agile. Mentre Redmine ti consente di assegnare versioni di rilascio, abbiamo deciso di realizzare più rilasci al giorno e quella funzione sarebbe stata "troppo". Invece spostiamo le carte mentre andiamo e ne siamo molto contenti.

Lo strumento deve essere al tuo servizio e non viceversa. Da quello che ho letto dal tuo post devi sicuramente usare qualcosa di semplice, per favore guarda in Trello.com (molto facile, libero da usare e un po ' meglio per supervisionare le attività).

Il tuo capo: digli che devi organizzare il tuo lavoro, altrimenti questo gli costerà un sacco di soldi / tempo se non lo fai. Ad esempio, se hai un elenco di attività che puoi mettere a fuoco. Se non ce l'hai, devi pensare ogni giorno per circa 30 minuti che cosa è necessario fare. Il denaro è solitamente ciò che convince la maggior parte dei capi.

Creazione di problemi: se vedi un bug (ad esempio un errore di battitura) lo aggiusto subito. Se vedo un bug che non riesco a risolvere in questo momento, sto creando un problema. Se il bug non viene eseguito con una semplice correzione o modifica in modo significativo il comportamento del sistema, creo anche un problema. Il motivo è che voglio averlo documentato. Personalmente lo sto facendo agile, e dovresti farlo per risparmiare tempo se non hai bisogno di documentare ogni passaggio da fare.

Altri tipps? Ti basta provare quello che è meglio per te e ciò che ti aiuta a concentrarti sui tuoi compiti. Ci sono molti tracker di problemi e ti promettono il paradiso. Ma la maggior parte di loro ha un problema: spesso hanno così tante funzioni che mangiano anche molto tempo. La mia visione è di avere una ripresa che mi supporti senza mai pensarci. Come già detto, la mia combinazione di Trello e Wunderlist funziona bene.

Dipendo pesantemente dal mio tracker dei problemi, per impedire alle persone di entrare e impiegare 10 minuti per spiegare un problema a me, che, quando avrò il tempo di fare qualcosa, l'avrò completamente dimenticato.

Facendoli scrivere, possono comporre ciò che vogliono dire, e il risultato tende ad essere più conciso. Mi dà tutti i problemi in sospeso in un unico posto. Significa anche che posso facilmente annotare il problema con i miei pensieri / progressi.

Sembra che il tuo problema principale sia impostarlo. Potresti riuscire a farlo a tappe:

Fase 1. Quando arriva il tuo capo, aspetta che spieghino il problema, prendendo appunti (sul computer, se puoi). Alla fine, chiedi al tuo capo di inviarti un'email di promemoria in modo da non perderti nello shuffle.

Stage 2. Una volta che il tuo capo è abituato a inviarti email di promemoria, chiedi loro di inserire un riepilogo nell'email.

Fase 3. falli trovare l'intero problema in un'email, dopo che te l'hanno spiegato

Fase 4. portali a inserire l'intero problema in un'email non appena iniziano a spiegare il problema.

Fase 5. Invitali a mettere l'intero problema nel bugtracker.

Assicurati che ci sia la minore resistenza possibile per loro. Se puoi, prendi un bugtracker che non ha campi obbligatori e non ha bisogno di un log in; solo una casella di modifica per risolvere il problema. Se possono inviare un indirizzo email specifico per aggiungere un bug, ancora meglio!

Se riesci a raggiungere il livello 2, puoi tagliare & incolla l'email nel bugtracker.

A giudicare da ciò, lo strumento non funziona per te. Il tuo capo non lo sta usando, quindi tutto ciò che stai facendo è passare del tempo prezioso a fornirgli dati. Quindi, perché non parcheggiarlo e usare qualcos'altro? Avendo usato Trello come cristiano, anch'io lo approvo pienamente. È tutto online e puoi persino usarlo sul tuo smartphone. Non richiede di inserire una quantità massiccia di dati privi di significato - inserisci semplicemente ciò che ti serve e lo fai.

Il tuo compito, a mio avviso, è di creare interesse ed essere un evangelista per il progetto che stai sviluppando. OK, stai cercando e risolvendo i problemi, ma perché il tuo capo dovrebbe preoccuparsi di questo?

Non dirlo al tuo pedante locale, ma il TDD può essere adattato a un progetto completato / parzialmente sviluppato. Basta scrivere una serie di test e si parte. Certo, non è così utile in questo modo, ma c'è ancora sicuramente un valore da avere.

Per quanto riguarda cosa monitorare - se si tratta di un errore di battitura o qualcosa non è abbastanza nel posto giusto sullo schermo, sarei propenso solo a occuparmi di questi. Allo stesso modo, se si tratta di problemi che solo tu stesso hai trovato che possono essere semplicemente risolti, allora fallo. Traccia tutto ciò che è più coinvolto. Come regola generale, se il tuo capo ti ha chiesto una demo ora, quali problemi penseresti che fosse importante menzionare?

Il problema sembra essere che il tracker dei problemi non faccia parte del tuo flusso di lavoro. Se lo fosse, allora ti verrà richiesto di usarlo per fare qualsiasi lavoro.

IMO un buon obiettivo sarebbe semplicemente isolare un piccolo problema o funzionalità, inserirne uno nel tracker, quindi creare un ramo corrispondente. Non sono d'accordo con la risposta precedente in quanto non mi dispiace avere problemi per tutto: errori di battitura, cambiamenti di lingua, ecc ... Se ci vuole un po 'per creare quel problema, quindi migliorare il flusso di lavoro in modo che ci vuole meno tempo per creare problemi .

Il vantaggio non è solo quello di avere un tracker dei problemi, ma di come si usa il tracker per migliorare la direzione e il flusso di lavoro del progetto.

A volte scrivevo un problema e pensavo "Questo sembra un compito troppo grande, ci sto davvero lavorando su questo? Forse dovrei suddividerlo in compiti più piccoli" o "La mia descrizione non ha alcun senso, forse dovrei cercare questo e vedere se vale la pena scrivere questo codice ". Permette anche di rivedere e valutare i tuoi progressi.

A molte persone non interessa, ma è più per te e per la tua squadra futura che per il tuo capo. Il tuo capo deve solo sapere che fa parte del software in via di sviluppo, come la cartella dei file del paziente che vedi nello studio del medico.

Alcuni esempi di integrazione del tracker dei problemi:

hubot e redmine

Sub e Jira