Jak poradzić sobie w nowej pracy, gdy wszyscy mnie ignorują?

LukeJL napisał(a):

Znowu przeceniasz rolę programistów, jakby to oni byli pępkiem świata i powinni mieć decydujący wpływ na organizację pracy co jest bzdurą.

Nie muszą, ale jest taki trend wmawiania programistom, że liczy się samoorganizujący się zespół, że scrum masterzy czuwają nad procesem, że jest wielki empowerment, że już zły wilk managementu/biznesu/polityk firmowych nie zaszkodzi programistom przy pracy, bo programiści mają swój proces, swoje sprinty, swoje retro....

I to jest prawda, ale to dotyczy organizowania pracy wewnątrz zespołu, a w to nie wchodzi zwalnianie członków, a tym bardziej PO. bo to jest orgranizacja pracy na wyższym poziomie.

Nie mówię, że demokracja jest lepsza(ani gorsza), ale bardziej uczciwie (tj. bez hipokryzji) byłoby cut the bullshit i wprowadzić ścisłą hierarchię w firmach i ścisły podział obowiązków, tak żeby każdy wiedział co ma robić, a jeśli nie wiedział, co ma robić, to spytałby się przełożonego (albo niekoniecznie przełożonego, a po prostu osoby odpowiedzialnej za coś).

To najlepsza droga do biurokracji i paraliżu pracy.

LukeJL napisał(a):

W pierwszej najpierw jeden typ coś tam niezdarnie może i próbował mnie wprowadzić w temat, ale nijak mu nie szło
(koleś był studentem, najmłodszym w zespole). Najstarszy koleś w zespole miał na temat głęboko wyjechane.

Ktoś musiał przyjmować polecenia od juniora, bo senior miał "głęboko wyjechane".

Władza to też odpowiedzialność, a często się o tym zapomina.

Nie sądzę, żeby retro pomogłoby by w takiej sytuacji, ponieważ to kwestia całej organizacji pracy, która jest zwalona, plus kwestia słabej etyki pracy (czytaj: tumiwisizm).

Zależy od organizacji. W tych dojrzałych kierownicy dostrzegają, że w danym zespole jest jakiś problem, bo jakoś tam mierzą sobie ich efektywność choćby takim burndown-chartem. Mogą wtedy wysłać Agile Coacha na retro i wtedy ta słaba etyka wypływa. Swoją drogą, ten "senior" to może seniorem być nie powinien, bo senior to nie tylko skil czysto techniczny, ale również ktoś kto bierze czynny udział w organizowaniu pracy całego zespołu, wdraża młodszych, wychodzi z inicjatywami, itp. Tam gdzie pracowałem taki tumiwisizm zamykałby mu drogę do awansu.

GutekSan napisał(a):

Oczywiście, że robią. I Ty to pewnie robisz, i ja czasem też. To wynika z różnic w ocenie tego, ile uwagi potrzeba poświęcić danej osobie. Tobie, dajmy na to, wydaje się, że wystarczy że podasz komuś adres strony na Confluence z opisanym procesem, linkami do narzędzi i ewentualnie przez pół godziny opowiesz mu o wewnętrznych praktykach to wystarczy. A ten ktoś potrzebuje by go przez miesiąc prowadzić za rączkę, i jeśli tego nie zrobisz to on będzie się czuł ignorowany.

Gdy ja komuś pomagam, to robię to skutecznie - nie wystarczy, że wytłumaczę, będę co jakiś czas pytał jak mu idzie i czy nie potrzebuje więcej pomocy.
Ignorowanie oznacza celowe niezauważanie, niespełnienie czyichś oczekiwań jest czymś zupełnie innym.

Albo ktoś ignoruje, bo nie dostrzega problemu, bo myśli, że skoro ktoś mu jasno nie nakazał, by nie ignorować

I to jest właśnie patologia - oczekiwanie, że ktoś mi powie, że mam nie ignorować drugiego człowieka. Jeśli ktoś tak robi, to znaczy, że brak mu empatii.

GutekSan napisał(a):

To najlepsza droga do biurokracji i paraliżu pracy.

Najlepsza droga do biurokracji i paraliżu pracy nazywa się Scrum. W praktyce: "najważniejsze są wykresy, nie możemy robić zadań spoza zakresu, idźmy na 3414231 meeting".

GutekSan napisał(a):

Zależy od organizacji. W tych dojrzałych kierownicy dostrzegają, że w danym zespole jest jakiś problem, bo jakoś tam mierzą sobie ich efektywność choćby takim burndown-chartem. Mogą wtedy wysłać Agile Coacha na retro i wtedy ta słaba etyka wypływa.

Zmierzymy wykresem, że ludzie to c**** i wyślemy klowna na pomoc. :)

