Brak komunikacji oraz problemy przy projektowaniu aplikacji i infrastruktury

2

Stanąłem przed nietrywialnym problemem. Problemem bałaganu, który w sumie chciałbym potraktować jako niezła przygodę zanim zmienię pracę na rozsądniejszą.

Mamy dwa zespoły.

  • Lokacja A programiści.
  • Lokacja B admin's / devops.

Mamy problem komunikacyjny pomiędzy tymi zespołami (znajdują się w dwóch różnych lokacjach). Dla wytrawnych możecie to rozumieć jako podkładanie bomby na A lub na B.
Wszyscy pracują nad jedną aplikacją, która docelowo ma być:

  • Uruchamiana na chmurach typu AWS, Azure, GCP (...)
  • Odpalana na VM'kach - Docker
  • Odpalana na Kubernetesie w piwnicy u klienta
  • Odpalana na własnym środowisku - Kubernetes

Do tej pory jednak zespół programistyczny nie do końca był świadom w jakich środowiskach ma działać aplikacja. Info o samej aplikacji:

  • Klasyka czyli mikroserwisy na start.
  • Aplikacja docelowo będzie odpalana w tysiącach lokacji. Przyjmijmy 10k lokacji.
  • Ów 10k lokacji w pewnym sensie ma się ze sobą komunikować ale nie do końca każda z każdą.
  • Ma swój własny framework (nazwałbym to biblioteką), który został pospinany z różnych bibliotek i on steruje skalowaniem serwisów na bazie danych ministerstwa danych z d**y.

Po ostatnim spotkaniu stoję przed trochę trudnym zadaniem doinformowania zespołów nawzajem gdyż zespół A robiąc aplikację kompletnie nie ma pojęcia o infrastrukturze i tym w jakich środowiskach będzie ona działać, a zespół B nie ma pojęcia jak zbudowana jest aplikacja i to dosłownie.

Problemy jakie zauważyłem:

  • Zespół programistyczny kompletnie nie potrafi się komunikować z zespołem od infrastruktury
  • Zespół od infrastruktury gdy dostaje prośbę o jakąś zmianę na środowisku czy informację, że coś na środowisku testowym nie działa - często nie ma za bardzo pojęcia gdzie szukać problemu i jego rozwiązania.
  • Zespół od infrastruktury kompletnie nie ma pojęcia jak zbudowana została aplikacja.
  • Zespół od infrastruktury wie tylko, że aplikacja jest rozbita na ~14 modułów takich jak API, Front, DB - nie wiadomo co z czym gada.
  • Testowe odpalenie service-mesh przez infra team spowodowało, że komunikacja się zapętliła i aplikacja przestała odpowiadać - XD
  • Zespół programistyczny zaprojektował sobie aplikację tak jak chciał - aplikacja będzie działać w dziesiątkach środowisk począwszy od VMek z Dockerem poprzez klastry Kubernetesa dziergane on-premises w piwnicy u klienta aż do usług chmurowych typu AWS, Azure, GCP (...)
  • Zespół programistyczny wydziergał z tej aplikacji mikroserwisy - nie wiadomo jak aplikacja została pocięta.
  • Zespół programistyczny sam zadecydował o tym kiedy i w jakich okolicznościach jakaś część aplikacji ma się skalować - nie wzięto pod uwagę, że Kubernetes może mieć to za przeproszeniem w d...e.
  • Zespół programistyczny kompletnie nie rozumie czym jest i jak działa Kubernetes.
  • Zespół infrastruktury nie ma pojęcia dlaczego do budowy aplikacji zostały wybrane takie, a nie inne elementy (DB, biblioteki, frameworki etc.)

*Zespół infry poza tym, że grzebie przy serwerach próbuje też zbudować sensowne CICD - na razie w środowisku testowym.

Wybaczcie jeśli gdzieś się powtórzyłem. Ciężko ogarnąć mi tą inżynierię chaosu w głowie. Moje pytanie do was - jak byście próbowali posprzątać ten burdel? I nie pytam tu o konkretne rozwiązania tylko w miarę ogólne. Nawet nie bardzo wiem od czego by tu zacząć i czy problemy, które ja widzę są faktycznie problemami i czy wymiana informacji pomiędzy lokacjami A i B w każdym z tych przypadków jest potrzebna.

