Zostań Scrum Masterem

Jeżeli piszecie, że Scrum Master jest niepotrzebny to chyba mieliście samych słabych. :)
Dla mnie taki Scrum Master ogarnia wszystko i mogę się skupić na technicznej robocie dzięki temu.

GutekSan napisał(a):

Nie. Po prostu chciałeś pokazać jaki to Scrum jest zły kosztem współpracy z ludźmi. Wymówki zachowaj sobie dla szefa.

No tak, zapomniałem, że lepiej znasz sytuację i moje zamiary. :)
Ja po prostu myślę bardziej długofalowo i chcę się pozbyć niekompetentnych ludzi z teamu zanim zrobią coś, co wprowadzi realne zagrożenie.
Nie wiem, czy zauważyłeś, ale to ja miałem rację i ja wygrałem. Moim celem jest działanie zgodnie z interesem biznesu. A biznes stwierdził, że robienie biznesu jest ważniejsze niż procesy scrumowe i zabawa dwóch fetyszystów.

Od doświadczonych deweloperów normalnie wymaga się nieco szerszego spojrzenia.

W takim razie chyba nigdy nie zostaniesz doświadczonym developerem.
Pracuję w firmie, w której cały biznes opiera się na tworzeniu softu, tak więc rozwiązywanie problemów biznesowych odbywa się przez tworzenie softu. U nas soft jest produktem, a więc też źródłem zysku, a nie kosztem jak w większości innych firm.
A Ty chyba nie odróżniasz tworzenia softu od klepania kodu.

Dostrzegasz różnicę między "programiści zazwyczaj" a "programiści w mojej firmie" ?

Skąd zatem ta opinia, jeśli nie z doświadczenia?

Doskonale pamiętam. Pisałem co można robić by mierzyć efektywność pracy. Ty stwierdziłeś, że nie korzystasz z tych rozwiązań i ogólnie planowanie rozjezdza się u was z pracą, cyt. "Fajnie. My nie mamy. No i ogólnie z wykresów wynika, że niczego nie robimy (bo większość tasków spada na następny sprint". No ale rzekomo problemów nie macie i jeszcze próbujesz mi wmówić, że to ja mam jakiś problem! Grunt to iść w zaparte! Przemyśl chłopie trochę swoją logikę i się nie kompromituj

Zupełnie nie. U nas praca idzie zgodnie z planem - biznes dostaje ficzery na czas.
To fetyszystom scruma się jakieś wykresy nie zgadzają i storypointy nie idą tak, jak powinny. Ale to nikogo nie obchodzi poza nimi.

I doskonale to rozumiem.

Jakbyś rozumiał, to byś nie dawał rozwiązań nie znając problemów. Tymczasem Ty kompletnie nie znasz sytuacji, a już wiesz, że problemem jest brak mierzenia velocity.

Za to przeciwnicy Scruma postulują takie właśnie jedno rozwiązanie - brak czegokolwiek, jakichkolwiek procesów, po prostu napie...my kod, hurra i do przodu.

To jest Twoja interpretacja, bo nikt w tym wątku czegoś takiego nie sugerował.

Po co Wy się kłócicie?

somekind napisał(a):

Nie wiem, czy zauważyłeś, ale to ja miałem rację i ja wygrałem.

Tak, bo ważniejsze jest żebyś ty wygrał, a nie to, że można było rozwiązać problem 2 dni wcześniej.

W takim razie chyba nigdy nie zostaniesz doświadczonym developerem.

Nie tobie to oceniać. Myślę, że doświadczenia mam trochę więcej niż ty.

Pracuję w firmie, w której cały biznes opiera się na tworzeniu softu,

Nigdy CAŁY biznes nie opiera się na wyłącznie na tworzeniu kodu. To jest podstawowa rzecz, której nie rozumiesz, i dopóki nie zrozumiesz, nie widzę sensu dalszego tłumaczenia ci czegokolwiek w tym temacie. Skoro, jak sam pisałeś jesteś deweloperem, zajmij się deweloperką, a nie wygłaszaniem opinii na temat tego czy Scrumowe wykresy i spotkania mają sens czy nie.

