Nel precedente post abbiamo risposto affermativamente alla domanda:
“Ha senso parlare di Architetture Agili?”
La risposta è scaturita sostituendo il concetto classico di Architettura con quello di Intentional Architecture e descrivendo i relativi obiettivi: Semplificazione, Minimalità, Modularità ed Estendibilità.
Facciamo ora un passo indietro e guardiamo con attenzione il mondo Agile a partire dal suo manifesto (http://agilemanifesto.org/) composto da 4 valori e 12 principi. Da una sua lettura parsimoniosa ci si rende conto che l’approccio Agile è pensato ed incentrato sul lavoro del Team che sviluppa il software, unico detentore del know-how relativo e responsabile delle scelte di sviluppo e di design. Prima di procedere vorrei di nuovo sottolineare che il Design di un Software appartiene ad un livello di astrazione inferiore rispetto all’Architettura e che la terminologia “Design Architetturale” fonde tra loro fasi progettuali differenti.
Tornando al manifesto Agile possiamo quindi evidenziare che l’approccio è pensato per team medio-piccoli e presenta dei “lati oscuri” per quanto riguarda la sua applicazione nel mondo Enterprise. Infatti è impensabile imbarcarsi nella realizzazione di un nuovo Sistema IT senza aver fatto una serie di valutazioni preventive, tra cui: Costi/Benefici, Opportunità di Business, Rischi annessi al fallimento del progetto, ecc. Per affrontare tali interrogativi è necessario realizzare alcune ipotesi in merito al Sistema che si sta approcciando, realizzando un planning (costi, economici e temporali) e proponendo una prima Architettura (Intentional, appunto).
Per l’ambito Enterprise, Dean Leffingwell propone 7 principi Agili da applicare sia allo sviluppo che alla sua Architetture/Design:
- Principle #1 The teams that code the system design the system;
- Principle #2 Build the simplest architecture that can possibly work;
- Principle #3 When in doubt, code it out;
- Principle #4 They build it, they test it;
- Principle #5 The bigger the system, the longer the runway;
- Principle #6 System architecture is a role collaboration;
- Principle #7 There is no monopoly on innovation.
In realtà Leffingwell parte dall’assunto, che qui e nel precedente post abbiamo completamente smontato, che il Design e l’Architettura siano la stessa cosa. Quindi il Principio #1, che prevede che sia il team di sviluppo a determinare l’Architettura del Sistema, va assolutamente corretto così come il principio #4, che afferma che il test sia fatto esclusivamente dal team di sviluppo, appare decisamente limitativo. Infatti il team di dev è sicuramente responsabile del test di unità (Unit Test) ma è comunque necessario prevedere un gruppo di testing per tutti quelli che sono i test che vanno al di la delle attività inerenti il singolo team e che verifichino gli SLA (Service Level Agreement) qualitativi.
In modo trasversale, inoltre, Leffingwell propone che la figura del Software Architect sia di supporto al Team di sviluppo, il quale può attingere dalla sua esperienza spunti e consigli su questioni di particolare rilievo e difficoltà.
Una strutturazione delle responsabilità di un Agile Enterprise Team può essere assimilabile a quanto proposto nella tabella seguente:
| AREA | Classic | Agile |
| Business |
|
|
| Project Management |
|
|
| Team |
|
|
Tabella 1: Responsabilità Agile Enterprise Team
Come si può vedere esiste comunque una fase di Project Management nel mondo Agile, ma questa viene affiancata da una continua fase di review durante il processo di sviluppo.
Tali considerazioni, ci portano a ridefinire i principi succitati, creando quelli che definiremo “Enterprise Agile Principles”:
- Principle #1: The Intentional Architecture are created by the Agile Software Architect;
- Principle #2 Build the simplest Architecture that can possibly work;
- Principle #3: The Teams that code the system Design the system;
- Principle #4 When in doubt, code it out;
- Principle #5 They build it, they test their own work;
- Principle #6 The bigger the system, the longer the runway;
- Principle #7 System architecture is a role collaboration;
- Principle #8 There is no monopoly on innovation.
Vediamo ora di descrivere tali principi.
Principle #1: The Intentional Architecture are created by the Software Architect
L’Agile Software Architect ha un ruolo di “guida”, poiché realizza l’Intentional Architecture effettuando scelte mirate soprattutto a garantire la qualità del progetto, nel rispetto dei vincoli di business concordati con il Product Owner e gli Stakeholder.
L’Intentional Architecture dovrebbe essere sempre realizzata con in mente la seguente affermazione:
“What is the simplest thing that can possibly work?” [attribuita a Ward Cunningham]
Principle #2: Build the simplest architecture that can possibly work
L’Agile Software Architect, coadiuvato dal Team, deve sempre sforzarsi di trovare l’architettura più semplice, in modo da favorirne il refactoring e l’estendibilità.
Principle #3: The Teams that code the system Design the system
Il Design spetta al Team, tenendo ben presente la netta differenza tra Architettura e Design. Questo fa si che il Team sia responsabile di gran parte delle scelte che caratterizzano il software (dai Pattern, ai Framework, ecc.) e contribuisca a migliorarne la relativa architettura nelle specifiche fasi di review con l’Agile Software Architect.
Principle #4 When in doubt, code it out
Quando si è di fronte a dei dubbi (Architetturali, di Design, di Implementazione e persino di Business) è consigliabile realizzare la funzionalità incriminata, anche in modo dirty&fast, e poi verificarla sul campo, in modo che tutti gli stakeholder possano dare la propria opinione.
Principle #5 They build it, they test their own work
Il Team che sviluppa il Sistema ha anche il compito di testarlo. Da tale attività, però, vanno esclusi i test estesi come: raggiungimento degli SLA, verifica nell’insieme delle Funzionalità, test di integrazione con sistemi terzi, che comunque devono essere effettuati da un team dedicato e non coinvolto nello sviluppo.
Principle #6 Intentional Architecture is the rails of long projects
Quanto più il Sistema è complesso, tanto più è necessario adottare un Planning Agile che preveda una review costante dei tempi e dei costi relativi, adattandosi ai ritmi del Team ed alle sue esigenze. In tal modo è possibile aggiornare continuamente le aspettative degli stakeholder evitando di arrivare alla data di rilascio prevista e accorgersi di essere assolutamente fuori tempo. In tale scenario l’Intentional Architecture assume un ruolo decisivo perché funge da guida all’evoluzione del Sistema, un po’ come le rotaie guidano il percorso del treno.
Principle #7 Agile Software Architect is a role collaboration
Un Agile Software Architect è una figura con un ruolo estremamente collaborativo, in grado di interagire apertamente con il Team e le altre figure annesse al progetto, al fine di garantire la qualità e il successo del Sistema stesso.
Principle #8 There is no monopoly on innovation
Un progetto Agile di per se prevede lo sharing del know-how e dell’innovazione che da esso ne deriva. Ciò, nel caso di progetti Enterprise, interessa anche la figura dell’Agile Software Architect, che nei processi di sviluppo standard è tipicamente visto come un “estraneo” rispetto agli altri membri del Team.
Nel processo di sviluppo (così come consigliato da Mike Cohn e dallo stesso Dean Leffingwell) è sempre utile trovare un periodo per l’apprendimento, la condivisione e la ricerca di nuove soluzioni, innovative o meno. In particolare Cohn parla della tecnica 6x2+1, ovvero 6 iterazioni (sprint) di 2 settimane intervallate da una settimana (hackathon o spike) dedicata alla sperimentazione di nuove soluzioni. Tale settimana può essere, come indicato in figura 1, costruttivamente interposta tra la Release Candidate del Sistema e la sua data di rilascio ufficiale.
Figura 1 - Release Planning - Rally Software Development
Conclusioni
Le Architetture Agile (Intentional) sono fondamentali nello sviluppo di sistemi Enterprise, sia per garantire la loro qualità che per fornire una “linea guida” per lo sviluppo stesso. Altrettanto fondamentale è l’Agile Software Architect che riveste un ruolo da mentore nella scelta di soluzioni qualitative e tecnologie di alto livello volte a migliorare sia il Sistema in se che il lavoro ed il know-how del team.
Riferimenti bibliografici:
- Scaling Software Agility, Dean Leffingwell
- Agile Estimating and Planning, Mike Cohn