Całość jak najbardziej nazywam problemem ponieważ jakieś 2/5 aplikacji już za nami, a problemy wyszły dopiero teraz (jestem od niedawna w tej karuzeli). Wcześniej nikt w to nie ingerował.
Potrzebuję spojrzenia kogoś z boku więc każdy komentarz mile widziany - nie ważne czy jesteś programistą czy instalujesz CentOS'y.

1

Kilka myśli / pytań odnośnie zespołów

  1. Co obecnie robi zespół od infrastruktury? Uruchamia hello world na kubernetesie? Pisze swoją aplikację?
  2. Rozumiem, że jest zespół - zrobił 2/5 prac (ciekawe...) i nie ma CI? Grubo (i smutno). Chyba bym zaczął od tego (co jak rozumiem robisz). Tu może się da najwięcej współpracy ugrać.
  3. Zespół infrastruktury nie ma pojęcia dlaczego do budowy aplikacji zostały wybrane takie, a nie inne elementy (DB, biblioteki, frameworki etc.) - ale dlaczego mieliby mieć pojęcie?
  4. Może powinna być jasna odpowiedzialność - za odpalenie i działanie, maintenance tej aplikacji odpowiada zespół programistyczny. Skoro wybrali technologię, architekturę to jakby naturalne.
    Nie teraz to oni to wszystko "instalują". W tym momencie zespół od infra powinien być do pomocy i review.
  5. Może niech zespół infra przygotuje demo jak sobie wyobraża aplikację, monitorowanie, debugowanie itd i zaprezentuje to na małym przykładzie,
    Chyba tak bym to widział - niech to będą mentorzy, nauczyciele, coache od infra, ale nie oni to teraz powinni głównie teraz nad yamlami zapierniczać.
  6. Zespół programistyczny sam zadecydował o tym kiedy i w jakich okolicznościach jakaś część aplikacji ma się skalować - nie wzięto pod uwagę, że Kubernetes może mieć to za przeproszeniem w d...e.
    tego nie rozumiem - pewnie z powodu technologii użytej. Jak aplikacja jest zrobiona jako mikroserwisy to gdzie tu może być problem? I jak może tu kubernetes przeszkadzać?

Lubię takie chore sytuacje. Zwykle i tak problem wynika z 2-3 konkretnych panów Edków, którzy robią nie to co powinni. Nie zawsze jest oczywiste jak ich zlokalizować.
I tak lepiej niż 3 zespoły programistyczne, które robią jedną aplikację, ale ze sobą nie gadają i każdy zespół robi po swojemu i od nowa - a takie akcje bywają.

0
jarekr000000 napisał(a):

Kilka myśli / pytań odnośnie zespołów

  1. Co obecnie robi zespół od infrastruktury? Uruchamia hello world na kubernetesie? Pisze swoją aplikację?
  • Ogarnia środowisko, które na ten moment jest jeszcze środowiskiem dev / testowym.
  • Stanowi support dla zespołu programistycznego.
  • Zarządza (to duże słowo) Kubernetesem za pomocą Ranchera na którym stoi ów aplikacja + kilka innych mniejszych projektów typu wordpressy, systemy ticketowe etc.
  • Ogarnia serwery na miejscu w serwerowni - dorzuca doń fizyczne graty, przepina, rozpina, podpina czyli to co old school admini.
  • Próbuje zrozumieć problemy zespołu programistycznego nie mając kompletnie pojęcia jak sklejona została aplikacja jak już wspomniałem. Kompletny brak wiedzy na ten temat.
  • Wystawia certyfikaty (u nas są tego tony, wszędzie potrzebujesz certyfikat).
  • Sprząta po jednym takim architekcie teoretyku, który teorię zna naprawdę po mistrzowsku. Niestety jego praktyka bazuje na tej teorii z książek w których wszystko jak zawsze pięknie działa. Jak pewnie wiesz to w realnym świecie nigdy tak ładnie nie wygląda.
  • I wiele innego szitu, który zajmuje dużo więcej czasu niż klasyczne 8h.
jarekr000000 napisał(a):
  1. Rozumiem, że jest zespół - zrobił 2/5 prac (ciekawe...) i nie ma CI? Grubo (i smutno). Chyba bym zaczął od tego (co jak rozumiem robisz). Tu może się da najwięcej współpracy ugrać.

W pewnym sensie jest. Aplikacja stoi łącznie na 3 albo nawet 4 środowiskach. Może nie tyle środowiskach co są 3-4 jej kopie.

  • Jedna dla testów, które są przeprowadzane z docelowymi klientami.
  • Druga dla zespołu klikającego w aplikacji.
  • Trzecia w formie typowej piaskownicy, bo teraz się obudzono, że security nie do końca ma sens i trzeba je szybko przerobić.
  • Czwarta została wdrożona u jednego klienta na zasadzie testów wewnątrz.
