[awful2]

Właśnie nowa skrum masterka powiedziała na daily, że za wolno sie odmutowujemy. Teraz wszyscy siedzą z włączonymi mikrofonami. Wiadomo, od hindusów słychać wszystko w tle, od pociągu, przez krzyk dzieci i walenie garami. Chińczyk siorbie herbatę. Przyjemnie się zrobiło. Na pewno jest lepiej xD #programista15k

[Jednobrewy]

@awful2: To co opowiadasz to jest pseudo Scrum w najlepszym wypadku. Jest tutaj tak wiele błędów, że głowa mała. SM w ogóle nie musi być na daily. SM nie prowadzi daily nawet jeżeli jest. SM zanim wdroży zmianę powinien skonsultować ją z zespołem i znaleźć kompromis. Daily nie służy do raportowania czy meldowania się. Zespół nie może mieć więcej niż 10 osób. A to tylko z tego co napisałeś, pewnie

[awful2]

@Jednobrewy: w wielu firmach byłem i jeśli zespół był "starej daty" - na początku pozytywnie nastawiony do skurma to bardzo szybko się z tego wycofał. Zaproponowana ilośc spotkań była przerostem formy nad treścią. Ostatecznie najlepiej działa dobrze wdrożona jira i planning raz na kwartał. Nawet już nie ma daily, jest tylko daily raz na tydzień i trwa godzinę. No ale to zespół super-seniorów, pracujących 15+ lat w tym środowisku. W

[Jednobrewy]

@awful2: I to też robota SM, pilnować czasu spotkań oraz ucinać zbędne dyskusje. Daily ma trwać max 15 minut niezależnie od wszystkiego. Jeśli są jakieś tematy to np. na refinement wrzucimy albo dwie osoby zostaną po daily i niech sobie omówią. Inna sprawa, że nie każdy musi lubić Scruma, nawet tego dobrze wdrożonego, są inne opcje. A nową Panią SM proponuję wysłać na szkolenie ze Scruma, może da się oszlifować

[JazzBlurr]

@awful2 jeśli to nie bajt to niezła idiotka

[Shatter]

@awful2 ale to wy rozumu nie macie własnego czy co?

[enzomatrix]

@Jednobrewy: Te opisy to dla mnie abstrakcja, mógłbyś opisać od A do Z jak w ogóle wygląda taka praca? Może na przykładzie jakiegoś projektu jaki realizowałeś?

[Devasto27]

@awful2: Marzy mi się przebranżować na scrum mastera i robić spotkania 3 minuty w których chwalę wszystkich i mówię żeby robili swoje i #!$%@? ja w was wierze chłopaki.

[awful2]

@Shatter: no ale Ty myślisz, że my jesteśmy idiotami i jej słuchamy? To są jej propozycje na które się upiera, a czy zespół się do tego stosuje to inna sprawa.

[Boska_Klaudia]

@awful2: BTW, o której wy macie to daily z Chińczykami i Hindusami i czy tam idzie cokolwiek zrozumieć?

[awful2]

@Boska_Klaudia: tak, żeby wszystkim pasowało
https://www.worldtimebuddy.com

[oszty]

@awful2: hindus wie, chińczyk też tylko Polak nie ogarnął że też musi jakieś dźwięki ulicy sobie puścić żeby pomysł szybko upadł xd

[renq]

@lokloklok: nie do końca tak, że SM wprowadza rzeczy i przeorganizowywuje procesy. Znaczy tak, ale nie zawsze i najczęściej nie wprost.
Jego główną rolą jest zadbanie o to, żeby zespół sam się usprawniał i szedł w kierunku empiryzmu i zdrowego rozsądku. To jest o wiele trudniejsze, za to trwalsze. Bo ludzie inaczej traktują narzucony sposób pracy i inaczej, gdy sami go wypracują.

[Jednobrewy]

@enzomatrix: Jasne, spróbuję ci to jakoś opisać bardziej bezpośrednio. Z góry zaznaczam, że nie należy tego traktować jako autorytet, coś wiem, ale do eksperta mi daleko :)

Przyjmijmy, że sprint trwa u nas 2 tygodnie. Projekt już trwa, trochę jest zrobione, mamy rozpisane mnóstwo rzeczy w backlogu do zrobienia. Zespół (Scrum Team) składa się ze Scrum Mastera, Product Ownera oraz developerów (mniej niż 10). Mając na myśli developerów ma na myśli frontów, back, UX, QA, fullstack, analityków - wszystko. Założenie jest takie, że dany zespół powinien móc zrobić wszystko bez delegowania zadania na zewnątrz.

Jest poniedziałek, godz. 9:00, zaczynamy planning. Książkowo powinien trwać max 4h, ale nam wystarcza zwykle godzina, na wszelki wypadek zaklepane mamy 2h w kalendarzu. Przychodzi Scrum Team, można zaprosić kogoś dodatkowo w roli konsultanta. PO określa cel sprintu "wypuszczenie pełnej wersji 0.XYZ". Otwieramy narzędzie projektowe (Jira, Azure DevOps, Asana, etc.) i tam jest backlog, gdzie na górze mamy rzeczy najistotniejsze, a im niżej tym mniej - o kolejność dba PO. Developerzy znając Sprint Goal wybierają poszczególne itemy z backlogu tak, aby spełnić cel. Każdy item ma wartość punktową (o tym później). SM powinien się upewnić, że developerzy rozumieją rozpisane zadania. Wybierają ich tyle, aby zapełnić swoje "capacity", czyli to, ile są w stanie zrobić, wyznacza się je z biegiem czas na bazie poprzednich