Se due team di Scrum usano lo stesso componente software, chi è responsabile di fornire una chiara visione architettonica di quel componente e mantenere / sviluppare questa visione man mano che la base di codice si evolve? In Scrum si suppone di avere una proprietà collettiva del codice, quindi come assicurarsi che lo sviluppo fatto dalla squadra A non interferisca con lo sviluppo fatto dalla squadra B?
Non sono un esperto di Scrum, ma la "proprietà collettiva del codice" di AFAIK è intesa come per team e per prodotto (e penso che la tua domanda non sia specifica per Scrum, potrebbe essere applicato a qualsiasi processo di sviluppo di "codice condiviso".
Se hai due squadre A, B, due prodotti A, B e un componente condiviso C, ci sono diversi possibili scenari. Forse il componente condiviso appartiene principalmente al prodotto A (ed è appena riutilizzato, ma non evoluto, dal team per il prodotto B). In questa situazione, la squadra 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 errori urgenti (dovrebbe esserci anche un modo per reintegrarli nella linea principale di C), ma B dovrebbe evitare di fare evoluzioni maggiori del componente.
Tuttavia, se entrambi i prodotti A e B hanno molti "requisiti di guida" per C, dovresti gestire C come un prodotto completamente separato, con il proprio controllo delle versioni, la gestione dei rilasci, la gestione delle modifiche, i test unitari e un team separato che ha la responsabilità di quel componente. Quella squadra potrebbe essere solo una "squadra virtuale", composta da sviluppatori separati della squadra A, B o entrambi. Questo team ha la "proprietà condivisa del codice" per C e la responsabilità per la "visione architettonica". Basti pensare a C di un componente fornito da un fornitore di terze parti.
Non esiste un concetto di "visione architettonica chiara" in Scrum o agile!
Sono da tempo un architetto e per me è chiaro che per avere una visione architettonica è necessario avere una visione chiara delle esigenze future. Poiché nella maggior parte dei casi i requisiti non sono chiari, non ha senso avere una visione fissa.
Ciò che è necessario è avere un'architettura che sia abbastanza 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 dell'accettazione che l'architettura che 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 del silos". In altre parole, può esserci una barriera di competenze, che è normale e attesa - non tutti sono un DBA esperto che può mettere a punto le query SQL, per fare un esempio - ma da ciò non deriva che solo un DBA può mano ottimizzare le query. Ci sarà un "esperto di dominio delle funzionalità" che può aiutare altre persone a diventare abili, ma i compiti dovrebbero ancora cadere su tutti.
Ad esempio: se sono l'esperto di dominio sulla funzione "A", quindi mi aspetto ancora che qualcun altro lavori sulla funzione "A", ma sono probabile che venga consultato quando devono verificarsi importanti cambiamenti 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 delle altre persone a conoscere questa funzionalità.
In sintesi: l'architettura è progettata e riprogettata più volte dagli sviluppatori man mano che i requisiti emergono e cambiano. Tutti si aspettano di apportare le modifiche necessarie in base alle loro capacità e sapere quando chiedere aiuto. Non c'è una visione a lungo termine sull'architettura perché ci fidiamo delle persone e non ci fidiamo dei requisiti .
Ad esempio, spotify utilizza un ruolo chiamato "Proprietario del sistema" per risolvere il problema, direttamente dal documento:
Technically, anyone is allowed to edit any system. Since the squads are effectively feature teams, they normally need to update multiple systems to get a new feature into production. The risk with this model is that the architecture of a system gets messed up if nobody focuses on the integrity of the system as a whole.
To mitigate this risk, we have a role called “System Owner”. All systems have a system owner, or a pair of system owners (we encourage pairing). For operationally critical systems, the System Owner is a Dev-Ops pair – that is, one person with a developer perspective and one person with an operations perspective.
The system owner is the “go to” person(s) for any technical or architectural issues related to that system. He is a coordinator and guides people who code in that system to ensure that they don’t stumble over each other. He focuses on things like quality, documentation, technical debt, stability, scalability, and release process.
The System Owner is not a bottleneck or ivory tower architect. He does not personally have to make all decisions, or write all code, or do all releases. He is typically a squad member or chapter lead who has other day-to-day responsibilities in addition to the system ownership. However, from time to time he will take a “system owner day” and do housekeeping work on that system. Normally we try to keep this system ownership to less than a tenth of a person’s time, but it varies a lot between systems of course.
Mi piace molto questa idea, con i vantaggi o le proprietà collettive del codice 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: link , è un breve ma molto, molto interessante documento basato su esperienze reali 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 una modifica a un'altra squadra finché non sono pronte a consumarla. Lascia che continuino a usare la vecchia build, mentre si passa alla nuova.
Assicurati di disporre di una strategia di controllo delle versioni che chiarisca quali modifiche si stanno verificando e quali sono le estensioni.
Inoltre, quando apporti una modifica, invia una revisione del codice a qualcuno SU OGNI SQUADRA. Lascia che guardino come è probabile che li influenzino, molto prima che siano costretti a consumarlo in modo che possano implementare le proprie modifiche in cima.
E, quando le cose si fanno veramente confuse; quando una squadra ha bisogno di fare un cambiamento e non può consumare facilmente un'altra modifica (questo dovrebbe essere un caso davvero raro), diramazione del codice, renderlo un pacchetto completamente diverso, ma renderlo prioritario tornare sul codice comune non appena il tempo permette.
La risposta che non è sempre così ovvia come potrebbe essere è lasciare che i team decidano come condividere un determinato componente.
Ad esempio, il mio team ha recentemente iniziato a sviluppare una nuova linea di prodotti che condivide un sacco di codice in comune con altri due team che hanno sviluppato prodotti simili da molto 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 alcuni diversi modi ad hoc di trattare la proprietà comune. Quindi, con una nuova grande funzione in arrivo, abbiamo deciso di riunire tutti i team per ottenere la stessa pagina, il che ha portato a un gruppo più piccolo composto da un paio di membri di ogni team che stanno elaborando i dettagli.
La soluzione dei nostri team potrebbe non funzionare in un'altra situazione. Potresti aver bisogno di qualcosa di più semplice o di qualcosa di molto più formale. Il punto è che prendi la proprietà collettiva e capisci cosa funziona per te.
Mi prenderò la libertà di assumere:
Se le ipotesi di cui sopra sono corrette, dovrebbero esserci solo occasionalmente momenti in cui due squadre interferiscono tra loro. Possono risolverlo usando i seguenti modi:
Leggi altre domande sui tag code-quality architecture scrum configuration-management