Własność kodu z wieloma zespołami Scrum

Jeśli dwa zespoły Scrumowe korzystają z tego samego komponentu oprogramowania, kto jest odpowiedzialny za zapewnienie jasnej wizji architektury tego komponentu oraz utrzymanie / rozwijanie tej wizji w miarę ewolucji bazy kodu? W Scrumie powinieneś mieć zbiorowe prawa własności do kodu, więc jak upewnić się, że rozwój wykonywany przez Zespół A nie koliduje z tworzeniem przez Zespół B?

Nie jestem ekspertem w Scrumie, ale „własność wspólnego kodu AFAIK” ma dotyczyć zespołu i produktu (i myślę, że twoje pytanie nie jest specyficzne dla Scrum, można je zastosować do dowolnego procesu rozwoju „kodu wspólnego”).

Jeśli masz dwie drużyny A, B, dwa produkty A, B i wspólny komponent C, istnieją różne możliwe scenariusze. Być może wspólny komponent należy przede wszystkim do produktu A (i jest po prostu ponownie wykorzystywany, ale nie rozwinięty, przez zespół dla produktu B). W tej sytuacji zespół A jest wyraźnie odpowiedzialny za wizję architektoniczną. Lub odwrotnie: należy wyraźnie do produktu B - więc odpowiedzialność za to istnieje. Jeśli zespół A jest odpowiedzialny, zespół B może użyć rozwidlenia komponentu, aby umożliwić pilne poprawki błędów (powinien również istnieć sposób reintegracji ich z główną linią C), ale B powinien unikać dokonywania większych zmian w komponencie.

Jeśli jednak oba produkty A i B mają wiele „wymagań dotyczących prowadzenia pojazdu” dla C, powinieneś zarządzać C jako całkowicie oddzielnym produktem, z własną wersją, zarządzaniem wersjami, zarządzaniem zmianami, testami jednostkowymi itp. Oraz osobnym zespołem, który ma odpowiedzialność za ten element. Zespół ten może być po prostu „zespołem wirtualnym”, składającym się z oddzielnych programistów z zespołu A, B lub obu. Zespół ten ma „współwłasność kodu” dla C i odpowiedzialność za „wizję architektury”. Pomyśl tylko o C jako komponencie dostarczonym przez zewnętrznego dostawcę.

W Scrumie lub zwinnym nie ma koncepcji „wyraźnej wizji architektury”!

Od dawna jestem architektem i jest dla mnie jasne, że aby mieć wizję architektoniczną, trzeba mieć jasny obraz przyszłych wymagań. Ponieważ w większości przypadków wymagania wcale nie są jasne, nie ma sensu mieć stałej wizji.

Konieczne jest posiadanie architektury wystarczająco dostosowalnej do zmieniających się wymagań. Innymi słowy, rzeczy się zmieniają i zmienia się architektura - nie opowiadam się za „miękką” architekturą, którą można zmienić. Mówię o zaakceptowaniu tego, że architektura, którą dziś mamy, wkrótce stanie się przestarzała i będzie musiała zostać zmieniona, więc nikt nie powinien się z nią „żenić”.

Wspólne posiadanie kodu oznacza, że ​​każdy powinien - teoretycznie - być w stanie zmienić wszystko. Należy to rozumieć jako „przeciwieństwo silosów”. Innymi słowy, może istnieć bariera umiejętności, która jest normalna i oczekiwana - nie każdy jest doświadczonym DBA, który może precyzyjnie dostroić zapytania SQL, aby dać przykład - ale z tego nie wynika, że ​​tylko DBA może ręczne optymalizowanie zapytań. Będzie „ekspert w dziedzinie funkcji”, który może pomóc innym ludziom w osiągnięciu biegłości, ale zadania powinny nadal spoczywać na wszystkich.

Na przykład: jeśli jestem ekspertem w dziedzinie funkcji „A”, nadal oczekuję, że ktokolwiek będzie pracował nad funkcją „A”, ale prawdopodobnie będę się konsultować, gdy będą potrzebne poważne zmiany lub ludzie będą potrzebować pomocy. Funkcja „A” z pewnością nie byłaby moją funkcją. To będzie funkcja, którą dobrze znam. Moim zainteresowaniem będzie poznać wiele innych funkcji, a zainteresowaniem innych osób - znać tę funkcję.

Podsumowując: architektura jest projektowana i przeprojektowywana wiele razy przez programistów w miarę pojawiania się i zmieniania wymagań. Oczekuje się, że każdy dokona niezbędnych zmian zgodnie ze swoimi umiejętnościami i będzie wiedział, kiedy poprosić o pomoc. Nie ma długoterminowej wizji architektury, ponieważ ufamy ludziom i nie ufamy wymaganiom .

Na przykład spotify używa roli o nazwie „Właściciel systemu” do rozwiązania problemu bezpośrednio z dokumentu:

Technicznie każdy może edytować dowolny system. Ponieważ drużyny są skutecznie składające się z zespołów, zwykle muszą aktualizować wiele systemów, aby wprowadzić nową funkcję do produkcji. Ryzyko związane z tym modelem polega na tym, że architektura systemu zostaje popsuta, jeśli nikt nie skupia się na integralności systemu jako całości.

