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:
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.
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:
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:
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.
Odpowiedzi:
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ł).
źródło