Come i Microservizi favoriscono il lavoro dei Feature Teams

Contesto

Lo scenario tipico vede due attori: il cliente e il team di sviluppo.
Durante lo sviluppo di un prodotto, il cliente richiede una modifica, una nuova funzionalità. Il team però è già sommerso di lavoro e quindi il cliente attende, con time to market rallentato, stress per il team che poi porta a lavorare di fretta e con bassa qualità.

Questa situazione genera caos e il sistema va fuori dal nostro controllo.

Un semplice caso d’uso

Per capire meglio la situazione, Giulio fa un esempio.
Abbiamo un Product Owner (PO), responsabile delle feature, e il nostro prodotto, un’applicazione di e-commerce con tre feature:

• A: catalogo prodotto;
• B: acquisto prodotti;
• C: review dei prodotti.

Siamo nel campo dell’e-commerce, tipicamente il prodotto sarà composta da un’app mobile, un sito e un insieme di servizi lato back-end da sviluppare.

Avremo quindi due team, uno front-end e l’altro back-end, che partono insieme a sviluppare la prima feature, e cioè il catalogo.

Il PO deve tradurre le feature in modo tale che i due team disponibili, uno per il frontend e l’altro per il backend, le possano sviluppare e rilasciare.

Lo sviluppo inizia con la feature A, e i due team partono sincronizzati. Ad un certo qualcuno lato frontend ha un problema e chiede supporto al team del backend che però chiede di aspettare perché non ha subito la soluzione pronta. Il team del frontend non rimane con le mani in mane e decide di passare allo sviluppo della feature B. Passano dei giorni e il team del backend comunica di avere una soluzione per il problema…inizia ad ad emergere del disallineamento fino a che entrambi i team torneranno sulla stessa feature A.

Stop Starting, Start Finishing

L’organizzazione dell’esempio è efficiente. Entrambi i team sono esperti, hanno competenze specifiche per il frontend o per il backend. Ma non basta, manca l’efficacia.

Come è possibile evitare questo ping-pong di richieste e conseguenti attese? E’ possibile evitare questi balletti?

E’ perlopiù una questione culturale: è inutile aprire n task in parallelo, concentriamoci e risolviamo una cosa dopodiché prendiamone in carico un’altra. In quattro parole  Stop Starting, Start Finishing (2).

Tornando all’esempio il team frontend, in attesa di risposte dal team backend, aspetta e magari fa altro ma non inizia un’altra feature. E’ meglio concentrarsi su attività di contorno del progetto ad esempio migliorando la qualità del codice e le performance dei test, facendo code review e distribuendo conoscenza. Attività  che possono essere facilmente interrotte quando il team di back-end sarà pronto a lavorare al problema emerso.
L’essere fermi ha un costo, che si tratti di un team che sviluppa software o di un’autoambulanza o un’autopompa. Quando sono ferme, queste macchine e tutto il personale è comunque pagato.

Da team a Feature Teams

Torniamo al nostro PO e ai nostri team di back-end e fron-tend, ma ribaltiamo l’organizzazione: non più dei team che lavorano parallelamente su back-end e front-end, ma team che lavorano su singole feature in modo verticale, unendo competenze di back-end e front-end e operando end-to-end su tutto il ciclo di vita di una feature.

Ovvero, Feature Team.

Cercando di dare una definizione, il Feature Team è un team cross funzionale con competenze che attraversano tutto lo stack tecnologico: dalla UX/UI allo sviluppo front-end e back-end, progettazione e mantenimento API, conoscenza delle logiche di business, test, deploy, operations. In pratica un team che sa gestire in autonomia le sue feature con uno sguardo diretto verso l’utente finale che le utilizzerà.

Non è semplice organizzarsi in questa maniera, anche perché vorrebbe dire avere tutte le competenze a bordo e si sa, le competenze e l’esperienza si acquisiscono con il tempo. Ma è altrettanto vero che così facendo si può lavorare seguendo il principio della stop starting, start finishing.

C’è il rischio che, per mancanza di know-how, i Feature Teams si trasformino in Component Teams. Come scritto prima, sappiamo quanto sia difficile essere dei veri e propri full-stack developer, ciò che è importante è che ci sia una specializzazione ma con diverse competenze che permettono di muoversi agevolmente all’interno di un determinato contesto. Si tratta del modello T-shape: verticalizzazione su una competenza ma capacità di muoversi orizzontalmente su tutte le altre.

Se mancano know-how e skills il team non riesce ad essere autonomo e finisce per organizzarsi in componenti più che in feature.

Legge di Conway

Ancora una volta, è una questione culturale, come fece notare per la prima volta Melvin E. Conway nel lontano 1967 (3)

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

La struttura aziendale trasferisce inconsapevolmente la propria struttura nel prodotto. E, cosa molto probabile, se l’azienda fosse organizzata in silos (4), il prodotto sarò costituito da componenti organizzati in silos.

Torniamo quindi al nostro e-commerce, con una serie di feature da implementare.

Se prendiamo queste feature e le dividiamo tra i nostri team, ognuno di loro avrà una propria responsabilità sull’insieme di feature.

