Feature Teams

Il modello dei Feature Teams (FT) è veramente interessante: l’approccio verticale può dare grandissimi vantaggi eliminando molti problemi che normalmente si hanno utilizzando Component Team / Layer Team.
Se i vantaggi sono chiari resta ancora da capire quali sono gli aspetti negativi, soprattutto ad esempio per un’azienda orientata al prodotto. Per cercare di evidenziare i problemi cercando di ragionare ho individuato almeno tre aspetti critici che vanno approfonditi.


Come si relaziona FT rispetto al middleware

Il middleware dovrebbe essere ragionevolmente intoccabile, se il middleware è esterno la cosa è relativamente banale essendo un componente non ci sono problemi di sorta. Se il middleware è sviluppato internamente si potrebbe essere tentati dal coinvolgerlo nella feature, magari perché una piccola modifica allo stesso potrebbe portare grossi benefici alla feature in termini di design e effort ( a patto che non si carichi il middleware con aspetti funzionali nel qual caso sarebbe comunque un errore).
Probabilmente l’approccio più corretto è quello quindi di considerare il middleware un componente chiuso, inserendolo semplicemente nello Stack di progetto e convivendo con i suoi limiti. Ma a questo punto la domanda è come si fa a gestire il middleware con un feature team.

Come si relaziona il feature team rispetto al design del layer / componente

Ragionevolmente se FT tocca i vari componenti si crea un problema di coerenza a livello di design del layer/ componente. Il problema andrebbe forse contestualizzato maggiormente, ma giusto per fare un esempio, FT potrebbe voler implementare una nuova funzione in un layer, questa funzione potrebbe essere molto vicina ad una già presente ma non sufficientemente generalizzata, FT aggiunge nuovo codice senza conoscere le altre componenti e quindi potrebbe creare una duplicazione di codice inutile al posto di un refactoring che porterebbe maggiori benefici (meno codice, più generalizzato). Si può mitigare il problema definendo un owner del componente che possa sovrintendere la crescita del componente partecipando al FT. Ma mi pare un controsenso, in questo modo si aggiungerebbe uno strato orizzontale portando di fatto ad avere una matrice che difficilmente è produttiva.

Skill del FT

Il feature team deve ovviamente conoscere bene la funzionalità, questo è un bene, ma come fa a conoscere tutti i tool , gli ambienti di sviluppo, gli hack specifici che solo un component team può conoscere condividere e rinforzare. Ancora una volta la soluzione sembra essere quella di aggiungere una responsabilità orizzontale, tornando al problema di prima.



Senza dubbio il concetto dei Feature Teams è molto potente e tende a risolvere un’ampia gamma di problemi (soprattutto di integrazione, ma anche di minore overspecification). Bilanciando la resistenza al cambiamento e la sua forza nel cercare di fare fallire gli stessi rispetto ai benefici non sono ancora certo che si possa applicare facilmente con successo.

Prossime letture sull’argomento:
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum


Inspired by: http://www.infoq.com/articles/scaling-lean-agile-feature-teams