Jak architekci mogą współpracować z samoorganizującymi się zespołami Scrum?

Organizacja z wieloma zwinnymi zespołami Scrum ma również niewielką grupę osób mianowanych „architektami korporacyjnymi”. Grupa EA działa jako kontrola i strażnik jakości i przestrzegania decyzji. Prowadzi to do nakładania się decyzji zespołu i decyzji EA.

Na przykład zespół może chcieć użyć biblioteki X lub REST zamiast SOAP, ale EA tego nie akceptuje.

Może to prowadzić do frustracji, gdy decyzje zespołu zostaną unieważnione. Mówiąc wystarczająco daleko, może potencjalnie doprowadzić do sytuacji, w której ludzie EA „przejmą” całą moc, a zespół skończy się czując się zdemotywowanym i niezbyt zwinnym.

Przewodniki Scrum mają o tym do powiedzenia:

Samoorganizacja: nikt (nawet Scrum Master) nie mówi zespołowi programistycznemu, jak zamienić Backlog Produktu w Przyrosty potencjalnie możliwej do uwolnienia funkcjonalności.

Czy to rozsądne? Czy zespół EA powinien zostać rozwiązany? Czy zespoły powinny odmówić, czy po prostu się zastosować?

Zespół programistów składa się z 3–9 osób o umiejętnościach interdyscyplinarnych, które wykonują rzeczywistą pracę

Scrum Master powinien zaprosić „Enterprise Architect”, aby stał się częścią zespołu projektowego. Wtedy komunikacja między architektem a programistami byłaby doskonała.

Wybór zastosowanej technologii jest częścią wymagań oprogramowania, co oznacza, że ​​jest częścią żądania funkcji, abyś nie korzystał z niektórych technologii z jakiegokolwiek powodu.

Architekci mówią za systemami i bazą kodów, ponieważ systemy i baza kodów nie mogą mówić same za siebie. Posiadanie architekta leży zasadniczo w długoterminowym interesie firmy, zwłaszcza opartej na oprogramowaniu wewnętrznym.

Architekci nie mówią deweloperom, jak zamieniać zaległości w przyrosty (sprinty), twierdzą, które technologie można, a których nie można użyć. Łączymy dwie różne kwestie.

Rozwiązaniem jest nic nie zmieniać. Jeśli twoje zespoły stają się sfrustrowane, ponieważ architekci są zbyt restrykcyjni lub zbyt narzuceni, jest to kwestia kadrowa, która nie ma nic wspólnego z SCRUM i powinna być podejmowana z interesariuszami biznesowymi jako kwestia zadowolenia pracowników i, jeśli to możliwe, wynik końcowy („ x%Opracowywanie funkcji zajmuje nam więcej czasu, yponieważ architekt znie pozwala nam korzystać z Turbo Pascal.”)

Tego rodzaju rzeczy są konieczne, aby zachować równowagę między potrzebą dużego zespołu, aby zrealizować projekt, a potrzebą utrzymania zwinnych zespołów małych.

Zasadniczo „zespół prowadzący zespół” składa się z jednego członka wybranego z każdej z mniejszych drużyn. Zapewnia to pewną samoorganizującą się naturę, a także zapewnia pewien sposób reprezentacji, dzięki czemu decyzje podejmowane przez grupę wysokiego szczebla są akceptowane przez grupę zwinną.

W twoim konkretnym scenariuszu należy zrobić coś, aby powstrzymać zwinną demotywację zespołu, ale prawdopodobnie nie bunt lub zwykłą akceptację. Zespół musi zdać sobie sprawę, że jesteś tam, aby tworzyć dobre oprogramowanie, a nie podążać za ideałami. Posiadanie grupy różnych zespołów, z których każda używa różnych technologii do robienia podobnych rzeczy w tym samym projekcie, doprowadzi do pogorszenia oprogramowania. Posiadanie grupy różnych zespołów stosujących różne standardy kodowania w tym samym projekcie doprowadzi do pogorszenia oprogramowania.

Więc będziemy potrzebować jakiś sposób, aby dojść do jakiegoś konsensusu w jaki sposób projekt będzie działać. Scrum lidera zespołu jest skutecznie wykorzystywany w innych miejscach. Być może będziesz musiał zrobić coś inaczej lub sprawdzić, dlaczego twoja grupa nie robi tego skutecznie.

Pytanie brzmi: z jakiego powodu istnieje ten zespół architektów? Jedynym powodem, dla którego mogę wymyślić, jest wymuszenie interoperacyjności między różnymi zespołami. Lub zespoły pracują nad różnymi częściami jednego produktu, a ten zespół architektów istnieje, aby utrzymać każdą część razem.

Naprawdę nie sądzę, aby ten schemat działał dobrze w zwinnym środowisku, z dokładnie określonych powodów. Różne zespoły powinny być niezależne, podobnie jak ich wkład i wyniki. Zatem ograniczanie ich wyników powinno być tylko częścią wymagań dotyczących nakładów. Ale te ograniczenia powinny być rozsądne. Coś w rodzaju „Nie wolno używać biblioteki X” nie jest dobrym wymaganiem, ale powiedzenie „Musi ograniczyć liczbę używanych bibliotek stron trzecich do minimum” lub „Dodanie nowych bibliotek, które nie są używane w innych zespołach, powinno być ograniczone”. powinno być dobrze.

Następnie rozpuściłbym zespół architektów we wszystkich zespołach i wykorzystałbym ich wiedzę w kwestiach architektury. Stając się częścią zespołu, będą mogli lepiej dostrzegać problemy zespołu i mogą mieć lepsze pomysły lub bardziej wykształcone opinie na temat zmiany podstawowych części architektury. Należy również zachęcać architektów z różnych zespołów do komunikowania się, aby zapewnić spójność architektury między zespołami.