somekind napisał(a):

Gdy ja komuś pomagam, to robię to skutecznie - nie wystarczy, że wytłumaczę, będę co jakiś czas pytał jak mu idzie i czy nie potrzebuje więcej pomocy.

Nie sprowadzajmy może dyskusji do osobistych postaw, bo wiadomo przecież, że każdy tu jest mistrzem pracowitości, sumienności i empatii ;) Mówmy o postawach, które przeważają. A postawa, która przeważa to taka, która wymaga wkładu minimum energii. Czyli pomagam gdy jestem poproszony w stopniu w jaki wydaje mi się niezbędny do uzyskania efektu. Kluczowe jest tu "wydaje mi się niezbędny", bo w zależności od doświadczenia kryje się pod tym co innego. Stąd właśnie nieporozumienia: komuś wydaje się że pomógł wystarczająco, albo że w danej sytuacji pomoc w ogóle nie jest potrzebna, w końcu od wszystkich wymaga się jakiegoś minimalnego poziomu, a tymczasem druga strona czuje się ignorowana bo wciąż nie wie wszystkiego co by chciała.

Ignorowanie oznacza celowe niezauważanie, niespełnienie czyichś oczekiwań jest czymś zupełnie innym.

Zauważ, że tak naprawdę znamy tylko subiektywną relację autora, więc rozmawiamy o jego odczuciach, a nie o faktach. Dlatego możesz wyłącznie domniemywać czy autor był ignorowany celowo, czy może to wyłącznie jego odczucia, gdy w istocie pomoc otrzymał ale dla niego niewystarczającą.

Albo ktoś ignoruje, bo nie dostrzega problemu, bo myśli, że skoro ktoś mu jasno nie nakazał, by nie ignorować

I to jest właśnie patologia - oczekiwanie, że ktoś mi powie, że mam nie ignorować drugiego człowieka. Jeśli ktoś tak robi, to znaczy, że brak mu empatii.

Albo oznacza, że komuś wyczerpał się limit cierpliwości, albo jest zawalony własnymi zadaniami.
Ignoruje się wtedy, gdy nie jest się pewnym jak postąpić. Członkowie zespołu mogą ignorować fakt, że ich nowy kolega większość czasu snuje się bez celu, albo siedzi na herbacie, albo surfuje po necie, albo prowadzi pogawędki, choć to może wskazywać że nie ma zajęcia. To też jest w zasadzie ignorowanie, ale jest raczej normą niż patologią.

GutekSan napisał(a):

To najlepsza droga do biurokracji i paraliżu pracy.

Najlepsza droga do biurokracji i paraliżu pracy nazywa się Scrum. W praktyce: "najważniejsze są wykresy, nie możemy robić zadań spoza zakresu, idźmy na 3414231 meeting".

Sorry, ale nie najwyraźniej nie rozumiesz na czym polega Scrum. Jeśli taka jest Twoja praktyka jak opisujesz, to znasz go wyłącznie w jakimś patologicznym wydaniu.

GutekSan napisał(a):

Nie sprowadzajmy może dyskusji do osobistych postaw

Dobrze, tylko Ty jakby zacząłeś pisząc: I Ty to pewnie robisz, więc odpisałem jak ja robię.

Kluczowe jest tu "wydaje mi się niezbędny", bo w zależności od doświadczenia kryje się pod tym co innego.

No to ja tu widzę wyłącznie problem doświadczenia (oraz kultury) ludzi.

Dlatego możesz wyłącznie domniemywać czy autor był ignorowany celowo

Ignorowanie z definicji jest celowe. Jeżeli dopuszczamy niecelowe ignorowanie, to ja odpadam z dyskusji, bo nie wiem co miałoby to znaczyć.

Albo oznacza, że komuś wyczerpał się limit cierpliwości, albo jest zawalony własnymi zadaniami.

No i teraz - jeśli nie mam siły komuś pomóc (albo widzę, że moja pomoc jest nieskuteczna), to proszę innego członka zespołu, żeby pomógł tamtej osobie. Jeśli nie mogę pomóc, bo jestem zawalony zadaniami, to idę do przełożonego i mówię: nowy kolega wymaga wdrożenia, mam mu pomóc, czy mam robić swoje zadania. Od razu - nie czekam na żadne profesjonalnie nazwane spotkania.

Sorry, ale nie najwyraźniej nie rozumiesz na czym polega Scrum. Jeśli taka jest Twoja praktyka jak opisujesz, to znasz go wyłącznie w jakimś patologicznym wydaniu.

No cóż, piszę o wydaniu, które przeważa w praktyce.

somekind napisał(a):

Dobrze, tylko Ty jakby zacząłeś pisząc: I Ty to pewnie robisz, więc odpisałem jak ja robię.

