Come segnalare lo stato di avanzamento del mio progetto (Agile) al mio datore di lavoro (che non è un programmatore)?

Questo è un problema comune quando sei un programmatore che lavora in modo indipendente e fai rapporto a qualcuno che non è tecnico.

I capi come questi vogliono soprattutto essere in grado di capire alcune cose:

• Quanto sono felici gli utenti?
• Sono le cose che gli utenti vogliono essere fatte?
• Quello che stai facendo vale i soldi che ti vengono pagati?

Un Agile burn-down o qualsiasi altra cosa sarebbe una pessima idea! Come hai detto, il tuo capo è molto occupato, quindi non avrebbero il tempo di informarlo, e probabilmente non è interessato comunque .

Quindi, se fossi in te, manderei loro un rapporto via e-mail una volta alla settimana contenente:

• Un "sommario esecutivo" all'inizio: "Sono state completate tre funzionalità questa settimana e ho ricevuto 2 nuove richieste di funzionalità. All'inizio di questa settimana, c'erano 11 richieste di funzioni non completate e alla fine ce ne sono state 10".
• Un elenco di stati di funzionalità, con una breve frase ciascuno, in tre gruppi:
  1. Le funzionalità che hai svolto durante la settimana
  2. Le richieste di funzionalità sono arrivate durante la settimana
  3. Le altre funzionalità nel "backlog"
• Una breve discussione su tutto ciò che è stato complicato o insolito, preferibilmente utilizzando un linguaggio non tecnico.

Se fossi il tuo capo e non avessi ricevuto alcun rapporto, sarei molto felice di riceverlo ogni settimana. E se volessi qualcosa di diverso, te lo chiederei.

Sembra che tu non abbia modo di sapere se sei completo o quanto tempo devi completare. Va bene.

Mantieni un elenco delle funzionalità richieste, quali sono state fatte, in corso o non avviate. Traccia questi come grafico settimanale del totale in ogni categoria. Questo ti darà una serie di punti che puoi estrapolare alla data di fine. Cioè (guardando solo i conteggi delle funzionalità "completati")

• Settimana 1 - 2 completa
• Settimana 2 - 5 completa (2 dalla settimana 1, 3 dalla settimana 2)
• Settimana 3 - 8
• Settimana 4 - 12

Se hai 16 settimane, puoi completare circa 48 funzionalità (non preoccuparti troppo di alcune funzionalità che sono più grandi / più piccole di altre, dopo 4-5 settimane generalmente si esaurirà). Puoi quindi segnalare a tutti che puoi gestire solo il numero X di funzioni. Alla fine del progetto, la cosa più importante è che hai fornito le funzionalità necessarie e non ti sei ucciso nelle ultime due settimane. Segnalando in questo modo, puoi estrapolare i requisiti chiave il prima possibile.

L'altra cosa che vuoi segnalare è quanta capacità hai. "Ho ricevuto solo 2 richieste di funzionalità, ma avrei potuto gestire 3 ... puoi chiedere allo staff di aumentare più funzioni prima?"

Non sono sicuro di avere completamente risposto alla tua domanda, quindi sentiti libero di porre domande di follow-up ...

Tre parole ... brucia il grafico.

Il tuo datore di lavoro, indipendentemente dal fatto che siano dipendenti o meno da agili sviluppatori, apprezzerà un burn-down chart .

Tutti amano capire quando un progetto sarà completato e sfruttando il tempo di ieri fornirà il più accurato e il modo più realistico per prevedere il completamento di un progetto.

