Se due team Scrum utilizzano lo stesso componente software, chi è responsabile di fornire una chiara visione architettonica di quel componente e mantenere / sviluppare questa visione con l'evoluzione della base di codice? In Scrum dovresti avere una proprietà di codice collettivo, quindi come assicurarti che lo sviluppo fatto dal Team A non interferisca con lo sviluppo fatto dal Team B?
Risposte:
Non sono un esperto di Scrum, ma la "proprietà del codice collettivo" di AFAIK è pensata per team e per prodotto (e penso che la tua domanda non sia specifica per Scrum, potrebbe essere applicata a qualsiasi processo di sviluppo del "codice condiviso").
Se hai due team A, B, due prodotti A, B e un componente condiviso C, ci sono diversi scenari possibili. Forse il componente condiviso appartiene principalmente al prodotto A (ed è appena riutilizzato, ma non evoluto, dal team per il prodotto B). In questa situazione il team A è chiaramente responsabile della visione architettonica. O viceversa: appartiene chiaramente al prodotto B - quindi la responsabilità è lì. Se la squadra A è responsabile, la squadra B potrebbe usare un fork del componente per consentire correzioni di bug urgenti (dovrebbe esserci anche un modo per reintegrarli nella linea principale di C), ma B dovrebbe evitare di fare una maggiore evoluzione del componente.
Tuttavia, se entrambi i prodotti A e B hanno molti "requisiti di guida" per C, è necessario gestire C come prodotto completamente separato, con proprio versioning, gestione delle versioni, gestione delle modifiche, unit test ecc. E un team separato che ha il responsabilità per quel componente. Quella squadra potrebbe essere solo una "squadra virtuale", composta da sviluppatori separati dalla squadra A, B o entrambi. Questo team ha la "proprietà del codice condiviso" per C e la responsabilità della "visione architettonica". Basti pensare a C essere un componente fornito da un fornitore di terze parti.
Non esiste un concetto di "chiara visione architettonica" in Scrum o agile!
Sono stato a lungo un architetto ed è chiaro per me che per avere una visione architettonica è necessario avere una visione chiara delle esigenze future. Poiché nella maggior parte dei casi i requisiti non sono affatto chiari, non ha senso avere una visione fissa.
Ciò che è necessario è avere un'architettura sufficientemente adattabile alle mutevoli esigenze. In altre parole, le cose cambiano e l'architettura cambia - non sto sostenendo un'architettura "soft" che può essere riconfigurata. Sto parlando di accettare che l'architettura che uno ha oggi sarà presto obsoleta e dovrà essere cambiata, quindi nessuno dovrebbe "sposarsi" con essa.
La proprietà del codice collettivo significa che tutti dovrebbero - in teoria - essere in grado di cambiare qualsiasi cosa. Questo deve essere inteso come "l'opposto dei silos". In altre parole, può esserci una barriera di competenze, che è normale e prevista - non tutti sono DBA esperti che possono mettere a punto query SQL, per fare un esempio - ma da ciò non segue che solo un DBA può la mano ottimizza le query. Ci sarà un "esperto del dominio delle funzionalità" che può aiutare altre persone a diventare competenti, ma i compiti dovrebbero comunque ricadere su tutti.
Ad esempio: se sono l'esperto di dominio sulla funzione "A", mi aspetto comunque che qualcun altro lavori sulla funzione "A", ma è probabile che venga consultato quando è necessario apportare cambiamenti importanti o se le persone hanno bisogno di aiuto. La caratteristica "A" non sarebbe certamente la mia caratteristica. Sarà una caratteristica che conosco bene. Sarà mio interesse conoscere molte altre funzionalità e l'interesse di altre persone a conoscere questa funzionalità.
In sintesi: l'architettura è progettata e riprogettata più volte dagli sviluppatori quando i requisiti emergono e cambiano. Tutti dovrebbero apportare le modifiche necessarie in base alle proprie capacità e sapere quando chiedere aiuto. Non esiste una visione a lungo termine sull'architettura perché abbiamo fiducia nelle persone e non ci fidiamo dei requisiti .
Ad esempio, Spotify utilizza un ruolo denominato "Proprietario di sistema" per risolvere il problema, direttamente dal documento:
Tecnicamente, chiunque è autorizzato a modificare qualsiasi sistema. Poiché le squadre sono effettivamente team di funzionalità, di solito devono aggiornare più sistemi per ottenere una nuova funzionalità in produzione. Il rischio con questo modello è che l'architettura di un sistema venga incasinata se nessuno si concentra sull'integrità del sistema nel suo insieme.
Per mitigare questo rischio, abbiamo un ruolo chiamato "Proprietario di sistema". Tutti i sistemi hanno un proprietario di sistema o una coppia di proprietari di sistema (incoraggiamo l'associazione). Per i sistemi operativi critici, il proprietario del sistema è una coppia Dev-Ops, ovvero una persona con una prospettiva di sviluppo e una persona con una prospettiva di operazioni.
Il proprietario del sistema è la persona "vai a" per qualsiasi problema tecnico o architettonico relativo a quel sistema. È un coordinatore e guida le persone che codificano in quel sistema per assicurarsi che non si inciampino l'uno sull'altro. Si concentra su aspetti quali qualità, documentazione, debito tecnico, stabilità, scalabilità e processo di rilascio.
Il proprietario del sistema non è un collo di bottiglia o un architetto di torre d'avorio. Non deve prendere personalmente tutte le decisioni, né scrivere tutto il codice, né fare tutte le versioni. In genere è un membro della squadra o un capo di capitolo che ha altre responsabilità quotidiane oltre alla proprietà del sistema. Tuttavia, di tanto in tanto prenderà una "giornata del proprietario del sistema" e farà il lavoro di pulizia su quel sistema. Normalmente cerchiamo di mantenere la proprietà di questo sistema a meno di un decimo del tempo di una persona, ma ovviamente varia molto da un sistema all'altro.
Mi piace molto questa idea, avere i vantaggi o le proprietà del codice collettivo a livello aziendale (non solo a livello di team) ma con i proprietari di questi sistemi che cercano di garantire una certa integrità architettonica.
Un link al documento completo: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , è un documento breve ma molto, molto interessante basato sull'esperienza reale sul ridimensionamento agile.
È un problema difficile da risolvere, e certamente non è risolto da Scrum, che è una metodologia di gestione del progetto, non una metodologia di sviluppo.
La soluzione più efficace che ho trovato è una buona gestione dei pacchetti (nuget / gem / etc) e il controllo delle versioni. Non applicare mai un cambiamento a un'altra squadra finché non sono pronti a consumarlo. Lascia che continuino a usare la vecchia build, mentre passi alla nuova.
Assicurati di avere una strategia di controllo delle versioni che chiarisca quali modifiche si stanno rompendo e quali estensioni.
Inoltre, quando apporti una modifica, invia una revisione del codice a qualcuno IN OGNI TEAM. Lascia che guardino come è probabile che li influenzino, molto prima che siano costretti a consumarlo in modo da poter implementare le proprie modifiche in cima.
E quando le cose si fanno davvero confuse; quando una squadra ha bisogno di apportare una modifica e non può consumare un'altra modifica facilmente (questo DOVREBBE essere un caso davvero raro), dirama il codice, rendilo un pacchetto completamente diverso, ma rendilo prioritario tornare al codice comune non appena permette.
La risposta che non è sempre così ovvia come potrebbe essere è quella di consentire ai team di decidere come condividere un determinato componente.
Ad esempio, il mio team ha recentemente iniziato a sviluppare una nuova linea di prodotti che condivide molto codice in comune con altri due team che hanno sviluppato prodotti simili per lungo tempo. Il nostro prodotto è diverso in alcuni modi, quindi occasionalmente dobbiamo capire come aggiungere punti di personalizzazione al codice comune.
Abbiamo avuto alcuni scontri su quel codice e provato diversi modi ad hoc per gestire la proprietà comune. Quindi, con una nuova grande funzionalità in arrivo, abbiamo deciso che dovevamo riunire tutti i team sulla stessa pagina, risultando in un gruppo più piccolo composto da un paio di membri di ciascun team che stanno elaborando i dettagli.
La soluzione proposta dai nostri team potrebbe non funzionare in un'altra situazione. Potresti aver bisogno di qualcosa di più semplice o di molto più formale. Il punto è che prendi la proprietà collettiva e capisci cosa funziona per te.
Mi prenderò la libertà di assumere:
Se i presupposti di cui sopra sono corretti, allora ci dovrebbero essere solo occasionalmente momenti in cui due squadre interferirebbero tra loro. Possono risolverlo usando i seguenti modi: