Quando eseguire la revisione del codice

Dipende dalla natura delle storie degli utenti.

Può essere efficace creare un ramo per ogni storia utente, i progressi su diverse storie sono visibili, possono essere passati in giro se necessario, se le storie non sono completate nello sprint, quindi i progressi possono rimanere nel ramo per il prossimo sprint. Le revisioni finali possono quindi essere eseguite alla fine di un articolo utente nel ramo della storia d'uso e unite nel caso in cui il codice sia conforme allo standard.

Per lavorare nel modo in cui le storie devono essere finemente granulose per evitare attività di unione non gestibili alla fine di uno sprint. Piccole storie permetteranno un costante aggiornamento del ramo di sviluppo attraverso lo sprint che gli sviluppatori che lavorano su altre storie di utenti devono costantemente estrarre da (VCM di base).

Questo crea i costi generali del processo che devono creare e unire costantemente i rami, che in alcuni casi possono essere risolti con gli script di automazione, ma il team deve comunque essere molto a suo agio con il VCS.

Alla fine di uno sprint unisci il tuo ramo dev in integrazione / produzione ecc.

Ho anche lavorato in team in cui tutti lavorano su un ramo di sviluppo, al termine di una user story il codice viene inviato a quel ramo per la revisione e il test e se qualcuno spinge qualcosa che rompe la build di sviluppo devono ottenere il team birre dentro.

Il modo più efficace per esaminare il codice è quello di alzarsi in piedi, trovare qualcuno e chiedere loro di venire a discutere del codice appena sviluppato.

Non utilizzare uno strumento a meno che non sia possibile trovare qualcuno che riveda il codice localmente.

È possibile evitare completamente le revisioni del codice tramite l'associazione.

Tutti i membri del team sono locali? Se è così, basta chiedere a qualcuno di venire a dare un'occhiata prima che il codice sia archiviato. Non locale? Avvia il tuo programma di condivisione dello schermo preferito e chiama qualcuno. Io personalmente lo faccio spesso. A volte lo faccio solo per dire "Ehi, guarda cosa ho fatto!"

Preferisco di gran lunga questo stile di recensioni di codici ad hoc allo stile in cui qualcuno è in piedi e presenta il proprio codice al team. Le recensioni ad hoc possono darti molti (tutti?) Dei benefici dell'accoppiamento senza l'imbarazzo. Inoltre, il tuo "revisore" ha maggiori probabilità di porre domande e suggerire miglioramenti in un ambiente informale, uno contro uno.

Credo che la revisione del codice non sia una parte formale di SCRUM, tuttavia le revisioni sono una tattica indipendente per raggiungere la qualità e migliorare i tuoi progetti / team.

Quindi, dovresti usare SCRUM (o un'altra metodologia di sviluppo agile) per assicurare / migliorare la qualità di PROJECT e continuare a pianificare. Inoltre, una buona tattica consiste nel fare la revisione del prodotto (non il codice) in modo indipendente dal normale QA / attività di test. Se questa attività potrebbe essere svolta di fronte al tuo team / partner / clienti / pubblico, sarà meglio.

Dovresti usare le revisioni del codice (o altre specifiche) principalmente per migliorare il tuo TEAM, aspettandoti i risultati a medio / lungo termine. Ciò influenzerà i tuoi PROGETTI, ma a lungo termine come un prodotto del tuo miglioramento TEAM.

Quindi, per rispondere alla tua domanda, credo che stai provando a spingere troppo da SCRUM, e dovresti prendere in considerazione le revisioni solo così com'è.

Non è ovvio effettuare revisioni del codice prima di controllare il codice?

TFS non funziona come GIT, quindi ogni volta che controlli il codice in un ramo o nel tronco, è disponibile per tutti.

Ciò significa che la verifica dovrebbe avvenire al momento del check-in, pertanto le modifiche errate non vengono propagate alla copia di lavoro di tutti.