Suppongo che tu faccia un one-to-one almeno una volta alla settimana, e possa discutere le tue priorità con il tuo manager in quel momento - ciò che è importante dal suo punto di vista (bisogni così e così la sua funzione prima dell'altra persona, ecc.) e può quindi riportare quanto di tutto ciò che fa sembrare buono il tuo manager rispetto alla quantità di cose che devi fare in totale.

Probabilmente il tuo manager non sta cercando una ripartizione minuto per minuto; sta solo cercando di vedere se il lavoro è finito, se le cose importanti stanno ottenendo più attenzione e che non stai affogando sotto il carico o inattivo perché non sei in grado di procedere.

Si noti che in un vero processo agile, si hanno effettivamente cose che arrivano in continuazione, ma tu e il tuo manager concordate su ciò che è più importante / più necessario e quanto di esso si adatta al periodo di lavoro corrente (che sia una settimana, due settimane, un mese ...), rompendo i lavori in pezzi più piccoli, se necessario, in modo che i pezzi si adattino al periodo.

Un'importante revisione del database che richiede diverse settimane potrebbe essere suddivisa come segue: stabilire backup, verificare i backup sono buoni, progettare il nuovo layout del database, scrivere il software di conversione e testarlo, impostare il rollback e testarlo, provando la conversione sulla macchina di staging, provando il rollback nello stesso posto e infine facendo la conversione. Ognuno di questi può probabilmente essere suddiviso in blocchi di 1 settimana (o meno). Se alcuni passaggi potrebbero richiedere 2 o 3 settimane, devi riportare quanto sei lontano nel corso della prossima riunione (targeting del 50% per 2 settimane, 33% per 3 settimane, ecc.).

Idealmente, avresti una tabella con le cose che devi fare contro le cose che farai ora, e controllerai gli elementi "fai ora" mentre procederai. Ciò consente al tuo manager di camminare e vedere quante cose sono contrassegnate rispetto a cose che sono presenti nell'elenco.

Una volta ogni settimana (presumo che la durata dell'iterazione / sprint nel tuo processo agile sia di una settimana per esempio), fai quanto segue :

• dimostra il nuovo lavoro allo staff, per assicurarti che le loro richieste siano state completate
• segnala al capo il numero di richieste che hai completato durante la settimana e identifica / descrivi tali richieste. Fai un breve riassunto
• segnala al capo il numero di nuove richieste aggiunte al tuo backlog / coda durante la settimana e il numero totale di richieste
• comunica al capo quali (quali richieste) prevedi di lavorare la prossima settimana; in altre parole, le priorità attuali. Ecco l'opportunità per lei di confermarli o cambiarli e per voi due essere chiari su quello
• comunica al capo quale è il piano per 1-2 settimane dopo.

Sento che il tuo capo non è abbastanza tecnico da preoccuparsi o comprendere termini agili come velocità , proprietario del prodotto o burndown tabella . Il modello precedente evita tale gergo, utilizza parole più semplici come "backlog" e "coda" nel loro senso comune, e dovrebbe quindi facilitare la comunicazione con il tuo capo.

Vorrei usare la mia velocità come statistica primaria per lui / lei. Questo mostrerà quante attività / caratteristiche ho "accettato" di parlare per una settimana particolare (o per un altro periodo) e quanti ne ho completati. Da questo, vorrei menzionare alcune delle implementazioni di funzionalità più importanti, e perché questo è cambiato da iterazioni precedenti. Puoi anche menzionare qualsiasi impedimento che hai incontrato e superato e come ha influito sulla tua velocità.

Altre statistiche che il tuo capo potrebbe voler sapere potrebbero includere il numero di nuove segnalazioni di bug segnalate, le segnalazioni di bug chiuse e le nuove richieste di funzionalità inoltrate. Dovrai o chiedere direttamente o usare il tuo miglior giudizio per determinare quali sono i più importanti. Alla fine, vorrei dare uno schema di base del progresso e chiedere se c'è qualcos'altro che lui o lei vorrebbe sapere. Tutto ciò che il capo vuole sapere è che stai facendo progressi e c'è tutto ciò di cui hai bisogno per lavorare al meglio.

Suggerisci di impegnare un rapporto settimanale: Elencare le funzionalità richieste. Registra le funzionalità modificate. Segnala cosa hai fatto.

Cercherò di metterlo in linea in un modo comprensibile ai manager.

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

Solo perché il tuo manager non è un programmatore non pensa che significhi che si aspetta che tu sappia una data esatta di completamento. Presenta i numeri che hai. Dopo che il manager vede il numero di richieste ricevute e completate salendo, il manager vede i progressi. Se i numeri delle tue richieste sfuggono di mano, il manager può intervenire e aiutarti a stabilire le priorità prima di sovraccaricarti. E se sei a corto di lavoro da fare potrebbero essere in grado di trovarti qualche piccolo progetto parallelo. Dopo tutto è sempre bello fare un po 'di pausa in un progetto quando sembra che non ci sia una fine in vista e i giorni lavorativi passano più velocemente e sono più gratificanti quando sei occupato.