To było retoryczne, w sensie: większość tak robi. Zresztą nie jestem przekonany, że nie zdarzało Ci się kogoś zignorować, kto dajmy na to był leniwy, samemu nie szukał rozwiązań, tylko podwieszał się pod innych wykorzystując ich życzliwość.

Kluczowe jest tu "wydaje mi się niezbędny", bo w zależności od doświadczenia kryje się pod tym co innego.

No to ja tu widzę wyłącznie problem doświadczenia (oraz kultury) ludzi.

Dlatego możesz wyłącznie domniemywać czy autor był ignorowany celowo

Ignorowanie z definicji jest celowe. Jeżeli dopuszczamy niecelowe ignorowanie, to ja odpadam z dyskusji, bo nie wiem co miałoby to znaczyć.

No i o tym mówię. Skąd wiesz co w tej całej sytuacji było celowe, a co nie? Bo autor użył określenia "ignorują mnie"? Ale on też pewnie nie wie czy to było celowe czy nie.

No i teraz - jeśli nie mam siły komuś pomóc (albo widzę, że moja pomoc jest nieskuteczna), to proszę innego członka zespołu, żeby pomógł tamtej osobie. Jeśli nie mogę pomóc, bo jestem zawalony zadaniami, to idę do przełożonego i mówię: nowy kolega wymaga wdrożenia, mam mu pomóc, czy mam robić swoje zadania. Od razu - nie czekam na żadne profesjonalnie nazwane spotkania.

Nie każdy zespół ma to szczęście byś był jego członkiem :). Ludzie nie robią tak jak piszesz, bo to zazwyczaj nie jest w ich interesie, bo nie chcą się wychylać, bo myślą że ktoś inny to zrobi. Potrzebują by ktoś wyłożył jasno sprawę i określił ich rolę.

Życie pokazuje, że jak w centrum miasta ktoś będzie leżał nieprzytomny, to ludzi w większości będą go omijać, oglądać z daleka, i mało kto przystąpi do udzielenia pierwszej pomocy. A nawet jak ktoś przystąpi i rzuci w tłum "proszę zadzwonić po pogotowie" to nikt nie zadzwoni, mimo że wszyscy wiedzą, że to konieczne, trzeba wskazać palcem kto ma to zrobić. I to też mógłbyś nazwać patologią, tylko że niestety to właśnie jest norma. A przecież to są sytuacje dużo poważniejsze niż jakieś problemy z wdrożeniem nowej osoby w pracy, tu chodzi o ludzkie życie.

No cóż, piszę o wydaniu, które przeważa w praktyce.

Scrum ma spory potencjał samonaprawczy. Dziwne, że przy Twoim poziomie zaangażowania w pomoc i zdolnościach organizacyjnych nie doprowadziłeś tej praktyki do porządku :)

GutekSan napisał(a):

Zresztą nie jestem przekonany, że nie zdarzało Ci się kogoś zignorować, kto dajmy na to był leniwy, samemu nie szukał rozwiązań, tylko podwieszał się pod innych wykorzystując ich życzliwość.

No cóż, nie przypominam sobie, abym takich ludzi spotykał w pracy.

No i o tym mówię. Skąd wiesz co w tej całej sytuacji było celowe, a co nie? Bo autor użył określenia "ignorują mnie"? Ale on też pewnie nie wie czy to było celowe czy nie.

Nie można niecelowo ignorować, to tak jakby przypadkiem zgwałcić. Jeśli autor użył złego słowa, bo myślał, że znaczy ono coś innego, to znaczy, że cała dyskusja jest bez sensu.

Nie każdy zespół ma to szczęście byś był jego członkiem :). Ludzie nie robią tak jak piszesz, bo to zazwyczaj nie jest w ich interesie, bo nie chcą się wychylać, bo myślą że ktoś inny to zrobi. Potrzebują by ktoś wyłożył jasno sprawę i określił ich rolę.

To raczej ja mam szczęście, że nie muszę pracować z niesamodzielnymi ludźmi.

Scrum ma spory potencjał samonaprawczy. Dziwne, że przy Twoim poziomie zaangażowania w pomoc i zdolnościach organizacyjnych nie doprowadziłeś tej praktyki do porządku :)

Nie dziwne. Jestem programistą, nie akwizytorem ciężkich metodyk. Nie zarabiam na wdrażaniu Scruma, więc hodowanie raka spowalniającego pracę nie leży w moim interesie.

somekind napisał(a):

Scrum ma spory potencjał samonaprawczy. Dziwne, że przy Twoim poziomie zaangażowania w pomoc i zdolnościach organizacyjnych nie doprowadziłeś tej praktyki do porządku :)

