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

Ho un problema nel riferire i progressi al mio datore di lavoro. Sono un programmatore part-time, gestendo un progetto software per il dipartimento (non tecnico) della mia scuola.

Persona di contatto:
1. Il personale che utilizza effettivamente il software e solleva richieste di funzionalità,
2. Il mio capo (non programmatore) e non è l'utente del software.

La natura del progetto:
è un software già pronto, acquistato da terze parti. Devo modificare o aggiungere funzionalità / funzioni a questo software per soddisfare le esigenze del dipartimento. Questo è un software che è necessario utilizzare durante tutto il semestre. Non tutte le funzionalità devono essere utilizzate all'inizio.

Quindi stiamo usando il modello Agile: quando il personale ha bisogno di una determinata funzionalità, solleva una richiesta e io apporto le modifiche. Entro la fine del semestre, suppongo che tutte le funzionalità richieste saranno aumentate e implementate.

Il problema: ogni
volta che il mio capo mi ha chiesto come sono fatti i progressi, non posso rispondere, perché non so come rispondere. Non ho un elenco completo di tutte le funzionalità richieste. Anche se ho completato funzionalità che sono state sollevate la scorsa settimana, non riesco ancora a dire al mio capo che ho "completato", perché stanno arrivando anche nuove funzionalità e non so quanto. Non posso dire "Abbiamo quanti% di completamento" né "Lo completeremo entro xxx". A volte su 3 richieste, riesco a completare 2, direi al mio capo "Ho completato 2, ma c'è una funzione non ancora completa". Dopo un lungo periodo di tempo, sembra "Ho sempre qualcosa che non finisce, dopo così tanto tempo".

Non essere in grado di segnalare i progressi mi fa sembrare davvero male. Non si tratta di quanto ho fatto, ma di come far sapere alla gente. Se fossi il manager e il mio staff continuasse a non farmi conoscere i progressi per mesi, sentirò che anche questo ragazzo è incapace.

Ragazzi avete idea di come segnalare o rispondere a una domanda semplice come "qual è lo stato / i progressi della modifica del software"?

AGGIORNAMENTO Il mio capo non coinvolge direttamente l'attività di sviluppo, quindi non ha idea di cosa sto facendo o di come funzioni il programma. Non ci incontriamo regolarmente perché è impegnata e penso che sarà una perdita di tempo perché non è l'utente principale, non conosce i dettagli del programma.

Incontro regolarmente con lo staff che utilizza e conosce meglio il software.

Mi sento difficile spiegare i progressi al mio capo.

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

Boss del genere vogliono soprattutto riuscire a capire alcune cose:

• Quanto sono felici gli utenti?
• Le cose che gli utenti vogliono fare?
• Quello che stai facendo vale i soldi che ti vengono pagati?

Un bruciore agile o qualsiasi altra cosa del genere sarebbe una terribile idea! Come hai detto, il tuo capo è davvero impegnato, quindi non avrebbero il tempo di conoscerlo, e probabilmente non sono interessati ad esso.

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

• Un "sommario esecutivo" all'inizio: "3 funzioni completate questa settimana e 2 richieste di nuove funzionalità. All'inizio di questa settimana, ci sono state 11 richieste non completate e alla fine ce ne sono state 10."
• Un elenco di stato delle funzioni, 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à del "backlog"
• Una breve discussione di tutto ciò che era complicato o insolito, preferibilmente usando 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 sei lontano dal completamento. Va bene.

Tenere un elenco delle funzionalità richieste, quali sono state eseguite, in corso o non avviate. Tieni traccia di 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à "completate")

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

Se hai 16 settimane, puoi completare circa 48 funzioni (non preoccuparti troppo che alcune funzioni siano più grandi / più piccole di altre, dopo 4-5 settimane sarà in media media). È quindi possibile segnalare a tutti che è possibile 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, è possibile estrarre al più presto i requisiti chiave.

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

non sono sicuro di aver risposto completamente 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 tossicodipendenti agili o solo un responsabile degli sviluppatori, apprezzerà un grafico esaurito .

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

