Che aspetto ha il rapporto sullo stato perfetto? [chiuso]

Question

Lavoro con molti sviluppatori e appaltatori fuori sede. Chiedo loro quotidianamente di inviarmi un rapido stato di 5 minuti del loro lavoro per la giornata. A volte devo consolidare lo stato delle persone in team e talvolta consolidare lo stato di una settimana, per i rapporti di fine periodo ai miei clienti.

Voglio imparare:

• Elementi realizzati e quanto tempo è stato impiegato su ciascuno
• Problemi riscontrati e tempo trascorso su ciascuno
• Articoli su cui lavoreremo in seguito, le loro stime (in ore uomo) e le loro date target
• Domande che hanno sul lavoro

Sto cercando un formato che fornirà queste informazioni mentre:

• Essere veloci per il completamento degli sviluppatori (5-10 minuti, senza pensare troppo)
• Facile da leggere e navigare velocemente
• È uniforme per ogni sviluppatore

Cosa suggeriresti?

Answer 1

Usa Scrum . Creare il backlog dello sprint, disporre di un foglio di calcolo con le attività e una colonna per ogni giorno dello sprint. Chiedi alle persone di compilare le ore lavorate su ogni compito ogni giorno. Invia un rapporto giornaliero iniziando con il grafico di burndown per lo sprint e poi corti due liner da uno per ciascun membro: l'ultimo ha funzionato e il prossimo ha lavorato. Invia un rapporto settimanale con il grafico di burndown, lo stato rosso / giallo / verde per ciascuna caratteristica principale (e blocca i problemi e le note se non è verde) e gli elementi rimanenti nel backlog dello sprint.

Non ho un link agli esempi, ma qui ci sono alcune bozze:

10/02/2008 - Product A daily status

<Burndown chart>

Team member A
Last 24: feature A
Next 24: feature A unit tests

Team member B
Last 24: bug jail
Next 24: feature B

Team member C
Last 24: feature C
Next 24: feature C
Blocked on: Dependency D - still waiting on the redist from team D

10/02/2008 - Product A weekly status

<Burndown chart>

**Feature A** - Green
[note: red/yellow/green represents status; use background color as well for better visualisation]
On track

**Feature B** - Yellow
[note: red/yellow/green represents status; use background color as well for better visualisation]
Slipping a day due to bug jail
Mitigation: will load balance unit tests on team member A

**Feature C** - Red
[note: red/yellow/green represents status; use background color as well for better visualisation]
Feature is blocked on external dependency from team D. No ETA on unblock.
Mitigation: consider cutting the feature for this sprint

**Milestone schedule:**
Planning complete - 9/15 (two weeks of planning)
Code complete - 10/15 (four weeks of coding)
RC - 10/30 (two weeks stabilization and testing)

Answer 2

probabilmente non vuoi ascoltarlo, ma eccolo qui comunque -

Sono stato in questa situazione su entrambi i lati della scrivania e sono giunto alla conclusione che questo tipo di rapporti sullo stato arrotolati sono una completa perdita di tempo per te e gli sviluppatori. Ecco perché:

• gli sviluppatori dovrebbero lavorare su funzionalità / risultati con scadenze specificate
• gli sviluppatori dovrebbero porre domande quando si verificano
• la comunicazione dovrebbe fluire in entrambe le direzioni secondo necessità

se queste cose non accadono, nessuna quantità di report sullo stato passivo risolverà i problemi che inevitabilmente sorgeranno

sul lato sviluppatore della recinzione: uno stato rapido di cinque minuti " [odio quella frase, cinque minuti non sono rapidi!] interrompe il flusso dello sviluppatore, causando una perdita di quindici minuti (o più) di produttività (penso che Joel abbia persino scritto un blog su questo). Ma anche se sono davvero solo cinque minuti, se hai una dozzina di sviluppatori, stai sprecando cinque ore-uomo a settimana in amministrazione (ed è probabilmente più simile a 20)

sul lato manageriale della barriera: raggruppare i rapporti sullo stato delle persone in team per progetto, ecc. è un lavoro non produttivo che fa perdere tempo. È probabile che nessuno legga nemmeno i rapporti.

ma ecco il vero problema: questo tipo di reporting e roll-up può indicare una gestione reattiva anziché una gestione proattiva. In altre parole, non importa quale metodologia venga utilizzata - scrum, xp, agile, razionale, a cascata, cresciuta in casa o altro - se il progetto è correttamente pianificato ed eseguito, allora dovresti già sapere cosa tutti sta facendo perché è stato pianificato in anticipo. E non importa se è stato pianificato quella mattina o sei mesi fa.

ignorando i requisiti del cliente per un momento, se hai davvero bisogno di queste informazioni su base giornaliera per gestire i progetti, allora ci sono probabilmente alcuni seri problemi con i progetti - chiedere allo sviluppatore ogni giorno su cosa lavoreranno dopo e quanto tempo ci vorrà, ad esempio, suggerisce che nessuna vera pianificazione è stata fatta in anticipo ...

per quanto riguarda i requisiti del cliente, se insistono assolutamente su questo tipo di minutia [e so che, per esempio, alcune agenzie governative lo fanno] allora l'opzione migliore è fornire un'interfaccia web o un'altra applicazione per automatizzare la noia che farà il roll-up per te. Perderai comunque il tempo degli sviluppatori, ma almeno non perderai il tuo tempo ;-)

oh, e per rispondere letteralmente alla tua domanda: il rapporto sullo stato perfetto dice "in target con il piano di progetto", e niente di più ;-)

Answer 3

Fornisci loro un modello strutturato in un formato in cui prevedi di vedere i dati restituiti. Puoi anche considerare di aumentare il tempo che dedicheranno a questo e rimuovere il "non pensare troppo". clausola se si richiedono stime per lavori futuri. Non mi fiderei di una stima che qualcuno ha inventato in 5 minuti. senza pensare.

Se stai attualmente utilizzando un software di gestione dei progetti, dovrebbe essere banale per gli sviluppatori registrare e rivedere (o anche solo ricordare) cosa hanno fatto compilandolo per te. Idealmente, registrerebbero problemi o domande durante il giorno e non proverebbero a risolverli solo per compilare il rapporto.

Sembra che il tuo " Voglio imparare " list è un ottimo punto di partenza da cui generare un modello. Solo tu saprai qual è il formato perfetto per te.

Answer 4

In genere ho appena fatto affidamento sull'e-mail come mezzo per fornire rapporti sullo stato, fornisce la semplicità e la velocità di completamento ma non applica alcun tipo di uniformità.

Esistono diverse opzioni per raggiungere questo obiettivo, ma tutte rischiano di rendere il processo più complesso e dispendioso in termini di tempo. Alcuni di questi potrebbero essere:

Un modulo online con sezioni per ciascuno o un foglio di calcolo a più fogli, con ogni foglio che è una sezione.

Tutti questi richiedono uno sforzo da soli per crearli, hai bisogno dell'uniformità per qualche scopo? per esempio. per automatizzare i rapporti di riepilogo.

Un'alternativa a questa sarebbe quella di utilizzare alcuni strumenti di gestione del progetto che gli appaltatori hanno compilato mentre stavano lavorando e su cui si poteva riferire in qualsiasi momento. Consiglierei Thoughtworks Studio Mingle, ma si basa su un processo agile.

Answer 5

Sembra che tu voglia fare Extreme Stand up meeting.

http://www.extremeprogramming.org/rules/standupmeeting.html

Puoi parlare con i membri del team fuori sede usando il telefono con altoparlante o qualche VOIP.