Vediamo così come, partendo da un dominio di business, costruiamo architetture IT che rispecchiano l’organizzazione e quindi come lo stile architetturale a microservizi possa favorire il lavoro dei feature team.

Quanto poi alla dimensione di un microservizio, alla sua granularità e come deve comunicare, sta alla specifica della realtà nel quale viene calato.

Feature Teams e il pattern Backend for frontend

Tornando all’esempio dell’e-commerce con le feature da implementare, possiamo pensare di accorparle in due microservizi che non saranno troppo granulari. Rispetto ai monoliti saranno più complessi da realizzare ma saranno sicuramente più adatti per possibili evoluzioni.

Una volta fatta la divisione in due microservizi, si può pensare per ciascuno l’esposizione su app Android e iOS e web.

I nostri due team ora sono Feature Team, ognuno con responsabilità e competenze specifiche, ma sicuramente avranno momenti di intersezione e richiesta di competenze dell’altro team.

In nostro aiuto viene il pattern Backend For Frontend (BFF) (5). Concettualmente, si dovrebbe pensare all’applicazione rivolta all’utente come a due componenti: un’applicazione lato client che vive al di fuori del perimetro e un componente lato server (il BFF) all’interno del perimetro. Il BFF è strettamente associato a un’esperienza utente specifica e in genere verrà gestito dallo stesso team dell’interfaccia utente, rendendo così più semplice definire e adattare l’API come richiesto dalla UI, semplificando al contempo il processo di allineamento del rilascio di entrambi i componenti client e server.

Feature Teams e Feature Toggles

Ipotizziamo di avere sprint di una settimana e che per ogni sprint rilasciamo qualcosa in produzione.
La prima settimana i nostri tre team al lavoro sviluppano delle feature, senza però completarle tutte interamente per la fine dello sprint.
Cosa si fa? Si rilasciano tutte, anche quelle non completate? Farlo potrebbe creare poca affidabilità del sistema e avere ricadute negative sul nostro lavoro.

Si potrebbe adottare la tecnica del Feature Toggles (6), o Feature Flag. In questa maniera si può nascondere, abilitare o disabilitare la funzione X a runtime o attivarla solo per un certo ambiente ad esempio quello di test.
Nel frattempo il team continua a lavorare e accende i toggle quando deve rilasciare.

In questo modo, con un ritmo sostenibile e ricorrente, si rilascia in produzione senza che i team debbano essere sincronizzati per i rilasci delle feature. Ricordiamoci che una feature è un insieme di user story quindi se in uno sprint si completano storie che non generano valore tangibile per il cliente, la feature non viene rilasciata.

Come gestire le dipendenze tra i microservizi?

Dall’esempio iniziale di un semplice e-commerce siamo arrivati ad un progetto più complesso gestito con un’architettura a microservizi e Feature Teams. Microservizi che possono avere delle dipendenze.

Come gestirle?

Prendendo spunto dal mondo dell’open source, potremmo pensare a dei team maintainer di un certo servizio. Qualora il mantainer non potesse svolgere il suo compito, un altro team può sviluppare la miglioria richiesta, ad esempio fare una pull request e attendere che venga approvata.

Cosa notiamo?

I team non rimangono fermi, e si evita che si creino i tanto temuti silos perché appunto il codice non rimane di proprietà esclusiva di qualcuno ma è modificato da tutti.

Come far emergere una organizzazione di questo tipo?

In primis dalle persone, tiene a precisare Giulio, che comunque risponde alla domanda con quattro punti:

• Visione chiara dei ruoli: PO, team e responsabilità, anche all’interno di ogni team. Un prodotto, un obiettivo, un backlog.
• Condivisione della conoscenza: ciò che produciamo sono righe di codice, facciamo sì che sia proprietà di tutti! Collective code ownership (7), in più mob programming assieme su tutto il codice, code review. e automatizzare gli standard per la documentazione.
• Condivisione a livello globale, ad esempio organizzando momenti come l’unconference (8) che aiutano a migliorare soft skill come l’abilità oratoria . Questo poi aiuta anche in fase di code review, perché spiegheremmo meglio il codice.
• Organizzare momenti formativi come sessioni di Kata. Aiuta a migliorare le proprie hard skill.

Conclusioni

Prima di salutarci, Giulio riassume quelli che secondo lui sono i concetti chiave:

• I Feature Teams accelerano il business: si riducono i tempi di attesa e si eliminano il caos organizzativo.
• I microservizi non sono un pattern ma uno stile architetturale.
• Il codice è di tutti
• NON ESISTE UN COPY-PASTE DI UN’ORGANIZZAZIONE. Il cambiamento va fatto emergere dal basso, da noi.

Qualora voleste rivedere l’intervento di Giulio, è disponibile la registrazione (9) nella pagina Facebook del gruppo FEVR.

Riferimenti

1. FEVR -Frontenders Verona – Gruppo Facebook
2. Libro “Stop Starting, Start Finishing!” – Amazon
3. Legge di Conway – Wikipedia
4. Silos – Agile Anti Patterns
5. Backend For Frontend pattern – Sam Newman
6. Feature Toggles – Martin Fowler
7. Collective code ownership – Agile Alliance
8. Unconference – play14
9. Registrazione della diretta streaming su Facebook dell’intervento