[q.....q]

scrum = rak
#takaprawda #programowanie #scrum

[tell_me_more]

@qwarqq: tak uważają ludzie, którzy nie doświadczyli waterfalla :)

[mktos]

@qwarqq: kurcze często spotykam się z niechęcią do scrum'a, zastanawia mnie to... Jaki jest twój powód?

[ppawel]

@qwarqq: przejdź do projektu "mamy swój LEPSZY proces", to będziesz błagać o kanonizację scruma

[PiotrekSul]

kurcze często spotykam się z niechęcią do scrum'a, zastanawia mnie to... Jaki jest twój powód?

@mktos: taki że mało który projekt i organizacja nadają się pod idealną książkową metodykę a bardzo często osoby wdrażające scruma do siebie na siłę starają się wepchnąć go w wersji książkowej co skutkuje problemami a później zniechęceniem do samej metodyki.

[ppawel]

scrum = rak

@qwarqq: Rozumiem, że piszesz to jako doświadczony dev a nie troll (w końcu #bordo zobowiązuje), i jesteś w stanie swoje stanowisko poprzeć jakimiś spostrzeżeniami, a może nawet zilustrować przykładami? Spodziewam się bowiem, że trzeba trochę takich doświadczeń "zkolekcjonować", aby wyrobić sobie tak jednoznaczne stanowisko.

[q.....q]

@tell_me_more: waterfall wydaje sie znacznie logiczniejszy, serio.

@mktos: Bo scrum masterzy przekładają organizacje nad pracę i jak to każdy PM myślą że jak do zadania przydzielą N developerów, to czas zmniejszy do 1/N zakładanego czasu. Co więcej wymagają takiego dzielenia się zadaniami, co powoduje że jeszcze więcej czasu palimy na bezsensowną komunikację, i rzeczy do rozwiązania w 30 min ciągną się całymi dnami, bo trzeba zadanie przekazać i

[ppawel]

Ale 300godzin na spotkania już spalone

scrum masterzy ... zadania przydzielą N developerów

@qwarqq: Obawiam się więc, że nie jest to żaden scrum, tylko jakiś nowotwór... Przykładowo: scrum określa limity czasowe na każde spotkania, w żadnym razie SM też nie powinien zajmować się rozdzielaniem zadań. Poczytajcie sobie "Scrum Guide" http://www.scrumguides.org/download.html i zobaczcie jak wiele rzeczy nie będzie się zgadzać z tym co wam narzucono, zbierzcie wszystko do kupy i zgłoście

[q.....q]

@ppawel:

Przykładowo: scrum określa limity czasowe na każde spotkania

Oczywiście, standupy ( mimo zaleceń do 15min) zamykają się w 30minutach. Za duży team. Za to retro i planning to praktycznie zawsze całodniowe

[meohaw]

@qwarqq: to nie hejtuj procesu, tylko waszą jego implementację

[tell_me_more]

waterfall wydaje sie znacznie logiczniejszy, serio.

@qwarqq: tak, o ile masz specyfikację wyrytą w kamieniu zanim zaczniesz cokolwiek implementować. Jeszcze nie miałem takiej sytuacji, ale może kiedyś się zdarzy :)

[q.....q]

@meohaw: hmm... kazda implementacja z która spotkałem się była irytująca i nieefektywna, magia. I taką argumentację słyszę zawsze jak ktoś narzeka na scruma, "że scrum jest super, ale wasza implementacja jest zła". A może po prostu metodyka jest do kitu, skoro każda implementacja nie do końca ją wciela? Może metoda jest bezużyteczna, skoro tak łatwo przekręcić jej założenia i tworzyć metodyczne raki palące setki godzin? Nie, na pewno to problem

[meohaw]

@qwarqq: idk, pracowałem w scrumie w 4 różnych firmach, i zawsze było generalnie w porządku. zdarzało się, że retro czy planning trwały dłużej niż powinny (w zalezności od firmy) i to w sumie tyle, a jak porównam do tych firm gdzie pracowałem bez scruma, no to w ogóle nie ma o czym rozmawiać, chaos, chaos, chaos, bez scruma sam chaos (odrobinę dramatyzuję, ale tylko odrobinę).

