The 2020 Scrum Guide™(TM) to jakiś troll?

Nie większy niż sam Scrum

Ze scrumem jest jak z dziedziczeniem w programowaniu obiektowym lub z testowaniem jednostkowym. Ludzie nie zrozumieli, zrobili dużo patologii i teraz trzeba wymyślić nową nazwę, bo stara już jest spalona.

Scrum jest zacny w teorii. Jak trójpodział władzy - ustawodawcza (Product Owner, bo mówi, co ma być zrobione), wykonawcza (Developerzy), sądownicza (Scrum Master, bo pilnuje, żeby proces Scruma był dobrze prowadzony). W teorii to wygląda dobrze i sprawiedliwie, a w praktyce nie do końca. W polityce albo jedna partia się dorwie do władzy (i jest źle), albo wiele partii walczy ze sobą (i też jest źle, bo intrygi, zakulisowe zagrania, sabotaże itp.). W programowaniu zwykle jest to drugie i brak jasnego przywództwa, a Scrum zamiast temu zaradzić, to jeszcze bardziej mydli oczy i tworzy jakieś pseudostanowiska, a i tak wiadomo, że ktoś musi w firmach rządzić, zlecać programistom robotę (chyba, że programiści sami by się rządzili jak w jakichś startupach założonych przez programistów)

@LukeJL: piękne porównanie. Pozwolę sobie ukraść na potrzeby prezentacji :)

@Koziołek spoko :)

Już czuję jak w kalendarzu pojawia mi się nowe spotkanie/prezentacja/szkolenie jakiegoś scrum slejva o nowych wytycznych, których będziemy musieli się koniecznie trzymać~

Firmy nie wiedzą co to jest praca w scrumie. Dla nich to daily, retro, burnout chart i pierdzielony mikro management z każdej strony. Jesteśmy scrum, ale tickety mamy bez specyfikacji, czytaj w myślach jakie potrzeby ma klient,a jak się spytasz PO/PM, czy klienta, to sami nie wiedzą co chcą, ale ticket mamy, wyceniliśmy ticket bez nawet pobieżnej wiedzy jak się za niego zabrac, jesteśmy agile.

Causing the removal of impediments to the Scrum Team’s progress - "nie widzę przeszkód, byś nie dowiózł tematu na czas" ;) Scrum to ładny hłyt martetingowy dla korpo, by móc non stop inwigilować pracę developerów tłumacząc to "transparensi end mejking constant impruwments" ;)

@urke ogólnie wycenianie tasków to jeden z największych absurdów IT. Kurczę, wyceniać to można rzeczy, które się już kiedyś robiło (albo robiło się coś podobnego), a nie rzeczy, do których człowiek nie wie, jak się zabrać i czy mu to zajmie 5 czy 50 godzin... Sprawę dodatkowo pogarszają grupowe estymacje - jeżeli w ogóle bawić się w estymację, to estymować powinien ten, kto to będzie docelowo robił, a nie cała grupa. Panuje jakiś dziwny pogląd, że estymacje są obiektywne (podczas gdy ten sam task może być zrobiony przez jedną osobę 5 godzin, bo będzie znała projekt/temat, a przez drugą 50, bo będzie musiała się wdrożyć)

Weź przestań mnie rozbrajać, dziewczyna która była niby PMem w ostatnim projekcie została scrum masterem. Narobiłam się za 3 osoby łącznie z tym że za nią, a jak odchodziłam ostatnie zdanie jakie przeczytałam od niej to "nie wiem ile userow jest w systemie" przez cały okres developowania było to zapisane na ścianie przed którą siedziała.:-D

@kate87: patrzcie jaka bezczelna! ale czego oczekiwać po kimś kto uważa, że witam jest tak chamskie i bezczelne że brak słów.?

Gdzie widzisz coś bezczelnego?

@kate87: możesz wyłączyć swój komputer?

@Anna Lisik: @kate87 : Truskawkowy czy malinowy?

"Scrum Masters are true leaders" no to problem dla wszystkim SMów, którzy zostali nimi "w nagrodę", bo trzeba było ich jaknajszybciej osunąć od kodu.

@AreQrm: co? Znaczy domyślam się, ale jeśli tak to ja rezygnuję......