Nie dziwne. Jestem programistą, nie akwizytorem ciężkich metodyk.

A ludzie, którym przed chwilą zarzucałeś patologię i brak empatii mogą powiedzieć "jestem programistą, a nie niańką". I Twoja i ich postawa to przejaw tego samego - niechęci do podejmowania działań poprawiających sytuację w zespole zasłaniając się tym, że Twój zawód nie ma takiej roli.

Poza tym to nie jest ciężka metodyka, wręcz przeciwnie - Scrum jest elementem Agile'a a Agile opiera się na Leanie, który z założenia ma być tak lekki jak to możliwe.

Nie zarabiam na wdrażaniu Scruma, więc hodowanie raka spowalniającego pracę nie leży w moim interesie.

Nie sugeruję byś hodował raka, tylko go leczył.

GutekSan napisał(a):

A ludzie, którym przed chwilą zarzucałeś patologię i brak empatii mogą powiedzieć "jestem programistą, a nie niańką". I Twoja i ich postawa to przejaw tego samego - niechęci do podejmowania działań poprawiających sytuację w zespole zasłaniając się tym, że Twój zawód nie ma takiej roli.

Nie, to zupełnie coś innego. Scrum nie jest konieczny do pracy zespołu, można poprawiać sytuację zespołu bez trzymania się biurokratycznej religii.

Poza tym to nie jest ciężka metodyka, wręcz przeciwnie - Scrum jest elementem Agile'a

Założenia założeniami, a w praktyce Scrum jako metodologia zorientowana na plany, wykresy, procesy i dokumentację łamie wszystkie 4 założenia Agile Manifesto.

somekind napisał(a):

GutekSan napisał(a):

A ludzie, którym przed chwilą zarzucałeś patologię i brak empatii mogą powiedzieć "jestem programistą, a nie niańką". I Twoja i ich postawa to przejaw tego samego - niechęci do podejmowania działań poprawiających sytuację w zespole zasłaniając się tym, że Twój zawód nie ma takiej roli.

Nie, to zupełnie coś innego. Scrum nie jest konieczny do pracy zespołu, można poprawiać sytuację zespołu bez trzymania się biurokratycznej religii.

Założenia założeniami, a w praktyce Scrum jako metodologia zorientowana na plany, wykresy, procesy i dokumentację łamie wszystkie 4 założenia Agile Manifesto.

Cały czas pokazujesz, że nie masz pojęcia czym jest Scrum, nie widziałeś nigdy dobrego Scruma i na tej podstawie budujesz sobie obraz.

@GutekSan: Widzę, że powoli idziemy w kierunku wojny, która miała miejsce w wątku "dlaczego OOP ssie". Może masz jakieś doświadczenia ze scrumem, ale niefajne jest to, że jeśli ktoś podważa jego sens, to Ty wyskakujesz z tekstem, że po prostu go nie zna/nie umie wykorzystać. Tak samo jak w podanym wątku o OOP - jak ktoś powiedział, że OOP nie jest fajne/nie nadaje się, to zamiast merytorycznie ocenić jego pogląd, od razu dostawał odpowiedzi "skoro krytykujesz OOP to znaczy, że nie umiesz programować".

A poza tym @somekind ma rację - niezależnie od tego, czy scrum jest fajny czy ble, nie jest jedyną możliwą i poprawną ideą. Większość z opisanych w tym wątku "patologii" można by było rozwiązać bez scrumowania - po prostu więcej życzliwości ze strony starszych kolegów, więcej asertywności ze strony świeżaka, a przede wszystkim kierownik/przełożony/team leader/project manager (nazwijmy go jakkolwiek - chodzi o osobę, która jest "nad" programistami) który ogarnia temat, ma jakieś pojęcie o tym, co się dzieje w zespole oraz umie sensownie rozdzielić zadania i pilnować tego, co robią jego podwładni. Można to rozwiązać w taki sposób, w jaki się koordynuje pracę w jakiejkolwiek innej branży, gdzie pracują zespoły. Przecież tak naprawdę to opisana na początku wątku sytuacja mogła równie dobrze mieć miejsce w jakimś urzędzie, w dziale księgowym albo na budowie. Tam się raczej scrumów nie stosuje - a mimo tego jakoś zespoły pracowników działają i sobie na ogół radzą.

Poza tym to nie jest ciężka metodyka, wręcz przeciwnie - Scrum jest elementem Agile'a a Agile opiera się na Leanie, który z założenia ma być tak lekki jak to możliwe.

Jak dla mnie Scrum, Agile, Lean to 3 zupełnie różne bajki, zupełnie inne filozofie (nawet jeśli można znaleźć w jakichś punktach pewne punkty podobne).

cerrato napisał(a):

