Krojenie stosu programowania - po przekątnej?

11

Mamy nowy projekt, w tej chwili programiści zostali podzieleni na dwa zespoły, zespół A i zespół B. Projekt składa się z 2 części, które wymagają rozwoju w całym stosie programistycznym. Bardzo uproszczona próbka naszego stosu pokazana poniżej:

wprowadź opis zdjęcia tutaj

Każda część projektu wymaga opracowania na całym stosie, więc zwykle oczekiwałbym podejścia programistycznego opartego na pełnym stosie, czyli w jaki sposób dzielimy naszą pracę w zespole B, projektując i opracowując interakcje między różnymi częściami.

wprowadź opis zdjęcia tutaj

Niedawno dowiedziałem się jednak, że zespół A chce kierować niektórymi częściami stosu, i proponują podział między dwoma zespołami, w których warstwą abstrakcji danych (i umieszczaniem zawartości w warstwie danych) zajmuje się sami bez rozwoju zespołu B. Podział wyglądałby podobnie do tego:

wprowadź opis zdjęcia tutaj

Dla mnie jest to bardzo nienaturalne. Każda drużyna ma różne cele i harmonogramy, aby je osiągnąć, ale Drużyna B będzie zależna od Drużyny A w zakresie wdrażania funkcji. Proponowane rozwiązanie polega na tym, że wspólne interfejsy są definiowane z góry (prawdopodobnie projekt ma 2 lata, więc mogą być liczne). Drużyna A opracuje następnie wymagane fragmenty tych interfejsów wcześnie, pomimo posiadania własnego zestawu bramek, podczas gdy Drużyna B usunie wszystkie wezwania na najbliższy krótki okres, aby mogli się rozwijać.

Mam obawy dotyczące tego podejścia dotyczącego:

  • Interfejsy mogą się zmieniać, a Zespół A może nie mieć przepustowości lub czasu, aby dostosować się do zmieniających się wymagań.
  • Błędy w kodzie Drużyny A mogą uniemożliwiać postęp Drużyny B, i znowu może nie być priorytetem ich naprawy, ponieważ Drużyna A ma inną kolejkę priorytetów.
  • Brak wiedzy rozprzestrzenił się na zespoły - Zespół B może nie w pełni zrozumieć, co dzieje się pod maską i może z tego powodu podejmować złe decyzje projektowe.

Sugerowano, że wiele firm w branży ma podgrupy i musi być w stanie sobie z tym poradzić. Z mojego zrozumienia, ogólnie zespoły są albo podzielone, jak początkowo oczekiwałem (pełny stos), lub przez rozbicie stosu technologii, jak poniżej:

wprowadź opis zdjęcia tutaj

Jestem więc zainteresowany tym, co robi reszta przemysłu. Czy większość podziałów jest pionowa / pozioma? Czy podział po przekątnej ma sens? Jeśli miałby nastąpić podział diagonalny, czy moje obawy wydają się uzasadnione i czy jest coś jeszcze, o co powinni się martwić Drużyna B? Należy zauważyć, że prawdopodobnie będę odpowiedzialny za sukces lub porażkę zespołu B.

Ian
źródło
10
„Reszta branży” prawdopodobnie robi każdą kombinację podziałów, jaką możesz wymyślić. Ale szczerze mówiąc, nie powiedziałeś nam, dlaczego zespół A chce być odpowiedzialny. I to robi różnicę, jak duże są twoje zespoły i czy mają równe kwalifikacje.
Doc Brown
Na trzeciej ilustracji, czy praca Drużyny A i Drużyny B jest oddzielona odrębnym API? Czy istnieje wyraźna, logiczna granica narzucona przez tę linię podziału? Podział pracy nie jest niczym nowym; Na przykład Stack Exchange ma własnego projektanta.
Robert Harvey
@DocBrown Wierzę, że Drużyna A chce rządzić, ponieważ czują, że „zbyt wielu kucharzy psuje bulion” po niepowodzeniu poprzedniego projektu z większym zespołem - ale tak naprawdę nie jestem tego pewien. Zespoły składają się z około 5 deweloperów i są dość równo wykwalifikowane.
Ian
1
Jeśli nie uda ci się przekonać ich do podziału pionowego, możesz chcieć, aby Zespół A zajął się wnioskami Drużyny B o wyższym priorytecie, jak ich własne żądania. Może to zapobiec blokowaniu i złej krwi i wydaje się uczciwą ceną do zapłacenia.
Hans-Peter Störr
1
@hstoerr: Co ciekawe, właśnie to sugeruje sojusz scrum Zespół konsumencki (zespół, który wykorzystuje lub „konsumuje” produkty innych zespołów) działa jako właściciel produktu zespołu producenckiego. zaczerpnięte z scrumalliance.org/community/articles/2012/september/…
Ian