@LukeJL: Szacowanie trudności zadania przy ustalonych punktach odniesienia jest obiektywne i jak najbardziej może być robione grupowo. Trudność zaczyna się, gdy ktoś przelicza story point na godziny bez uwzględnienia wydajności pracownika, ale wtedy problemem nie są estymaty, tylko ich nieumiejętne użycie. Estymatę powinno podawać się jako "jeżeli mam zespół X pracowników pracujących wyłącznie nad zadaniem Y, to szansa na zakończenie zadania do dnia Z wynosi P%", a nie jakieś opowieści, że coś zajmie "X godzin". wyceniać to można rzeczy, które się już kiedyś robiło (albo robiło się coś podobnego), a nie rzeczy, do których człowiek nie wie, jak się zabrać i czy mu to zajmie 5 czy 50 godzin - zawsze mnie bawi, jak programiści uznają swoją pracę za tak niepowtarzalną, że aż nie da się oszacować skali trudności. Tylko czekam, aż inne branże to przyjmą i hydraulik kiedyś mi powie, że "to kolanko zajmie 5 a może i 50 godzin".

Nie jest obiektywne, te same rzeczy mogą być łatwiejsze dla jednych, a trudniejsze dla innych. Ludzie mają różne umiejętności oraz predyspozycje. Idąc już w takie metafory remontowe - to nie bez powodu są hydraulicy, elektrycy itp. I jak chcesz wiedzieć, ile czasu zajmie wymiana kranu, to pytasz hydraulika, a nie elektryka. Jak kiedyś w Scrumie pracowałem, to zdarzało mi się, że backendowcy szacowali prace frontendowe (i to bardzo nisko, bo przecież "to tylko frontend, co w tym trudnego?" - a potem okazało się, że opis taska nie uwzględniał dodatkowych wymagań, a całe zadanie okazywało się trudniejsze, szczególnie ze względu na spaghetti kod w projekcie - i potem wychodziło na to, że za mało punktów historii dowożę, bo przecież brałem się za taska, który został wyceniony nisko, a robiłem go długo xD co prawda wtedy miałem niższe skille, ale i tak myślę, że te taski były mocno niedoszacowane). Ale i odwrotnie - będąc frontem + nie mając pojęcia o projekcie musiałem wyceniać taski backendowe, w zasadzie w ciemno (kierując się opiniami innych). To była jedna wielka parodia.

@Afish Chociaż myślę, że estymacje mogą być spoko (ale właśnie, jak się ocenia coś podobnego do czegoś, co się już robiło - trochę nie rozumiem twojego zdania zawsze mnie bawi, jak programiści uznają swoją pracę za tak niepowtarzalną, że aż nie da się oszacować skali trudności - bo wydaje mi się, że potwierdza to, co ja napisałem. Jak robiłeś kiedyś coś podobnego, to praca staje się powtarzalna, więc można ją jakoś oszacować. Ale z drugiej strony jak musisz zrobić coś w technologii, którą słabo znasz, albo w projekcie, którego nie rozumiesz (szczególnie jeśli to spaghetti), albo jeśli musisz zmagać się z bugami, albo wymagania nie są precyzyjne itp. - to oczywistym jest, że ta piękna estymacja się rozleci za chwilę, bo za dużo jest czynników, które wpływają na pozytywne ukończenie taska. Wystarczy, że ktoś nie odpisze ci na mejla i już jesteś przyblokowany...)

@LukeJL: Opowiadasz o patologiach i dziwisz się, że Scrum nie działa. Ludzie mają różne umiejętności oraz predyspozycje Tak, ale trudność jest od tego niezależna. Zrobienie jednego kolanka jest łatwiejsze od dziesięciu kolanek, niezależnie od tego, czy jesteś hydraulikiem, czy kierowcą rajdowym. backendowcy szacowali prace frontendowe (...) potem okazało się, że opis taska nie uwzględniał dodatkowych wymagań - typowa patologia, szacuje się jedno, a robi drugie. Ale czy temu Scrum winien? A jakbyś robił w modelu kaskadowym, to byłoby inaczej? będąc frontem + nie mając pojęcia o projekcie musiałem wyceniać taski backendowe, w zasadzie w ciemno - ponownie, czy to wina Scruma? Ja nie jestem z tych, co to zawsze twierdzą, że "robicie Scruma źle", ale jak już robi się estymaty w taki skopany sposób, to nie ma znaczenia, czy to Scrum czy inna metodyka, bo wychodzi tak samo kijowo. wydaje mi się, że potwierdza to, co ja napisałem - nie, nie potwierdza. Twoja znajomość technologii nie wpływa na trudność zadania przy estymacji w story pointach. To wpływa na przeliczanie story pointów na godziny, wtedy trzeba uwzględniać staż, znajomość technologii i wszystko dookoła. albo wymagania nie są precyzyjne - no jak masz nieprecyzyjne wymagania, to planowanie często nie wyjdzie, ale ponownie - to nie jest wina Scruma.