Aby zminimalizować to ryzyko, mamy rolę o nazwie „Właściciel systemu”. Wszystkie systemy mają właściciela systemu lub parę właścicieli systemów (zachęcamy do parowania). W przypadku systemów o krytycznym znaczeniu operacyjnym Właściciel systemu to para deweloperów - czyli jedna osoba z perspektywą programistyczną i jedna osoba z perspektywą operacyjną.

Właścicielem systemu jest osoba (osoby) „udające się” w sprawie wszelkich problemów technicznych lub architektonicznych związanych z tym systemem. Jest koordynatorem i prowadzi osoby, które kodują w tym systemie, aby się nie potknęły. Koncentruje się na takich kwestiach jak jakość, dokumentacja, dług techniczny, stabilność, skalowalność i proces wydawania.

Właściciel systemu nie jest wąskim gardłem ani architektem wieży z kości słoniowej. Nie musi osobiście podejmować wszystkich decyzji, pisać całego kodu ani wykonywać wszystkich wydań. Zazwyczaj jest członkiem lub dowódcą oddziału, który ma inne codzienne obowiązki oprócz własności systemu. Jednak od czasu do czasu bierze „dzień właściciela systemu” i wykonuje prace porządkowe w tym systemie. Zwykle staramy się, aby własność tego systemu była mniejsza niż jedna dziesiąta czasu danej osoby, ale oczywiście różni się ona znacznie w zależności od systemu.

Naprawdę podoba mi się ten pomysł, posiadanie korzyści lub własności zbiorowego kodu na poziomie firmy (nie tylko na poziomie zespołu), ale z właścicielami tych systemów starającymi się zapewnić integralność architektoniczną.

Link do pełnego dokumentu: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , to krótki, ale bardzo, bardzo interesujący dokument oparty na prawdziwych doświadczeniach na temat skalowania zwinnego.

Jest to trudny problem do rozwiązania i na pewno nie został rozwiązany przez Scrum, który jest metodologią zarządzania projektami, a nie metodologią programistyczną.

Najbardziej skutecznym rozwiązaniem, jakie znalazłem, jest dobre zarządzanie pakietami (nuget / gem / etc) i wersjonowanie. Nigdy nie wprowadzaj zmiany w innym zespole, dopóki nie będą gotowe do jej wykorzystania. Pozwól im dalej korzystać ze starej wersji, gdy przejdziesz na nową.

Upewnij się, że masz strategię kontroli wersji, która wyjaśnia, które zmiany się psują, a które rozszerzenia.

Po dokonaniu zmiany prześlij recenzję kodu komuś NA KAŻDYM ZESPOLE. Pozwól im spojrzeć na to, jak może to na nich wpłynąć, na długo przed tym, zanim zostaną zmuszeni do konsumpcji, aby mogli wprowadzić własne zmiany.

A kiedy sprawy stają się naprawdę nieuporządkowane; gdy jeden zespół musi dokonać zmiany i nie może łatwo z łatwością wprowadzić kolejnej zmiany (MUSI to być naprawdę rzadki przypadek), należy rozgałęzić kod, uczynić go całkowicie innym pakietem, ale priorytetem jest powrót do wspólnego kodu, gdy tylko czas pozwala.

Odpowiedź, która nie zawsze jest tak oczywista, jak to tylko możliwe, pozwala zespołom zdecydować, w jaki sposób udostępnią dany komponent.

Na przykład mój zespół niedawno zaczął opracowywać nową linię produktów, która ma wiele wspólnego kodu z dwoma innymi zespołami, które opracowują podobne produkty od dłuższego czasu. Nasz produkt różni się pod kilkoma względami, dlatego czasami musimy wymyślić sposoby dodania punktów dostosowywania do wspólnego kodu.

Mieliśmy kilka sprzeczek dotyczących tego kodu i wypróbowaliśmy kilka różnych metod ad hoc radzenia sobie ze wspólną własnością. Potem, gdy nadchodzi duża nowa funkcja, zdecydowaliśmy, że musimy zebrać wszystkie zespoły, aby dostać się na tę samą stronę, w wyniku czego powstała mniejsza grupa złożona z kilku członków z każdego zespołu, którzy opracowują szczegóły.

Rozwiązanie opracowane przez nasze zespoły może nie działać w innej sytuacji. Możesz potrzebować czegoś prostszego lub bardziej formalnego. Chodzi o to, że bierzesz kolektywną własność i zastanawiasz się, co Ci odpowiada.

Pozwolę sobie przyjąć, że:

• testy akceptacyjne są zautomatyzowane ..
• komponent stosuje dobre zasady OOP: niskie sprzężenie i wysoką kohezję.

Jeśli powyższe założenia są prawidłowe, to niekiedy zdarzają się sytuacje, w których dwie drużyny przeszkadzałyby sobie nawzajem. Mogą rozwiązać to na następujące sposoby:

• Gdy tylko test akceptacyjny drugiego zespołu nie powiedzie się, porozmawiaj z nim, aby dowiedzieć się, czy korzystanie z udostępnionego komponentu jest prawidłowe, czy twoje. Jeśli oba zastosowania są w porządku, sprawdź, czy wspólna część tego użycia jest przekazywana (refaktoryzowana) do wspólnego komponentu podstawowego, a rozbieżność w użyciu jest zarządzana za pomocą klas potomnych lub może być poprzez kompozycję.
• Uczyń jedną osobę odpowiedzialną za komponent, gdy jest on w fazie rozwoju. Powinien działać jako wspólny zasób między zespołami.