@GutekSan: Widzę, że powoli idziemy w kierunku wojny, która miała miejsce w wątku "dlaczego OOP ssie". Może masz jakieś doświadczenia ze scrumem, ale niefajne jest to, że jeśli ktoś podważa jego sens, to Ty wyskakujesz z tekstem, że po prostu go nie zna/nie umie wykorzystać.

Tylko przemyśl co tą wojnę wywołuje. Ja zacząłem od pozytywnej uwagi - wskazałem, że opisany problem można naprawić elementem Scruma, czyli retrospektywą. Wiem, że jest na to szansa, bo mam takie doświadczenia, że to pomagało. Natomiast w odpowiedzi dostaję niepoparte niczym malkontenctwo, pisanie o "cyrkach", "klaunach", "patologii". Uważasz, że to jest rzeczowy głos w dyskusji? Jeśli ktoś próbuje mi wykazać, że coś nie może działać, jeśli ja widziałem, że to działa, to przykro mi, ale pokazuje ignorancję w temacie.

A poza tym @somekind ma rację - niezależnie od tego, czy scrum jest fajny czy ble, nie jest jedyną możliwą i poprawną ideą. Większość z opisanych w tym wątku "patologii" można by było rozwiązać bez scrumowania -

oczywiście. I ja nigdzie nie stwierdziłem, że korzystanie ze Scruma jest konieczne i że to jedyna słuszna metoda. Wskazałem tylko przyczyny pewnych sytuacji, do których może zaliczać się tu opisana, i to że Scrum pozwala takim sytuacjom przeciwdziałać Ale jeśli ktoś ma parcie na konflikt, to będzie robił fałszywe założenia co do przedmiotu dyskusji, dopatrywał się doktrynerstwa, a potem radośnie z nim walczył.

Przecież tak naprawdę to opisana na początku wątku sytuacja mogła równie dobrze mieć miejsce w jakimś urzędzie, w dziale księgowym albo na budowie. A tam się raczej scrumów nie stosuje - a mimo tego jakoś zespoły pracowników działają i sobie na ogół radzą.

Zawsze wydawało mi się, że większość ludzi narzeka na opieszałość urzędów i panujący tam bałagan i biurokrację, więc może właśnie scrum by tam pomógł :)

Moze zamiast sie klocic o metodyki, postarajmy sie podsumowac ten watek jakas checklista, jak (idealnie) powinna zachowac sie nowa osoba w zespole a jak zespol, zeby integracja i wdrozenie przebieglo szybko, sprawnie i z maksymalnie ograniczonymi utrudnieniami dla calego zespolu?

To jest jak flowchart z komunizmem, że jak nie wypalił to to "nie był prawdziwy komunizm" i należy próbować kolejny raz. Analogicznie niektórzy traktują scrum/agile. Jeśli nie działa to "nie jest prawdziwy Scrum" :D A prawda jest taka że dziala tylko http://programming-motherfucker.com/ ;)

W ofertach pracy widnieje checklista, a niej kwiatek "Metodologia Agile ― Scrum". Jak można dyskutować o Scrumie na forum, gdzie nikomu nie przeszkadza stwierdzenie, że agile to "Metodologia"? :)

[GutekSan napisał(a)]:

Zależy od organizacji. W tych dojrzałych kierownicy dostrzegają, że w danym zespole jest jakiś problem, bo jakoś tam mierzą sobie ich efektywność choćby takim burndown-chartem. Mogą wtedy wysłać Agile Coacha na retro i wtedy ta słaba etyka wypływa

Nie wiem jak się definiuje "dojrzałą organizację", ale doświadczenie nauczyło mnie, że "kierowników" najczęściej interesuje "średni" wynik pracy ludzi w zespole / projekcie.
Kwestia też tego jak uwagi z retrospektywy są wdrażane (i czy np. uwagi dotyczące "miękkich" (nie związanych nijak z procesem) spraw w ogóle są brane pod uwagę)

[GutekSan napisał(a)]:

Swoją drogą, ten "senior" to może seniorem być nie powinien, bo senior to nie tylko skil czysto techniczny, ale również ktoś kto bierze czynny udział w organizowaniu pracy całego zespołu, wdraża młodszych, wychodzi z inicjatywami, itp. Tam gdzie pracowałem taki tumiwisizm zamykałby mu drogę do awansu.

No niestety nie wszędzie to tak działa i często ludzie dostają awans za zasiedzenie / wiedzę nawet gdy są zupełnie aspołecznymi jednostkami.
A potem w firmie jest grono seniorów, które najlepiej pracuje samo ze sobą z słuchawkami na uszach, a świeżaki to "niech se wezmą łannołta, poczytają i się ogarną".
Widziałem w życiu z "seniorów" którzy chyba czerpali frajdę z opierdzielania przy wszystkich juniora za to, że nie ogarnia czegoś, co dla nich jest "oczywiste". Albo takich którzy mówili w kuluarach wprost że nauczanie podstaw juniora to jest totalna obelga i poniżej ich godności.

