Non far entrare più lavoro di quanto il reparto regge
I limiti WIP entrano nei flussi di FlowSharp. Configurarli mette in evidenza un problema: un limite incerto non può diventare silenziosamente illimitato.
Un processo può funzionare secondo tutte le sue regole e lasciare comunque un reparto sommerso di lavoro.
Se continuiamo ad aprire pratiche mentre quelle in corso aspettano nella stessa fase, il fatto che il motore non segnali errori dice poco. La coda cresce, le priorità diventano confuse e qualcuno deve ricominciare a scegliere tutto a mano.
Questa settimana ho portato dentro FlowSharp i limiti WIP, il limite al lavoro contemporaneamente in corso.
Sapere quando non aprire un’altra pratica
Il limite può riguardare un flusso o una fase. Al raggiungimento della capacità prevista, il processo deve seguire il comportamento configurato, comprese eventuali deviazioni per il sovraccarico.
Non vorrei che venisse usato per assegnare un numero comodo e smettere di osservare il reparto. La capacità reale cambia, e un limite va discusso. Almeno, però, possiamo rendere visibile una decisione che altrimenti resta implicita: quanto lavoro vogliamo tenere aperto insieme?
Ho aggiunto anche variabili globali e di flusso, oltre al lavoro sulla libreria dei modelli. Sono strumenti per evitare di riscrivere le stesse scelte in molti punti, con il rischio di dimenticarne uno quando cambiano.
L’errore che non deve aprire tutte le porte
Durante le verifiche è emerso un comportamento sbagliato: una configurazione non valida del limite poteva essere interpretata come assenza di limite.
È esattamente il contrario di quello che volevo ottenere. Avevo chiesto al sistema di fermarsi davanti a una soglia e, nel caso incerto, lo lasciavo proseguire.
Ho cambiato il criterio: se il limite non può essere determinato correttamente, il problema deve emergere e il controllo non va aggirato. È il principio fail-closed, ma mi interessa soprattutto la conseguenza pratica: non fingere che una regola sia stata applicata quando non sappiamo se lo è stata.
Anche il Flow Agent ha ricevuto la schermatura dei dati. Le protezioni devono seguire tutti i percorsi attraverso cui una funzione può essere usata.
Un freno utile
Duecentottantatré commit e ventitré rilasci. Una settimana molto attiva dedicata, in parte, a impedire al sistema di fare troppo.
Mi sembra una buona contraddizione da tenere a mente. L’automazione serve anche a rendere sostenibile il lavoro che c’è già, non soltanto ad aprirne altro più velocemente.