GutekSan napisał(a):

Skoro, jak sam pisałeś jesteś deweloperem, zajmij się deweloperką, a nie wygłaszaniem opinii na temat tego czy Scrumowe wykresy i spotkania mają sens czy nie.*

*Chyba że opinia będzie przedstawiać Scruma w pozytywnym świetle. ;)

ToTomki napisał(a):

Po co Wy się kłócicie?

Odwieczny konflikt - ludzie którym płacą za dostarczenie produktu (dev) kontra ludzie, którym płacą za udowadnianie, że coś robią (w tym wypadku sm).

GutekSan napisał(a):

Tak, bo ważniejsze jest żebyś ty wygrał, a nie to, że można było rozwiązać problem 2 dni wcześniej.

Ważne jest to, żeby biznes dostał ficzery na czas. Ze scrumowymi sabotażystami to się w pewnym momencie może przestać udawać, więc trzeba zrobić coś, żeby się ich chorych pomysłów pozbyć.

Nie tobie to oceniać. Myślę, że doświadczenia mam trochę więcej niż ty.

W latach możesz mieć nawet 10 razy więcej, ale to bez znaczenia, jeśli nie potrafisz wyciągać wniosków i używać wyobraźni.

Nigdy CAŁY biznes nie opiera się na wyłącznie na tworzeniu kodu. To jest podstawowa rzecz, której nie rozumiesz, i dopóki nie zrozumiesz, nie widzę sensu dalszego tłumaczenia ci czegokolwiek w tym temacie. Skoro, jak sam pisałeś jesteś deweloperem, zajmij się deweloperką, a nie wygłaszaniem opinii na temat tego czy Scrumowe wykresy i spotkania mają sens czy nie.

Nawet nie wiesz, gdzie pracuję, a lepiej wiesz na czym polega nasz biznes.
Prawie mnie przekonałeś. ;)

Nigdzie nie napisałem, że biznes polega wyłącznie na tworzeniu kodu. Ja pisałem, że biznes opiera się na sofcie. Bez nowego softu nie ma zwiększenia sprzedaży. Potrzeby biznesu przekładają się ściśle na pracę developerów.
A skoro nie odróżniasz softu od kodu, to prawdopodobnie to jest przyczyna, dla której bronisz patologii, z którymi ja walczę. Bo przeszkadzanie developerom w tworzeniu softu jest wbrew potrzebom biznesu.

somekind napisał(a):

W latach możesz mieć nawet 10 razy więcej, ale to bez znaczenia, jeśli nie potrafisz wyciągać wniosków i używać wyobraźni.

Powtórzę. Nie tobie to oceniać.

Nawet nie wiesz, gdzie pracuję, a lepiej wiesz na czym polega nasz biznes.

To bez znaczenia gdzie pracujesz. I nie wypowiadałem się o WASZYM biznesie. Jak zwykle dopowiadasz sobie, a potem pouczasz.

Nigdzie nie napisałem, że biznes polega wyłącznie na tworzeniu kodu. Ja pisałem, że biznes opiera się na sofcie. Bez nowego softu nie ma zwiększenia sprzedaży. Potrzeby biznesu przekładają się ściśle na pracę developerów.

Wyłącznie na sofcie też się nie opiera.

ToTomki napisał(a):

Po co Wy się kłócicie?

Bo zaraza rozlazła się tak, że trudno dziś nie być dotkniętym. W prawie każdym ogłoszeniu o pracę jest Scrum. Ludzie jeszcze nie wiedzą co będą robić, ale wybierają Scrum. Ludzie robią utrzymaniówkę... i bach Scrum. Ludzie robią projekty ściśle fixed price i robią Scruma. (Ta ostatnia to ideał dla sprytnego klienta i widziałem wykorzystanie tego :-) ).
Scrumowa policja utrudnia mi życie, nawet jeśli mój team totalnie olewa Scruma. Np. wczoraj chcieli żebyśmy przeleźli przez jakieś 200 tasków w backlogu i je inaczej pooznaczali bo im sie słupki w raportach z ze zdziry nie zgadzają :-) (ale zostali pogonieni).