Odpowiedzi:

12

Twoje obawy są niezwykle ważne. Zwłaszcza pierwsze dwa punkty na temat tego, że Drużyna A nie ma czasu na dodawanie funkcji lub naprawianie błędów, które wpływają na Drużynę B. Widziałem to kilka razy w mojej własnej pracy.

Może to być dobry pomysł, jeśli:

  • Wiadomo, że Zespół A będzie pracował nad projektami, które wymagają nowych funkcji w bazie danych, podczas gdy celem Zespołu B jest zasadniczo wykonywanie funkcji „tylko nakładki”. Na przykład, jeśli Zespół B pisze nową aplikację Twojej firmy na iPhone'a, prawdopodobnie nie dodają nowych pól bazy danych przez jakiś czas, ponieważ muszą przenieść / ponownie wdrożyć wszystkie funkcje wersji komputerowej.

  • „Pełny stos” stał się na tyle skomplikowany, że żaden pojedynczy deweloper (lub zespół programistów) nie jest w stanie skutecznie „posiadać” całości. Przez „własny” rozumiem nie tylko dodawanie funkcji i naprawianie błędów, ale rozumienie i dbanie o cały system do tego stopnia, że ​​mogą uniknąć dodawania do niego więcej długu technicznego z czasem. W tym przypadku podział „diagonalny” jest sensownym posunięciem, jeśli zespół A posiada interfejs użytkownika / interfejs API, który jest albo niezwykle prosty, albo nieunikniony ściśle powiązany z implementacją DAL / bazy danych (być może niektóre wewnętrzne narzędzia diagnostyczne?), Podczas gdy zespół B ma wszystkie skomplikowane interfejsy użytkownika.

  • Kierownictwo rozumie ryzyko, że zespół A stanie się wąskim gardłem, i byłby skłonny do przekątnej rzeczy, jeśli lub kiedy ryzyko to stanie się prawdziwym problemem.

Nie mogę rozmawiać o tym, co jest mniej lub bardziej powszechne w branży, ale przynajmniej tam, gdzie pracuję, wszyscy programiści aplikacji muszą mieć „pełny stos”. To, co mamy, to zespoły ds. Infrastruktury, które opracowują / utrzymują naszą wewnętrzną bazę danych, naszą strukturę usług internetowych i naszą strukturę interfejsu użytkownika (czy wspominałem, że moja firma jest ogromna?), Aby wszystkie nasze setki aplikacji mogły mieć pełny stos deweloperów, podczas gdy firma jako całość może nadal zapewniać stałą wydajność i interfejs dla wszystkich naszych usług.

Niedawno nasza firma opracowała zupełnie nową platformę interfejsu użytkownika, więc był okres, kiedy niektóre z naszych nowych aplikacji były dość mocno zablokowane pod kątem błędów i brakujących funkcji w nowej strukturze. Tak już nie jest, głównie dlatego, że niektórzy z nas otrzymali pozwolenie na przesyłanie żądań ściągania do zespołu, który jest właścicielem frameworka (niezupełnie „demagnetyzacja”, ale masz pomysł).

Ixrec
źródło
2
Po drugie, wydaje się, że dotyczy to każdej aplikacji biznesowej o rozsądnej wielkości. Biblioteki z dobrze zdefiniowanymi interfejsami API wydają się być logicznymi granicami, pod warunkiem, że nie są zbyt duże.
Robert Harvey