Wpis z mikrobloga

Kij tam, niech stracę. Ogólnie jak ktoś zaczyna dyskusję (tutaj o #scrum i SM) to powinien posiadać elementarną wiedzę o temacie a nie głośno krzyczeć powtarzając przy okazji 'W sumie nie wiem jakie sa obowiązki SM' bo to jest idiotyczne podejście.
Ale macie, uprzedzając pytanie co dwa dni 'Czym zajmuje się SM' wkleję tu mój komentarz na przykładzie mojego projektu:

Zacznijmy od tego, że nie jestem SM (co niektórzy hejterzy mi tu przypisują tylko dlatego, że nie zgadzam się z ich ślepą nienawiścią do tej pozycji). Pracowałem jednak z nieudacznymi scrum masterami (którzy byli nimi tylko z nazwy) oraz naprawdę ogarniętymi, którzy robili dużą różnicę w projekcie. Mogę Ci więc opisać kilka obowiązków i działań które przyczyniły się do poprawy jakości naszej pracy, ogólny zarys można wygoglować szukając pierwszej lepszej oferty lub opisu stanowiska.

(z góry przepraszam za wklejanie angielskiej terminologii ale od lat pracuję w zagranicznych firmach i nawet nie mam pojęcia jak i czy tłumaczy się niektóre zwroty)

- Dobór narzędzi - zmienialiśmy przestarzałego bug trackera (na który narzekaliśmy na kilku retro ale o tym za chwilę) i SM nadzorował proces. Szukał innych rozwiązań, rozmawiał z firmami, ostatecznie poszliśmy w Jirę i on ogarniał potrzebne nam funkcjonalności co by potem przekazać wiedze mniej doświadczonym pracownikom na szkoleniach, tworzył dashboardy ogólnofirmowe, pomagał z tymi teamowymi itd. Teraz jest contact pointem między supportem Jiry a naszą firmą.

- Nadzór na sprintami aby działać wg scrumowej metodologi - wcześniej pracowaliśmy w czymś w rodzaju waterfalla który nawet nim nie był. Totalny chaos. SM wprowadził scrum, zaznajomił nas z nim i aktualnie pracuje się o niebo lepiej. Sprinty są uporządkowane, przejrzyste, ze ściśle określonymi goalami, sm pilnuje ile ticketów chcemy wziąć do sprinta (przy kooperacji z PO) tym samym nie kończymy z kupką nieruszonych spraw.

- Nawiązując do tego - sprawowanie 'pieczy' nad naszym velocity i burndown chartami dzięki czemu zespół nauczył się już ile może w sprincie zrobić i czego się wystrzegać podczas planningów.

- popularne 'impediment remover' - SM jest u nas osobą kontaktową jeśli masz problem ze sprzętem, procesem, softem, w organizacji. Nie wiesz do kogo zgłosić się bezpośrednio, rozmawiasz z SM i on to eskaluje lub pomaga. Często sam myśli o potencjalnych przeszkodach które napotkamy (np. zaczynając nowy feature) i zawczasu rozwiązuje problemy które jeszcze nie powstały.

- nadzorowanie spotkań - rolą SMa nie jest prowadzenie spotkać (co większość tu zarzuca) ale sprawianie, żeby były wartościowe. I tak, powie czasem na daily żebyście kończyli i przenieśli dyskusję do prywatnej rozmowy i to jest jak najbardziej ok bo w innym wypadku 6 osób siedzi i słucha kłótni dwóch devów przez 10 minut na tematy o których nie mają pojęcia / zupełnie ich nie interesują.

- retrospective i sprawianie, żeby były to wartościowe spotkania - wcześniej mieliśmy coś na wzór retro ale polegało to na narzekaniu na firmę, procesy. I tyle z tego było. Aktualnie masz pewność, że jeśli coś przeszkadza lub masz dobry pomysł to ktoś się tym zajmie. Efektem finalnym spotkań są ZAWSZE akcje które zazwyczaj są ruszane do następnego retro (czyli w góra 2 tygodnie widzisz jakiś rezultat).

- i te mityczne sprawowanie pieczy nad pracą wg metodologi scrumowej - nie wiem czemu tak wielu to boli ale pracujecie wg pewnych zasad i reguł i ktoś musi tego pilnować. Było tak zawsze i wszędzie - niezależnie czy pracowaliście w kanbanie, waterfallu czy nawet czymś bez nazwy, zawsze jest ktoś to musi tego pilnować. Tu robi to SM bo posiada odpowiednią wiedzę.

I wiele wiele innych

To tak 'pokrótce' jak to wygląda u mnie w zespole. Z tego co widzę większość hejtu i wyśmiewania tutaj wywodzi się z powielania zupełnie nieprawdziwych mitów lub wcześniejszej styczności z SMami którzy nimi być nie powinni i nie robili tego co do nich należy.

Także pora na mnie

#pracawit #pracbaza #programista15k
  • 42
@ATAT-2: no spoko, problem problem polega wlasnie na tym, ze wiekszosc smow jest bezuzyteczna i nie wie co ma robic. To po pierwsze, a po drugie to wiekszosc z tego co wymieniles to robi ogarniety PM i nie potrzeba dodatkowego kola u wozu w postaci roli oddzielnego sma. Takze nawet to co opisujesz to jest uposledzony PM z waskim scopem.
Takze nawet to co opisujesz to jest uposledzony PM z waskim scopem.


@a4z4a4: Połowa zadań nijak ma się do roli PMa, druga połowa odnosi się ściśle do scruma. Na pewno każdy PM byłby zachwycony gdybyś mu naglę na głowę zwalił takie obowiązki.

@stefan_pmp: No spoko, tylko ja nie o tym. Znam też nierobów programistów, QAów którzy ledwo komputer potrafią odpalić, PO bez elementarnej wiedzy o produkcie ale wciąż to są
Połowa zadań nijak ma się do roli PMa, druga połowa odnosi się ściśle do scruma


@ATAT-2: bo kto tak powiedzial? Biblia scruma?

Na pewno każdy PM byłby zachwycony gdybyś mu naglę na głowę zwalił takie obowiązki.


@ATAT-2: ile godzin tygodniowo wedlug ciebie te wymienione obowiazki powinny zajac?
@ATAT-2: bo kto tak powiedzial? Biblia scruma?


@a4z4a4: No nie, zdrowy rozsądek i zakres obowiązków PMa. Nawet nie pracując w Scrumie wymienione przeze mnie zadania nie należą do obszaru PMów.


@NoMoreTearsJustSmile: A jednak na etacie pracują. I jednak największe firmy IT wolą powierzać te obowiązki SM a nie PMom. I ponownie - dałem tylko kilka przykładów w czym SM pomógł naszemu projektowi, to nie jest cały zakres obowiązków.
No nie, zdrowy rozsądek i zakres obowiązków PMa. Nawet nie pracując w Scrumie wymienione przeze mnie zadania nie należą do obszaru PMów.


@ATAT-2: mam nadzieje, ze zdajesz sobie sprawe, ze nie jestes tutaj zadna wyrocznia i w roznych firmach obowiazki pma moga sie roznic? Wiesz, ze to nie jest zadne stanowisko uregulowane prawnie i jak sie uzna, ze "zarzadzanie burndown chartami" (xd) jest w gestii PMa, to PM sie bedzie tym
jednak największe firmy IT wolą powierzać te obowiązki SM a nie PMom.


@ATAT-2: no spoko, ale wiesz jak tam te role dzialaja? Bo ja mialem doczynienia z smami i w tych tech korpo i w roznych innych firmach. I tak w tych duzych firmach to ma wieksze szanse na dzialanie, bo po pierwsze sa tam zatrudniani ludzie na wyzszym poziomie, a po drugie ich zakres jest inny, sa zwykle raczej coachem
mam nadzieje, ze zdajesz sobie sprawe, ze nie jestes tutaj zadna wyrocznia i w roznych firmach obowiazki pma moga sie roznic?


@a4z4a4: Brawo, bardzo odkrywcze to co napisałeś.
Tylko idąc Twoim tokiem rozumowania obowiązki QA można zwalić na deva (niech testują swoje zmiany nawzajem) a Lead Engineer przejmie schedę po PO bo 'po co nam ktoś nietechniczny w projekcie'.

Tylko co starasz się przekazać? Że można usunąć pozycję scrum mastera dowalając
QA można zwalić na deva (niech testują swoje zmiany nawzajem)


@ATAT-2: yyyy, ale ty wiesz, ze to jest powszechna praktyka?

Lead Engineer przejmie schedę po PO bo 'po co nam ktoś nietechniczny w projekcie


@ATAT-2: to sa dwa calkiem odmienne skillsety, to po pierwsze, a po drugie to sa role, ktore zwykle wymagaja wiekszych nakladow pracy niz "zarzadzanie burndown chartami".

Tylko co starasz się przekazać? Że można usunąć pozycję scrum
yyyy, ale ty wiesz, ze to jest powszechna praktyka?


@a4z4a4: Super, a czy prawidłowa? Nie powiedziałbym.

ktore zwykle wymagaja wiekszych nakladow pracy niz "zarzadzanie burndown chartami".

nie masz kasy albo mozliwosci zatrudnic kogos ogarnietego (z faktycznym doswiadczeniem w dostarczaniu softu, nie w "zarzadzaniu burndown chartami")


@a4z4a4: ehh widze musisz na każdym kroku pokazać swoją ignorancję (lub niewiedzę w temacie) przez co z każda wypowiedzią co raz mniej chce mi się
Super, a czy prawidłowa? Nie powiedziałbym.


@ATAT-2: ale wiesz, ze w duzej czesci zespolow w tych wielkich firmach, na ktore sie dopiero co powolywales, nie ma dedykowanego QA? To jak, jednak nie wiedza najlepiej? Czy moze testowanie oprogramowania to jest integralna czesc jego wytwarzania i nie ma sensu jej rozdzielac?

widze musisz na każdym kroku pokazać swoją ignorancję


@ATAT-2: bede sie tego czepial, bo nadal sie nie doczekalem twojej estymaty
bede sie tego czepial, bo nadal sie nie doczekalem twojej estymaty ile czasu te wymienione zadania powinny zajmowac czasu ogarnietemu PMowi, ktory i tak juz bierze udzial w spotkaniach typu retro, planning?


@a4z4a4: jprdl xD
Może jeszcze kawkę i pizze Ci zamówić co by moje posty przyjemniej się czytało?
Czy może inne życzenia pan ma?
@a4z4a4: Poważnie? Nie raczyłeś nawet wygoglowac sobie zakresu obowiązków SMa, teraz żądasz ode mnie przedstawiania jakiś dupnych estymatów co byś raczył kontynuować dyskusję. Pytam więc czy coś jeszcze dla pana mogę zrobić co by pan chciał zaoferować mi przywilej rozmowy?

Do tej pory nie przeczytałeś ze zrozumieniem mojego pierwszego posta i wciąz powielasz mity zamiast konstruktywnie rozmawiać także przeprasza, że nie będę skakać jak mi zagrasz. Sam sobie estymaty zrób i
@ATAT-2: Ładne podsumowanko. Nieomylne ameby developerskie z przerośniętym ego myślą, że ktoś im da taska, będą go sobie kisić 2 miesiące, łaskawie go w końcu zrobią jak im się będzie chciało i na pewno będzie gitarka. Najlepiej bez kontaktu z kimkolwiek przez ten czas. A już na pewno nie są gotowi na jakiekolwiek zmiany w prowadzeniu projektu, bo dostają skrętu kiszek na samą myśl. Będą rzeźbić tygodniami w piwnicy, a na
@a4z4a4: @ATAT-2: @NoMoreTearsJustSmile: różnica PM, SM, to różnica pomiędzy dobrym policjantem (SM), a złym policjantem PM. SM uczy zespół jak wziąć odpowiedzialność za projekt i estymacje, tak żeby dowozili commitment który zrobili na planowaniu i estymacji, zachęca, daje marchewkę, ale sam SM nie zajmuje się drugą stroną marchewki czyli kijem, bo to odpowiedzialność PM, czyli zwykle odłączaniem przez PM najsłabszych ogniw od lokomotywy sprintu. Czyli SM ma za zadanie