Najgorszy jest bezkrytyczny Scrum - dla Scruma, niestety to norma. Jeśli krytyka chociaż trochę obudzi niektóre umysły i skłoni do paru refleksji to już coś. Może będzie w paru miejscach Scrum z ludzką twarzą.

Dodatkowo Scrum moim zdaniem nie pasuje totalnie do roku 2019 - to metodyka dostosowana do cykli długości 1-3 tygodnie. A w nowoczesnych technologiach to za długo. Mam takie powiedzienie, że jak jestem w stanie planować na tydzień do przodu to znaczy, że moje narzędzia obsysają (i tak czasem bywa).
Żeby było śmieszniej normą są zespoły robiące sprinty 2 tygodniowe, a nawet miesieczne. Ci ostatni to już na pewno kod ryją na glinianych tabliczkach.
Podpowiedź - w wielu projektach największym ograniczeniem jest dla mnie wchłanianie logiki biznesowej - jestem w stanie dość szybko tą logikę na kod przerobić (byłem w projekcie, gdzie to było prawie na bieżaco - mieliśmy planowanie pracy zespołu na dzień). Nie jestem w stanie na raz przyjąć informacji na np dwa tygodnie (a to poniekąd jest wymagane przy dłuższym planowaniu).

iddqd napisał(a):

Jeżeli piszecie, że Scrum Master jest niepotrzebny to chyba mieliście samych słabych. :)
Dla mnie taki Scrum Master ogarnia wszystko i mogę się skupić na technicznej robocie dzięki temu.

Ale to musi być Scrum Master?
Czy może po prostu Scrum Master to robi, bo macie Scrum Mastera, i on po prostu ma czas na takie rzeczy?

Bo ja jestem pewien, że ogarnianiem wszystkiego może się zajmować ktoś inny, i nawet nie mieć Scrum w nazwie stanowiska.
A jak firma jest agilowa, to nawet nie potrzeba za bardzo niczego ogarniać, bo developer nie ma aż tak dużo problemów infrastrukturalnych, tylko ewentualnie techniczne (np. z użyciem komponentów innych teamów), a w tym przypadku wystarczy się z innym teamem skontaktować, np. na firmowym Slacku.
A problemy infrastrukturalne developer rozwiązuje zgłaszając ticketa do adminów. To jest szybsze niż tłumaczenie komuś o co chodzi, i robienie z niego proxy do adminów.
Tylko chyba nie ma agilowych firm na 50k developerów. Inna rzecz, czy wszyscy z tych 50k developerów to ludzie związani z naszym projektem.

WeiXiao napisał(a):

A jak to wygląda w innych krajach / większych firmach?

nie zdarzylo mi sie byc w dzialajacym scrumie a wylacznie w jego przeszkadzajacych mi derywatywach.
ktos moglby powiedziec ze to ze mna jest problem, no ale na podstawie pracy w kilku firmach z branzy finansowej, wielkosc od 100-100k pracownikow, dochodze do nastepujacych wnioskow (staram sie byc obiektywna, ale wiadomo):

1. standupy:
   a) odrywa mnie to od pracy, psuje mi wene, robi mi context switch, wiadomo o co chodzi :)
   b) czesc ludzi musi sie pochwalic jak to duzo zrobila i jak duzo ma zamiar zrobic dzisiaj, ja jestem stworzona do siedzenia a nie stania pol godziny z uprzejma mina czekajac az barany se wygadaja
   c) "kierownicy" uzywaja ich zeby sie dowiedziec co robia ludzie w teamie, zeby poinformowac o czyms, dac ludziom czas na zadanie im pytan, zaplanowac release itd itp
   d) malo kogo obchodza problemy projektowe innych ludzi w zespole. a jesli obchodza to jako normalni ludzie rozmawiamy ze soba i te problemy rozwiazujemy a nie czekamy do standupu