jarekr000000 napisał(a):
  1. Zespół infrastruktury nie ma pojęcia dlaczego do budowy aplikacji zostały wybrane takie, a nie inne elementy (DB, biblioteki, frameworki etc.) - ale dlaczego mieliby mieć pojęcie?

Ponieważ jest sporo problemów z samą aplikacją. I oczywiście narzekanie zespołu programistycznego, że wina leży po stronie zespołu infrastruktury. Nie ma sensownego toola, który mógłby monitorować flow całej aplikacji na środowisku testowym/dev. Często padają kontenery np. Redisa i nijak nie wiadomo jaki jest tego powód. Dodanie do compose restart: always nie podnosi kontenera. Wobec czego na ostatniej prezentacji gdy "nagle" wszystko padało siedziała osoba od infry gapiąc się w terminal i gdy padało restartowała ręcznie :D
Po ostatnim spotkaniu i propozycji wpięcia jakiegoś porządnego monitoringu zespół programistyczny stwierdził (cytuję):

Haha! Chcecie tak nas tutaj dokładnie monitorować żeby zrzucać na nas winę?

Przykre, bo nie taki jest cel infry. W moim odczuciu powinni oni mieć monitoring wszystkiego żeby móc dostarczyć konkretne logi, a nie później się tłumaczyć dlaczego Kubernetes jest niestabilny (jest stabilny).
Wydaje mi się, że zespół infry lepiej zrozumie co gdzie szukać i ewentualne problemy w chwili gdy będzie wiedzieć jak zbudowana jest aplikacja. Ale mogę oczywiście być w błędzie.

Przykładowy temacik sprzed kilku dni.

  • Pada prośba od zespołu programistycznego o dodanie headera dla CORS do jednego z modułów aplikacji, bo chłopaki mają błąd. Zespól infrastruktury nie wie czym ów CORS jest, gdzie go szukać i jaki nagłówek dodać. Złapanie jednego z programistów i zadanie mu konkretnych pytań pozwala oczywiście szybko zrobić temat wraz z restartem samej aplikacji.
    Problem trywialny ale mimo wszystko jest to niejako aktualnie problem.

Ci/CD, dla niektórych środowisk jest. Aczkolwiek dla mnie to jakaś proteza nie mająca wspólnego zbyt wiele z automatyzacją. Bo co to za pipeline przy którym devops i tak musi wiecznie coś robić. Wraz z przenoszeniem środowisk. Mam tu na myśli fakt, że środowisko klikane przez testerów po ich akceptacji trzeba ręcznie przenosić na środowisko do prezentacji dla klientów.
Był docker-swarm połączony z TeamCity. Teraz jest Kubernetes połączony z TeamCity. Decyzje te zostały zapoczątkowane przez osoby, których już tu nie ma, a ja niejako wpadłem w to gościnnie i próbuję się rozeznać w temacie + wnieść coś co jakoś uporządkuje ten burdel.

Jedno środowisko jeszcze nie jest przeniesione więc trzeba je ręcznie siekać.

  • Pobierać z jednego środowiska kontenery do siebie lokalnie.
  • Tagować je pod drugie środowisko.
  • Przelogować się na drugie środowisko.
  • Wypychać je na drugi registry.
  • Ubijać stare / podnosić nowe.
jarekr000000 napisał(a):
  1. Może powinna być jasna odpowiedzialność - za odpalenie i działanie, maintenance tej aplikacji odpowiada zespół programistyczny. Skoro wybrali technologię, architekturę to jakby naturalne.
    Nie teraz to oni to wszystko "instalują". W tym momencie zespół od infra powinien być do pomocy i review.

W punkt. Próbujemy to właśnie ogarnąć ale do tego potrzeba. Teraz wygląda to tak:

  • Wewnętrzny git z tonami branchy i o dziwo nie. To, że coś jest na master nie oznacza, że jest finalne i działające (w zależności od repo).
  • Część leci do TC jako kod, a część jako artefakty - :D !?
  • Następuje cały proces pchania tego w kontenery do lokalnego registry.
  • Pchania kontenerów na K8s.

Teraz nie bardzo wiadomo kto dokładnie podjął takie decyzje, a nie inne więc chcemy to podzielić według jakiejś fajnej logiki. Z drugiej strony puszczenie programistów na infrastrukturę prosi się o kłopoty.

