No, non è un titolo per un post per scuola guida! 😝

Ritorno per l’ultimo episodio sul tema della legge di Conway.

Risposte alla legge di Conway

Abbiamo visto, fino ad ora, due approcci a cui ne aggiungiamo un terzo e ultimo.

1. Ignora: non sai che esiste o fai finta che non esista o che nel tuo contesto non si applichi.
2. Accetta: sai che c’è e riconosci il suo impatto. Verifica l’attuale organigramma rispetto alle tue architetture software.
3. Manovra inversa: (ri)struttura l’organigramma aziendale di chi progetta i software per incentivare il design architetturale voluto.

Manovra inversa

C’è un ulteriore approccio che si sta diffondendo come risposta alla legge di Conway che consiste nello (ri)strutturare intenzionalmente l’organigramma aziendale dei dipartimenti di sviluppo per incentivare l’architettura software desiderata.

Questo approccio si chiama la Manovra Conway Inversa.

Questa tecnica è spesso citata nel contesto dei microservizi, dove si promuove la creazione di team piccoli, stabili e focalizzati sugli obiettivi di business, dotati di tutte le competenze necessarie per rilasciare valore al cliente finale.

I microservizi sono una soluzione tecnica a problema organizzativo. – Michelismo

La cosa fondamentale da ricordare sulla legge di Conway è questa: la suddivisione del sistema in moduli e l’organizzazione del team di sviluppo vanno progettate insieme.

E non vale solo all’inizio.

L’evoluzione dell’architettura e la riorganizzazione delle persone devono andare di pari passo per tutta la vita dell’azienda.

Azioni

Quali sono perciò le topologie di team che abbiamo a disposizione per progettare i nostri dipartimenti di sviluppo ed influenzare le decisioni architetturali?

Beh, ne parlimo nel prossimo episodio!

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!