IMHO to wszystko kwestia dobrej woli ludzi.
Projektu który jest totalnie niezgrany i w którym jest podział na zamknięte grupki się raczej nie naprawi. Takie rzeczy to często po prostu kwestia ludzi, a ludzi zmienić nie jest łatwo (i raczej nie specjalizują się w tym pracodawcy - dla nich ważne jest mieć wynik, a ludzi w razie czego sobie można za odpowiednią stawkę wymienić, bo na rynku nieco ich jest).

Niestety czasem najlepsze rozwiązanie to zmienić projekt / pracodawcę zamiast psuć sobie nerwy i robić za piąte koło u wozu..

GutekSan napisał(a):

Cały czas pokazujesz, że nie masz pojęcia czym jest Scrum, nie widziałeś nigdy dobrego Scruma i na tej podstawie budujesz sobie obraz.

Masz rację, nigdy nie widziałem "dobrego Scruma", bo buzzwordy generalnie nie są dobre. Za to rozmawiałem z dziesiątkami programistów zamęczanymi tym "frameworkiem", zmuszanymi do uczestniczenia w bezsensownych spotkaniach, codziennego spowiadania się nawet gdy to nie ma sensu, estymacji przy użyciu kart, pilnowania głupich wykresów i retrospektyw, na których bohatersko walczy się z problemami wywołanymi przez Scruma i żadnymi innymi.

"Individuals and interactions over processes and tools" - wiesz skąd to cytat? Bo Scrum w praktyce to ślepe podążanie za narzędziami i procesami.

GutekSan napisał(a):

I ja nigdzie nie stwierdziłem, że korzystanie ze Scruma jest konieczne i że to jedyna słuszna metoda.

Nie? Bo napisałeś to w takim tonie, jakby to było jedyne remedium, bez użycia jakiegokolwiek wyliczenia albo trybu warunkowego:

I właśnie żeby przeciwdziałać takim problemom wymyślono daily stand-up i retrospektywę.

Nieważne na czym faktycznie polega problem i jaką ma naprawdę przyczynę, ale Scrum został wymyślony, żeby właśnie takie problemy naprawiać. No cóż, zero doktrynerstwa tutaj.

Zawsze wydawało mi się, że większość ludzi narzeka na opieszałość urzędów i panujący tam bałagan i biurokrację, więc może właśnie scrum by tam pomógł :)

I tu także.

latami pracowalam w korpo-scrumie i nauczylam sie go naginac zeby bylo po mojemu.

obecnie mam jedno polgodzinne spotkanie z teamem tygodniowo, aby ustalic kiedy nastepny release i co do niego wejdzie. wszystko inne jest ad hoc, ktos cos chce to podchodzi do mojego biurka, pisze na czacie albo zaklada jire.
byl w teamie jeden duren co chcial zebysmy byli bardziej agile i robili scrum (bo w poprzedniej firmie byl scrum masterem) i nawet pisal maile do "wyzszych instancji" o benefitach.
na szczescie nasz dyrektor/tech lead zalatwil to bardzo profesjonalnie, poszedl na kilkudniowe szkolenie ze scruma, zrobil jakis certyfikat i oficjalnie potwierdzil do swoich zwierzchnikow ze juz mamy scruma w teamie i ze zawsze mielismy wiec nie ma potrzeby na dodatkowe zmiany ;)

somekind napisał(a):

Masz rację, nigdy nie widziałem "dobrego Scruma", bo buzzwordy generalnie nie są dobre. Za to rozmawiałem z dziesiątkami programistów zamęczanymi tym "frameworkiem", zmuszanymi do uczestniczenia w bezsensownych spotkaniach, codziennego spowiadania się nawet gdy to nie ma sensu, estymacji przy użyciu kart, pilnowania głupich wykresów i retrospektyw, na których bohatersko walczy się z problemami wywołanymi przez Scruma i żadnymi innymi.

A ja widziałem dziesiątki dzieci zmuszanych do mycia rączek i ząbków, nawet jesli wg nich były czyste. Tylko, że dzieci mogą nie rozumieć pojęcia higieny, a dorośli programiści już powinni.

