Requisiti degli architetti esterni al team Scrum

Qualche tempo fa mi è stato chiesto cosa pensassi dell'affidare ai "Saggi Architetti" di un'azienda la supervisione tecnica dei vari team di progetto. Spesso sento l'argomento che questi architetti non fanno parte del team e quindi non dovrebbero decidere come il team sviluppa qualcosa...

...questo però non è un argomento particolarmente valido, perché ci sono abbastanza altre persone esterne che pongono requisiti a un team. Questi requisiti vengono tuttavia sempre filtrati dal Product Owner – è lui a decidere se sono importanti o meno.

I "Saggi Architetti" non fanno proposte di soluzione

Un "Saggio Architetto" fornisce spesso al team requisiti non funzionali, che io considero più come vincoli o condizioni. Non può quindi prescrivere al team come risolvere un problema. Può però stabilire determinati vincoli, ad esempio "Il sistema deve essere scalabile per un certo numero di utenti concorrenti", "deve elaborare X transazioni al minuto", "deve funzionare su Linux", "deve integrarsi con questo e quello" ecc.

I requisiti non funzionali diventano Product Backlog Item e possono essere prioritizzati dal Product Owner, a seconda di quanto li ritenga importanti. Se ad esempio non ritiene fondamentale che il sistema funzioni su Linux e potrebbe altrettanto bene funzionare su un altro sistema operativo, il Product Owner può rimuovere questo requisito o spostarlo in basso nel Product Backlog (in modo che il team possa comunque vedere che l'architetto lo desidera).

Questo testo proviene dal blog di Mike Cohn ed è stato tradotto.