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
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@ATAT-2: No ale właśnie o to chodzi w zwinnych zespołach, ze w idealnym świecie cały zespół robi to co jest potrzebne żeby dowieźć cel, a wypina się na zasadzie „nie jestem testerem wiec nie będę testował, ja tu jestem od klepania kodu a jak nie odwiezieni zobowiązań bo akurat tester się rozchorował no to trudno, nie mój problem”. Więc zamiast przypisywania obowiązków sztywno do określonych osób każdy robi to co
  • Odpowiedz
@ATAT-2: ja p------e, ja myślałem, że typ pisze o Straży Miejskiej, bo na początku pisał o nienawiści do SM xDDD weźcie te informatyczne wysrywy tagujcie z góry xD
  • Odpowiedz
wiekszosc z tego co wymieniles to robi ogarniety PM


@a4z4a4: W Scrumie nie ma PMa. Jest PO, SM i autonomiczny zespół deweloperski. Jak masz PMa to nie pracujesz w Scrumie, i dyskusję o przydatności Scrum Mastera możemy zakończyć - bo jak nie pracujesz w Scrumie to rzeczywiście Ci Scrum Master niepotrzebny ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@Strus: no super, dokladnie o tym pisze. Zatrudnianie nowego czlowieka tylko po to zeby spelnic jakies wydumane zasady, bo inaczej to "hehe nie pracujesz w scrumie" jest bezsensowne. Mnie tylko smieszy to mega proceduralne podejscie. Celem jest wytwarzanie softu, a nie spelnienie postulatow z bibli scruma.
  • Odpowiedz
@Strus: rzeczywiscie, swietne porownanie. Gra zespolowa ze scisle okreslonymi zasadami, tak zeby grajace strony mialy te same szanse, vs proces wytwarzania oprogramowania. Literalnie to samo.

można mieć „autonomiczny” zespół z managerem nad głowa


@Strus: uwazasz, ze nie mozna miec autonomicznego zespolu bez sma?
  • Odpowiedz
@Strus: jeszcze dodam, ze dla ciebie najwyrazniej wartoscia jest sama praca w scrumie. Dla mnie wartoscia jest dowozenie oprogramowania. Jak mi ogranizacja (albo jej jakiś fan), ktora sie utrzymuje ze szkolen scrumowych, nie da certyfikatu, ze moj team pracuje w scrumie, to trudno, jakos to przezyje. Wazne zeby soft dzialal, a czy przy jego tworzeniu byl sm, czy go nie bylo, to jest kwestia trzeciorzędna.
  • Odpowiedz
uwazasz, ze nie mozna miec autonomicznego zespolu bez sma?


@a4z4a4: Uważam, że nie można mieć autonomicznego zespołu programistów, jeśli ten zespół ma managera, bo siłą rzeczy wtedy manager zarządza zespołem.

dla ciebie najwyrazniej wartoscia jest sama praca w
  • Odpowiedz
Uważam, że nie można mieć autonomicznego zespołu programistów, jeśli ten zespół ma managera, bo siłą rzeczy wtedy manager zarządza zespołem.


@Strus: to nie jest odpowiedz na moje pytanie. Co ma obecnosc managera do obecnosci sma? Uwazasz, ze jak nie ma sma, to oznacza, ze koniecznie musi byc manager, ktory zarzadza zespolem i mowi kazdemu co ma robic?

Bo jak nie pracujesz w Scrumie, to rzeczywiście jest Ci Scrum Master niepotrzebny.
  • Odpowiedz
Co ma obecnosc managera do obecnosci sma? Uwazasz, ze jak nie ma sma, to oznacza, ze koniecznie musi byc manager, ktory zarzadza zespolem i mowi kazdemu co ma robic?


@a4z4a4:
Upraszczając:
1. Jak zespół nie ma Scrum Mastera to nie pracuje w Scrumie
2. Jak zespół chce pracować w Scrumie, to nie powinien
  • Odpowiedz
Upraszczając:

1. Jak zespół nie ma Scrum Mastera to nie pracuje w Scrumie

2. Jak zespół chce pracować w Scrumie, to nie powinien mieć managera

3. Jak zespół chce pracować w Scrumie, to powinien mieć Scrum Mastera


@Strus: dalej masz problem z odpowiedzia na moje pytanie. Czy brak sm powoduje, ze musisz miec managera, ktory zarzadza zespolem. To jest proste pytanie tak/nie. Podpowiem ci, ze z doswiadczenia wiem, ze nie musisz i mozna miec autonomiczny zespol bez sma. Serio, ci debile nawet tego
  • Odpowiedz
Dotyczy raczej tego, czy 100% implementcja i kurczowe trzymanie sie procesu scrumowego jest niezbedne do wytwarzania oprogramowania i czy przynosi efekty, ktore przewyzszaja koszty z tym zwiazane


@a4z4a4: Nie, pomyliłeś wątki.
  • Odpowiedz
@ATAT-2: no to chyba faktycznie nic potrzebnego nie robi, bo zamówić jirę to ja mogę w 2 godz., a na te ceremonie mozemy sie umowic sami w zespole, tak samo organizowania jakis tam spotkan. A od zglaszania problemow to jest lider.
  • Odpowiedz
@aczutuse: no spoko, właśnie więc rozdystrybuowales cześć zadania scrum mastera pomiędzy innych pracowników. Idąc tym tokiem rozumowania możesz zastąpić każdego pracownika dowolna ilością innych, pytanie tylko czy ma to sens i czy się opłaca
  • Odpowiedz