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