Lavorando su un modello informativo, nel senso più ampio del termine, gli strumenti e le piattaforme di produzione e coordinamento ci impongono una serie di vincoli e, come direbbe Morpheus, alcuni di questi vincoli possono essere sfruttati a nostro vantaggio mentre altri possono essere infranti.
Eliyahu Goldratt, nel suo Beyond the Goal, individua cinque passi per la gestione di questi vincoli:
- Identificare i vincoli del sistema (es: nella gerarchia informativa del modello, una certa categoria di oggetti presenta una condizione di hosting rispetto ad un’altra categoria);
- Decidere come sfruttare i vincoli del sistema: come mai il sistema presenta questi vincoli? I vincoli ad esempio allineati ai processi progettuali o costruttivi? Questi vincoli ci aiutano a essere maggiormente precisi / accurati / coordinati?
- Subordinare qualunque decisione alle considerazioni emerse dal punto precedente;
- Elevare i vincoli del sistema a vincoli di processo;
- Se si decide di infrangere il vincolo, tornare al punto 1 senza lasciare che sia l’inerzia a provocare un vincolo nel sistema.
Nel nostro caso, si tratta di impedire che vincoli apparenti (il software normalmente funziona così) si trasformino in vincoli di processo (non si può fare).
I vincoli tipici individuati da Gene Kim nei suoi principi di DevOps, che ci stanno accompagnando da qualche mercoledì a questa parte, sono quattro:
- Vincoli nella creazione dell’ambiente di sviluppo: gli ambienti di produzione o di test devono essere autonomi, in modo da essere a libera disposizione di chiunque in qualunque momento ne abbia bisogno;
nel nostro caso: chiunque deve avere a disposizione modelli di esempio, script di test, e bisogna creare nel team la cultura di testare nuove componenti in un ambiente neutro, prima di mandarle in produzione. - Vincoli nel rilascio: le consegne devono essere il più possibile automatiche;
nel nostro caso: è necessario evitare a tutti i costi situazioni in cui, prima della consegna e della condivisione, viene richiesto di effettuare operazioni manuali e ridondanti come l’eliminazione di oggetti segnaposto. - Vincoli nelle fasi di test: le procedure di test dovrebbero essere automatizzate il più possibile in modo da garantire rilasci in sicurezza e facendo sì che le operazioni di test non rimangano indietro rispetto alle operazioni di sviluppo;
nel nostro caso: le eventuali procedure di controllo del modello dovrebbero essere automatizzate il più possibile, senza rimanere subordinati ad eventuali enti terzi incaricati di questo controllo. - Vincoli in architetture di sistema troppo restrittive: l’architettura dovrebbe essere flessibile in modo da consentire ai responsabili dei diversi moduli di effettuare modifiche in sicurezza e autonomia.
nel nostro caso: discipline diverse hanno esigenze diverse (ad esempio nel breakdown dei modelli o nella strategia di gestione degli oggetti ospitanti) ed è necessario costruire standard che consentano a ciascuno di lavorare in modo ottimale.
No Comments