[fhsdjklvgnasiogfy]

@qwarqq: No sorry ale jak wam narzucają sposób mergowania i akceptacji PRów to to nie ma nic wspólnego z niczym agile, ani scrumem. Pierwsze z listy agile manifesto: Individuals and interactions over processes and tools. U mnie jak zespół się zrobił za duży to po prostu sami go podzieliliśmy, bez pozwoleń PMów ani w ogóle scrum mastera (który u nas jest dodatkową funkcją jakiejś osoby). Zespoły scrumowe nie muszą być

[q.....q]

@fhsdjklvgnasiogfy: pozostaje mieć nadzieję ze kiedyś będzie mi dane pracować w "prawdziwym" scrumie. Bo z tego co mówicie, to na razie w taki nie trafiłem, a w każdym projekcie miałem różnych SM'ów, młodych, starych, doświadczonych i nie. Ale serio mam nadzieje kiedyś dotknąć tego mitycznego prawdziwego scrumu, to na pewno tak doskonały system pracy, jak doskonałym systemem społecznym jest socjalom wg założeń (tylko wszystkie implementacje nie dorastają do założeń xD

[fhsdjklvgnasiogfy]

@qwarqq: Nie mówię że jest doskonały, ale w ogóle te procesy działają głównie wtedy kiedy PMi się o--------ą i zaufają zespołowi. Podobnie scrum masterzy powinni się dostosować do zespołu. Wydrukujcie sobie agile manifesto i wytykajcie im jego naruszenia za każdym razem kiedy zacznie im o---------ć.

[TurboDynamo]

waterfall wydaje sie znacznie logiczniejszy, serio.

@qwarqq: hahahahahahah
K---a pracowalem pare razy w waterfallu i w waterfallu ktory udawal scrum. Serio to najgorsze podejscie z mozliwych.
Jedyne co mi przychodzi do glowy w krytyce scruma to ze ktos ma fobie spoleczna i nie potrafi rozmawiac ze swoimi kolegami z pracy.

[q.....q]

@TurboDynamo: Fobii społecznej nie mam, wręcz na meetingach jestem jednym z najbardziej gadatliwych. Fakt jedynie jest taki, że mimo dołożenia 2 devów do teamu ( w sumie dokładnie 7 osób od klepania kodu + 4 konsultantów), team w scrumie pracuje tak tragicznie wolno, że potrzebowalibyśmy miesiąca na pojedyńcze userstory. Nigdy wcześniej ten team tak wolno nie pracował, to jest wręcz ewenement. Całość jest prowadzona przez podobno doświadczoną scrum masterkę, która

[TurboDynamo]

team w scrumie pracuje tak tragicznie wolno, że potrzebowalibyśmy miesiąca na pojedyńcze userstory.

@qwarqq: moze nie pracowal wolno tylko zle byly zdefiniowane i wyestymowane us. Ja na swoich projektach w robocie nigdy nie robie sprintow dluzszych niz 2 tygodnie. I usy maja byc tak ulozone zeby dalo sie je wykonac w tym czasie.
Z tego co mowisz to nie wina scruma tylko zle prowadzonego scruma.

[q.....q]

@TurboDynamo: najprawdopodobniej masz rację. nie wiem, serio nie mialem jeszcze, mimo 6 lat doświadczenia w zawodzie, styczności z dobrze działającym scrumem. A jak ktoś już mówi że u niego scrum dobrze dziala, to zawsze okazuje się że to mocno zmodyfikowana wersja, daleka od pierwotnych założeń. Dlatego mnie tak ta metodyka irytuje, bo w sumie moze oznaczać wszystko i nic, a z mojego doświadczenia im bliżej do teorii, tym mniej efektywnie.

[ppawel]

@qwarqq:
Powtryniam się jeszcze.

Fakt jedynie jest taki, że mimo dołożenia 2 devów do teamu ( w sumie dokładnie 7 osób od klepania kodu + 4 konsultantów)

Kim są owi konsultanci i po co oni zespołowi developerskiemu