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

20

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ć?

Martin Wickman
źródło

Odpowiedzi:

20

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.


źródło
2
Słuszna uwaga; jednak nie widzę, jak to może działać, jeśli jest wiele zespołów, z którymi współpracują architekci.
śleske,
1
„Hej, EA, teraz siedzisz tutaj i nadal komunikujesz się z tymi samymi ludźmi. Po prostu częściej”. Jak dokładnie pomaga to rozwiązać konflikt między EA a innymi deweloperami?
Izkata,
@sleske, dlaczego nie podzielić grupy architektów korporacyjnych między zespoły? lub zatrudnić więcej architektów? Problem polega na tym, czy firma chce SCRUM i zwinnych zespołów, czy może czegoś nieźle. Izkata, codzienne spotkania bardzo zmieniają komunikację zespołu, poważnie, gdy EA poczuje, że jest on częścią DT, a nie jakąś pozaziemską architekturą, jest większa szansa na kompromis.
1
@ariwez: „dlaczego nie rozdzielić grupy architektów korporacyjnych” między zespoły? ” Ponieważ mamy więcej zespołów niż architektów; także architekci pracują głównie nad problemami, które dotyczą wielu zespołów.
śleske,
@sleske: „Osoby i interakcje dotyczące procesów i narzędzi”
17

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.”)

Jonathan Rich
źródło
Nie chodzi o osobistą satysfakcję, chodzi o produktywność, jakość i dbałość o wartość produktu. Zakładam, że deweloperzy w zespołach mogą to rozróżnić.
Martin Wickman,
2
W pewnym momencie ktoś podjął decyzję, że nie może. Dlatego istnieją architekci.
Jonathan Rich
4
Obecnie pracuję nad aplikacją po trzy serwery po stronie serwera, łączącą Railsy, ​​Javę i .NET, które tak naprawdę nie musiały być bardzo skomplikowane. Tak, strażnicy mogą być dobrą rzeczą, ale decyzje technologiczne powinny być podejmowane przez deweloperów osiągających konsensus i kierownictwo zatwierdzających lub komunikujących obawy, a nie osoby niebędące deweloperami podejmujące arbitralne decyzje techniczne lub decyzje zespołu deweloperów przesuwające się z boku podczas sprintu.
Erik Reppen
4
@erik A kiedy trzy oddzielne zespoły podejmą swoje trzy, osobne, zgodne decyzje, możesz uzyskać mieszankę Railsów, Java i .Net.
MarkJ
@ MarkJ, jeśli masz trzy oddzielne zespoły pracujące w izolacji dla tej samej aplikacji internetowej po stronie serwera, zasługujesz na to, co dostajesz.
Erik Reppen
6

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.

Telastyn
źródło
2
Jasne, ale odwrócenie tego: zmuszanie wszystkich drużyn do korzystania z tej samej gównianej technologii jest jeszcze bardziej paskudne (wszystkie idą tą samą brzydką ścieżką). Natomiast „różnorodność” z pewnością przyniesie przynajmniej niektóre rozwiązania, które będą się dobrze rozwijać.
Martin Wickman,
2
@MartinWickman czasem decyzje dotyczące złych technologii są związane z decyzjami biznesowymi. Jeśli 80% programistów na danym rynku ma doświadczenie z kiepską technologią, wówczas zastosowanie tej technologii może mieć sens z biznesowego punktu widzenia, ponieważ pozwala na pozyskiwanie kontrahentów w razie potrzeby. Na małym rynku możesz nie być w stanie znaleźć programistów Pythona wartych soli.
Jonathan Rich
@JathanathanRich Kiedy mówię gówniany, mam na myśli gówniany. Oznacza to, że nie można znaleźć nikogo, kto to wie.
Martin Wickman,
1
@MartinWickman - Jasne, zakładam, że twoi wyznaczeni programiści najwyższego poziomu (przydzieleni lub samoorganizujący się) nie są kompletnymi idiotami.
Telastyn
1
@JathanathanRich ma wadliwą logikę biznesową, IMO. Większa ilość nie oznacza wyższej proporcji jakości i zajmuje dużo mniej twórców Pythona, aby wykonać zadanie, jeśli są przynajmniej kompetentni.
Erik Reppen
5

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.

Euforyk
źródło
5

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.

Jay S.
źródło
4

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.

Śleske
źródło
2
Zgadzanie się z @MartinWickman, że „granica” jest kluczem pod wieloma względami: po pierwsze, opinie architektów powinny być uwzględniane w granicach oprogramowania , gdzie łączą się komponenty z wielu zespołów; po drugie, architekci znają swoją własną granicę władzy , aby powstrzymać się od podejmowania decyzji zespołu, o ile decyzje te nie wpływają na interoperacyjność.
rwong
3

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ń.

back2dos
źródło
Wyraźnie robią więcej niż kontrolę jakości. Oni decydują o użyciu narzędzia.
Erik Reppen
@ErikReppen: Byłem trochę niejasny. Miałem na myśli, że QA jest tym, co powinni robić.
back2dos,
@ back2dos: Myślę, że musisz zmienić kontrolę jakości w celu standaryzacji. Wiem, co mówisz, ale QA to zupełnie inny zespół i mylisz swój punkt widzenia.
gbjbaanb
2

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.

Sean McSomething
źródło
„Kiedy twoi architekci nie angażują się, dopóki nie zostaną podjęte decyzje, nie osiągają zwinności”. - Jeśli odwrócimy to stwierdzenie: „Gdy zespół nie angażuje architektów w podejmowanie decyzji, wtedy zespół nie działa sprawnie”. Jeśli zespół podejmuje decyzje, które są zmianą technologii, istniejących wzorców itp., Wtedy zespół musi uwzględnić architekta, aby zapewnić spójność całego produktu.
Metro Smurf
2

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.

Bob Lieberman
źródło
0

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.

Erik Reppen
źródło
To brzmi bardziej jak rant niż odpowiedź.
Bryan Oakley
Ktoś musi to zrobić.
Erik Reppen