Zostań Scrum Masterem

12

Na programowanie trwa mega hype, każdy chce zostać programistą. Tymczasem, od stycznia pracuje u nas koleżanka, która była nauczycielem biologii, a 18 miesięcy temu zaczęła pierwszą pracę jako Scrum Master. O Scrumie nie ma pojęcia, po angielsku ledwo mówi, w sumie to tylko przytakuje managerowi, technologicznie zero, ma problemy z logowaniem się do systemów. I co? I dzisiaj na spotkaniu zminimalizowała sobie przeglądarkę, pod nią był pasek wypłaty, a na nim 14400 brutto. No nic tylko rzucić wszystko i brać się za taką robotę, ja tyle dostałem po 5 latach pracy, ale jak widać źle wybrałem.

TL;DR - zostań scrum masterem, nie programistą.

2

Może jest też księgową, a wypłata dotyczyła kogoś innego. Skąd pewność, że to były jej miesięczne zarobki?

3
Pyxis napisał(a):

Może jest też księgową, a wypłata dotyczyła kogoś innego. Skąd pewność, że to były jej miesięczne zarobki?

Słyszałem, ile potrafią zarabiać scrum masterzy i tym podobni w niektórych firmach i jestem w stanie w to uwierzyć :P

W niektórych przypadkach dwójka z przodu i wcale nie oznacza to okolic minimalnej krajowej.

0
zarejestrowany_troll napisał(a):

Na programowanie trwa mega hype, każdy chce zostać programistą. Tymczasem, od stycznia pracuje u nas koleżanka, która była nauczycielem biologii, a 18 miesięcy temu zaczęła pierwszą pracę jako Scrum Master. O Scrumie nie ma pojęcia, po angielsku ledwo mówi, w sumie to tylko przytakuje managerowi, technologicznie zero, ma problemy z logowaniem się do systemów. I co? I dzisiaj na spotkaniu zminimalizowała sobie przeglądarkę, pod nią był pasek wypłaty, a na nim 14400 brutto. No nic tylko rzucić wszystko i brać się za taką robotę, ja tyle dostałem po 5 latach pracy, ale jak widać źle wybrałem.

TL;DR - zostań scrum masterem, nie programistą.

skoro nie ma o scrumie pojęcia, jakim cudem może pracować jako scrum master?

6
zarejestrowany_troll napisał(a):

Na programowanie trwa mega hype, każdy chce zostać programistą. Tymczasem, od stycznia pracuje u nas koleżanka, która była nauczycielem biologii, a 18 miesięcy temu zaczęła pierwszą pracę jako Scrum Master. O Scrumie nie ma pojęcia, po angielsku ledwo mówi, w sumie to tylko przytakuje managerowi, technologicznie zero, ma problemy z logowaniem się do systemów. I co? I dzisiaj na spotkaniu zminimalizowała sobie przeglądarkę, pod nią był pasek wypłaty, a na nim 14400 brutto. No nic tylko rzucić wszystko i brać się za taką robotę, ja tyle dostałem po 5 latach pracy, ale jak widać źle wybrałem.

TL;DR - zostań scrum masterem, nie programistą.

Usiądź do Scruma na 2-3 miesiące. Pokaż na forum publicznym jej brak kompetencji w takim razie i szybko skończy się ta niespełniona kariera.

4

co robi taka ScrumMasterka? Rozlicza programistow z kazdej godziny, kaze im pisac sprawozdania, organizuje spotkania i robi wszystko, zeby nie pozwolic im pracowac? Fajnie macie

7

Tymczasem, od stycznia pracuje u nas koleżanka, która była nauczycielem biologii, a 18 miesięcy temu zaczęła pierwszą pracę jako Scrum Master. O Scrumie nie ma pojęcia, po angielsku ledwo mówi, w sumie to tylko przytakuje managerowi, technologicznie zero, ma problemy z logowaniem się do systemów

Ale czy ona coś robi poza przytakiwaniem menedżerowi? Jeśli nic nie robi, a tylko dostaje kasę za nic, to... co cię w zasadzie to interesuje? :D Nie twoja kasa.

Dużo gorzej, jeśli taka niekompetentna osoba faktycznie próbuje coś robić. Wtedy jest to niebezpieczne, bo cały projekt jest narażony i spowalniany przez takiego sabotażystę.

Trochę jak z posłami. Nie byłoby w tym jeszcze tragedii, gdyby posłowie brali kasę i nic nie robili, tylko np. pili wódkę. Gorzej, że faktycznie biorą się do pracy i sabotują Polskę za każdym głosowaniem.

16

Praca uwłaczająca godności to chociaż rekomensata finansowa musi być.
Za mniej chyba mało kto by się zgodził.

Nie wiesz jak to jest być ZEREM, jeśliś nie był scrum masterem

3

nic nowego, zycie nie jest sprawiedliwe i jesli oczekujesz sprawiedliwosci i rownego traktowania to oszalajesz

3
lambdadziara napisał(a):

co robi taka ScrumMasterka? Rozlicza programistow z kazdej godziny, kaze im pisac sprawozdania, organizuje spotkania i robi wszystko, zeby nie pozwolic im pracowac? Fajnie macie

Podbijam. Czy to jest praca na pełen etat? Co robi taka przez cały dzień, oprócz review, retro?

7
Adam Boduch napisał(a):

Podbijam. Czy to jest praca na pełen etat? Co robi taka przez cały dzień, oprócz review, retro?

Raz lub dwa spytaliśmy naszego Bardzo Dzielnego Scrum Mastera (w skrócie BDSM), na czym taka praca polega.

Wychodzi na to, że teoretycznie jego rola ma polegać na tym, by zespoły scrumowe nauczyły się samodzielnie pracować w scrumie. Czyli w sumie jego celem jest przestać być potrzebnym - cel trochę autodestrukcyjny, jak by nie patrzeć, i może dlatego scrum tak często przemienia się w jakiś dziwny turbo-pier**lnik, na który potem narzeka @jarekr000000 - w końcu jaki interes ma mieć Scrum Master w stawaniu się niepotrzebnym? ;)

