Raz pracowałam w czymś a'la scrumowym, ale PO był osobą techniczną, długoletnim programista i codzienne rozmowy z nim miały wartość i duży wpływ na projekt.
Pozostale przypadki "scruma" to bezwartościowe paplaniny.
4
0
jarekr000000 napisał(a):
i już wiesz, że pisze ktoś, kto nie ma pojęcia nie tylko o agile, nie tylko nie widział waterfalla, ale też raczej nigdy nie pracował w projekcie innym niż kopanie rowów
ale zakładam też wersję optymistyczną: pomroczność jasna - można się w dyskusji zapędzić i palnąć coś bez sensu.
Niestety, podejrzewam, że pracował i pracuje w innym projekcie niż kopanie rowów. Tylko jeszcze tego nie dostrzegł.
Tu w obronie waterfalla - nieprawda. Waterfall nie był nigdy popularny. To zawsze był jakiś promil - mityczne projekty rządowe i czasem powód żartów, czasem zazdrości (że w ogóle tak się da). Nie robiliśmy waterfalla, nawet jak agile manifesto nie było jeszcze nawet napisane.
Słyszałem o dobrym projekcie w waterfallu. Tak, był to "mityczny projekt wojskowy". Brałem udział w projektach udających waterfalla i generalnie problemy były takie jak w agile. Ostatecznie udawanie że coś jest zrobione jest złe niezależnie od tego, czy to waterfall/agile.
Waterfall obecnie to wróg publiczny kołczów agilowych, każdy kto nie wierzy w ich brednie automatycznie musi chcieć pracować w waterfallu. Ale to po prostu PRowa bzdura.
Tak, w mitologi agile, waterfall to taka czarna wołga zabierająca niegrzeczne dzieci. Też nikt jej nie widział, ale mówili na kursie dla uzwinniaczy.
(komentarz) A widziałeś gdzieś czystego idealnego agile? Jak sam napisaleś, to spektrum. Ja wolę jednak ciągnąć w strone agile, niż w tę drugą. No i prosba o nie stawianie znaku równości miedzy agile i scrum, tym bardziej SAFe, którym szczerzę gardzę
Ideałów nie ma, bo skoro agile to coś, gdzie można zmienić wszystko, żeby było poprawnie to ideał oznacza, że już wszystko jest super. SAFe nie jest ideałem (hehe), ale da się go oswoić. W moim projekcie zauważyliśmy, że patrząc na warstwy SAFe nikogo nie interesuje, czy mamy sprinty, liczymy story pointy, mamy PI planningi dłuższe czy krótsze niż te przepisowe, święte 2 dni. Na poziomie zespołu interesuje nas właściwie tylko co jest na wejściu (czy wymagania od biznesu są czytelne dla PO i kolejność w jakiej są poukładane w backlogu (tak, ~Kanban) i odpowiadamy czy coś zostało zrobione (czyli status epic/feature/story w Jira). PI planning trwa dla zespołu jakieś 2-4 godzin raz na PI, bo generalnie cała praca jest wykonywana wcześniej - przegadanie tasków, rozpisanie ficzerów, przesunięcie na górę, albo na dół backlogu bo są jakieś wcześniej rozpoznane zależności. Czasami nawet estymowanie zadań - traktujemy to raczej jako test, czy faktycznie zadanie jest gotowe do wejścia w development. Wewnątrz zespołów jest różnie - część pracuje w czymś na podobieństwo SCRUM'a, część wolała wybrać coś na podobieństwo Kanbana, co do części nawet nie wiem jak pracują. Nie wiem czy to wciąż jest SAFe, ale też nie mam ambicji bycia super zgodnym z tą metodyką.
Dla odmiany wcześniejsze doświadczenia z tą metodyką:
- co sprint kilka godzin dyskusji czym jest 1SP i chociaż jest to 1 dzień, to nie jest to 1 dzień.
- święte wojny, że program board ma być na tablicy, a nie w narzędziu do tasków
- pretensje, że nie ma zależności pomiędzy zespołami, bo program board wygląda ubogo
- pretensje, że cały planning został zrobiony w pół dnia, a nie w 2 dni, bo SAFe każe robić 2 dni i strzelanie focha, bo wszyscy poszli robić coś sensownego
- retro na których można było mówić jedynie o tym, co można jeszcze zrobić, żeby być bardziej SAFe, ale ktoś złośliwie wciąż mówił o tym, że mamy dostarczać produkt, a nie brać udział w konkursie na miss SAFe
- ... mógłbym pisać jeszcze sporo, ale chociaż myślałem, że już mi przeszło, to jednak wciąż się wkurzam
8
4
Prawda jest taka, że jeśli SM jest osobą techniczną i ma trochę pojęcia co się realnie dzieje w projektach i ma nad nimi kontrolę oraz łączy technologię z biznesem to tylko wtedy taka rola i stanowisko ma sens
2
Jedyny przypadek działania Scrum jaki znam to taki, gdzie SMem był po prostu kierownikiem odpowiedzialnym za delivery.
Nie było miejsca na bullshit, na przepychanie się product ownerek co do tego, czy ux ma mieć przycisk różowy czy zielony, na sranie devów o jakieś tam estymaty.
Gość był konkretny, żądał informacji, dostawał, praca szła, były z tego propsy. Miał budżet, rozdawał szkolenia techniczne według potrzeb, uwalał czarodziejskie szkolenie soft skills bez pokrycia, pracowało się okej. Nie raz pałował fantazje ownerek czy devów odnośnie fiuczerów które były fajne by design, ale w ogóle niepotrzebne do zakresu projektu (gold-plating). Ale wiecie - polityka, bonusy, tak dalej.
Inne przypadki to różne takie przepychanki polityczne o to kogo głos jest na górze - biznes (od PO) gdzie zawsze nowe fiuczery są najważniejsze, proces (od SM) gdzie badziewny proces to zaciąganie długów people/process/ tools, czy tech (od tech leada czy głosu devów ogólnie) bo chcemy akurat tę technologię przetestować by się nauczyć i spierdzielić do innej firmy za +5000 za rok czy dwa.
Powiem tyle, o ile w Polskim rządzie koalicja to must żeby ten szajs jakoś działał, tak w biznesie musi być jeden po prostu lider, to nie komuna gdzie jest 10 interesariuszy i każdy miksuje priorytetami jak mu się widzi, a budżet tylko się pomniejsza.
Komunizm nie działa, co historia potwierdza. OK, działa, ale dla grupy osób, nie dla całego społeczeństwa ogółem.
1
Mieliśmy taką scrum masterkę a przynajmniej tak to było przedstawiane. Kobieta codziennie(prawie) pytała deweloperów(poza daily) o jakieś rzeczy, próbując robić za proxy ale w sumie to nie wiedziała o co chodzi. Opowiadasz o jednym tasku, potem coś o drugim, ona próbowała to zapisać sobie, po czym jak się dyskutowało to mieszała tematy... Najlepsze było i tak to, że raz na jakiś czas zdarzyło się być na spotkaniu gdzie ona coś tam streszczała komuś i słuchasz, że wszystko przekręciła i tematy pomieszała... albo słucham, że miesza tematy które robi ktoś inny z teamu i najbardziej podstawowe pytanie jak ktoś zadaje jej to "musze dopytać xyz"(a czesto zorganizowac spotkanie, gdzie wystarczyłoby zeby osoba zainteresowana zostawiiła wiadomosc dla XYZ).
Odnośnie tego, że codziennie spamowała(a tak z 2x w tygodniu sie chciala wdzwonic) do ludzi jak tam idzie, jak progres i czy są problemy to bez sensu bo nic to nie przyspieszało. Zwykle jak ktoś w zespole miał jakiś problem to szybciej sam sobie znalazł pomoc.
No ale z plusów to wydawała się być miła.
1
Nie mam dobrej opinii, żaden startup z doliny się w takie rzeczy nie bawi gdy trzeba faktycznie dowozić funkcjonalności: kto nie pracuje ten nie je.
Na szczęście moda na tego typu "metodyki" już mija, w ostatnich 2 pracach nie miałem żadnego SM, a Scrum tylko z nazwy - była robota koordynowana w JIRA i się robiło.
Jak był problem to się rozwiązywało od razu a nie czekało na jakieś głupie spotkanie retro.
Scrum nie przystaje do rzeczywistości:
- Oncall nie pasuje do tego modelu pracy.
- Inne podejście w US: jedna lub grupa osób ciągnie dany feature, nie ma cięcia na karteczki tylko robi się od początku do końca.
- Nacisk na design techniczny vs nacisk na wycenę w jakiejś głupiej skali.
- Często trzeba oszacować czas oraz koszt rozwiązania (zgrubnie).
1
@0xmarcin opinia o przemijaniu mody jest dość znana od względnie kilku lat. Była pseudo-drama po tym, jak wywalili ponad 1000 chyba agile people z Capital One, to apologeci skrama darli szaty, że o nie to atak na zwinność.
Taa.
Oncall jest OK jak się ludzie dogadają, a jak masz kowbojów albo po prostu ludzi co wolą się zesrać niż porozumieć to masz rację, nie zadziała.
Function/product teams ogólnie spoko, ot mają też swoje bolączki ALE to wszystko zależy od architektury korporacyjnej i przyjętej metodyki prowdzenia prac.
Nie znam projektu który byłby prowadzony metodą "emerging architecture" i odniósł sukces komercyjny względnie nie byłby pod dużym kosztem utrzymania i łatania przeciekającego statku. W jednej firmie tak robili system, że nie było architekta tylko były łby seniorzy którzy lepili co było i jak na swoje czasy robili dobrą robotę, tyle że, w efekcie po kilkunastu latach diagram systemu to było spaghetti z klopsikami i nieustanne jojczenie, że łojezu czemu tyle bugów i maintenance, my chcemy się rozwijać.
Jak do estymat biorą się ludki które nie biorą za te estymaty odpowiedzilaności to takie są potem efekty, że ten walnie 5, ten 8, tamten 13 i w efekcie jest 69 różnych komplikacji na skutek patrzenia tylko na wycinek obrazka zamiast na cały obrazek z góry.
Do tego należy dodać ogólne realnia, gdzie dev czy tester nie będzie się móżdżył nad czymś bo za 2-3 lata zrobi hopka indziej za większy hajs oraz to, żę firmy jednaj przechodzą z rąk do rąk i jak się ludzie ugadali z klientem X to klient Y robi czystki i elo, nah shit here we go again.
Czarów nie ma, są realia, każdy chce zarabiać a bullshit pachnie dość mocno więc niektórzy odgrywają swoje role póki płacą.
Jak to szło w Conway's law?
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
Nie mam na to żadnych twardych dowodów, ot obserwacje, że tak w istocie jest.