Scrum zaczęto wprowadzać masowo dopiero parę lat temu, nic dziwnego, że niektórzy traktowali go na początku jak nową zabawkę, robiąc wszystko wg książek. To się zmienia, dociera, zespoły same ustalają sobie jak głęboko chcą w to wchodzić, w zależności od potrzeb. Jedni mają retro co sprint, inni co 3, a inni co release produktu. Jak wszystkim pasuje, good for them. Trzeba rozumieć, że ta swoboda istnieje, a Scrum oferuje po prostu narzędzia pomagające w utrzymaniu higieny w projekcie. W zespołach dojrzałych, mających doświadczonych i zgranych ze sobą pracowników pewnie takie narzędzia są zbędne, ale już w zespołach o dużej rotacji czy niskiej motywacji ten rytuał standupów i retrospektyw to właśnie taka higiena projektowa zapobiegająca budowaniu się większych problemów.

I właśnie żeby przeciwdziałać takim problemom wymyślono daily stand-up i retrospektywę.

Nieważne na czym faktycznie polega problem i jaką ma naprawdę przyczynę, ale Scrum został wymyślony, żeby właśnie takie problemy naprawiać. No cóż, zero doktrynerstwa tutaj.

Owszem. Bo scrum sam w sobie to nie jest magiczne lekarstwo tylko raczej platforma diagnostyczna. Retro pomaga przede wszystkim zidentyfikować, że problem istnieje i daje czas na zastanowienie sie wlasnie nad jego przyczynami i wlasciwymi lekarstwami.

Retro pomaga przede wszystkim zidentyfikować, że problem istnieje i daje czas na zastanowienie sie wlasnie nad jego przyczynami i wlasciwymi lekarstwami

Tylko tak naprawdę od wielu dziesiątek lat (nie tylko w branży IT) za to odpowiadał dobry szef / przełożony - miał mieć ogląd całości, nadzorować pracę zespołu, rozdzielać obowiązki oraz rozwiązywać powstające konflikty. Stosując to do niniejszego wątku - wcale nie trzeba scrumować, po prostu "świeżak" powinien pójść do swojego kierownika / szefa / project managera i powiedzieć o problemach (chociaż naprawdę dobry szef powinien to już sam zauważyć znacznie wcześniej). Scrum - może być, ale większość z problemów można doskonale rozwinąć bez niego, nie tworząc jednocześnie tej całej "sekciarskiej otoczki" - jak wiele osób to odbiera.

cerrato napisał(a):

Retro pomaga przede wszystkim zidentyfikować, że problem istnieje i daje czas na zastanowienie sie wlasnie nad jego przyczynami i wlasciwymi lekarstwami

Tylko tak naprawdę od wielu dziesiątek lat (nie tylko w branży IT) za to odpowiadał dobry szef / przełożony - miał mieć ogląd całości, nadzorować pracę zespołu, rozdzielać obowiązki oraz rozwiązywać powstające konflikty. Stosując to do niniejszego wątku - wcale nie trzeba scrumować, po prostu "świeżak" powinien pójść do swojego kierownika / szefa / project managera i powiedzieć o problemach (chociaż naprawdę dobry szef powinien to już sam zauważyć znacznie wcześniej). Scrum - może być, ale większość z problemów można doskonale rozwinąć bez niego, nie tworząc jednocześnie tej całej "sekciarskiej otoczki" - jak wiele osób to odbiera.

"Pójście do szefa" zawsze miało posmak donosicielstwa, czy chociaż nielojalności wobec kolegów. Ktoś stwierdził, ze może lepiej pozwolić zespołowi pozałatwiać część problemów we własnym gronie, a z pójściem do szefa zawsze można zdążyć.

"Pójście do szefa" zawsze miało posmak donosicielstwa, czy chociaż nielojalności wobec kolegów

To czy jak w szkole starsze dzieciaki wyżywają się na młodszych, to pójście do nauczycielki też jest kapusiowaniem?
Poza tym o ile pamiętam, autor wątku pisał, że prosił o wsparcie czy przydzielenie mu zadań, ale (mówiąc wprost) - został olany. Więc nie powinieneś oceniać go źle - jako donosiciela, jednocześnie nie zastanawiając się ani nie krytykując pozostałych członków ekipy, którzy niczego nie robią, żeby pomóc nowemu się wdrożyć.

Poza tym - znowu dochodzimy do tego, o czym pisałem wiele razy - czyli o dobrym zarządzaniu. Dobry szef powinien powiedzieć coś w stylu "Krzysiek - tutaj masz świeżaka, proszę go wrdożyć w to, co robimy. Świeżaku - jeśli masz jakieś problemy albo pytania - wal śmiało do Krzyśka, on ma Ci pomóc". Szef mógł jeszcze dodać coś w stylu "Świeżaku - na razie masz do zrobienia XXX, zrób to w technologii YYY, podczas pracy pomoże Ci Stefan". I wszystko w temacie. A jeśli okaże się, że Krzysiek i Stefan mają wylane na świeżaka, to znaczy że oni są winni a nie świeżak.

