Come documentare e fare la revisione dei pari a Scrum? [Chiuso

Question

Sono uno sviluppatore relativamente nuovo in una piccola impresa (un team di 3 sviluppatori e una filiale di QA altrettanto piccola) che lavora su un sistema di medie dimensioni. L'attuale iterazione è ancora sotto 100.000 righe di codice (server e client combinate), ma potrei immaginare che, a lungo termine, la dimensione totale potrebbe essere di 200 kloc o più. Stiamo tentando di utilizzare Scrum per lo sviluppo e stiamo lavorando per una valutazione di livello 2 CMMI.

Stiamo adottando metodi di revisione peer per verificare la progettazione del software e il codice sorgente. Eliminiamo i requisiti del software durante la riunione di pianificazione dello sprint e documentiamo i requisiti del software in un Master SRS. Questo ci dà anche un inizio nella progettazione del software, ma non abbiamo un metodo formale per rivedere i concetti di progettazione, come il design OO, la progettazione dell'interfaccia utente, i modelli di progettazione riutilizzabili e altro ancora. Per il nostro codice sorgente, stiamo provando nuove tecniche, come l'uso di fogli di calcolo per documentare le recensioni delle spalle e le recensioni di pass-around e-mail, ma può essere difficile per il revisore comprendere i concetti di progetta codice sorgente.

(Per favore scusami se sto travisando concetti; ne stiamo tentando molto da zero.)

Non siamo contrari all'uso di UML per esprimere classi, oggetti, interfacce software, modelli di eventi o altri concetti di progettazione, ma non siamo sicuri quando o come scrutare i nostri sforzi di progettazione. Spesso, uno sviluppatore può essere completo del 70% con una storia dell'utente e rendersi conto che deve essere modificato un elemento di progettazione fondamentale (e, successivamente, revisione revisione paritaria).

Nel tentativo di evitare una discussione aperta sull'argomento e promuovere risposte concise, cercherò di proporre due domande specifiche:

1. Qualcuno sa di buone risorse (cioè libri, documenti, articoli) sulle migliori pratiche dei concetti di design di revisione tra pari?
2. Ho letto che il codice stesso è il design (implementazione del). La revisione tra pari del codice sorgente può essere utilizzata come revisione tra pari del design?

Grazie.