Come si tiene traccia di ciò che voi e il vostro team stanno lavorando giorno per giorno?

Parlo con loro.

La tecnologia non può risolvere i problemi sociali. Hai brevi alzate del mattino. Cosa hai fatto ieri? Cosa farai oggi? Eventuali impedimenti?

Se qualcosa sembra strano (o sono curioso), mi fermo e faccio domande: "Stavi lavorando su XYZ ieri, come è andata a finire?". Questo costringe le persone a prestare attenzione e a sapere realmente cosa sta succedendo. Ti tiene anche il team leader nel ciclo (e prestando attenzione, e sapendo in realtà cosa sta succedendo). Questo ha bisogno di essere puntuale e breve (10 minuti massimo ). Tutto il resto e le persone non "accantonano" il lavoro. Si fermeranno e attenderanno la situazione e poi prenderanno il tempo di ricominciare. Alcuni lo faranno comunque, ma è in gran parte inevitabile.

Poi mi fermo alla scrivania di tutti nel pomeriggio. Non tutti i pomeriggi (anche se potrebbe essere più di ogni pomeriggio per nuove persone), non nello stesso tempo, ma più o meno nello stesso periodo (quindi è sia informale che regolare). "Eventuali problemi? Eventuali impedimenti?"

Sarai sorpreso di quanto spesso incontrerai dei problemi quando le persone sono una contro una.

Se le persone non hanno problemi, ottimo; tornare al lavoro. Se non hanno problemi tutta la settimana ? Problema. Non li stai sfidando abbastanza, o non si stanno aprendo. Chiedete come sta andando XYZ (che hanno menzionato in stand-up). Fagli spiegare le cose.

Questo non è microgestione. Non stai dicendo loro come fare il loro lavoro. Non li stai prendendo in giro. Sei lì per rimuovere gli impedimenti dalla loro vita quotidiana. Hai bisogno di informazioni per farlo. Fintanto che mantieni la tua squadra fuori dalle riunioni e i project manager dai loro cubi, una persona che si ferma per aiutare una volta al giorno non causerà loro dolore. Ma tutte queste interazioni devono venire dalla vena di "Sono qui per aiutarti".

Un'altra cosa che farò è rivedere i changeset (da solo, informalmente). Posso quindi vedere con quale frequenza le persone effettuano il check-in, quanto sono grandi i loro changeset, in che modo corrispondono a ciò che hanno segnalato, quanto spesso rifanno le cose, quanti bugfix hanno e così via. Un oggetto di lavoro che modifica lo stato in "fatto" è quasi privo di significato. Guarda il codice. Sembra fatto?

nota: un punto di vista estremamente serio: quanto è grande la tua squadra? È più di 7 persone? Ovviamente non sarai in grado di tenere traccia di tutto ciò che succede se la tua squadra è troppo grande.

Non gestisci i tuoi sviluppatori con micro-comandi!

Lo sviluppo di software produttivo richiede lunghi periodi di sforzo mentale concentrato. Non è realistico aspettarsi che producano risultati costanti. Se inizi a misurarli quotidianamente, ristruttureranno il loro lavoro in modo che producano sempre alcuni artefatti visibili da vedere ogni giorno. Ciò potrebbe o meno avere un impatto positivo sulla qualità del tuo software. Certamente avrà un impatto negativo sull'efficienza dei tuoi sviluppatori.

Poiché suggerisce Robert Harvey , non gestisci la tua squadra. Offri al team alcune attività prioritarie con un valore aziendale concreto e consenti al tuo team di capire come fornire questo valore aziendale.

Se il team offre valore aziendale, dovresti essere felice. In che modo assicurano che consegnino le funzionalità richieste dovrebbero essere a loro.

Tuttavia:

Cards will stay in progress for days on end without an update at the daily stand-up

Questo potrebbe indicare che c'è una carenza nel processo.

