In Agile, dovrei creare un'attività di revisione del codice?

Le recensioni fanno parte del lavoro che deve essere svolto per portare a termine un compito, proprio come l'implementazione e il test. Per questo motivo, lo sforzo di revisione dovrebbe essere incluso nella stima per l'attività.

Poiché hai già stati diversi per l'implementazione e il testing, è opportuno aggiungere uno stato aggiuntivo per indicare che il codice per un'attività è in fase di revisione.

Nota a margine, se ritieni che spesso le attività implementate non possano essere rilevate immediatamente per la revisione o il test (perché gli altri membri del team sono impegnati in altre attività), potresti voler aggiungere "stati di attesa simili a kanban" "per le tue attività, come" pronto per la revisione "e" pronto per il test ". Questo può chiarire se ci potrebbe essere un collo di bottiglia nelle fasi di revisione e / o test, avendo una pila di attività negli stati "pronti per". Significa anche che colui che ha scritto il codice non deve assegnare un revisore / tester (o chiedere in giro per uno), ma chiunque abbia un momento libero può ritirare un'attività in attesa di revisione / test.

Abbiamo usato entrambi. Quando si dispone di un'attività di revisione separata, è possibile assegnare tempo a tale attività ed è visibile a tutti. Ma hai un sacco di compiti alla lavagna. Utilizziamo una lavagna con post-it in modo che la proprietà immobiliare sia limitata, in qualche modo uno svantaggio.

Al momento usiamo uno stato separato per la revisione. Questo è meno di una seccatura quando si aggiorna per un nuovo sprint. Lo usiamo anche per avere il codice funzionante revisionato. Nel nostro team un altro sviluppatore esegue la revisione tecnica del codice e lo specialista del dominio esegue una revisione funzionale.

Per ora uno stato separato è il nostro metodo preferito.

Dipende.

Personalmente, mi piace avere compiti per la revisione del codice perché consente di valutare correttamente queste cose. Crea anche un elemento di monitoraggio che mostra chiaramente se / quando viene eseguito. E ti consente di assegnare esplicitamente a qualcuno la revisione del codice e di mantenere il lavoro equilibrato.

Ma sono anche dell'opinione che non tutto il lavoro richiede revisioni del codice, e certamente non sempre formali.

Se la tua organizzazione richiede revisioni del codice per tutto , allora diventa un po 'di lavoro generico per creare tutte le attività e rappresenta un'unità di lavoro separata. Se lo stai richiedendo per tutto, non lo vuoi separare - lo vuoi radicato come "qualcosa di naturale come pianificare / codificare / testare". Quindi, mentre penso che questo approccio allo sviluppo del software sia eccessivo nella maggior parte dei casi, è appropriato in altri. In questi casi, lavorerei per rendere le revisioni del codice un passaggio del processo, non compiti separati.

Prima di aggiungere nuovi stati di qualsiasi tipo, ti consiglio di considerare per che cosa userai quello stato. Se c'è qualche parametro che stai cercando di tracciare come il tempo di ciclo in quello stato, allora potrebbe essere utile. Altrimenti, cosa c'è di sbagliato nell'includere le revisioni del codice nella tua definizione di fatto?

Non vedo la necessità di aggiungere ulteriore complessità al processo solo per il gusto di averlo. C'è un valore nell'avere quello stato? Che cosa hai intenzione di fare con le informazioni che sapere che una cosa è in quello stato ti dà?