Nella gestione del gruppo da remoto, i membri del gruppo possono essere attivi in momenti diversi o essere impegnati con attività familiari nel bel mezzo dell’attività lavorativa (e va bene così: le persone dovrebbero lavorare quando possono essere più produttive).
Quindi, come dovrebbero i lavoratori remoti comunicare le pratiche e le procedure ai colleghi quando non possono semplicemente parlare tra di loro: "Ehi, come possiamo fare delle revisioni del codice qui?"
Liste di controllo
Uso liste di controllo da anni. Nello sviluppo dei software se ne utilizzano molte, come i principi SOLID sulla progettazione orientata agli oggetti.
Ma non è stato sempre così. Il libro "The Checklist Manifesto" spiega il vero potere delle liste di controllo e come renderle procedure operative standard nei gruppi di sviluppo software.
Il libro descrive uno studio che è particolarmente rilevante oggi, dato che il mondo soffre del peggior disastro globale dalla seconda guerra mondiale: la pandemia di COVID-19. Lo studio è stato condotto da Stephan Luby con il supporto di Proctor & Gamble per testare l'efficacia del sapone antibatterico e ha prodotto risultati incredibili: l'incidenza di varie malattie è scesa del 35% - 52%.
Ma la cosa veramente interessante di questo studio è che il tipo di sapone che è stato usato non ha fatto una grande differenza, le persone usavano già in precedenza il sapone. La differenza era che le istruzioni includevano due liste di controllo - Quando lavarsi le mani:
- Prima di preparare il cibo o darei da mangiare agli altri.
- Dopo aver starnutito.
- Dopo aver pulito un bambino.
- Dopo aver usato un bagno.
Molte persone si stavano già lavando le mani dopo aver usato il bagno, ma non lo stavano facendo correttamente. La lista di controllo includeva altre istruzioni:
- Usare il sapone.
- Bagnare completamente entrambe le mani.
- Strofinare il sapone fino a formare una spessa schiuma che copra completamente entrambe i palmi.
- Lavare le mani per almeno 20 secondi (non incluso in questo studio, ma ci vogliono almeno 20 secondi per abbattere i virus virali incluso Coronavirus, quindi lo metto qui per i poster).
- Risciacquare completamente il sapone.
Non era il sapone particolare usato - qualsiasi sapone è efficace. Sono state le liste di controllo a prevenire le malattie. Le liste di controllo hanno cambiato i comportamenti e hanno insegnato alle persone come e quando lavarsi correttamente le mani.
I membri di gruppi di lavoro che utilizzano liste di controllo consigliare di utilizzare le liste di controllo per molte attività. Le migliori liste di controllo sono hanno queste regole:
- Includre solo i punti chiave
- Creare punti corti da memorizzare facilmente
Se diventano troppo lunghi, la conformità alla lista di controllo diminuisce, poiché le persone iniziano a vedere i punti della lista di controllo come suggerimenti opzionali.
Ecco alcuni esempi reali delle liste di controllo che vengono utilizzate comunemente nei gruppi di lavoro. Alcuni di questi (come FIRST e RAIL) sono ampiamente utilizzati e sviluppati esternamente. Molte altre regole (includi 5 domande, RITE Way, Test Timing ed entrambi gli elenchi CI / CD) sono stati sviluppate dall’autore dell’articolo Eric Eliot, ma ispirati alle migliori pratiche del settore:
Elenco di controllo per la revisione del codice
Prima di aprire una richiesta modifica, verificare che siano stati considerati i seguenti punti:
- Il codice è leggibile
- Il codice è stato testato
- Le funzionalità sono documentate
- I file sono posizionati e denominati correttamente
- Gli stati di errore sono gestiti correttamente
- Bonus: schermate / demo screencast incluse
Elenco di controllo test codice (RITE Way)
Nel software di qualità, gli sviluppatori devono fornire test che dimostrano automaticamente che il codice funziona. Per testare il RITE Way, ogni test dovrebbe essere:
- Leggibile
- Isolato (unità e test) / Integrato (per test di integrazione)
- Accurato
- Esplicito
Elenco di controllo dei tempi di prova
- I test dell'unità vengono eseguiti in meno di 10 secondi
- I test funzionali dovrebbero essere eseguiti in meno di 10 minuti
- I controlli CI / CD dovrebbero essere eseguiti in meno di 10 minuti
5 domande a cui ogni test unitario dovrebbe rispondere
- Qual è il componente in prova?
- Qual è il comportamento atteso (in forma leggibile all'uomo)?
- Qual è il suo output effettivo?
- Qual è l'output atteso?
- Come si riproduce un fallimento del test? (Controlla che le risposte a quanto sopra rispondano a questa domanda).
Questi elenchi sono sorprendentemente simili alle liste di controllo per la segnalazione degli errori di progettazione, perché tutti i test unitari non riusciti dovrebbero essere buoni reseconti sui differenti errori presentati.
Elenco di controllo per la segnalazione di un errore
Ogni segnalazione di errore dovrebbe includere:
- Descrizione (compresa la posizione)
- Uscita prevista
- Uscita effettiva
- Istruzioni per la riproduzione
- Ambiente (versioni del browser / sistema operativo, estensioni)
- Bonus: Screenshot / screencast che dimostra il bug
Elenco di controllo dei componenti (FIRST)
I componenti dovrebbero seguire i principi dei FIRST:
- Focalizzazione
- Indipendenza
- Riutilizzazione
- Grandezza
- Testabilità
Elenco di controllo delle prestazioni dell'interfaccia utente del software (UI) (RAIL)
Le interfacce utente del software devono essere conformi al modello di prestazioni RAIL:
- Rispondi all'interazione dell'utente in meno di 100 ms
- I fotogrammi di animazione devono essere disegnati in meno di 10 ms
- I processi di inattività dovrebbero essere raggruppati in blocchi di meno di 50 ms
- Carica in meno di 1 secondo
Elenco di controllo per la preparazione alla consegna continua
- Un minimo dell'80% del codice è coperto da test unitari.
- Tutti i flussi di lavoro degli utenti critici sono coperti da funzionalità
- Tutte le integrazioni critiche sono coperte da test di integrazione.
Esiste un sistema di attivazione / disattivazione delle funzionalità per attivare o disattivare le funzionalità nell'ambiente di produzione. Tutte le funzionalità non completate sono disattivate per impostazione predefinita.
Elenco di controllo CI / CD
- Ogni commit a master deve prima passare attraverso un processo Pull Request (PR). L'unione deve essere bloccata fino al completamento dei controlli.
- Ogni richiesta pull deve essere rivista da peer prima di fondersi nel ramo master.
- Ogni richiesta pull deve superare una serie completa di test automatici configurati per interrompere il processo di integrazione in caso di esito negativo di eventuali test.
- Ogni commit attiva la propria build sandbox per test, dimostrazione e verifica. Il link di compilazione viene aggiunto ai dati di revisione del codice.
- Dopo aver superato tutti i controlli, l'unione viene sbloccata.
- L'autore della richiesta pull deve OK l'unione (o essere personalmente responsabile dell'unione).
- La fusione dovrebbe innescare la distribuzione automatica della produzione del nuovo codice integrato. Pertanto, il ramo principale dovrebbe sempre riflettere la build del prodotto di produzione.