Quanto spesso rivedi e convalidi le tue pratiche / processi?

How often/When do you review you development process?

Sempre.

How do you validate the changes in your process are effective?

Monitorando e valutando tutto tutto il tempo.

Può sembrare incredibile, ma dove lavoro non smettiamo di recensire. A prescindere dal post-mortem formale di rilascio per quanto riguarda i problemi pianificati e realizzati (e perché alcuni sono stati posticipati o anticipati), e le solite "revisioni delle prestazioni" dell'HRM, non abbiamo un programma formale per le valutazioni.

Valutiamo e impariamo. Sempre. Nessun programma. Ogni volta che incontriamo qualcosa che preferiremmo non accadesse di nuovo, cerchiamo di trovare un modo per evitare che accada di nuovo. Ogni volta che qualcosa va particolarmente bene, cerchiamo di capire cos'è che lo rende migliore delle altre volte, quindi possiamo replicarlo in futuro.

È informale e molto ad hoc, ma molto efficace e molto efficace. Per uno perché qualsiasi disassociazione di una situazione è immediata, il che significa che tutto è ancora fresco per tutte le persone coinvolte. Per un altro perché se non sei coinvolto nella situazione e / o non fai parte della ricerca della soluzione, non devi perdere tempo in riunioni programmate alle quali potresti non avere nulla da contribuire.

Personalmente, mi piace questa continua (continua?) attenzione su come possiamo migliorare il nostro prodotto, i nostri processi e noi stessi. Non puoi farlo in nessuna delle squadre però. Richiede:

• Un'idea molto chiara delle priorità in tutti gli aspetti del prodotto e del suo sviluppo.
• Una squadra di persone dalla mentalità molto aperta.
• Un'assenza di spostamenti dell'ego / dell'ego. Nessuno è perfetto e prima donna entra in tutti.
• Nessuna proprietà del codice da parte di individui. Nessuno è il solo padrone di un pezzo di codice, tutti possono lavorare su qualsiasi cosa. Sebbene la competenza sia presa in considerazione, il trasferimento delle conoscenze è altrettanto importante.
• Un'atmosfera in cui si riconosce che gli errori accadono e tutti possono commettere un errore o giudicare erroneamente l'impatto / il tempo richiesto per un problema. Questo non significa che ci piacciono errori o errori. Certamente non ci piace vedere lo stesso errore della stessa persona più di una volta.

Mi piace la tua risposta, ma eccone un'altra, per ragioni di varietà:

• esamina 2 settimane e / o 3 cicli dopo l'inizio del processo o della pratica - quando la tua squadra ha il tempo sufficiente per risolvere i problemi di tipo "abbiamo fatto questo totalmente sbagliato" ed è appena iniziando a darci una mano. "Start" può essere una nuova fase (come le fasi di cascata), o l'istanziazione di qualcosa di nuovo che dovrebbe trascendere le fasi - come un nuovo sistema di generazione continua

• recensione alla massa critica - quando hai una quantità "statisticamente significativa" di dati da esaminare. Ho dovuto metterlo tra virgolette, perché qui non faccio analisi statistiche. Ma 3 iterazioni sono troppo piccole. Intendo da qualche parte tra 10-20 ripetizioni di qualcosa in cui potresti avere dati sufficienti per vedere alcuni valori anomali o una tendenza media. Questo può essere roba davvero rilevante per la macchina come il tempo necessario per fare una build, o può essere roba soggettiva come l'accuratezza delle stime individuali o il tempo stimato necessario per correggere una classe di bug.

• recensione completata - se la pratica verrà interrotta dai un'occhiata e guarda se è stata cattiva o buona, avrebbe potuto essere migliore o avrebbe avuto effetti collaterali grandiosi che non avevi anticipare.

• recensione al cambio di personale - indipendentemente dal fatto che tu stia crescendo o diminuendo, le modifiche dello staff sono un buon momento per toccare la base e la recensione. Se si tratta di una nuova persona che si unisce al team, forse hanno dei trucchi fantastici che non ti piacciono. Se è un membro del team in partenza, acquisisci quell'ultima conoscenza. Questo potrebbe non essere necessariamente uno sport di squadra - potrebbe essere un manager / un cambiamento di personale - in particolare se pensi che sia un processo caro a una seria critica.

• recensione perché il gioco è cambiato - il prodotto o l'ambiente in cui lo hai modificato - il tempo di valutare e vedere se devi fare qualcosa in modo diverso.

Non posso dire che faccio tutte quelle cose tutte le volte. Troppe occhiate di ombelico ti faranno impazzire. Ma queste sono tutte pietre da taglio decenti da usare con considerazione.

Qui suonerò il diavolo, perché credo fermamente nel cambiare per il bene piuttosto che nel cambiare per il gusto di farlo. Credo anche che ogni squadra si muove lentamente verso un equilibrio - può rimanere lì per l'eternità.

Hai misurato costantemente i costi / i benefici del cambiamento dei processi? Conosco un gruppo di team che hanno lavorato per anni su un modello di sviluppo incrementale con incontri regolari e sono perfetti per loro. Sì, i nuovi membri del team si uniscono, i vecchi se ne vanno - ma il processo si è bloccato e ha funzionato a meraviglia.

Un'altra domanda che ho è come ridimensionare questo / adattarlo a una squadra impegnata con date strette? Posso vedere che potrebbe funzionare in un piccolo team con risultati gestibili - ma l'hai provato a livello di team / azienda più grande?