Metodologie comuni per scrivere recensioni "post-mortem" [chiuso]

7

Recentemente abbiamo aggiunto una funzionalità relativamente grande al nostro prodotto che ha coinvolto l'intero reparto R & D (con tutti i diversi team al suo interno).

Questa funzionalità includeva sviluppo dell'interfaccia utente, sviluppo lato server ed enormi migrazioni di schemi SQL (e altre cose di cui io stesso non ero affatto coinvolto).

Il processo di sviluppo di questa funzione era caotico: i team Front-End e Server non erano sincronizzati, le migrazioni SQL interrompevano il DB e le specifiche del prodotto erano incomplete, il che significava che in ogni fase del nostro modo di trovare nuovi problemi con la definizione iniziale , richiedendo modifiche ai concetti chiave su cui gli sviluppatori si erano basati.

Nel complesso, una funzionalità che era stata pianificata per essere rilasciata entro 10-14 giorni, ha impiegato circa 24 (intensivi) giorni di sviluppo.

Mi è stato richiesto di scrivere un rapporto su "Cosa è andato storto" (dal lato della mia squadra - ogni squadra scrive un rapporto dal loro pov).

Quali sono le metodologie comuni per scrivere tali rapporti, in particolare nel campo dello sviluppo del software?
Inoltre - Esiste un nome formale per tali rapporti?

EDIT & RISPOSTA:
Apparentemente, un tale rapporto / processo di revisione viene comunemente chiamato "Progetto Post-Mortem" (esistono anche altri nomi).
Dopo averlo scoperto, ho trovato queste due risorse che delineano le metodologie suggerite per raccogliere i dati necessari, organizzarli, analizzarli e formulare soluzioni per i problemi rilevati (così come alcune informazioni generali su queste recensioni e sui loro scopi):

'Un processo definito per il progetto Post Mortem' -
link

"Recensioni post-mortem: scopi e approcci nell'ingegneria del software" - link

    
posta Tudmotu 01.03.2014 - 21:08
fonte

1 risposta

4

Avendolo fatto molte volte, questo è il formato che ho usato con successo in passato. L'ordine in cui queste intestazioni sono presentate farà anche la differenza nel modo in cui la relazione viene ricevuta dal management. Quando è possibile, lasciali con un buon gusto in bocca.

Questo non dovrebbe essere detto, ma ... mantieni il tuo linguaggio professionale per tutto il rapporto.

Che cosa è successo?

Descrivi cosa è successo, sia nel bene che nel male. Fornire dettagli su ogni incidente. Non dare la colpa. Mantieni le opinioni al di fuori di esso. Immagina te stesso come un reporter che racconta la storia di quello che è successo.

Che cosa è andato storto?

Questa è la parte difficile. Ammetti ciò che tu, la tua squadra o altri team avete sbagliato. Lascia la colpa a questo! Basta indicare i fatti. "Noi (il mio team) abbiamo apportato delle modifiche al database che hanno causato ritardi per l'intero gruppo di sviluppo per il numero X di giorni."

Cosa è andato bene?

Parte del racconto di questa storia dovrebbe includere il punto in cui la tua squadra o altre squadre hanno fatto la cosa giusta. Comunicazione di ritardi, modifiche, ecc. "Abbiamo aggiunto molte più colonne alle tabelle X, Y e Z. Queste colonne ci permetteranno di tracciare qualcosa ."

Come miglioriamo il processo?

Questo è il punto in cui inizi a mostrare alcune opinioni. Ti è stato chiesto cosa è successo e cosa si potrebbe fare per risolverlo. Indica le tue opinioni supportate con fatti. "Quando abbiamo apportato la modifica del database di interruzione, avremmo dovuto implementare queste modifiche su un database di sviluppo separato."

    
risposta data 01.03.2014 - 23:18
fonte

Leggi altre domande sui tag