In test
No testers (dev tests their own code)
Spero davvero che tutti gli sviluppatori testino il loro codice prima di inviarlo da qualsiasi altra parte, ma avere tester dedicati è ottimo anche per una seconda serie di occhi. Potrebbe essere possibile per te ottenere questo secondo set di occhi senza tester dedicati, per esempio effettuando revisioni parziali di codice.
Per quanto riguarda i test automatici, considera quanto segue: Ci vorranno un sacco di tempo e sforzi concentrati per scrivere questi test. Molto probabilmente andranno bene, ma è un'impresa enorme che ti assorbirà quasi tutto il tuo tempo. C'è sicuramente una pentola d'oro alla fine dell'arcobaleno, ma dovresti davvero davvero limitare l'ambito di questi test a funzioni critiche e percorsi di esecuzione. Costruisci una suite di test nel tempo.
È molto probabile che la mancanza di test e test del codice sia un motivo per cui si verificano molte interruzioni, ma invece di avere l'obiettivo di testare tutto ciò che si è creato prima di provare a stabilire obiettivi migliori per il nuovo codice. Se crei una nuova funzione, crea test per questo. Se aggiorni una vecchia funzione e nessun test esiste: scrivili.
On Interruptions
Lots of interruptions along the sprints, to do another stuff wasn't planned
Anch'io ho lavorato in questo modo, ma cosa fare in realtà dipende dalle interruzioni. Non puoi davvero sfuggire a qualcuno di loro; mai sentito qualcuno dire "riavvieremo i server durante il prossimo sprint?"
Le interruzioni sono un effetto collaterale di molte cose e ci sono alcuni rimedi che potrebbero aiutarti ad alleviare il dolore. Prova a prendere provvedimenti per rilasciare:
- Codice stabile
- Codice senza bug
- Codice che realizza l'attività desiderata
Alcune delle cose menzionate in precedenza aiuteranno in questo. Una migliore verifica della stabilità del codice e l'assenza di bug dovrebbe tenere alcuni di questi problemi lontani dalla tua tabella.
Assicurarsi che le attività siano specificate correttamente prima che qualcuno inizi a programmare è incredibilmente utile e, a mio avviso, a volte non viene affatto eseguita dalle persone. Lavorando in una piccola azienda preferisco avvicinarmi alla persona che userà quello che programmerò e chiedere loro di parlarmi del loro problema. Questo potrebbe non essere praticabile per te e potrebbe essere completamente impossibile a seconda delle dimensioni dell'azienda e della cultura. Joel Spolsky ha un'interessante serie su specifiche di scrittura .
Inoltre, proprio come Ewan ha detto che Kanban può essere un ottimo strumento quando hai molti compiti in arrivo dalla linea laterale. Tieni semplicemente un backlog in ordine prioritario e ogni volta che arriva una nuova cosa importante viene messo in primo piano (o ovunque sia appropriato).
A volte devi anche educare le persone a introdurre nuovi requisiti su cosa significa un'interruzione. Se metti le persone in un esercizio in cui devono dare la priorità alle attività da svolgere, di solito dicono che tutto è prioritario e in qualche modo credere che ciò significhi che ogni cosa con priorità assoluta sarà fatta velocemente. Dopo tutto, nessuno mette lo sforzo in bassa priorità. Qui è importante insegnare alle persone che le interruzioni richiedono più tempo, vedere ancora una volta Joel Spolsky in Human Task Switch Considerated Harmful . Inoltre, fai in modo che le persone si chiedano veramente se chiedere a uno sviluppatore di cambiare quell'indaco in un colore magenta è davvero urgente come credono.
Una raccomandazione generale
Se il tuo processo attuale non funziona o non è abbastanza buono, non aver paura di cambiarlo. Tieni presente che se un determinato cambiamento non funziona puoi provare qualcos'altro o tornare a come sono state fatte le cose in precedenza. Non apportare modifiche enormi o modificare tutto allo stesso tempo, ma migliorare in modo incrementale il processo. Migliora il processo come se migliorassi il tuo codice.