Zresztą jeśli ktoś próbuje się dogadać z zespołem, ale trafia na ścianę, to chyba naturalne jest pogadanie z kimś wyżej i nie widzę w tym niczego złego. Czym innym jest skarżenie, że Krzysiek przez pół godziny zamiast pracować to siedział na Fejsbuku, a czym innym poinformowanie, że w wyniku braku pomocy ze strony kolegów jest się totalnie nieprzydatnym.

GutekSan napisał(a):

A ja widziałem dziesiątki dzieci zmuszanych do mycia rączek i ząbków, nawet jesli wg nich były czyste. Tylko, że dzieci mogą nie rozumieć pojęcia higieny, a dorośli programiści już powinni.

Czyli jednak Scrum jest konieczny i niezbędny do życia, bez niego po prostu się nie da.

Scrum zaczęto wprowadzać masowo dopiero parę lat temu

Ja z kolei mam inne spostrzeżenia - parę lat temu niektóre firmy zaczęły się opamiętywać i odchodzić od tego czegoś. Na początek zwalniając scrum masterów i agile coachów, potem przestając udawać, że "subtle controll" to nie kontrola i normalnie strukturyzując i delegując odpowiedzialności. A potem pozwalając dorosłym ludziom pracować i sobie pracę organizować.

W zespołach dojrzałych, mających doświadczonych i zgranych ze sobą pracowników pewnie takie narzędzia są zbędne, ale już w zespołach o dużej rotacji czy niskiej motywacji ten rytuał standupów i retrospektyw to właśnie taka higiena projektowa zapobiegająca budowaniu się większych problemów.

Tu się zgodzę, w sensie nie mam jak zaprzeczyć, że Scrum to dobre rozwiązanie dla zespołów złożonych z początkujących i niesamodzielnych ludzi.
Ale da się pracować zarówno bez Scruma jak i bez niesamodzielnych ludzi.

Owszem. Bo scrum sam w sobie to nie jest magiczne lekarstwo

Czyżby? A wiesz, że sprawiasz wrażenie jakbyś tak właśnie próbował go tutaj sprzedawać.

@Trzeźwy Lew:

Widziałem w życiu z "seniorów" [...] którzy mówili w kuluarach wprost że nauczanie podstaw juniora to jest totalna obelga i poniżej ich godności.

Może nie jest to chlubna postawa, ale trochę prawdy w tym jest - o ile taki senior to rzeczywiście ekspert w swojej dziedzinie to parowanie go z juniorem nie jest dobre dla żadnej ze stron. Ekspert myśli na zupełnie innym poziomie abstrakcji, bardzo intuicyjnie, ciężko mu przekazywać wiedzę juniorowi, który potrzebuje ścisłych instrukcji.

Tutaj ogólnie o modelu braci Dreyfus: https://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas
Tutaj o dobieraniu ludzi:

[Maciej Cąderek napisał(a)]:

@Trzeźwy Lew:

Widziałem w życiu z "seniorów" [...] którzy mówili w kuluarach wprost że nauczanie podstaw juniora to jest totalna obelga i poniżej ich godności.

Może nie jest to chlubna postawa, ale trochę prawdy w tym jest - o ile taki senior to rzeczywiście ekspert w swojej dziedzinie to parowanie go z juniorem nie jest dobre dla żadnej ze stron. Ekspert myśli na zupełnie innym poziomie abstrakcji, bardzo intuicyjnie, ciężko mu przekazywać wiedzę juniorowi, który potrzebuje ścisłych instrukcji.

Z jednej strony masz rację. Sam wiem, jak to jest próbować wytłumaczyć nowicjuszowi tok rozumowania "na skróty" np. przy szukaniu buga w jakimś skomplikowanym projekcie...
Ale jeśli z projektu uciekają ludzie z poziomem mid (totalna rotacja), a nabór dostarcza w większej części "świeżaków", to chcąc nie chcąc ktoś im tą wiedzę przekazać musi. Ot potrzeba chwili.
Jeśli nie przekaże jej senior, to nowicjusze po prostu utkną w bzdurach i ich produktywność będzie marna. Bus factor spada, a projekt ktoś musi utrzymywać.
Jeśli wiedza nie zostanie przekazana, to w projekcie prędzej, bądź później nastąpi jakiś kryzys / fakap.

Dla mnie osobiście senior to ktoś, kto potrafi opakować ciężki temat tak, by chociaż na poziomie abstrakcji był możliwy do przełknięcia dla osoby posiadającej jedynie podstawy.
Przekazywanie wiedzy to jest jednak sztuka. I to jeden ze wskaźników, które dla mnie osobiście odróżniają "prawidzwego seniora" od "seniora z zasiedzenia"

a...
Ciekawe linki :)