Come mettere le lezioni apprese, le buone pratiche, ecc. nel "flusso di lavoro"

Va bene, ecco quello che credo.

Quando si tratta del tuo esempio con i log, penso che tu abbia effettivamente la risposta nella tua lista. Quello che si riduce a è in definition of done . Se gli sviluppatori stanno stampando dati sensibili sui log e si suppone che i tester controllino che nessun dato sensibile arrivi ai log, allora chiaramente questa funzione non viene eseguita, il che significa che il tester deve riportare quella funzionalità a In progress o qualunque cosa voi stiate facendo per tenere traccia dello sviluppo.

Lo stesso vale per tutto ciò che ha a che fare con il codice reale, ora non sto promuovendo una vista che i tester dovrebbero teach degli sviluppatori. Ma dovrebbero funzionare come una guardia che l'implementazione è all'altezza dei vostri standard. Qualsiasi sviluppatore che valga il suo / il suo sale dovrebbe prendere rapidamente a cuore se ogni volta che creano una nuova funzione viene rimandato perché non aderiscono correttamente ad alcune delle vostre regole.

Un'altra cosa che penso sia davvero importante è ciò che @Robert Harvey ha inserito nel campo dei commenti, la revisione del codice. Potrebbe essere qualsiasi cosa, dalla programmazione di coppia a qualcosa di più formale. Se un pezzo di codice ha toccato solo un paio di occhi, credo fermamente che qualcosa debba essere fatto. Una cosa così semplice come una descrizione di alto livello di ciò che il codice fa mentre mostra il codice reale mi ha fatto arrossire più volte perché ho trovato problemi o cose che ho perso diverse volte. E di solito sono solo stupidi errori.

Quindi per riassumere:

• Una responsabilità dei tester è controllare che gli sviluppatori rispettino le regole.
• Non permettere agli sviluppatori di comportarsi da lupo solitario, dovrebbe essere un'attività sociale (non sempre mi piace ma è vero).
• Avere una chiara definizione di fatto, e non lasciare che l'implementatore sia l'unico a dire che è fatto.

Penso che questa sia una domanda sulla cultura e non sugli strumenti.

Abbiamo usato un wiki in un lavoro precedente, e ha funzionato bene. Eventuali modifiche sono state rese pubbliche agli sviluppatori e i responsabili del team hanno discusso a intervalli regolari.

Sembra che sia nella tua lista, hai sia la migliore pratica di programmazione che le definizioni dei processi. Suggerirei innanzitutto di scrivere il processo con cui sviluppate il software. Quindi puoi aggiungere sotto-politiche riguardanti le migliori pratiche o le linee guida specifiche per la lingua. La politica principale dovrebbe fare riferimento ad essa e chiarire che gli sviluppatori dovrebbero seguire le linee guida sulla pratica dello stile a meno che non ci siano buone ragioni anche per non farlo.

Si noti che non sto sostenendo la scrittura di pagine e pagine di documenti, quanto basta per chiarire cosa si suppone debba fare un dev in un punto particolare di un progetto. Se non riesci a sintetizzarlo facilmente, suggerirei che il processo in sé è vago.