@Afish jeżeli mam zespół X pracowników pracujących wyłącznie nad zadaniem Y, to szansa na zakończenie zadania do dnia Z wynosi P%", a nie jakieś opowieści, że coś zajmie "X godzin". jaka różnica? tu i tu się strzela że coś się uda zawsze mnie bawi, jak programiści uznają swoją pracę za tak niepowtarzalną, że aż nie da się oszacować skali trudności. to że od strony technicznej taski są banalne / robione nty raz wcale nie oznacza że od np. zdobycia know how biznesowego nie było to czasochłonne. Usłyszysz zadanko przepchać dane z systemu A do B i pomyślisz 5h roboty + na oglądanie kotów w necie starczy, a miesiąc później dalej nie skończone :D

@WeiXiao: jaka różnica? tu i tu się strzela że coś się uda Jeżeli patrzysz z perspektywy osoby technicznej, to nie ma różnicy, ale osoby nietechniczne słysząc "to zajmie X godzin" traktują to jako pewnik. Tak samo jak programista słyszy "czy da się to zrobić do X", to w głowie szuka argumentów na udowodnienie "niemożliwe jest zrobienie tego do X", więc nawet jak szansa jest mała, to potwierdzi, pewnie czymś w rodzaju "no tak, da się, jeżeli będziemy mieli wymagania itp itd", a druga strona wtedy słyszy "do X będzie zrobione". To jest tylko przykład mechanizmu, żeby mi tu ktoś nie wrzucał zaraz argumentów "a ja wcale tak nie słyszę", jedynie pokazuję różnicę w komunikacji przez zastosowanie ekstremum. Ale jeżeli przedstawisz wycenę jako "mając X ludzi pracujących tylko i wyłącznie nad Y, to szanse na zrobienie do Z wynoszą P", to wtedy przekaz ten jest o wiele bardziej klarowny (szczególnie, jeżeli P jest rzędu dziesięciu procent).

Usłyszysz zadanko przepchać dane z systemu A do B i pomyślisz 5h roboty - tu świetnie widać, że mówimy o różnych rzeczach. Masz oszacować skalę trudności, a nie liczbę godzin. Skala trudności siłą rzeczy wymaga punktów odniesienia, więc musisz umieć uargumentować, że najprostsze było zadanko A polegające na czymś tam, najtrudniejsze było zadanko Z polegające na czymś innym, a to obecne zadanko to umlaut. To jest zgodne z wiedzą tłumu (bo w ogólności ludzie w zespole prawdopodobnie zgadzają się co do stopnia skomplikowania) i to spokojnie można oceniać grupowo. Teraz jeżeli chcesz przetłumaczyć poziom trudności na liczbę godzin, to musisz mieć przeliczniki uwzględniające skomplikowanie systemów A i B, umiejętności inżyniera pracującego nad zadaniem, liczbę okolicznych świąt, okres wakacyjny i masę innych rzeczy. Jeżeli zadanka A i Z dotyczą tych samych systemów, to przelicznik będzie dokładniejszy (i można tam dodać jakiś dodatkowy mnożnik odpowiadający za "bo system A to dinozaur i używa jakiejś pogańskiej corby"), dodatkowo dodajesz próg niepewności ("bo system B może używać jakiegoś własnego szyfrowania i nagle się okaże, że trzeba to dekompilować") i wreszcie przekazujesz biznesowi informację "jak będę pracował tylko nad tym, to na P procent zajmie to T tygodni". Co więcej, prostsze zadanie może zająć więcej czasu, przykładowo "poprawienie dokumentacji" jest zapewne mało złożone, ale bardzo czasochłonne.

No i na samym końcu wracamy do faktu, że to tylko szacunki. To nigdy nie będzie precyzyjne (a szacowanie przez eksperta jest w praktyce często chybione), są inne metody na planowanie projektów (chociażby Monte Carlo i szukanie ścieżek krytycznych), ale ciągle da się to robić i można na tym opierać plan pracy. Tylko trzeba to robić sensownie, a nie estymować w godzinach zadanie bez wymagań, a potem dziwić się, że zamiast pięciu godzin było pięćdziesiąt.