Presumo che tu faccia uno a uno almeno una volta alla settimana, e che tu possa discutere le tue priorità con il tuo manager a quel punto - ciò che è importante dal suo punto di vista (così e così ha bisogno della sua funzionalità prima altra persona, ecc.) e può quindi segnalare quanta roba che fa apparire bene il tuo manager rispetto alla quantità di cose che devi fare in totale.

Il tuo manager probabilmente non è alla ricerca di una ripartizione minuto per minuto; sta solo cercando di vedere se il lavoro sta per essere completato, se le cose importanti stanno attirando più attenzione e che non stai annegando sotto il carico o inattivo perché sei bloccato dal procedere.

Tieni presente che in un vero processo agile, hai davvero cose in arrivo tutto il tempo, ma tu e il tuo manager siete d'accordo su ciò che è più importante / più necessario e su quanto si adatterà nel periodo di lavoro corrente (sia che si tratti di una settimana, due settimane, un mese ...), suddividendo i lavori in pezzi più piccoli, se necessario, in modo che i pezzi si adattino al periodo.

Un'importante revisione del database che potrebbe richiedere diverse settimane potrebbe essere analizzata in questo modo: stabilire backup, verificare che i backup siano corretti, progettare il nuovo layout del database, scrivere il software di conversione e testarlo, impostare il rollback e testarlo, provare la conversione su la macchina di staging, provando il rollback nello stesso posto e infine eseguendo 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, segnaleresti quanto tempo eri nella prossima riunione (mirando al 50% per 2 settimane, al 33% per 3 settimane, ecc.).

Idealmente, avresti un grafico che ha le cose che devi fare rispetto alle cose che farai ora e spunta gli elementi "fai ora" mentre procedi. Questo consente al tuo manager di passare e vedere quante cose sono contrassegnate rispetto alle cose che sono nella lista da fare.

Una volta ogni settimana (suppongo che la durata dell'iterazione / sprint nel tuo processo agile sia di una settimana a titolo di esempio), procedi come segue :

• demo i nuovi lavori allo staff, per assicurarsi che le loro richieste siano state completate
• segnalare al capo il numero di richieste completate durante la settimana e identificare / descrivere 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
• dì al capo su quale (quali richieste) hai intenzione di lavorare la prossima settimana; in altre parole, le priorità attuali. Ecco l'opportunità per lei di confermarli o cambiarli e per voi due di essere chiari su questo
• di 'al capo qual è il piano per 1-2 settimane dopo.

Sento che il tuo capo non è abbastanza tecnico per prendersi cura o comprendere termini agili come velocità , proprietario del prodotto o grafico di burndown . Il modello sopra evita tale gergo, usa parole più semplici come "arretrato" e "coda" nel loro senso comune e dovrebbe quindi facilitare la comunicazione con il tuo capo.

Vorrei usare la mia velocità come statistica principale per lui / lei. Questo mostrerà quante attività / caratteristiche ho "concordato" di parlare per una determinata settimana (o altro periodo) e quante ho completato. Da questo, vorrei citare alcune delle più importanti implementazioni di funzionalità e perché questo è cambiato dalle iterazioni precedenti. Puoi anche menzionare tutti gli ostacoli che hai incontrato e superato e come ciò ha influito sulla tua velocità.

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

Suggerisci di inviare un rapporto settimanale: elenca le funzionalità richieste. Registra le funzionalità modificate. Segnala ciò che hai fatto.

Vorrei provare a farlo in un modo che i manager capiscono.

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 pensare che ciò significhi che si aspettano che tu conosca una data di completamento esatta. Presenta i numeri che hai. Dopo che il manager ha visto il numero di richieste ricevute e completate in aumento, il manager vede progressi. Se i numeri delle tue richieste sfuggono di mano, il manager può intervenire e aiutarti dando la priorità prima di essere sovraccarico. E se stai esaurendo il lavoro per farlo, potrebbero essere in grado di trovarti qualche piccolo progetto laterale. Dopotutto è sempre bello fare una pausa per un progetto quando sembra che non ci sia fine in vista e le giornate di lavoro passano più velocemente e sono più gratificanti quando sei occupato.