Potrebbe essere la squadra che non sta davvero funzionando come una squadra, e non intervenire per aiutarsi a vicenda quando sono bloccati. Potrebbe anche essere la comunicazione con l'azienda. I compiti sono troppo grandi, quindi diventa difficile capire cosa è necessario. Le specifiche non sono chiare.

Potrebbe anche essere che non ci sia alcun vero problema. Forse la squadra funziona perfettamente con carte che rappresentano i principali lavori che richiedono giorni per essere completata, e forse il team sta lavorando bene per raggiungere questo obiettivo.

Penso che sia valido utilizzare la retrospettiva come piattaforma per esprimere la tua preoccupazione. A volte è una buona cosa ricevere osservazioni dall'esterno.

Ma lascia che la squadra capisca se c'è un problema e qual è la causa di ciò. E sii pronto ad accettare che forse è necessario adattare il modo in cui le attività vengono consegnate al team.

Ricorda che lo stand up giornaliero è uno strumento per il team che li aiuta a organizzare il lavoro; NON è uno strumento per i manager per tenere traccia di ciò che sta facendo il team.

'Push messaging' not 'pull messaging'

Uno sviluppatore spesso accede a uno dei seguenti stati che ti interessano:

1. Yaaay, ho fatto X!
2. Sto lavorando su X, ma sembra che ci vorrà un tempo prolungato ...
3. Sono bloccato sul problema Y, sto effettuando delle ricerche ma potrebbe essere necessario un consiglio;
4. Sono bloccato perché sto aspettando A, B e C

Idealmente, si desidera disporre di informazioni ragionevolmente aggiornate su questi stati senza interrompere la produttività effettiva. Costante "Ci siamo già?" è controproducente, ma può darsi che tu possa fare qualcosa di utile per gli stati 2-4, quindi devi essere informato su di loro.

Ciò che funzionerà è una cultura del "push messaging", preferibilmente in modo automatico. Potrebbe non essere necessario esaminare l'intero commit-log, ma è possibile creare una "dashboard" in cui si vede l'ultimo commit o l'ultimo ticket risolto (per bug o funzionalità) di ogni membro del team. Per il resto delle situazioni, puoi inviarli via e-mail in modo proattivo con tali aggiornamenti (si spera che siano più rari dei commit) o andare e chiedere loro se non vedi progressi continui su qualsiasi dashboard - se hai un Accordo interno che rimanere bloccati deve essere sollevato (potrebbe essere che alcune funzionalità non sono necessarie se si scopre che costa 80 ore e non 8 ore), quindi o ti terranno aggiornato o ti infastidiranno.

In alternativa, puoi creare una cultura di qualcosa come link rapporti giornalieri indirizzati a tutto il team - questo garantirà che altri siano sul stessa pagina.

Un'alternativa ad alcune delle altre risposte (incentrate sulla comunicazione) è che forse i compiti sulle tue carte note possono essere suddivisi in parti più piccole su cui saresti in grado di ottenere un feedback prima.

Con i pezzi più piccoli, il team si sente realizzare qualcosa ogni giorno che dovrebbe riflettere nello stand-up.

Lo svantaggio è che queste schede separate probabilmente si affideranno molto l'una sull'altra. Una squadra che è in grado di comunicare molto facilmente tra di loro è utile qui, o i pezzi non possono combinare come dovrebbero. Potresti anche dover ritirare alcune delle carte se hai bisogno di certe cose per prime.

Detto questo, la gente si bloccherà ancora o scoprire che un'attività è molto più impegnativa di quella che tu o te, di tanto in tanto, ti aspetti. Questo è il motivo per cui è ancora utile discutere apertamente di questioni in stand-up in cui altri possono offrire consigli senza giudicare la persona che ha problemi.

Per rispondere al problema della microgestione come alcune delle altre risposte sollevate: anche se le persone svolgeranno piccoli compiti ogni giorno, avranno una visione più ampia del loro lavoro compiuto per ottenere un percepisci quanto effettivamente ogni persona viene effettivamente fatta, piuttosto che giudicarle dai risultati quotidiani.