Grupa w Scaled Agile Framework bardzo dobrze z tym rozmawia. Większość z nas zajmuje się na poziomie zespołu, ale przy zwiększaniu skali musimy pamiętać, że istnieją role do odegrania również na poziomie programu i portfela. Decyzje architektoniczne należy podejmować w całej organizacji, co powinno uwzględniać to, co dzieje się na niższych poziomach organizacji. Nie ma nic złego w podejmowaniu decyzji architektonicznych!

W związku z tym ostatnia książka Deana Leffingwella na temat wymagań zwinnego oprogramowania jest dobrą lekturą na ten temat, sam ją czytałem.

Mamy też wiele zwinnych zespołów (niektóre do Kanban, niektóre Scrum) i architektów. Architekci są odpowiedzialni za infrastrukturę obejmującą wszystkie nasze produkty (biblioteki pomocnicze, uwierzytelnianie, budowanie infrastruktury) itp. Podejmują decyzje techniczne, ale także wdrażają rzeczy, głównie elementy infrastruktury.

Działa to dobrze i zwykle nie ma konfliktu. Uważam, że jednym z kluczowych punktów jest:

Architekci nie mają formalnej władzy nad zespołami i nie mogą ich po prostu unieważnić. Zwykle architekci podejmują decyzje dotyczące wszystkich produktów, a zespoły podejmują decyzje dotyczące ich produktów. Jeśli wystąpi konflikt, architekt i zespół muszą tylko osiągnąć porozumienie lub przejść do zarządzania (choć rzadko się to zdarza).

Myślę, że bardzo ważne jest, aby architekci i programiści byli rówieśnikami. Oba dążą do wspólnego celu, tylko w różnych obszarach. Jeśli nikt nie może po prostu „unieważnić” drugiego, współpraca będzie lepsza.

Nie widzę tutaj żadnego konfliktu. Z tego, co rozumiem, cała EA (jakkolwiek pompatyczny tytuł, jak sądzę, że to jest) ma na celu zapewnienie jakości. Wszyscy powinni być tego świadomi.

Należy wziąć pod uwagę, że w każdej metodologii programistycznej (która zasługuje na uznanie jej za jedną), gromadzenie wymagań jest kluczowym krokiem, niezależnie od tego, czy jest iteracyjne, czy z góry.

Niektóre z tych wymagań są określone przez zasady firmy. A te ustanawiają podstawowe zasady:

• Zespół będzie musiał ich przestrzegać, jak w przypadku innych wymagań. Zakwestionowanie polityki jest zatem po prostu poza zakresem projektu i powinno być rozpatrywane osobno.
• Zadaniem EA jest egzekwowanie tych wymagań i nie narzucanie ich osobistej fantazji. Nie lubią X, to ich osobista opinia. Nic dodać nic ująć. Traktuj to jak każdą inną opinię. Jeśli jednak EA może wykazać, że używanie X narusza istniejący wymóg, mają oni prawo zabronić używania X, a jeśli znają wykonalną alternatywę, a zespół nie, to ma prawo je egzekwować.

Ale w obu przypadkach wymaganie jest spełnione lub nie. Jeśli trudno jest ustalić tę kwestię, brakuje tego wymogu i trzeba go powtórzyć, aby był naprawdę sprawdzalny (w szerszym znaczeniu). Powinieneś sobie z tym poradzić jak każde powtórzenie wymagań.

Twój architekt nie powinien unieważniać decyzji podjętych przez zwinne zespoły. Twój architekt powinien uwzględnić je w wymaganiach / historiach przekazanych zespołom. Powinny one aktualizować zespoły, gdy zmieni się krajobraz projektu i zostaną wprowadzone nowe wymagania dotyczące interoperacyjności.

Architekci wydawający zamówienia i sprawdzający decyzje techniczne to wada kulturowa. Uważają się za „szefa”, a nie tylko utrzymują wspólny cel / wizję i utrzymują oddzielne zespoły na tej samej stronie. Metodyki zwinne opierają się na komunikacji i kontakcie. Kiedy twoi architekci nie angażują się, dopóki nie zostaną podjęte decyzje, nie osiągają zwinności.

Martin, myślę, że możesz mieć błędne wyobrażenie o tym, jak samoorganizujący się zespół funkcjonuje w swoim otoczeniu.

Cytujesz Przewodnik Scrumowy: „Nikt (nawet Scrum Master) nie mówi zespołowi programistycznemu, jak zamienić Backlog Produktu w Przyrosty potencjalnie możliwej do uwolnienia funkcjonalności”.

Nie jest to licencja dla zespołu Scrum na robienie wszystkiego, co chce (o ile zapewnia), bez względu na technologię i potrzeby biznesowe firmy jako całości, a także potrzeby innych zespołów.

Pewni interesariusze mogą nadużywać swoich wpływów. To jedno z wyzwań współpracy i na pewno nie ogranicza się do EA. Ale współpraca nie kończy się na granicy zespołu.

Waterfall lub Scrum (to wydaje się mieszać dwa, co tak, nie zadziała), co dla mnie brzmi jak całkiem bezcelowa warstwa zarządzania. Strażnicy decyzji dotyczących technologii powinni być głównymi deweloperami, ogólnym kierownikiem ds. Rozwoju, którego zadaniem powinno być utrzymanie preferencji twórców przed przekształceniem aplikacji w hydrę wyborów technologicznych, a każdy budżet musi pokryć potencjalny rachunek.

Nic mnie nie ogłusza, tak jak nie-deweloperzy, którzy mają chęć podejmowania decyzji technologicznych, nawet bez konsultacji z rzeczywistymi ludźmi, którzy muszą ponieść konsekwencje tych decyzji.