2. planningi/progress:
   a) "granie w karty" to jakis ponury zart, jedna z bardziej zenujacych rzeczy w IT, nie jestem w stanie zrozumiec jak powazni dorosli ludzie moga odstawiac taka farse. po prostu zadanie bedzie zrobione jak bedzie zrobione, jestem w stanie powiedziec czy jest to quick hit, czy jest to na pare godzin czy na pare dni czy pare miesiecy. uzywanie do tego kart i punktow nic nie wnosi.
   b) burndown chart to kolejny idiotyzm ktory jest w stanie dzialac przy zalozeniu ze wszystkie taski sa podobnej wielkosci i sa rownomiernie rozlozone w sprintach. w praktyce nigdy nie wystepuje i analizujac 50 kolejnych burndown chartow mozna sobie wyciagac dowolne wnioski :)
   c) omawianie zmian na nastepny sprint to strata czasu dla doswiadcznych devow, oni wiedza co robic bez tego. mniej kumaci tylko udaja ze wiedza o co chodzi a i tak beda zawracac glowe pozniej
   d) wlasnie tak - nic tak nie poprawia mojej produktywnosci jak pol dnia (albo i wiecej) siedzenia na spotkaniu
   e) w srodku sprintu przychodzi user ktory chce dolozyc feature ktorego implementacja zajmie pol dnia ale oszczedzi kilka dni pracy paru osobom. sorry nie moge bo to wbrew wykresowi :D

3. reszta badziewia - demo/retro/review
   a) serio mam czekac do tego czasu z moimi problemami?
   b) serio ktos kto czeka na funkcjonalnosc dopiero wtedy dowie sie ze tak naprawde zajmie to 3x dluzej?
   c) again - co mnie obchodzi ze jozek przez 2 tygodnie nie moze dostac approvala na konto aplikacyjne, krysi zle z xmlem a andrzejowi udalo sie skonczyc pare rzeczy szybciej niz planowal

podsumowujac, nie lubie takiego pitolenia i udawania ze mamy proces i ze on dziala.
za kazdym razem po wpadnieciu na pomysl "wprowadzamy scruma" nie mija pare miesiecy jak dochodzi do sytuacji: "scrum", albo ja, i zwykle pada na mnie :( albo raczej :)
w niektorych firmach mialam ciche przyzwolenie na olewanie scruma i bardzo to sobie cenilam.

pracowalam dlugo w 5-7 osobowym zespole w ktorym istnianialo jedno zaplanowane 30 minutowe spotkanie tygodniowo, ktore zwykle konczylo sie juz po 5 bo po prostu nie bylo o czym gadac. w pare lat napisalismy od nowa prawie cale jdk + do tego kod biznesowy z licencja na 60+ gield, przetestowalismy i wdrozylismy na kilkuset serwerach podzelonych na kilkanascie data data centre. potem wszedl obowiazkowy scrum, my w miedzyczasie odeszlismy i potem po niecalym roku slyszalam ze nowy team ma juz kilkadziesiat osob dumnie pracujacych w scrumie nad ogarnieciem maintenance :D

Odnosnie estymat: http://www.commitstrip.com/en/2019/03/06/estimates/

Ja za to zauważyłem + się dowiedziałem od ludzi na odpowiednich stanowiskach, że scrum (nie określam jaki, określam ogólnie) czasem włazi do firmy, tylko po to, aby przed radą nadzorczą lub inwestorami powiedzieć "my pracujemy w scrumie". U zarania "dziejów" taki "tekst" powodował zdezorientowany wzrok osobistości dyskutujących przy stole, bo któż to wiedział wtedy co to za szamańskie zaklęcie pada (a nóż zaraz ktoś padnie martwy). Ale teraz to już taka prawie "normalka".