Suggerisco questo perché lavoro su un team di 8 persone, dove la comunicazione è molto semplice e le persone sono molto disponibili. Ci vengono assegnati compiti che non dovrebbero mai richiedere più di due giorni di lavoro. A volte queste attività sono strettamente correlate e dobbiamo aggiornarci reciprocamente su come ognuno di noi fa il proprio pezzo. Ognuno di noi è responsabile della segnalazione di ciò che abbiamo realizzato ogni due settimane al nostro manager.

Dopo aver letto di nuovo la domanda, mi rendo conto che potresti chiederlo come membro di un team, non come leader, e quindi potresti non avere il controllo sui tuoi compiti.

1. Puoi suggerire al tuo leader di suddividere le attività più
2. Se il tuo lavoro viene bloccato o dipende dal lavoro di un altro membro del team, sentiti libero di controllarlo e intraprendere un'altra attività se necessario.

Prima di tutto devi analizzare te stesso in termini di tempo e abilità. Se sei una persona tecnica con qualche esperienza pratica precedente, le cose potrebbero essere diverse da quelle in cui sei solo un manager (non con una solida conoscenza tecnica su ciò che i tuoi sviluppatori sono in realtà lavorando su) che ha solo bisogno di assicurarsi che le scadenze siano rispettate.

Il punto comune in entrambi i casi è che devi essere in grado di facilitare la tua squadra e creare la sensazione che ti fidi di loro. Non stai giudicando le loro prestazioni ma stai cercando di essere empatico e di aiuto nel rendere la loro esperienza divertente e facile.

Supponiamo ora di essere solo un manager come ho detto sopra, in tal caso, anche se alcuni sviluppatori si trovano di fronte a qualche serio problema legato allo sviluppo, potresti non essere in grado di aiutarla. Il problema attuale può richiedere molto tempo e richiederà anche la concentrazione. Supponendo inoltre che lo sviluppatore sia sincero con il proprio lavoro e paghi a tempo pieno (anche più tempo) per risolvere il problema ma, sfortunatamente, non è ancora in grado di risolverlo. E in una situazione del genere (quando non sei nemmeno in grado di comprendere pienamente il problema) continui a chiedere del problema facendo progressi ogni giorno e anche in modo informale due volte al giorno. Il risultato sarebbe estrema frustrazione e disturbo per lo sviluppatore. Sia che si tratti di un'app per la raccolta di progressi quotidiani o della sua riunione quotidiana in piedi, entrambi possono essere frustranti.

D'altra parte, mantenendo tutti gli altri fattori uguali, presumi semplicemente di avere una solida preparazione tecnica e di aver lavorato alle stesse tecnologie in passato. In questo caso, fare progressi quotidiani o organizzare incontri stand-up è davvero utile. Gli sviluppatori avranno sicuramente fiducia in te e nella tua esperienza e saranno a tuo agio nel discutere la grande sfida che stanno affrontando. Fornirai alcuni suggerimenti che possono essere utili o anche se non sono direttamente utili ti aiuteranno a fornire alcuni approcci alternativi.

Tuttavia, le riunioni in stand-by giornaliere in ogni caso devono creare la sensazione che tu sia un membro del team e non un responsabile / lead / manager. A meno che i membri del tuo team non ti considerino allo stesso livello, non saranno in grado di comunicare le loro preoccupazioni / suggerimenti / problemi / feedback ecc.
Un altro punto da prendere in considerazione è la dimensione del tuo team e il tempo che hai per gestirli, prima di pensare di utilizzare un software di monitoraggio del progresso automatico o aumentare la tua interazione. È necessario assicurarsi che qualsiasi problema sia stato sollevato dalla tua squadra, sei in grado di risolverli al più presto. Uno dei principali fattori demotivanti per un membro del team è che le loro preoccupazioni / suggerimenti / feedback non vengono presi seriamente o non sono valutati. Conoscere i progressi quotidiani è importante ma solo nel caso in cui siate pienamente coinvolti nel lavoro di squadra. Se sei coinvolto anche in alcune attività collaterali, non cercare di interagire di più con il tuo team. Pensa a una situazione in cui la risposta del tuo team è schiacciante e stanno inoltrando i loro compiti ben prima del tempo, sollevando dubbi e domande ma non sei in grado di fornire feedback e recensioni tempestivi. In una situazione del genere, la tua influenza in quanto team lead sarà notevolmente ridotta

