Perché è così difficile convincere i dipendenti ad aggiornare il tracker dei problemi?

Il motivo è che non emettono perché dovrebbero aggiornare il tracker dei problemi, a parte il fatto che tu lo dica.

Perché è così? La mia ipotesi è che l'aggiornamento del tracker non influenzi il loro lavoro in alcun modo significativo, quindi la soluzione è probabilmente quella di implementare un sistema di tracciamento che li aiuti effettivamente a fare meglio il loro lavoro.

È difficile, perché i dipendenti sentono che l'aggiornamento del tracker dei problemi non è importante. Devi cambiarlo, ma c'è un problema. La comunicazione è difficile. Una comunicazione efficace è davvero difficile - molto più difficile di quanto si possa pensare. Così difficile, che la comunicazione di solito fallisce, salvo per caso .

Mostra, non dire. Per esempio. non dire che tu (o il tuo capo) hanno bisogno dei dati per un rapporto. Mostra dal punto di vista dei dipendenti in che modo il tracker dei problemi aggiornato li influenza e li aiuta.

Guida con l'esempio.

Sono uno sviluppatore e fatico a utilizzare il tracker dei problemi che abbiamo al lavoro. Questo è un peccato perché io sono tutto per loro per mantenere le cose organizzate. La mia soluzione per il momento è quella di utilizzare uno strumento di tracciamento personale e fare riferimento a esso per parlare di progressi nella nostra mischia quotidiana.

Ecco cosa mi farebbe usare il tracker tutto il tempo:

• Integrazione perfetta con IDE e controllo del codice sorgente. Utilizziamo alcune webapp goffe perché le licenze sono state già acquistate per questo. Ci vuole tempo per creare / aggiornare attività e ha alcune caratteristiche dell'interfaccia utente confuse. Sfortunatamente l'utilizzo di questo è al di fuori del controllo della nostra squadra.

• La semplicità. Con questo voglio dire non prendere 10 campi compilati manualmente solo per aggiungere un'attività. Stime orarie vs. tempo di completamento, inserimento manuale del progetto / componente / ecc. in diversi campi, ecc. basta aumentare la quantità di tempo.

• Solo uno. Non sono sicuro di quanto sia comune, ma la gestione dei progetti utilizza uno strumento, il supporto ne usa un altro e lo sviluppo ne usa un terzo. Se uno non viene aggiornato, tre certamente non lo sono e la sincronizzazione tra di essi è improbabile che sia automatizzata.

Prima di tutto: cosa intendi con "le persone che aggiornano i loro progressi"?

Intendi "sviluppatori che aggiornano la stima corrente" o "gli sviluppatori non impostano un problema da risolvere", o piuttosto "clienti / tester che non risolvono un problema risolto" o tutti insieme?

Dal punto di vista dello sviluppatore, è una miscela di mentalità e cultura.

• mindset: quando imposti un problema per risolverlo significa che hai finito, e responsabile se è bacato
• cultura: se l'intera azienda non è molto entusiasta di utilizzare tali strumenti, ma preferisce altre strategie organizzative

La mia esperienza è: hai bisogno che la cultura punti nella giusta direzione, almeno. Quello che aiuta in seguito è definire un DoD (definizione di "fatto") - se uno sviluppatore (lavora anche per altri ruoli) può dire (s) che ha adempiuto l'intera lista è alleviato per marcare il problema risolto e andare avanti senza bisogno guardare indietro.

Smetti di chiedere informazioni sul progresso della codifica (di solito è una percentuale arbitraria strappata dal nulla) finché il biglietto non è chiuso. Se la cosa principale che misura è il numero di biglietti chiusi, migliorerà.

Presta tuttavia attenzione al fatto che tutte le metriche possono essere giocate e le metriche tendono a funzionare meglio se raggruppate con metriche complementari, ad es. probabilmente vuoi anche esaminare i problemi che vengono riaperti in quanto ciò implica che vengono prematuramente chiusi

Come sottolineato da alcune altre risposte, la domanda giusta qui è probabilmente: perché hai un tracker di problemi. Una buona risposta a questa domanda (non solo dal punto di vista gestionale ma anche dal punto di vista dello sviluppatore) è fondamentale se si desidera che un sistema di rilevamento dei problemi funzioni realmente e venga aggiornato regolarmente.

In molte aziende il sistema di monitoraggio dei problemi viene utilizzato principalmente come strumento di reporting gestionale. Fare in modo che i programmatori aggiornino i problemi solo in modo che la gestione possa eseguire un report non funziona bene. E forzare i programmatori ad aggiornare i problemi non funziona - potresti avere problemi aggiornati, ma dovresti mettere in dubbio i dati.

Nella mia esperienza, l'unico modo per far sì che gli sviluppatori (e tester, gestione, ecc.) usino efficacemente un sistema di tracciamento dei problemi è quello di integrarlo nel processo di sviluppo. Ciò significa che l'output di una parte del processo diventa l'input per la parte successiva del processo.

Per dare l'autorità del sistema di tracciamento dei bug suggerirei quanto segue:

• Gli sviluppatori lavorano solo su bug / funzionalità registrati nel tracker dei problemi e nessun lavoro viene svolto al di fuori di esso. Anche tutte le idee, i progetti di refactoring, le nuove funzionalità, gli strumenti personalizzati da sviluppare, ecc. Devono essere registrati.
• I problemi vengono elaborati in ordine di priorità. La priorità dovrebbe essere determinata in parte dal management, ma gli sviluppatori dovrebbero sicuramente avere voce in capitolo nel determinare le priorità. Ciò è particolarmente vero quando si tratta di problemi di manutenzione e di refactoring.

Per quanto riguarda l'elaborazione, è possibile utilizzare qualcosa di simile al seguente:

• status 'new' indica che un problema non è stato ancora rilevato da uno sviluppatore ed è ancora nella coda di problemi prioritari
• stato 'assegnato' indica che è stato assegnato a uno sviluppatore. Questo potrebbe essere fatto dallo sviluppatore o da qualcun altro come il responsabile del team. Trovo che funzioni bene avere alcuni problemi assegnati a ciascun sviluppatore e di solito un mix di "heavy lifting" come nuove funzionalità e facili selezioni come semplici bug o semplici lavori di manutenzione. Ciò consente agli sviluppatori di scegliere il lavoro in base al loro umore.
• stato 'in corso' significa che uno sviluppatore sta lavorando su un problema. Solo uno o due problemi per sviluppatore dovrebbero essere "in corso" in qualsiasi momento.
• una volta risolto il problema, lo sviluppatore può modificare lo stato del problema in "necessità di test" e cambiare il proprietario nel tester. Questo è un passaggio importante, poiché questa è anche la coda di lavoro dei tester.
• i tester possono cambiare lo stato in "testing fallito" e cambiare la proprietà dello sviluppatore, il che significa che va in cima alla coda per lo sviluppatore, oppure possono cambiare lo stato in "pronto per la distribuzione".
I problemi
• con lo stato di "pronto per la distribuzione" possono essere uniti e rilasciati in base al ciclo di rilascio da parte di chiunque sia responsabile delle versioni.

In breve: rendere il sistema di tracciamento dei problemi una parte essenziale del processo di sviluppo e non dovrai preoccuparti di problemi non aggiornati.

Forse lo considerano troppo lavoro per aprire un browser, accedere, trovare il biglietto e riempirlo. Forse puoi provare a incoraggiarli con hook . Al giorno d'oggi è una caratteristica comune che nel messaggio git / hg [presumo tu usi uno di questi] puoi scrivere qualcosa come FIXED # 123, e il ticket cambierà automaticamente dopo aver premuto il commit. In questo modo non è quasi nessun lavoro per lo sviluppatore [se lavora su ogni problema in un ramo separato - ha già l'id del ticket] e molto probabilmente aggiungerà quei due caratteri nel messaggio di commit. Se questa soluzione non è sufficiente, forse significa che l'ambito dei ticket è troppo grande e dovrebbe essere diviso in molti ticket più piccoli?

Questo suona come un problema di cultura aziendale più di ogni altra cosa. Chi ha istituito la necessità di utilizzare il tracker? Se questo è qualcosa che una persona o un gruppo gettato là fuori, e si aspetta che tutti gli altri solo accettino e usino, buona fortuna. A meno che le persone non capiscano cosa sia, sappia come usarlo e accettino che in realtà rendono le loro vite più facili (le loro vite, NON le tue), non lo userebbero se non costretti dalla direzione. Detto questo, se usare il tracker è una decisione aziendale, allora dovrebbe essere il management a rafforzarlo. A meno che il tuo ruolo non includa la responsabilità e l'autorità di far sì che le persone usino il tracker (suona come no, come hai indicato che sei uno sviluppatore), non andrai molto lontano, indipendentemente da quello che fai (realisticamente, IMHO ).

Probabilmente è simile al motivo per cui è così difficile per le persone inserire il proprio tempo regolarmente. È un lavoro noioso ...

Molti tracker di problemi si integrano con l'IDE. Ad esempio, il Tracker dell'elemento di lavoro TFS consente di contrassegnare un'attività come risolta quando si esegue un check-in. C'è anche un'opzione per richiedere che un check-in sia associato a un'attività. Rendere l'aggiornamento di una voce di lavoro parte del processo di check-in semplifica le cose. L'alternativa è di aprire il tracker dei problemi in un'interfaccia separata per eseguire la modifica.

Un'altra opzione consiste in una riunione di stato (o durante lo standby giornaliero) in cui qualcuno apre il tracker e aggiorna le attività man mano che le persone forniscono lo stato.

Una cosa da tenere in considerazione è che la GUI è di per sé un impedimento. Ad esempio, alcuni ostacoli potrebbero includere:

• Troppi clic
• Server applicazioni tracker dei problemi non ottimizzato o underpower
• Scarsa usabilità o accessibilità

L'esposizione di un'API consentirà di aggiornare il problema al tracker degli errori tramite script come gli artefatti tecnici (copertura del codice, rapporti sui test delle unità, stato di build, ecc.)

Riferimenti

• Scrumwise - API

• Riferimento dell'API REST cloud JIRA

• API REST di Alfresco Content Services