Come eseguire una revisione efficiente del codice durante la febbre?

La risposta qui è comunicare.

1. Informa il responsabile tecnico / del team sul problema
2. Parla con il QA del potenziale impatto
3. Informa la direzione del progetto (chi è alle tue spalle) che potrebbe esserci un problema che causa il ritardo della pubblicazione, e ti ricontatterai ASAP (in pochi minuti o ore)
4. Valuta se questo problema è uno stopper per il rilascio

Se il problema non è uno stopper, continua con la versione. Informare il QA e gli utenti del problema e impegnarsi in una data di follow-up in cui il problema verrà corretto. Questo diventa solo un altro rischio per la produzione.

Se questo è uno stopper (il che significa che avrà un impatto negativo sulla linea di fondo o sullo stato di salute di qualcuno) comunicherà alla catena che il tuo consiglio è di ritardare il rilascio e dire perché. Quindi torna indietro con lo sviluppatore e calcola il tempo necessario per risolvere il problema e comunica alla direzione che hai bisogno di X numero di minuti / ore / giorni.

È probabile che la gestione non sarà contenta di un fermo spettacolo in ritardo nel gioco, ma non vorrà che venga pubblicato in produzione.

Comunicare e lasciare che la gestione effettui la chiamata.

Non comunicare semplicemente il problema, documentalo

La mia grande preoccupazione per le altre risposte finora: qualsiasi cosa tu dica in questo modo al tipico project manager di fronte a una scadenza imminente è probabile che venga ignorata o dimenticata. Quindi, puoi ancora finire con l'essere in difficoltà per insufficientemente comunicare il rischio, se qualcosa va storto.

Fai sapere al project manager del problema che hai trovato e fagli sapere che lo documenta . Devi essere in grado di indicare la tua due diligence.

Dove documentare e chi dire dipende dal tuo ambiente di lavoro, ma sicuramente include il tuo capo.

Identifica rischio e impatto

Hai menzionato che il problema non è critico ma non definisci realmente cosa significhi. Fleshing è il tuo prossimo passo.

Fai un rapido analisi del rischio e dell'impatto identificando il problema, la probabilità di causare un problema (rischio) e la gravità delle conseguenze se il rischio si concretizza (impatto). Utilizza termini ben definiti (che il tuo project manager dovrebbe sapere) come quelli trovati nel link sopra, ma fornisci anche una descrizione a sostegno dell'analisi.

La tua documentazione dovrebbe includere anche la tua linea di condotta raccomandata. Sì , è corretto sollevare un problema e consigliare comunque di procedere con la versione. È corretto identificare il rischio .

Quando è la tua prossima versione?

Se, dopo aver completato l'analisi di rischio / impatto, sei ancora in discussione su cosa consigliare, prendi in considerazione il tuo programma di rilascio. Alcuni codici imperfetti possono essere rilasciati se puoi prevedere di includere la correzione entro due settimane.

Se c'è la possibilità che la risoluzione della tua preoccupazione venga "deprioritizzata" (cioè trascurata in favore del prossimo miglioramento brillante), allora questo è un motivo in più per documentare il problema il più presto possibile dopo averlo scoperto: se efficacemente "avvia l'orologio" sul problema.

In questo caso, informa tutti e lascia che decidano. Probabilmente non è il primo bug che hai pubblicato.

La scadenza è domani, ma ti trovi in questa situazione:

project manager is standing over your shoulder and presses you to finally make a build

Questa potrebbe essere un'eccezione, quindi non apportare modifiche drastiche al tuo processo solo perché un bug è sfuggito. Quello che dovresti fare è mettere in atto alcune misure, quindi non stai costruendo build all'ultimo minuto. Si spera che si costruisca build con una frequenza abbastanza regolare per darti la certezza che avrà successo. Non è ancora una buona ragione per eseguirli all'ultimo minuto. Avere le cose ben testate è un altro pezzo per aumentare la fiducia.

Presenta questo scenario a chiunque stia conducendo questa cosa.

• Determina quali tipi di problemi devono essere presentati.
• Identifica le opzioni.
• Chi prende la decisione
• Quando tutto questo dovrebbe essere deciso da? Probabilmente sarà relativo alla data di rilascio.

Sebbene questo non risponda a cosa fare con questo problema dell'ultimo minuto, offre un modo per assicurarti di essere in grado di gestirli in futuro. Soprattutto quando c'è una pressione da rilasciare, vuoi avere un modo per gestire le cose in un modo che è pensato e non guidato da emozioni.

Se c'è una scadenza e il tuo manager è proprio dietro di te che guarda da dietro le spalle, gli dici di andare via. Lui se ne va o te ne vai. Spiega a lui che essendo costretto a rivedere sotto pressione, si potrebbe anche non rivedere il codice.

In una situazione come questa, puoi essere sicuro che alcuni bug critici andranno a buon fine.

Potresti trovarti in una situazione fortunata, ad esempio l'invio all'App Store di Apple, dove hai alcuni giorni per ritirare una nuova versione. Ma se il tuo codice viene spedito ai clienti, questa è una ricetta per il disastro. La prossima volta spero che il tuo manager pianifichi meglio.

Altre risposte si concentrano sul problema del tuo manager che cerca di piegare il tuo processo di qualità.

Tuttavia, quello che penso tu stia chiedendo è come affrontare il fatto che la revisione del codice richiede almeno 2 persone, e quindi introduce ritardi significativi. Ad esempio, se un'attività richiede 2 ore per l'implementazione e 2 ore per la revisione, spesso c'è una lunga pausa tra le due attività. In tempo reale l'attività potrebbe richiedere 2 o 3 giorni per completare.

Questo è un classico problema di throughput vs latenza. Negli switch per la produzione di software (esseri umani) i commutatori di contesto sono costosi, quindi evitare che il lavoro di qualcuno faccia immediatamente una revisione non dovrebbe essere una pratica comune.

Ecco alcuni suggerimenti per mitigare il problema:

• Mentre si lavora su un'attività, inviare il codice in piccole parti, in modo che il revisore non lo faccia devono riservare lunghi blocchi di tempo.
• Promuovi una cultura di alta priorità per le revisioni del codice. Non interrompere l'attuale unità di lavoro quando ricevi una richiesta, ma quando ti stai chiedendo cosa fare dopo, scegli sempre una recensione dalla tua coda.
• Approfitta della differenza di fuso orario nei tuoi team, se ce n'è uno.
• Non impegnare una sola persona nella revisione del solo codice. È controduttivo. Non sarà in grado di gestire il carico, se sarà serio sul suo compito. Il tuo manager non accetterà l'idea che qualcuno sia inattivo, solo per poter potenzialmente salvare un giorno.