Crea e fai buon uso delle varie chat room per le varie configurazioni. Alcuni possono essere ampi come @engineers e alcuni possono essere specifici come @newFeatureA

Considera la possibilità di prendere in considerazione una revisione giornaliera dei biglietti in volo.

Utilizza un ambiente aperto che supporti la collaborazione e assicurati che il QE e il proprietario del prodotto principale siedano al centro degli sviluppatori. Sentirai molto e avrai l'idea di vedere gli schermi intorno a te.

Come sottolinea Robert, soprattutto non si vede che si tratti di microgestione (annota l'uso di "essere visto", cioè indipendentemente dal tuo intento effettivo).

In definitiva, teniamo traccia di ciò che viene realizzato nel tempo e vediamo qual è la nostra velocità. Concentrarsi sui progressi durante il giorno è controproducente in quanto le persone diventeranno demoralizzate e / o andranno via.

Sono sorpreso che nessuno qui abbia ancora menzionato la messaggistica del repository "seguito" o "stellato" integrato in sistemi come GitHub o BitBucket.

I nostri stakeholder tecnici (responsabili di progetto, responsabili dello sviluppo e del supporto) seguono tutti il nostro problema e impegnano storie di aggiornamento sui loro progetti rilevanti. Abbiamo una piccola squadra (15 FTE + appaltatori), ma questo sembra funzionare per noi per

Nessuno viene misurato su nessuna di queste cose, ma in aggiunta ai report di stato settimanali dei PM, questo dà una visione giornaliera del progetto per almeno tenere tutti consapevoli di quali aree vengono lavorate, quindi nessuno se ne va senza visibilità.

È anche aiutato ad aumentare la trasparenza tra sviluppatori e appaltatori e i nostri legami commerciali che aiutano tutti a essere responsabili nei loro piani di consegna.

Se combinati con feed RSS associati a repository specifici o all'intera organizzazione, siamo stati in grado di limitare le email (laddove desiderato) e offrire un set di dati simile in tempo reale e in sintesi tramite lettori RSS. Per alcuni utenti questo è Outlook quindi è fondamentalmente un indirizzo email per loro, anche se leggermente diverso, ma per gli altri utenti usano un client RSS completo con tutti i filtri aggiuntivi di cui hanno bisogno per personalizzarlo alle loro esatte esigenze.

All'inizio ci siamo imbattuti in preoccupazioni simili riguardo al volume delle e-mail, ma i nostri utenti finali hanno ideato il sistema RSS senza che l'Org di Engineering debba fare molto oltre a suggerire i client per coloro che non utilizzano Outlook. Ha lavorato per noi, sempre attorno ai 20-30 FTE + Contractors durante tutto l'anno in più uffici e fusi orari. YMMV, ovviamente.

Questa è un'aggiunta molto marginale (e non è specifica per il programmatore), ma ho avuto un buon successo con Asana negli ultimi progetti.

Per l'integrazione con gli strumenti di collaborazione online esistenti, non guardare oltre Slack . È costruito attorno a una chat, ma funge da hub abbastanza minimalista per gli altri strumenti tra cui Asana, GitHub e Bitbucket. Ha una collezione decente di queste "integrazioni", sia pre-made che community-made , utilizzando l'API che ovviamente consente di crearne di propri.