Niestety, ale to gorzej dla niższych szczeblem, bo jak siedzi taki zdezorientowany prezes rady nadzorczej, w otoczeniu 30stu członków i każdy się chwali, że ma scruma w swoich działkach, a 1-2 czy członków siedzi cicho (bo nie wiedzą co to jeszcze, lub właśnie wiedzą, ale nie chcą tego) to wiadomym jest, że spojrzenie pytające prezesa z cyklu "a wy co?" będzie przeszywające conajmniej. A nie daj Bóg zespoły tych dwóch "outsiderów" mają jakieś deadline i budżety zawalone (bez względu na przyczynę) - to prezes już wtedy wie, że to bankowo, że oni tego "scruma" nie mają!

I tak się żyje w tym IT potem...

Odnośnie roli Scrum Mastera - tutaj ciekawy artykuł na temat: https://mlynarze.com/jak-zostac-scrum-masterem/ .
Dodałbym tylko, że w tej roli naprawdę warto być technicznym, w przeciwnym wypadku nie wyobrażam sobie, żeby taki SM chociaż rozumiał o czym rozmawiaja developerzy.

Czy ktoś z Was programistów ma wątpliwości do tego że „scrum master ” to leser i nierób…?
Nie wiem ale się wypowiem... i musi być na moim to główna dewiza tych nieudaczników.
Zamiast utrzymywać tak niepotrzebne stanowiska lepiej te pieniądze przeznaczyć na premie dla tych do pracują :)

@PrzemysławWiśniewski: Dosyć skrajna opinia :) Być może spotykałeś się w swojej karierze ze Scrum Masterami leserami, ale w każdym zawodzie są osoby które migają się od pracy i odpowiedzialności jak i takie, które się do roboty przykładają i angażują. Wrzucenie wszystkich SM do jednego worka nierobów jest tak samo krzywdzące jak określenie wszystkich programistów mianem nerdów ;)

@Jarosław Łojko:

1. SM to leserzy i nieroby
2. Określenie nerd może być też pochwałą. Moja żona cały czas narzeka że prawdziwych nerdów coraz mnie
3. Widzę że zbierasz punkty na złotą łopatę :D

@KamilAdam: Spoko, każdy ma prawo do swojej opinii :) Chętnie podyskutuję, bo ciekaw jestem dlaczego tak uważasz? Co takiego robił/robiła SM z którym pracowałeś, że uważasz wszystkich za nierobów i leserów?
Ad. 3 - punkty na złotą łopatę? Hę?

Jarosław Łojko napisał(a):

Chętnie podyskutuję, bo ciekaw jestem dlaczego tak uważasz? Co takiego robił/robiła SM z którym pracowałeś, że uważasz wszystkich za nierobów i leserów?

To nie ma o czym dyskutować. W najlepszym przypadku SMi biorą kasę za nic nie robienie. W najgorszym powodują nowe problemy i ludzie się przez nich zwalniają. W rzadkim wypadku ludzie potrafią się postawić i SMi są zwalniani. Ale to widziałem tylko raz jak ludzie zarządali wyjaśniena co w zasadzie robią SMi a SMi nie umiejąc odpowiedzieć się zwolnili. W ten sposób pewna duża firma w Katowicach przestała mieć Scruma :D

To SM nie są sekretarkami do umawiania spotkań o_O?

TestWariat napisał(a):

To SM nie są sekretarkami do umawiania spotkań o_O?

Raczej do poganiania innych zespołów, pilnowania offtopu na spotkaniach, i tego, żeby zespół nie deklarował więcej roboty niż jest w stanie wykonać.

i tego, żeby zespół nie deklarował więcej roboty niż jest w stanie wykonać.

U nas robi to PM

UPDATE - PM pilnuje żebyśmy nie deklarowali więcej bo potem on musi świecić oczami :)

@KamilAdam: Nie wiem, czy to prawidłowe, ale też się nie znam, poza tym u mnie PMa nie ma. Jest SM i robi swoją robotę, tzn. wspomaga zespół w kwestiach organizacyjnych.