jarekr000000 napisał(a):
  1. Może niech zespół infra przygotuje demo jak sobie wyobraża aplikację, monitorowanie, debugowanie itd i zaprezentuje to na małym przykładzie,
    Chyba tak bym to widział - niech to będą mentorzy, nauczyciele, coache od infra, ale nie oni to teraz powinni głównie teraz nad yamlami zapierniczać.

Dobra sugestia. Dodam jeszcze, że na pytanie czy w aplikacji jakoś logują błędy (na froncie logują wyrzucając komunikat Wystąpił błąd 093893984374) dostałem odpowiedź, że: `tak, tak. Ludzie z infry chcieliby mieć (powinni?) dostęp do tych logów u siebie żeby móc podrzucać je do programistów.
W ogóle wydaje mi się, że wszelkiej maści zgarnianie logów powinna robić infra i rzucać je do programistów. Jestem w błędzie?

jarekr000000 napisał(a):
  1. Zespół programistyczny sam zadecydował o tym kiedy i w jakich okolicznościach jakaś część aplikacji ma się skalować - nie wzięto pod uwagę, że Kubernetes może mieć to za przeproszeniem w d...e.
    tego nie rozumiem - pewnie z powodu technologii użytej. Jak aplikacja jest zrobiona jako mikroserwisy to gdzie tu może być problem? I jak może tu kubernetes przeszkadzać?

Zastanawiam się czy jak aplikacja i jej superhiper framework (oczywiście zbudowany przez kilku geniuszy) zacznie się sama skalować wedle jakichś ichniejszych założeń to co się stanie w przypadku gdy infra zdecyduje zrobić swoje własne reguły dla Kubernetesa? Tu znowu wydaje mi się, że przy użyciu K8s takie tematy powinny zostać zdefiniowane bezpośrednio w nim, a nie samej aplikacji. Oczywiście tutaj również mogę być w błędzie i chętnie posłucham bardziej doświadczonych.

jarekr000000 napisał(a):

Lubię takie chore sytuacje. Zwykle i tak problem wynika z 2-3 konkretnych panów Edków, którzy robią nie to co powinni. Nie zawsze jest oczywiste jak ich zlokalizować.
I tak lepiej niż 3 zespoły programistyczne, które robią jedną aplikację, ale ze sobą nie gadają i każdy zespół robi po swojemu i od nowa - a takie akcje bywają.

Problem wynika jak już mówiłem z braku komunikacji. Stres zaczyna się w momencie gdy jest jakiś deadline. Wtedy z góry idzie zjebka. I to trwa do prezentacji. Na prezentacji "jakoś" się uda więc lecimy dalej z tematem i nie cofamy się żeby naprawić ten burdel. Rączki na górze uściśnięte, papierki podpisane, uśmiechy wymienione, plecy poklepane.

Ja też jestem podniecony na samą myśl tej dramy. Ale podniecenie może minąć jak mnie ktoś jeszcze kilka razy "zirytuje" i pójdę sobie gdzieś gdzie nie będzie irytacji. Finalnie będziemy próbować wymusić niejako na obu zespołach pewne zachowania. Najpierw jednak pasowałoby wiedzieć co i na kim wymuszać. Stąd mój temat do bardziej doświadczonych, którzy już przerobili takie (podobne) problemy.

2

Trochę nie rozumiem w jaki sposób programiści naklepali skalowanie kiedy w 90% przypadków skaluje się infrastrukturę. Bo co komuś da niby odpalenie kolejnej aplikacji na tej samej maszynie? :D

Moim zdaniem problem wynika od samego początku z organizacji zespołów. Myślałem że raczej standardem są już zespoły przekrojowe, gdzie zespół składa sie np. z kilku devów, testera i admina, tak żeby mogli samodzielnie pracować nad dowolnym zdaniem. Taki podział o jakim mówisz sprawdza sie raczej słabo, chyba ze macie bardzo wysoki poziom automatyzacji devopsowych tasksów -> CI, każdy branch i commit automatycznie się budują i lecą do jakiegoś repozytorium, można jednym klikiem deployować wybrany build na wybranym środowisku, cały czas hulają jakieś automatyczne testy e2e, oraz macie środowiska testowe identyczne z "prodem" na których lecą automatyczne deploye i e2e z mastera.

1

Streszczę co zrozumiałem z opisu:

  • jest aplikacja
  • są dwa zespoły
  • jest jakiś problem

Nie rozumiem w czym jest problem. Nie opisałeś jaki jest cel, który mają osiągnąć obydwa zespoły. Nie ma jasno określonego celu -> nie wiadomo do czego dążyć -> wszystko jedno, gdzie się jest w danej chwili, każdy kierunek jest tak samo dobry/zły.

Trzeba określić:

  1. Cel
  2. Odpowiedzialność zespołów A, B (niektórzy wolą słowo "zakres", bo słysząc coś od odpowiedzialności dostają pianotoku, więc ostrożnie z doborem słów ;) )
  3. Czego potrzebuje zespół A do realizacji celu
  4. Czego potrzebuje zespół B do realizacji celu
  5. Kto będzie koordynował

Co robię w takich przypadkach? Wiadomo, spotkanie (jak inaczej komunikować się efektywniej?).

  • max. 30 min
  • zapraszam liderów zespołów A i B (zaproszenie wszystkich wywoła jakieś dyskusje z d**y)
  • krótkie przedstawienie problemu i oczekiwań
  • planowanie dalszych kroków -> od razu ustawiam spotkanie

(p.s. organizator takiego spotkania staje się naturalnym koordynatorem całego shitu, ale jeśli to jest w Twoim interesie, to może warto ? ).

0
purrll napisał(a):

Po ostatnim spotkaniu i propozycji wpięcia jakiegoś porządnego monitoringu zespół programistyczny stwierdził (cytuję):

Haha! Chcecie tak nas tutaj dokładnie monitorować żeby zrzucać na nas winę?

Nie wiem, ale się domyślam gdzie jest problem. W tej organizacji dwóch niezależnych zespołow to IMO deweloperzy powinni klepać całą infrastrukturę z konsultingiem po stronie infry. Chyba, że wszystko jest na tyle dobrze napisane i trywialne, że ktoś z zewnątrz może to wszystko poskładać, ale z tego co piszesz to raczej tutaj to nie ma miejsca.

3

O kurczę brzmi jakbym czytał jeszcze raz Project Pheonix :) najpierw trzeba to poukładać procesowo na szczeblu liderów i wyższym, potem operacyjnie. Zacząłbym od wypracowania procesu developerskiego - siadacie i wypracowujecie propozycje do przedyskutowania w szerszym gronie, najlepiej na docsie. Musicie określić wzajemne oczekiwania.

Odnośnie podejścia to ustawiłbym wspólne cele dla obu zespołów, tzn. aby całość uznać za done, każdy musi wykonać dobrze swoją robotę. Myśle, ze jakaś turystyka międzyzespołowa tez byłaby Ok.

EDIT. Przypomniało mi się - jak się interesujesz to w Team Topologies jest opisane podejście do zespołów produktowych i infrowych, jaka powinna być relacja między nimi. W skrócie - produkt jest klientem infry na czas określony. Potem powinien się usamodzielnić, np. moc testować i wdrażać bez ich ingerencji. Do tego czasu infra służy usługi na rzecz produktu. To są usługi dla usług.

2

A czy zespół programistyczny/administracyjny dostał jakieś wytyczne do tego? Czy jest tam jakiś PM, który ogania cokolwiek czy pracujecie w metodologi ułańskiej (weźmy i zróbmy)? Moim zdaniem należy zrobić krok w tył (a może nawet dwa): przygotować dokumentację projektową: jakie moduły, co który robi, jak się ze sobą komunikują i dostarczyć to do adminów. Pewnie będą jeszcze potrzebne jakieś wymagania konkretnych modułów - óne bazy, kolejki i inne duperele. Do tego człowiek, który będzie to koordynował (jest to robota PMa albo SM w zależności od metodyki).

1

Żeby nie było, że olałem temat. Zbieram wasz feedback w każdej postaci i staram się pogrupować wszystko aby określić jakiś dalszy plan. I bardzo dziękuję @UglyMan, @Charles_Ray, @yarel, @Shalom, @jarekr000000.

Plusem na pewno jest brak jakiejkolwiek metodyki. Dla was Scrum/Agile guys jest to na pewno szokująca informacja. Natomiast osoba, która mogłaby być tu takim fajnym PM bawi się bycie Tech Leadem i bardziej pracę utrudnia niż ułatwia.

Na ten moment jest bardzo duży problem braku komunikacji. I chaosu ale wstyd mówić jak wygląda komunikacja i dzielenie zadań więc przemilczę :-)

slsy napisał(a):

Nie wiem, ale się domyślam gdzie jest problem. W tej organizacji dwóch niezależnych zespołow to IMO deweloperzy powinni klepać całą infrastrukturę z konsultingiem po stronie infry. Chyba, że wszystko jest na tyle dobrze napisane i trywialne, że ktoś z zewnątrz może to wszystko poskładać, ale z tego co piszesz to raczej tutaj to nie ma miejsca.

Oj na pewno nie. Programiści wyrzeźbili sobie jakiś fajny..."fajny" framework do skalowania swojej aplikacji. Robi wszystko. Kolacja z winem wraz z porannym śniadaniem. Ale jak się dowiedział, że nie będzie skalować Kubernetesem (w uproszczeniu) z poziomu swojej aplikacji to kompletnie do niego to nie docierało i wykłócał się, że jego wspaniały framework będzie to robić.

Natomiast jak poszła kontra, że dostanie 1CPU, 2GB RAM odgórnie przydzielone to będzie sobie mógł skalować tylko zasobami, które dostanie i wtedy chyba nastąpiło lekkie zwarcie w głowie, że coś tutaj jest nie tak. Ale do tego też jakby dojdziemy za jakiś czas :P

2

Mam dwa zespoły i jeden z nich to devops - i już człowiek wie że żadnego devops to tam się nie uskutecznia. Jak czytam Twój opis to właśnie rozwiązaniem na tego typu problemy jest DevOps, ale najpierw trzeba wiedzieć na czym to w ogóle polega. Za to jesteś już na dobrej drodze, zacząłeś diagnozować gdzie coś nie działa tak jak powinno ;]

0
cmd napisał(a):

Mam dwa zespoły i jeden z nich to devops - i już człowiek wie że żadnego devops to tam się nie uskutecznia. Jak czytam Twój opis to właśnie rozwiązaniem na tego typu problemy jest DevOps, ale najpierw trzeba wiedzieć na czym to w ogóle polega ;]

Próbuje się uskuteczniać. Tylko piastowanie tego stanowiska poniekąd nie powoduje, że będziesz mógł to robić. Żeby tak było najpierw ktoś decyzyjny wyżej musi poznać czym tak naprawdę powinna się taka osoba zajmować i jaką rolę pełnić w zespole + jakie są plusy pracy w ten sposób. Tu jest problem.

Jestem jedną z dwóch osób, które wiedzą na czym to polega ;-) Niestety uczenie innych będzie czasochłonne. Powiedzmy, że ludzie tutaj myślą w kontekście aby coś działało na już, a problemami będziemy się martwić później.
Finalnie jest deadline, prezentacja, uściski dłoni ludzi w krawatach, klepanie się po plecach, wymiana uśmiechów iiii...po tym nikt jakby nie wraca do tego co było problemem jeszcze chwilę temu tylko goni dalej. Specyfika miejsca. Dla mnie osobiście może to być fajnym wyzwaniem oraz jakąś lekcją na przyszłość gdzie nie pracować :P dopóki wystarczy mi cierpliwości i nie przyjdę z papierem pewnego pięknego dnia.

2

Próbuje się uskuteczniać. Tylko piastowanie tego stanowiska poniekąd nie powoduje, że będziesz mógł to robić. Żeby tak było najpierw ktoś decyzyjny wyżej musi poznać czym tak naprawdę powinna się taka osoba zajmować i jaką rolę pełnić w zespole + jakie są plusy pracy w ten sposób. Tu jest problem.

I to kolejne potwierdzenie że niestety jeszcze do devopsa u was daleko. To nie jest stanowisko (mimo usilnych starań pań z HRu) i rola jednej czy dwóch osób w zespole, to jest metodyka którą będziesz wdrażał całemu zespołowi :)

1

Nie wiem czy dobrze rozumiem (albo nie znam wszystkich szczegółów), ale mam wrażenie, że mamy tutaj 2 zespoły, które są siłą zmuszone do wzajemnej współpracy. Czy jest w tym całym bagnie ktokolwiek "nad" tymi zespołami, ktokolwiek odpowiedzialny za całokształt wszystkiego? (chyba że to autor wątku, ale to chyba by się nie przyznawał xD)

Jak dla mnie, tu nie chodzi o to że zespoły się nie komunikują, ale że nie chcą się komunikować (bo tak im wygodniej - zupełnie rozumiem) i nikt nie ma władzy aby cokolwiek z tym fantem zrobić.

1 użytkowników online, w tym zalogowanych: 0, gości: 1