A w praktyce - tacy Scrum Masterzy przypominają zespołom, że pora zrobić standup, uciszają programistów, którzy za bardzo wchodzą w szczegóły techniczne zamiast pokrótce zrelacjonować stan d**y co aktualnie robią / planują robić. Na jakichś planningach czy innym estymowaniu też często moderują spotkanie, żeby zakończyło się w sensownym czasie i przyniosło cokolwiek. Ogólnie spotkania to dość znaczący ułamek czasu pracy SM - nawet, jeśli nie ma akurat spotkań z zespołami, to zawsze znajdzie się jakieś scrumowo-edżajlowe spotkanko z innymi SM :)

Ale SM są też generalnie mniej zamknięci w sobie od typowego developera i czasem to się przydaje - jak np. raz mieliśmy za sąsiadów w open space jakąś małpiarnę, która robiła niesamowity hałas od rana do nocy (pomagała im w tym tzw. "szczekaczka" oznajmiająca co 15 min. czy ich buildy przechodzą przy akompaniamencie przydługich sucharów), a podczas swojego stanu d**y stand-upu uwalała się na nasze biurka, drąc nam się nad uszami, to w końcu właśnie BDSM poszedł ich ochrzanić, bo my się krępowaliśmy iść we trzech upominać 30 chłopa - nie bez powodu jest Bardzo Dzielny :D

A tak na boku, to ponoć sporo SM (może nawet większość) zostaje SM głównie po to, by dość szybko katapultować się na stanowiska managerskie ;)

1
Adam Boduch napisał(a):
lambdadziara napisał(a):

co robi taka ScrumMasterka? Rozlicza programistow z kazdej godziny, kaze im pisac sprawozdania, organizuje spotkania i robi wszystko, zeby nie pozwolic im pracowac? Fajnie macie

Podbijam. Czy to jest praca na pełen etat? Co robi taka przez cały dzień, oprócz review, retro?

W skrócie to taki KO-wiec, tylko zamiast statku wycieczkowego jest zaciemnione biuro i ludzie którym nie przeszkadza geometria.

Facet na kursie podsumował tę rolę tak, że jeśli SM jest bardzo dobry i wykonał swoją robotę dobrze, to gdy jest na urlopie nikt nie zauważa że jego nie ma.

2

Ostatnio scrum master zapytał u mnie w zespole czy chcemy retro. Wszyscy się tylko popatrzyli po sobie i cisza... Rolę sm odczytuje jako osobę, która organizuje spotkania z byle powodu, żeby nabić dupo godziny... i tak się robi w tym korpo.

3

Silicon Valley jak zawsze w punkt ;)

4

Ale ból d**y w tych postach. Brzmi jakby was bolało, że ktoś może dostawać tyle co dev nie będąc devem. Ogarnięty scrum master ogarnia na raz 3 teamy. Praca ma polegać w dużym skrócie na tym, żeby to właśnie programiści nie musieli siedzieć na durnych spotkaniach. Jego rola to m.in. odsiewanie szumu od teamu. Być może nie mieliście nigdy styczności ze SM, który wie co powinien robić.

9
WyjmijKija napisał(a):

Ale ból d**y w tych postach. Brzmi jakby was bolało, że ktoś może dostawać tyle co dev nie będąc devem. Ogarnięty scrum master ogarnia na raz 3 teamy. Praca ma polegać w dużym skrócie na tym, żeby to właśnie programiści nie musieli siedzieć na durnych spotkaniach. Jego rola to m.in. odsiewanie szumu od teamu. Być może nie mieliście nigdy styczności ze SM, który wie co powinien robić.

Ludzi boli zazwyczaj brak kompetencji, wpieprzanie się w ich robotę, przeszkadzanie w codziennej pracy i to, że ktoś udając, że coś robi uprzykrza życie innym. Zakładam, że kilka/naście lat temu ludzie niekompetentni wprowadzili więcej ludzi niekompetentnych. Dzięki temu dzisiaj w typowej korporacji 70% ludzi pracujących utrudnia pracę pozostałym 30% swoimi durnymi pomysłami, spotkaniami, stand-upami i innymi zabierającymi czas, nikomu niepotrzebnymi debilizmami.
A w przypadku gdy przychodzi jakaś larwa, która uczyła dzieci Biologii i jest wielkim SM no to sorry typie :-) Nie tędy droga.

1

U mnie w firmie scrum master to po prostu programista z dodatkowymi odpowiedzialnościami, zazwyczaj są to team leaderzy.

5

W wielu firmach są parytety więc gdzieś trzeba kobiety upchać, stąd wiele stanowisk z powietrza.

1

scrum masterke pamietam bo tym ze chodzila z lapkiem po firmie a na retro gralismy w jakies gry lub opowiadalismy dobre/zle cechy kolegów ktorzy siedzieli obok

1

Może ona podglądała twoją wypłatę :D
W NBP panie bez kompetencji też zarabiają krocie ;)

8

Scrum Master to ważna postać w prawdziwym scrumie. Scrum Master jest rolą z natury konfliktową. Ma za zadanie wiedzieć jakie w SP ma moce zespół na dany sprint. Powinien pilnować, poprawnych wycen (bo zespół powinien wyceniać na planning poker, a jak całe grono strzeli np. 12 SP, a jakiś junior 2SP, to nie zlewamy go, ale dochodzimy dlaczego etc. ). Na planowaniu powinien wcisnąć maksymalnie zadań na sprint, na dayli powinien monitorować, czy team spala zadania (SP) zgodnie z planem, i czy przy obecnej prędkości spalania wyrobi się do koca sprintu do zera (analiza burndown), czy cel sprintu nie jest zagrożony, czy jakiś programista nad zadaniem 2SP nie spędza już 3 dnia - jeśli tak, to trzeba zorganizować mu pomoc, burzę mózgów.
Jednak także działa w celu rozwiązania problemów - nie mogę zrobić zadania x bo nie mam dostępu do serwa y a dział z nie chce mi dać - to SM mówi "spoko spoko, klep część zadania w kodzie co tam musisz, a ja pogadam i załatwię dostęp". Jak ktoś powie - "EE nie kompiluje mi się bo nie mam licencji na jakieś liby - to SM działa, by to rozwiązać. Jak jest zaplanowany sprint i trwa, gdy ktoś wpadnie, że kurde taki i taki ficzer potrzebny, że trzeba zmienić etc. to SM wali go w mordę, potem słucha i zastanawia się, czy można jakieś zadanie wyciągnąć ( nie burząc celu sprintu) i wsadzić coś dodatkowego, czy to może poczekać etc. ew. konsultuje się z PO. Jeśli PO stwierdza, że należy to dokoptować do sprintu to SM mówi - hola hola! Sprint nie jest z gumy - skoro te nowe 20SP robimy teraz to co wyciągamy ze sprintu ?! Pilnuje PO, żeby historyjki miały sens, były dobrze opisane i żeby na wycenach nie było zastanawiania się o co chodzi w tym tasku.
SM generalnie ma dbać o sprint, proces, scrum, żeby się toczył i żadna strona nie naginała zasad, dlatego jest zawsze troszkę w konflikcie między zespołem, ale także w konflikcie z PO, ale też im pomaga. To rola trudna. Dlatego, że największy konflikt jest z PO (PO chce jak najwięcej, najwcześniej, a SM broni Team, żeby robili tyle ile jest mocy i to w jakości jaką zakładają - pilnowanie kontraktu scrumowego), to rola PO nie może łączyć się z SM co często jest błędem w pseudo scrumach. Często jeden mniej introwertyczny programista przyjmuje tą role, ofc. ze świadomością, że jego produktywność w kodowaniu spadnie. Czasami jeden SM opędzluje kilka zespołów.
Ludzie twierdzący, że SM jest niepotrzebny, to albo mieli złych SM, albo potrafią pracować i są zajebiści. Niestety większość nie potrafi pracować, dogadywać się, planować, dowozić, ustalać i dla tej większości jest scrum. Dobry zgrany zespół nie potrzebuje scruma, ale właśnie scrum generuje takie zespoły ucząc je jak pracować, takie zespoły zmieniają scrum pod siebie, na końcu tworząc dobrze działający zespół, gdzie już część zasad ze scruma nie ma, ale działają ok więc jest ok. Niemniej to zajmuje rok, dwa lata. Rynek IT jest tak dynamiczny, jest tyle skoczków, że zespoły często ciągle muszą uczyć się scruma i siebie bo się zmieniają. Tylko dwa razy widziałem ostateczną formę takich zespołów co się nauczyły pracować, ale to tez potem się zmieniły (nowi ludzie) i od początku - dlatego SM jest ciągle potrzebny.
Bycie SM to obowiązek, i dodatkowa robota, a nie gratyfikacja. To ciężki kawałek chleba być między młotem a kowadłem (PO/Team). Chyba, ze jest się SM tylko z tytułu przed nazwiskiem a tak serio się bumeluje. Dobry SM jest jak basista - nie widać, nie słychać, chyba, że zacznie coś robić nie tak.
Niemniej 14k i to jeszcze brutto, to nie są jakieś kokosy, żeby dev się rzucał do tej, bądź co bądź troszkę szambiastej roboty - nie że umniejszam, szambiarze są mega potrzebni, ale mają przejebaną robotę.

Z przymrużeniem oka ale pokazuje ideę:

Troszkę na pół serio biorąc pod uwagę, że dużo programistów to introwertycy i takie troszkę ciapy (no poza wojenkami na 4p ;p ), to kobieta z jajami, taka korpo bicza, żyleta dobrze sprawdzi się w tej roli.

2

A u mnie w pracy nie ma żadnych scrum musterów, nie mamy żadnych retro na którym gadamy o rzecach które i tak na ogół nikt nie zmieni. Normalnie gdy jest taka potrzeba to gadamy w zespole (mamy 3 osoby więc nie jest to trudne). Na typowe spotkania nie poświęcam więcej niż 2h na tydzień (zazwyczaj około pół godziny/godzinę). Da sie normalnie pracowac :)

1
scibi92 napisał(a):

A u mnie w pracy nie ma żadnych scrum musterów, nie mamy żadnych retro na którym gadamy o rzecach które i tak na ogół nikt nie zmieni.

Czasami gorzej jeśli właśnie zmieni. Ciężko znoszę zmiany organizacyjne, tygodnie jeśli nie miesiące zajmuje mi przyzwyczajenie się do nowej sytuacji, a takie "retro" są nastawione na "co by tu zmienić" - dla samej tylko zmiany, nawet jeśli wszystko działa jak powinno (albo na tyle na ile jest to realne).
Masakra.

2

Sorry @jarekr000000, ale potrzeba odpowiedzi na wszystkie nieprawdy, które napisałeś o Scrumie, retro itp przekracza objętość komentarza, więc kontunuuję tę dyskusję tutaj.

Satysfakcją się nie najesz. Nie opłacisz ZUS. Zaskakująco dużo programistów, nawet niezłych, pracuje dla kasy - toż to demagogia w najczystszej postaci. Co jak co, ale zarobki to najmniejszy problem programistów, zwłaszcza tych niezłych, i większość mi znanych pozbyła się już mentalności robola, który dla paru grosików więcej pozbawi się satysfakcji z wykonywanej pracy czy wpływu na warunki w jakich to robi. Co do ZUSu, na UOP opłaca go za mnie pracodawca, z tym że nie wiem co to ma do dyskusji o retro.
A tak w ogóle, nie rozumiem czemu sugerujesz, że satysfakcja pracownika miałaby się kłócić z wynikami biznesowymi. Bo raczej doświadczenie pokazuje, że te rzeczy idą w parze: kultura pracy, w której słucha się ludzi, a pracownicy są zadowoleni, jest efektywniejsza.

A do tego nie kupisz najlepszych ludzi. Właściwie czyj punkt widzenia reprezentujesz w tej dyskusji? Pracownika czy pracodawcy? Mam wrażenie, że tego drugiego. Bo zatrudnianie ludzi to nie jest problem pracownika.

Mnie bardzo demotywuje jak ktoś mi każe robić zadania na demo, jak wiem, że z powodu nagłej akcji konkurencji nasz biznes potrzebuje czegoś innego niż zaplanował, i to na wczoraj - i właśnie na retro masz okazję o tym powiedzieć. Natomiast Ty próbujesz ubić swoje podstawowe narzędzie do wywierania wpływu na management w kwestii biznesu i tego co jak powinno być robione. Zadziwiająca logika.

Scrum to defokusacja od biznesu. - jest dokładnie odwrotnie. Właśnie dzięki Scrumowi firmy mają możliwość reagowania na zmieniające się warunki biznesowe. W Scrumie planujesz na najbliższy sprint, czyli 2-3 tygodnie, w Waterfallu miałeś plan na kolejne pół roku, co oznaczało że jak potrzebowałeś zmienić plan, to nawet tyle musiałbyś czekać. Chyba, że postulujesz by w ogóle nic nie planować, tylko lecieć na żywioł. Ok, załóż firmę, wdróż taką metodę pracy i udowodnij światu, że jest skuteczna. Powodzenia.

A wracając jeszcze do Twojej opinii: zmany w oczekiwaniach, wyciąganie ludzi do innych projektów, nieoczekiwane zadania to rzecz normalna i pożądana., pozwolę sobie na komentarz. Sytuacja A: Masz zadanie, które zajmuje trochę czasu - miesiąc, może 2. Zdążyłeś się wgryźć, przychodzi kierownik i mówi: rzuć to i leć gaś pożar gdzie indziej. Wracasz, musisz się na nowo wgryzać, w międzyczasie coś się pozmieniało. A potem Cię pytają: czemu Twoje zadanie idzie opieszale? Sytuacja B: Praca nad projektem idzie ku ukończeniu, większość modułów napisana, przetestowana, zaczyna się integracja. Przychodzi kierownik projektu i mówi: niestety musicie dodać nowy ficzer (taki, który akurat psuje całą architekturę), bo ktoś obiecał to klientowi, ale zapomniał powiedzieć. Oczywiście terminy nadal obowiązują. Czy te 2 sytuacje to dla Ciebie są "rzeczy normalne i pożądane"? Dlaczego chcesz pozbawić programistów możliwości eskalowania takich sytuacji?

Wybacz, ale jak na osobę tak lotną i łatwo przyswajającą wszelkie techniczne nowości, w kwestii metod organizacji pracy prezentujesz jakieś archaiczne podejście. Wbiłeś sobie do głowy "Scrum to zło", a widzę, że nie bardzo rozumiesz o co w ogóle w nim chodzi - utożsamiasz Scruma czy w ogóle Agile z jakąś obrzędowością w postaci spotkań o ustalonej formie, wykresów, karteczek, pokerów, a nie sposobem podejścia do pracy. Może warto zamiast uczyć się kolejnego języka programowania przeczytać co nieco o Agile, o Leanie czy w ogóle o filozofii tworzenia oprogramowania?
Uprzedzając kontrataki typu: "czego to Scrum nie robi z ludzi", oświadczam, że w Scrumie pracuję odkąd się pojawił w mojej pracy, czyli już jakieś 10 lat, ale nigdy nie pełniłem w nim jakiejkolwiek roli poza rolą członka zespołu, więc nie bronię swojej pozycji. Pamiętam za to jak głupia i nieefektywna była praca przed Scrumem, jak pozwalała nierobom okopywać się w swoich grajdołkach i jak utrudniała zdobywanie doświadczenia.

2

5

@GutekSan: zarzucasz mi nieprawdę, ale w sumie nie wiem w czym, bo gdzieś musiałbym skłamać, a nie widzę gdzie w Twoim poście.

Wręcz przeciwnie Twój cały post dokładnie zgadza się z moim doświdczeniem. Tylko wnioski mamy inne.

Co do ZUSu, na UOP opłaca go za mnie pracodawca, z tym że nie wiem co to ma do dyskusji o retro.

Z czego ten ZUS pracodawca płaci? Z restrospektywy się magicznie kasa generuje?
Dla mnie ważnym elementem satysfakcji z pracy jest poczucie, że:

  • zarabiam odpowiednio dużo pieniędzy
  • nadal opłacam się pracodawcy

Właściwie czyj punkt widzenia reprezentujesz w tej dyskusji? Pracownika czy pracodawcy? Mam wrażenie, że tego drugiego. Bo zatrudnianie ludzi to nie jest problem pracownika.

Jestem pracownikiem, ale zajmuje się czasem zatrudnianiem ludzi. To chyba normalne. To jest mój problem, jak nie zatrudnię dobrych ludzi to będę musiał pracować z pierdołami.

Właśnie dzięki Scrumowi firmy mają możliwość reagowania na zmieniające się warunki biznesowe. W Scrumie planujesz na najbliższy sprint, czyli 2-3 tygodnie, w Waterfallu miałeś plan na kolejne pół roku, co oznaczało że jak potrzebowałeś zmienić plan, to nawet tyle musiałbyś czekać.

Nie wiem w jakiej działce praujesz. Ale ja pracuje w dośc konserwatywnej (bankowość, ubezpieczenia). Co więcej, zupełnym przypadkiem, moi ostatni klienci / pracodawcy to firmy, które na rynku istnieją od ponad 100 lat (założone w XIX wieku). W IT to dość długo.
W żadnej z nich przestój na 2 -3 tygodnie tylko dlatego że jakiś zespół ma cele sprintu, to raczej nie jest normalna sprawa. W biznesie 3 tygodnie to czasem bardzo długo. Przeważnie nie, ale bywają 3-4 akcje w roku, że jednak.

Co do Waterfalla, to ja pracowałem w latach 90tych i na początku 21 wieku. Zanim ktokolwiek o Scrumie i agile słyszał. Co ciekawe wtedy też nie robiliśmy waterfalla. Były legendy, że gdzie na kontraktach rządowych w stanach się tak robi i raczej się z tego śmialiśmy.
IMO Waterfall został wymyślony przez Scumowców, aby zdefiniować jakiegoś wroga. Tak jak bolszewicy wymyślili kułaków, chociaż ich prawie w Rosji nie było.
Mieliśmy różne procesy iteracyjne (spiralny) z cyklami - miesiąc, 2 miesiące (wzorowane na bieda RUP, który też był mitycznym procesem), różniły się tym od Scrumu, że nie było tyle straty czasu na spotkania :-) Za to było nonsensowne modelowanie i wiele innego RAKA. Raka w ilościach ogromnych, ale to raczej wynikało, z tego, że IT było młode i rak ten miał mało wspólnego z procesem, więcej z techniką.

I nieważne jakie były te cykle i plany to nagłe wrzutki i tak były i były normalne. Zmienialliśmy kilka razy plany prawie z dnia na dzień, pracując dla całkiem konserwatywnych banków (jeden miał nawet zawsze plan 10-letni (!)).

Sytuacja A: Masz zadanie, które zajmuje trochę czasu - miesiąc, może 2. Zdążyłeś się wgryźć, przychodzi kierownik i mówi: rzuć to i leć gaś pożar gdzie indziej. Wracasz, musisz się na nowo wgryzać, w międzyczasie coś się pozmieniało. A potem Cię pytają: czemu Twoje zadanie idzie opieszale

Takie akcje to dla mnie normalka, tylko, że żaden kierownik nie pyta mnie czemu idzie opieszale, bo jak przyszedł powiedzieć rzuć i leć gaś pożar to powiedziałem, że tak będzie. Btw. miałem dokładnie taką rozmowę w tym tygodniu we wtorek.
I uwaga: myślę, że to że kierowniki nauczyły się to rozumieć, a ja i inni programiści nauczyliśmy się takie fakty komunikować zawdzięczamy agile. Tu oddaję sprawidliwość. Idzie po staremu, ale mniej jest rozczarowań i pretensji.

Chyba, że postulujesz by w ogóle nic nie planować, tylko lecieć na żywioł. Ok, załóż firmę, wdróż taką metodę pracy i udowodnij światu, że jest skuteczna. Powodzenia.

Pisałem już kiedyś, że jak zespół jest dobry to i scrum mu nie przeszkodzi. To dotyczy prawie dowolnej metodyki. Również chyba tej na żywioł.

oświadczam, że w Scrumie pracuję odkąd się pojawił w mojej pracy, czyli już jakieś 10 lat, ale nigdy nie pełniłem w nim jakiejkolwiek roli poza rolą członka zespołu, więc nie bronię swojej

Agile poznałem w 2007 i strasznie się zajarałem. Marketing (mendy) mają dobry. Tyle, że przez wiele lat trafiałem na firmy gdzie ten agile było wypaczany (korpo agile/korpo scrum, błedy i wypaczenia). Moja wiara, jakkolwiek, pozostała silna. System dobry, tylko ludzie nie dorośli. I dopiero w Szwajcarii (dla mnie niedawno) trafiłem do zespołu, który robił praktycznie scrum by the book. Dopiero wtedy zrozumiałem, że to naprawdę wielka strata czasu.
Pojeździłem po konferencjach, pogadałem z ludźmi, doczytałem. Wyszło na to, że nie jestem jedyny, który to zaobserwował.
Ale fakt, że krytyka Scruma i podobnych jest ciągle niezbyt powszechna i nie tak radykalna jak moja.

1

Scrum nie jest stały, i nie ma dwóch takich samych scrummów, dlatego dyskusja o nim jest nieco trudna (dlatego to metodyka zwinna - bo zmienna). Jakieś awarie, wrzutki etc. powinien ogarniać SM i PO i co z tym zrobić, a DEV powinien napierdzielać, jako żołnierz. On ma się skupić i skoncentrować na dostarczeniu przyrostu,a SM i Scrum ma go bronić, właśnie przed dodatkowymi spotkaniami w połowie sprintu, rozwiązywaniu fuckupów, ustalania priorytetów etc. Jeśli dev jest nagle w połowie inspiracji i nawalania kodu wyrywany na jakiś planning to to dupa a nie scrum. Scrum ma parę prostych zasad - pozwolić devom skupić się i chronić przed światem, oraz pomóc dowiedzieć się, co jest do zrobienia i przewidywać krótkoterminowe dowożenie kolejnych ficzerów. Jak coś się zepsuje i trzeba wyrwać członka to nie powinien o tym wiedzieć, tylko PO i SM ogarniają, czy mogą to zrobić, czy może ktoś inny ma ogarnąć naprawę. Jak ten DEV sie dowie, to się jeszcze zdekoncentruje, nawet jak kto inny ogarnie awarie. SM i PO w skrajnych przypadkach (klient, upadł, jest na skraju updaku bo wszystko leży, sklep internetowy nie działa, zamówienia nie przychodzą etc) mają prawo przerwać sprint, "anulować" go i iść na żywioł, ratując sytuacje. Ale jak kurz opadnie, znów się organizujemy, PO sprawdza czego teraz potrzebujemy na za 2 tyg. SM ogarnia sprawę, pilnuje wycen i zaczynamy znów działamy jak doskonale spasowane trybiki. Retro jest po to, żeby wszystkie frustracje wyszły na retro a nie w trakcie, a nie, żeby przerywać robote w ciągu sprintu. To, że jest ok, to nie znaczy, że będzie zawsze - bo przyjdzie nowy, będzie miał biurko naprzeciw mnie i okaże się, że mlaszcze jedząc obiad a mi niezręcznie zwrócić mu uwagę to na retro można pomyśleć, że "chciałbym przemeblować pokój, bo mi światło razi". Wtedy razem pomyślimy co i jak zrobić, nikt nie będzie urażony a problem się rozwiąże nie przerywając pracy. Retro powinno być tak, krótkie jak można, więc jak nie ma problemów to zakończy się w 5 minut, ale za 6 sprintów może coś wyjść. Zauważyłem, że retro to najważniejszy element scruma. Tam gdzie retro zanikało, zaraz wszystko sie rozwalało, a rotacja rosła. Dlatego na retro musza być wszyscy. Niemniej inne spotkania i scrum można modyfikować. Pracując w 3 osobowym zespole, na planning pokerze byli wszyscy. Przy 14 osobach - trwało to mega długo, i zjadało mega kasy, więc podjeliśmy decyzje, że na pokerze musi być min 3 osoby, wtym jeden senior i jeden junior (rozwój), a planing robimy raz w tygodniu, w określonym dniu, i przychodzi kto chce byle zasady były zachowane. To skróciło czas pokera, stał sie tańszy i efektywniejszy, Przestaliśmy też wszystko wyceniać, a tylko te elementy co PO chciałby wrzucić na najbliższym sprincie.Wydaje mi się Jarek, że masz dużo racji - niepotrzebne spotkania są niepotrzebne, a jak się pali to się gasi a nie czeka na kolejny sprint, ale to nie jest definicja scruma, tylko co najwyżej ułomnego jego wdrożenia przez ślepego zapatrzonego w jakąś instrukcje SM. Co do współodpowiedzialności za firmę - to jest dobra cecha, ale podczas sprintu masz sie skupić na robocie, a podczas retro dyskutować. Przerywając prace na dyskusje o tym co lepsze dla biznesu - przerywasz dostarczenie przyrostu. O ile jesteś zajebisty to zaraz wrócisz do roboty, ale pamiętaj, że czasami pracuje się z ludźmi, których raz wybijesz z rytmu to dopiero na drugi dzień się skoncentrują i wpadną w flow wytwarzania. Trzeba patrzeć poza czubek swojego nosa. Być może jesteś na złej pozycji w firmie. Pracowałem w organizacji z płaską strukturą, bez kierowników, zwierzchników. Ludzie mogli przechodzić między zespołami i przyjmować różne role. Jednak jak zdecydowałeś się być żołnierzem to musiałeś spełniać swoją służbę do końca misji (sprintu). Scrum nie kłóci się z organizacjami turkusowymi/holokracją, ale turkus i współodpowiedzialność, to nie jest anarchia. Może powinieneś zmienić role, a wiem, że dużo programistów dobrze się czuje, nawalając kod i nie skupiając się na '[CIACH!]' lub to minimalizując w dobrym scrumie, a nie w scrumie ale tylko z nazwy, żeby był i na ofercie pracy to wpisać. Inna sprawa, że Scrum nadaje się do projektów. Mamy początek, koniec i nie ma zawracania d**y. Jeśli pracujesz w utrzymaniu, serwisie, supporcie - tam gdzie nie masz ogólnego celu, produktu, taski spływają, a co jakiś czas jest pożar czy jebnięcie atomówki - no to tutaj Scrum kompletnie się nie nadaje i tylko przeszkadza w robocie i o ile lubię scrum, tak w tym przypadku odradzam. Dla takich procesowych zespołów, sugeruje kanban, to ogarnięcia co, kiedy, w jakim stanie jest, ew. retro raz na miesiąc, żeby ludzie nie zaczęli się zwalniać i tyle, bo jeśli u kliena nie działa import csv, to poker i rozpiska tego to faktycznie strata czasu, bo wiaodmo co zrobić, a klient czeka. Dobierajmy narzędzia do potrzeb, a scrum nie nada się do procesów, ale do pracy projektowej. To, że scrum jest procesem nie oznacza, że do procesów się nadaje, w procesie nie masz jasnego przyrostu, celu, a nawet wrzutki po drodze mogą być ważniejsze niż zaplanowane taski. W waterfallu pracowałem, i nie polecam. Po roku pracy okazuje sie, że jest za drogo i to nie to co klient chciał. RUP niby to rozwiązuje, ale RUP jest przeładowany, natomiast Scrum wprowadza zarówno lekkość, jak i systematykę,ale dobrze prowadzony Scrum. No i chodząc po konferencjach nie gadasz z większością szaraków, tylko z marins, którzy są ponad przecietni, więc to nie wyznacznik.

0
jarekr000000 napisał(a):

@GutekSan: zarzucasz mi nieprawdę, ale w sumie nie wiem w czym, bo gdzieś musiałbym skłamać, a nie widzę gdzie w Twoim poście.

W pierwszej wersji chciałem Ci zarzucić nie "nieprawdę" a po prostu "bzdury", z tym że nie chciałem zaogniać tej dyskusji i zastąpiłem to słowo pierwszym lepszym eufemizmem, który mi przyszedł do głowy. Faktycznie, trudno przypisać obiektywną prawdę czy nieprawdę stwierdzeniom: scrum to defokusacja od biznesu albo wyciąganie ludzi z zespołów jest pożądane, natomiast bliżej im po prostu do zwykłych bzdur. Nie uznaję tych bzdur jednak jako przejaw głupoty, bardziej chęci pokazania zabawnej i prowokacyjnej kontrowersyjności.

Co do ZUSu, na UOP opłaca go za mnie pracodawca, z tym że nie wiem co to ma do dyskusji o retro.

Z czego ten ZUS pracodawca płaci? Z restrospektywy się magicznie kasa generuje?

Trochę tak. Tyle, że tyle w tym magii ile w pętli sprzężenia zwrotnego w układach elektronicznych, albo filtrze Kalmana. Retrospektywa to nie jest zebranie, tylko spojrzenie wstecz na proces i decyzje z odpowiedniego dystansu, znając już przynajmniej częściowo konsekwencje podjętych działań. Pozwala wprowadzić korekty do procesu, który samoistnie dryfuje od wyznaczonego celu. A szybsze czy pewniejsze osiągnięcie tego celu, to zazwyczaj w biznesie oznacza więcej kasy.

Dla mnie ważnym elementem satysfakcji z pracy jest poczucie, że:

  • zarabiam odpowiednio dużo pieniędzy
  • nadal opłacam się pracodawcy

Tyle, że te rzeczy zapewniasz sobie przez odpowiednią negocjację na wejściu i rzetelną pracę, na co dzień nie musisz się tym martwić. Za to istnieje szereg czynników, które mają wpływ na satysfakcję z pracy, a które trzeba cały czas kontrolować:

  • poczucie sensu wykonywanej pracy
  • relacje z kolegami
  • styl zarządzania (np. micromanagement)
  • brak przeszkód i różnego typu dystraktorów
  • tematyka zgodna z wewnętrznymi zainteresowaniami
  • możliwość rozwoju

Jeśli ich nie ma lub są słabe, satysfakcja leży i kwiczy, choćby się zarabiało gar złota. A do kontrolowania tych czynników służy właśnie retro.

Właściwie czyj punkt widzenia reprezentujesz w tej dyskusji? Pracownika czy pracodawcy? Mam wrażenie, że tego drugiego. Bo zatrudnianie ludzi to nie jest problem pracownika.

Jestem pracownikiem, ale zajmuje się czasem zatrudnianiem ludzi. To chyba normalne. To jest mój problem, jak nie zatrudnię dobrych ludzi to będę musiał pracować z pierdołami.

Nie zajmujesz się zatrudnianiem, co najwyżej rekrutowaniem. A jeśli Cię to boli to dopisz to sobie do mojej listy powyżej, i masz kolejny argument by zachować retro. I pamiętaj też, że nie chodzi tylko o to by zatrudniać dobrych, ale i o to by dobrych nie stracić, a brak satysfakcji do tego prowadzi.

W żadnej z nich przestój na 2 -3 tygodnie tylko dlatego że jakiś zespół ma cele sprintu, to raczej nie jest normalna sprawa. W biznesie 3 tygodnie to czasem bardzo długo. Przeważnie nie, ale bywają 3-4 akcje w roku, że jednak.

Ale o czym w ogóle mówimy? O wprowadzania nowego produktu na rynek czy o utrzymaniu istniejącego? Bo przy wprowadzaniu 2-3 tygodnie to jest nic. Zwłaszcza, że te 2-3 tygodnie to najgorszy scenariusz (zmiana pojawia się zaraz po zaplanowaniu, a to stosunkowo łatwo naprawić). W praktyce średnio taki przestój wynosiłby tydzień.
Ale oczywiście, bywa że trzeba zrobić coś na już, bo nie działa. Tyle, że z faktu że trzeba to zrobić, nie wynika np. kto ma to zrobić. Np. zamiast odrywać od zadań kogoś czyje cele są naprawdę ważne, można kazać gasić pożary komuś, kto się akurat nudzi.

IMO Waterfall został wymyślony przez Scumowców, aby zdefiniować jakiegoś wroga. Tak jak bolszewicy wymyślili kułaków, chociaż ich prawie w Rosji nie było.

Waterfall był, tylko pewnie nie aż tak wypaczony, jak to Agile prezentuje. Objawem Waterfalla jest np. rozdzielenie na dział developmentu i dział testów. Ja pracowałem w takim systemie.

Mieliśmy różne procesy iteracyjne (spiralny) z cyklami - miesiąc, 2 miesiące (wzorowane na bieda RUP, który też był mitycznym procesem), różniły się tym od Scrumu, że nie było tyle straty czasu na spotkania :-)

Ale w mojej opinii Scrum nie oznacza spotkań. Spotkania są tam, gdzie organizacja jest wewnętrznie zbiurokratyzowana i się w nich lubuje. Jakbyś zlikwidował Scrum i wprowadził dowolną inną metodykę, spotkania i tak tam pozostaną. Ot, taka mentalność. U mnie bywało różnie, obecnie nie mam prawie wcale spotkań wynikających ze Scrumu (poza 5-10 minut daily, sprint planningiem i godzinnym retro raz na miesiąc).

I nieważne jakie były te cykle i plany to nagłe wrzutki i tak były i były normalne. Zmienialliśmy kilka razy plany prawie z dnia na dzień, pracując dla całkiem konserwatywnych banków (jeden miał nawet zawsze plan 10-letni (!)).

No więc i tak pracowaliście w Agile'u, tyle że nie nazwanym. Przecież to jest właśnie esencja Agile'u - szybka reakcja na zmiany. Cała reszta (Scrumy, Kanbany, itp) to po prostu pewne standardy łączenia możliwości szybkiego reagowania z realizacją długotrwałych celów.

Dodam jeszcze, że to że wrzutki są, nie oznacza, że są normalne. Generalnie dużo rzeczy da się przewidzieć, i wystarczy niewiele by zła wrzutka stała się dobrym elementem backlogu. A nawet jeśli nie da się ich uniknąć, można poprawić sposób w jaki są zarządzane.

Sytuacja A: Masz zadanie, które zajmuje trochę czasu - miesiąc, może 2. Zdążyłeś się wgryźć, przychodzi kierownik i mówi: rzuć to i leć gaś pożar gdzie indziej. Wracasz, musisz się na nowo wgryzać, w międzyczasie coś się pozmieniało. A potem Cię pytają: czemu Twoje zadanie idzie opieszale

Takie akcje to dla mnie normalka, tylko, że żaden kierownik nie pyta mnie czemu idzie opieszale, bo jak przyszedł powiedzieć rzuć i leć gaś pożar to powiedziałem, że tak będzie. Btw. miałem dokładnie taką rozmowę w tym tygodniu we wtorek.

Bywa, że kto inny mówi: 'rzuć to i leć gaś pożar', a kto inny mówi: 'rób swoje zadanie'.

Pisałem już kiedyś, że jak zespół jest dobry to i scrum mu nie przeszkodzi. To dotyczy prawie dowolnej metodyki. Również chyba tej na żywioł.

To są mrzonki. W praktyce nie spotkałem się z taką sytuacją. Nawet jak masz zespół samych gwiazd to jakiś standard pracy jest potrzebny, może zwłaszcza tam.

Agile poznałem w 2007 i stracznie się zajarałem.

A ja przeciwnie. Najpierw myślałem: "czego oni oczekują? że będziemy znać się na wszystkim? Do pewnych branż Scrum po prostu nie pasuje". Z czasem zobaczyłem, że dzięki temu lepiej rozumiem nad czym pracuję, bo nie jestem zamknięty w swojej bańce, a wszystko szło efektywniej.

Tyle, że przez wiele lat trafiałem na firmy gdzie ten agile było wypaczany (korpo agile/korpo scrum, błedy i wypaczenia). Moja wiara, jakkolwiek, pozostała silna. System dobry, tylko ludzie nie dorośli. I dopiero w Szwajcarii (dla mnie niedawno) trafiłem do zespołu, który robił praktycznie scrum by the book. Dopiero wtedy zrozumiałem, że to naprawdę wielka strata czasu.

Tyle, że wg mnie właściwy scrum to właśnie ten "wypaczony" scrum, a właściwie nie "wypaczony" tylko "przycięty do potrzeb". Scrum "by the book" jest dla nowicjuszy, którzy pierwszy raz o nim słyszą, więc się im pokazuje wszystko co mają do dyspozycji. Ale z czasem każda organizacja czy nawet zespół go dostosowuje pod siebie. Im dłużej pracuję w Scrumie, tym jest mniej nacisku na scrumowe obrzędy, za to pozostaje filozofia Agile i podstawowe narzędzia do kontroli postępu prac. U mnie nie ma sprint goali, velocity, pokera, regularnych demo. W innych zespołach wciąż widzę niektóre z tych elementów, ale może im to pasuje.

Scrum "by the book" jest jak Kata w sztukach walki. Ćwiczy się to, ale jeśli ktoś będzie chciał to zastosować na ulicy przeciw 3 zakapiorom, to jest debilem. Scrum "by the book" jest jak danie żołnierzowi pełnej zbroi, miecza, topora, szabli, mizerykordii, rapiera, pistoletu, kałasznikowa, M40, M134, granatnika i łuku, i wrzucenie na pole walki. W 10 minut załamie się pod ciężarem tego wszystkiego, ale jak sobie wybierze co mu odpowiada, będzie efektywny.

3

U mnie w zespole 7 os. daily potrafi trwać do 30 min. do tego review i planning 3-4h, retro 2h. W wyniku retro "zespół" wymyślił spotkania projektowe 4h na których interpretujemy dokumenty od biznesu. Do tego jeszcze co tygodniowe spotkania na wycenę trwające po 2-3h. Oprócz tego dochodzą szkolenia wewnętrzne i zewnętrzne, inne niezaplanowane spotkania oraz spotkania korporacyjne. Na pracę zostaje około 45h na dwa tygodnie. Jak można nie kochać agile?! Ja nie kocham...

0
Haskell napisał(a):

U mnie w zespole 7 os. daily potrafi trwać do 30 min. do tego review i planning 3-4h, retro 2h. W wyniku retro "zespół" wymyślił spotkania projektowe 4h na których interpretujemy dokumenty od biznesu. Do tego jeszcze co tygodniowe spotkania na wycenę trwające po 2-3h. Oprócz tego dochodzą szkolenia wewnętrzne i zewnętrzne, inne niezaplanowane spotkania oraz spotkania korporacyjne. Na pracę zostaje około 45h na dwa tygodnie. Jak można nie kochać agile?! Ja nie kocham...

Długość spotkań zazwyczaj odzwierciedla liczbę problemów, poziom wewnętrznego niezrozumienia się, itp. Wtedy trzeba się zastanowić, co sprawia, że ludzie mają tyle do powiedzenia, i czy faktycznie wszyscy są tym zainteresowani, czy to gadanie cokolwiek zmienia. Na daily bywają gawędziarze, więc ich się delikatnie młotkuje, by się pilnowali. Sprint można wydłużyć do 3 tygodni, wtedy ten stały overhead się rozkłada na dłuższy odcinek. Review bywają długie, bo zazwyczaj PO wtedy nadrabia zaległości nt. dokonań, zamiast śledzić postęp na bieżąco. Zaplanować robotę niektóry można na kilka sprintów do przodu, wówczas przesuwają sobie tylko zadania z backlogu na to-do. Wszystko da się przyciąć, kluczem do sukcesu jest właśnie sprawny SM i zewnętrzna motywacja. Bo jeśli jest faktycznie tak jak mówisz, że pracujecie przez 45 min. w tygodniu to chyba ktoś tam na górze marudzi, że praca idzie wolno więc powinien mieć interes by ją przyspieszyć. A jeśli nie marudzi, to chyba i tak nikomu na tej pracy nie zależy. W takiej sytuacji sam sobie odpowiedz, co trzeba zrobić.

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