Dopo avere letto un po di materiale su Kamban, sulla Teory of Constraint e sul Lean in generale mi convinco sempre di più che probabilmente è il modo corretto di lavorare. La limitazione del Work In Process infatti è probabilmente la procedura di controllo migliore che possiamo fare durante lo sviluppo software, perchè troppo spesso lavorare su mille cose in parallelo è fonte di bassissima qualità.
Il problema è che lavorare sempre in condizioni di “mancanza di tempo”, produce solitamente confusione ed un cattivo uso del poco tempo a disposizione, che essendo già poco dovrebbe essere invece usato nel migliore modo possibile. Purtroppo sembra che questo modo di procedere si sia oramai sedimentato e preso come assunto, per cui è oramai normale pensare di lavorare sempre in condizioni di scheduling assurdi ed agire di conseguenza.
Il sintomo di questo è arrivare a ridosso delle date di scadenza con “quasi tutto fatto”, ma senza avere bene specificato cosa significa “fatto”. Quello che accade è quindi deploy stile “bagno di sangue”, problemi di manutenzione e via dicendo, perchè in realtà fatto viene spesso tradotto con “lo sviluppatore ha scritto il codice e se va bene qualcuno ha fatto un giro nel software per verificare che non esploda”.
Sono quindi convinto che adottare dei processi iterativi, con limitazione stile Drum-Buffer-Rope, possa risolvere molti dei problemi, soprattutto perchè in questo caso nessuno nel team può produrre codice di bassa qualità con la scusa di “non avere tempo” o “scheduling impossibili”, dato che il quantitativo di Work In Process è limitato.
L’obiezione classica è che non si può dire al cliente che non faremo tutto, o che alla data di scadenza avremo solamente quello che siamo riusciti a fare, ma in realtà limitare il work in process non significa far lavorare il team più lentamente, significa razionalizzare il processo, affrontare i problemi un poco per volta e soprattutto piano piano “capire” quanto veloce può andare il team e magari fare pianificazioni future più aderenti alla realtà. Se il nostro team è in grado di realizzare diciamo 4 user stories ogni due settimane, non potrà mai implementarne 50 in due mesi, indipendentemente dal processo utilizzato, e dalle ore di overtime imposte al team.
Gian Maria.