Non concentrarti sui tecnicismi.

• Dovremmo adottare i microservizi o un monolite?
• Ci conviene usare Kubernetes o OpenShift?
• Come server CI usiamo Jenkins?

Se sei un architetto software, o in generale una qualunque figura senior, queste sono le domande più sbagliate che puoi porti.

Le tecnologie che scegli sono irrilevanti se le persone che le usano le odiano, fanno fatica a usarle o se, ancora peggio, non permettono di raggiungere gli obiettivi aziendali e non riflettono le modalità operative che si vogliono ottenere.

Quallo che importa è abilitare i team di sviluppo a rilasciare senza dipendere da altri team, senza rituali di comunicazione dispensiosi in termini di tempo ed energie, senza dipendenze da una singola persona o pochi eletti e possibilmente senza causare momenti di down per i propri utenti.

Azioni

Ecco alcune domande di riflessione che puoi porti.

Il mio team, riesce a:

• Fare cambiamenti di design importanti al proprio prodotto/servizio senza dover ottenere il permesso da qualcuno FUORI del team?
• Implementare cambiamenti importanti senza creare rilavorazioni pesanti per altri team?
• Completare il proprio lavoro senza comunicare con altri team?
• Rilasciare il loro prodotto/servizio on-demand senza badare ai servizi da cui dipende?
• Eseguire la maggior parte dei test on-demand, senza un ambiente di test integrato?
• Rilasciare in produzione nelle normali ore d’ufficio con downtime compatibili col business?

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!