Co to ten scrum, bo już nie wiem.

Pracowałem w 3 miejscach. W każdym używało się Scruma i w każdym wyglądało to inaczej...

Są ci którzy krytykuja scruma i którzy zachwalają, natomiast chciałbym się cofnąć krok do tylu i zapytać co to dla was oznacza Scrum i kiedy Waszym zdaniem warto zostać formalista technik scrumowych a kiedy wyluzować i dać ludziom pracować albo się opieprzać.

Duzo osób pisze, ze scrum jest dobry dla mniej zorganizowanych i leniwych zespołów, bo porządkuje chaos i konkretyzuje etapy, natomiast traci to sens gdy mamy fajny zespół ambitnych ludzi. Wtedy jakikolwiek formalizm jest zbędny a nawet szkodliwy i kosztowny.

Natomiast właśnie..
Totalnie nie jestem w stanie odpowiedzieć na pytanie, które techniki scruma są zawsze ważne a które mniej. W tym obszarze jest dość duży szum informacji, który powoduje, ze sam nie wiem co tym scrumem, na co warto zwracać uwagę itd..

Pewien czas temu ktoś (chyba @somekind , ale pewny nie jestem. EDIT autorem tego jest @superdurszlak - Zostań Scrum Masterem) rozwinął skrót BDSM na "Bardzo Dzielny Scrum Master". I to chyba jest klucz do zrozumienia tematu.

Ze scrumem jest tak, jak z erotyką - nie da się tego ściśle zdefiniować, każdy ma w tym zakresie inne potrzeby i czerpie radość z innych aspektów. Niektórzy całe życie w celibacie, a inni to bez owcy, zestawu noży, pejcza i wiertarki do łóżka nie pójdą ;)

Co do mnie - wydaje mi się, że największym plusem jest elastyczność i dopasowywanie zadań oraz czasu na ich realizację w miarę postępu prac.

Minusem jest często spotykane robienie z tego religii, czyli uznanie jakiekolwiek krytyki za złamanie przykazań i obrazę Boga, a także zrobienie że Scrum Mastera kapłana czy proroka. Zresztą, czytając opinie ludzi na 4p, można odnieść wrażenie, że ten SM jest największym problemem - człowiek, który nawet nieraz nie jest techniczny, troche się powymądrza, coś powie z mniejszym czy większym sensem i kasuje często więcej niz programista.

Do tego jeszcze ludzie często do tematu podchodzą bezmyślnie - nie zastanawiają się nad tym, czy coś ma sens, a jedynie bezmyślnie wykonują to, co któraś z definicji scruma zakłada. Chociażby to, o czym napisał @Aleksander32 - czyli czekanie że zgłoszeniem problemu aż będzie jakieś oficjalne spotkanie, a nie na bieżąco wyjaśnianie problemów. Tak samo te poranne spotkania, na których czego nic mądrego nie padnie - ludzie mówią kilka zdań z tyłka żeby mieć to odhaczone, a pół godziny czasu pracy całego zespołu poszło w piach.

Moze w założeniach było to fajne, ale realizacja często leży. Zamiast na siłę tworzyć stanowiska, bo trzeba być agile, lepiej wrócić do tego, że mamy produkt managera (czy jakkolwiek by nazwać kierownika projektu) i to on koordynuje pracę i rozwiązuje problemy.

Ze scrumem jest tak, jak z erotyką - nie da się tego ściśle zdefiniować, każdy ma w tym zakresie inne potrzeby i czerpie radość z innych aspektów.

Chyba jak z komunizmem. To nie był prawdziwy komunizm, tym razem zadziała ;)

kiedy Waszym zdaniem warto zostać formalista technik scrumowych

Nigdy. Zresztą nawet mądrze to podsumował @somekind - że to musi być zrypana metodologia pracy żeby czekać dwa tygodnie z powiedzeniem co jest nie tak i co nas blokuje (retro). Ja za to jestem ciekawy jak to byłoby pracować z kanbanem.

Scrum to bardziej taki zalecenia niż zasady, których się trzeba trzymać choćby nie wiem co.

Ogólnie chodzi o to aby wartości biznesowe dowozic w określonych sprintach.
Czyli nie chodzi o to aby zakodować np. kolejki tylko aby to zakodowanie dawało na koniec wartość biznesową.

Ogólnie to przed sprintem powinny być rozpisane historyjki, powinny być wyjaśnione i rozpisane taski techniczne do nich.
Każda z historyjek powinna mieć też priorytet - czyli jak skończy się ta, to która powinno się rozpoczynać.

Kolejna istotną rzeczą jest to aby każda z historyjek była rozpisana tak aby ją zrealizować w jednym sprincie. Jeżeli jest zbyt złożona, to trzeba ją dzielić tak długo aż złożoność będzie na tyle mała, że da się ją zrobić w jednym sprincie.

Chodzi też o to aby na sprint trafiało tyle mięsa aby dało się z niego zrobić kiełbasy.
To jest chyba najtrudniejsze - czyli wiedzieć ile zespół będzie w stanie zrobić kiełbasy i nic nie zostało albo aby tego mięsa nie zabrakło.

Codzienne spotkania mają na celu zaraportować czy ktoś ma problem i ewentualnie zmienić priorytet jeżeli wypada na sprint np. bug z utrzymania.

Ogólnie SM, PO ma właśnie tak zarządzać backlogiem, aby była ciągłość pracy, żeby ludzie wiedzieli też od strony biznesowej jak to zakodować.
Jak SM to dupa, to i dupa będzie dowieziona..

dla mnie scrum = daily meeting oraz planowanie np. następnego tygodnia lub dwóch (w godzinach, a nie słoneczkach czy innych dziwactwach)

W ilu miejscach widziałeś czcze zapewnienia o obiektowości, mikroserwisach, stosowaniu wzorców, czy CI/CD? Scrum nie jest niczym wyjątkowym, jak ludzie uprawiają jakieś czary i nawijają makaron na uszy byleby tylko nie podejść na serio do jakiegoś zagadnienia, to do wszystkiego można zastosować porównanie do komunizmu - aka "idea szczytna, ale w życiu to tragedia z niej wychodzi".

Dla mnie Scrum oznacza zaufanie, autonomię, samoorganizację i współpracę. Pod tym kątem oceniam czy ktoś mi wciska kity że pracuje w ramach Scruma. Np. wspomniane "Daily meetingi", jeżeli wyglądają tak, że każdy odklepuje regułkę spowiadając się co zrobił / będzie robił, to już lepiej niech tego nie będzie. Daily powinno wyglądać jak taki "czas" w meczu, gdzie zespół się przegrupowuje / naradza jak rozegra kolejną rundę (tu, dzień) aby osiągnąć sukces, spowiadanie się z tego kto co zrobił jest mniej istotne, niż wspólne ustalenie co jest aktualnie ważne aby osiągnąć nasz wspólny cel na Sprint - np. jeżeli potrzebna jest pomoc testerowi w testach, to korona z głowy programiście nie spadnie jak w nich pomoże, i analogicznie jak nie ma co testować, to testerowi korona nie spadnie jak się sparuje z devem, czy usiądzie z PO zobaczyć w backlog.

Jeżeli widzisz tylko grupę indywidualistów gdzie każdy przepycha "swoje taski" z lewa na prawo, to to nie jest ani Scrum, ani jakiekolwiek efektywne podejście do pracy intelektualnej.

Sacrum zupełnie wysiada jak zespół laczy utrzymanie z rozwojem. Najlepiej według mnie działa w tworzenie oprogramowania gdzie na początku tak naprawdę nie wiadomo co jest do zrobienia i pomysł się rozwija razem z produktem. Robienie sprintów, stendupow itp nie robi ze jesteś agail. Nie da się robić agail jak tylko dział IT jest agail i reszta nie.

Kto pracował w pseudoscrumie przy apce, gdzie były głównie bugfixy i przepisywanie modułów, bo systemu nie dało się używać, a biznes w połowie sprintu wrzucał mega pilne taski, bo jesteśmy agile scrum, ten się w cyrku nie śmieje.

Polecam odcinek https://open.spotify.com/episode/2eAzFIlr3pcfNaF1uwHH8Z?si=SieAVlArSS2jDozR9QSZRA

IMO wszystko sprowadza się do refleksji nad tym jak pracujemy i po co to robimy :)

Przede wszystkim należy zacząć od pojęcia Agile (zwinność), bo to jest często mylone. Agile jest szerszym zbiorem metodyk programowania, w których zakłada się minimum planowania na przyszłość i skupieniu na implementowaniu rozwiązań, których chce klient. W związku z tym, przeważnie operujemy na historyjkach (user story), które opisują konkrentne scenariusze użycia, bez szczegółów technicznych . Przeważnie ustalamy sobie krótkie iteracje (sprinty) w obrębie których wybieramy sobie konkretne historyjki do zaimplementowania. Po każdym sprincie wyciągamy wnioski z tego jak nam poszło, co można zmienić, czy dobrze oceniliśmy czas wykonywania zadania, itd.
Scrum natomiast jest konkretną metodyką opartą o te wartości (inne to np. eXtreme Programming i Kanban). Jest bardzo ścisłym opisem tego jak jest organizowana praca w zespole. Z ważniejszych rzeczy to mamy tu codzienne spotkania i demo na koniec sprintu, ocenianie czasu na poszczególne zadania (scrum poker), instytucja scrum mastera, product ownera i ich funkcje też są dosyć szeroko opisane. Zwykle używa się małego lub mniejszego wycinka tego, a nazywa się to scrumem, bo scrum jest modny. Myślę, że najlepiej byłoby przeczytać jakąś książkę na ten temat. Czytałem kiedyś „Wydajne programowanie Extreme programming” - Kent Beck, Cynthia Andres, krótka, ciekawa, ale raczej o Agile w ogóle, z naciskiem na XP, podobała mi się. O samym scrumie chyba nic nie znam.
Bynajmniej nie powiedziałbym, że jakikolwiek Agile jest dobry dla leniwych, niedoświadczonych zespołów; jest zupełnie na odwrót (nawet jeśli leniwi i niedoświadczeni zdają się lepiej pracować). W Agile nie ma analityków i innych ludzi, którzy dostarczą dokładną specyfikację tego co ma być zrobione, to zespół musi ustalić architekturę, jakie rozwiązania, itp. Dodatkowo, Agilie zakłąda, że w każdym momencie możemy zmienić kierunek rozwoju, a to działa tylko dobrze jeśli kod jest pisany dobrze; inaczej mało elastyczny kod może się bardzo szybko zemścić. Generalnie, Agile przekłada znaczną cżęść odpowiedzialności na zespół developerów, więc siłą rzeczy nie jest dla każdego.

Scrum = samo zło, wypowiadałem się już na ten temat wystarczająco wiele razy i ale wypowiem się jeszcze raz.

Kilka punktów do refleksji:

1. Planować można i bez Scruma, dzielenie funkcjonalności tak żeby wlazła w sprint to jak obcinanie nóg gościom bo się nie mieszczą w hotelowym łóżku...
2. Rytuały i ceremonie, Scrum to religia, ma nawet swojego kapłana - ScrumMastera. Jak wiadomo dzień należ zacząć od modlitwy (standup), a sprint nalezy konczyć nabożeństwem (demo). To że na demo 90% osób drzemie to inna sprawa...
3. To co niewygodne np. przygotowanie UX i jak się to wpisuje w resztę pracy jest często zmiatane pod dywan. Inne niestandardowe rzeczy takie jak dokumentacja, tłumaczenie, email do klientów z info o nowej funkcjonalności rownież.
4. Retro - jedyna sensowna rzecz niestety często przyjmuje formę gorzkich żali, lub tyranii uśmiechu (jest dobrze, dobrze jest).

Obecnie Scrum w wydaniu przecietno-korporacyjnym to antyteza Agile Manifesto i powód do wstydu dla tych wszystkich coachy i ScrumMasterów. Nie doświadczyłem jeszcze dobrze działającego Scruma, za to widziałem 2 alternatywne procesy w 2 różnych firmach które w miarę dobrze działały. Oba opierały się na zaufaniu i zdrowym rozsądku. Programiści byli traktowani jak partnerzy a nie podwykonawcy. Może tu tkwi tajemnica popularności Scruma...

Sensem scruma jest iteracyjne podejście do programowania. Programujesz małą część, pokazujesz klientowi. Klient wskazuje co jest źle i co chce dalej. Poprawiasz i rozwijasz i znów pokazujesz.
W praktyce w polskich kołchozach scrum jest narzędziem wywierania presji na koderach. Co 2 tyg. ma być dowieziona kolejna część W OSTATECZNEJ WERSJI, nawet jak implementacja czegoś wymaga > 2 tyg. Scrum jest formą zalegalizowanego mobbingu.
Owocem scruma jest powstawanie gównianego kodu: w sprintach nie myślisz o całości rozwiązania, bo go nie znasz tylko skupiasz się na dowiezieniu małego fragmentu. Z każdą kolejną historyjką dokładasz kolejne placki kupy do coraz większej kupy.

@0xmarcin:

Scrum = samo zło

No nie.. Scrum jako "scrum" nie jest zły. To ludzie, którzy go źle implementują powodują że staje się patologicznym bytem...

1. Planować można i bez Scruma, dzielenie funkcjonalności tak żeby wlazła w sprint to jak obcinanie nóg gościom bo się nie mieszczą w hotelowym łóżku...

Chodzi o to aby dana iteracja dowiozła wartość biznesową a nie sam kod, który od strony biznesowej może nic nie robić. Nie oszukujmy się ale praca programisty w firmie nie polega na klepaniu randomowych funkcjonalnoście wedle wyboru danego programisty.
Klient płaci np. za dorobienie archiwum dokumentów i ma dojechać archiwum dokumentów a nie połowa, czy 1/3 archiwum.
No i kluczową rolą jest tutaj osoba, która zbiera wymagania i na ich podstawie są rozpisywane historyjki. Jeżeli historyjki są wyceniane i na sprint trafia tyle ile trzeba, to problemu nie ma. Problem rodzi się dopiero jak ktoś z biznesu myśli, że uda się urodzić dziecko w miesiąc przez 9 kobiet..
Tylko to nie jest wina samej metodyki a błędnej implementacji.

1. Rytuały i ceremonie, Scrum to religia, ma nawet swojego kapłana - ScrumMastera. Jak wiadomo dzień należ zacząć od modlitwy (standup), a sprint nalezy konczyć nabożeństwem (demo). To że na demo 90% osób drzemie to inna sprawa...

Nie wszystkie firmy maja SM, zamiast nich tę rolę poniekąd pełni PO. Stundup jest moim zdaniem dobrym wyjściem, bo każdy mówi co zrobił, z czym ma problem i co będzie robił następnie. Jak ma z czymś problem to natychmiast są korygowane inne rzeczy. Oczywiście jak ktoś i tego nie zmiętoli...

1. To co niewygodne np. przygotowanie UX i jak się to wpisuje w resztę pracy jest często zmiatane pod dywan. Inne niestandardowe rzeczy takie jak dokumentacja, tłumaczenie, email do klientów z info o nowej funkcjonalności rownież.

No ale zamiatanie projektowania pod dywan nie jest związane ze Scrumem, tylko z idiotami na górze. Jak ktoś nie ogarnia że bez makiet frontendowiec nic nie zrobi, no to chyba nie powinien być na miejscu na którym był.
Jeżeli chodzi o dokumentację. U mnie są robione na to historyjki i taski.

1. Retro - jedyna sensowna rzecz niestety często przyjmuje formę gorzkich żali, lub tyranii uśmiechu (jest dobrze, dobrze jest).

Znowu, wszystko zależy od firmy. Jak ktoś źle zaimplementował Scruma, to nic tylko uciekać i się nie męczyć, bo na pewno lepiej nie będzie. Jeżeli ludzie będą brali w tym udział mając możliwość odejścia, to firmy dalej będą robić patologię.

Programiści byli traktowani jak partnerzy a nie podwykonawcy. Może tu tkwi tajemnica popularności Scruma...

No ale np. zatrudniając się na B2B to jesteś tym podwykonawcą... ;)
To jak są traktowani ludzie w firmie nie zależy od metodyki ale od biznesu. Jak biznes jest chory, to i reszta firmy będzie chora. Nic tylko się zwolnić...

@Wawer0123

W praktyce w polskich kołchozach scrum jest narzędziem wywierania presji na koderach. Co 2 tyg. ma być dowieziona kolejna część W OSTATECZNEJ WERSJI, nawet jak implementacja czegoś wymaga > 2 tyg.

No i to jest patologią... Tylko czy tam będzie scrum czy coś innego, to nie ma znaczenia... Jeżeli w firmie jest taka atmosfera to nie ważne jaką metodykę wdrożysz i tak będzie żal smutek i płacz.

Niestety ale w firmach często zespołami dyrygują handlowcy dla których liczy się premia ;) Mają gdzieś, że coś nie gotowe itd. Dopóki tacy ludzie będą u sterów, to nigdy nic nie będzie robione jak należy bez względu na stosowaną metodykę.

Owocem scruma jest powstawanie gównianego kodu: w sprintach nie myślisz o całości rozwiązania, bo go nie znasz tylko skupiasz się na dowiezieniu małego fragmentu. Z każdą kolejną historyjką dokładasz kolejne placki kupy do coraz większej kupy.

Nie do końca się zgodzę. Powiedzmy, że zaczynasz nowy projekt, jakaś aplikacja od zera. Są wstępne założenia co ma być jej rdzeniem. Tworzysz wymagania, rozpisujesz i implementujesz. Kiedy dochodzi nowa funkcjonalność to oplatasz ją o ten rdzeń.
Oczywiście to tak działa jak programiści znają biznes, wiedzą co ma robić i jakie problemy rozwiązywać. Jeżeli tego nie ma to cóż...

Cała ta nisza Scruma jest niestety mocno chora. To trochę, jak z niejedną partią polityczną - niby ma fajne postulaty, ogólnie to trochę do Ciebie przemawia, ale jest tam masa ludzi, którzy niczego nie czają i mają swoje dziwne poglądy.
Jeżeli chodzi o mnie, to miałem momenty, w których byłem fanatykiem Scruma i miałem też momenty, w których go nienawidziłem, bo męczyły mnie spotkania, rozmyta odpowiedzialność i wolałem po prostu kodzić w ciszy.
Dlatego, odpowiadając na pytanie OPa, poniżej wypiszę to, co myślę i wiem o Scrumie z perspektywy kogoś, kto jest devem z kilkuletnim doświadczeniem (człowiek-orkiestra .NET robiący we wszystkim po trochu, ale mający swoją specjalizację - czyli idealny do bycia cross-functional, jak to ładnie mówią BDSMy) z certami PSM I i PSM II pozdawanymi na niemal 100% (naprawdę mocno zgłębiłem temat, żeby wiedzieć, o co w tym wszystkim do cholery chodzi, bo to jak z kodem - jak czegoś używam, to lubię to dobrze poznać).
Moje wnioski:

1. Większość BDSMów NIE MA POJĘCIA czym jest Scrum i o co w tym wszystkim TAK NAPRAWDĘ chodzi.
2. Większość BDSMów traktuje tą metodykę, jak religię, którą wyzwają niczym fanatycy. Spotkałem się z wątkiem na scrum.org, gdzie BDSM był oburzony, że programiści NIE STOJĄ na Daily - serio.
3. Większość BDSMów to ludzie po dziwnych studiach nieinformatycznych i często nawet nieinżynierskich, którzy chcą się wepchnąć do IT, więc przeczytali 14 stron bez zrozumienia myśląc, że wszystko wiedzą.
4. Większość developerów została skrzywdzona przez posiadanie takich BDSMów, którzy skutecznie obrzydzili im całego Scruma dopieprzając się do jakichś g**no-rzeczy.
5. Większość meetup'ów agilo-scrumowych W OGÓLE nie uwzględnia w swoich programach programistów. Siedzą więc w swoich sektach i nie rozmawiają o tym DLACZEGO PROGRAMIŚCI NIE CHCĄ ICH SCRUMA. Co jest dla mnie totalnie idiotyczne, bo to programiści dostarczają WARTOŚĆ, a nie PO czy SM. Bo PO i SM to są czyste koszty. To programiści generują wartość.

W Scrumie chodzi tak naprawdę nie o te wszystkie zasady, spotkania, role itd. tylko o:

• Dbanie o to, żeby dział się PROCES EMPIRYCZNY, czyli żeby ludzie nie latali z łopatami i taczkami non-stop, tylko od czasu do czasu zastanowili się, co my do cholery robimy źle i zaczęli to poprawiać.
• Znalezienie chwili w ciągu dnia na zaplanowanie następnych 24h.
• Zmniejszenie ryzyka straty kasy do kilku tygodni (czyt. spotkanie się z klientem raz na jakiś czas i pokazanie mu, jak to wszystko na teraz wygląda, a nie płakanie, że 6 miesięcy pracy w błoto, bo w kontrakcie jakieś niedopowiedzenia były).
• Żeby manager i inne dziwne osoby nie wpieprzały Ci się w pracę co chwilę, bo chcesz coś w końcu zakodzić porządnie.
• Posiadanie dobrego, znającego się na rzeczy BDSM, który się nie wpierdziela ze swoimi mądrościami, tylko obserwuje z boku, jest tarczą przed osobami z punktu wyżej, dba o to, żebyście dostrzegali swoje błędy, dbali o jakość kodu pomimo napierania ze strony biznesu, a jak wszyscy rozkładają ręce, bo np. problem jest na poziomie całej organizacji, to Dzielnie biegnie na pomoc (lub świeci zespołowi latarką na obszar, którego nikt nie widzi, albo nie chce widzieć, żeby najpierw sami spróbowali po sobie posprzątać).
• Posiadanie DoD, w którym wyraźnie powiesz, że nie zgadzasz się na g**no kod bez testów i refactoringu tego szamba, do którego musiałeś wskoczyć. Nie interesuje Cię, że klient tam czeka na nowy feature, bo to, co do tej pory zrobiłeś, nie jest skończone i się pod tym nie podpisujesz.
• ZARABIANIE PIENIĘDZY (robienie tego, co się rzeczywiście opłaca, sprawnie i w dobrej jakości, czyli żeby końcowi klienci byli zadowoleni - to jest kwintesencja tego, o co w tym wszystkim tak naprawdę chodzi).
• Ograniczenie spotkań do MINIMUM, a nie ich dokładanie.
• Zapewnienie, że to programiści mówią JAK wykonać robotę, bo są z tego rozliczani, sami ją robią i nikt im w tym nie przeszkadza (np. PO czy manager, który był kiedyś programistą i ma swoje cenne rady/opinie).

Jak mniej więcej robisz to wyżej, to osobiście mam gdzieś, czy masz dejli, retro, rewju, czy robisz na nich planka, czy masz ładną tablicę, czy jesteś już zwinny jak lis i możesz z gracją zapierdzielić sąsiadowi kurę, czy nazywasz to Scrumem, czy Programming, Motherfucker, czy Bardzo Dzielną Metodyką. Mam to gdzieś. Liczą się tylko powyższe punkty. One IMO po prostu mają sens i dają dużo pieniędzy.

Także tak. Takie jest moje subiektywne zdanie na ten temat i mam nadzieję, że chociaż trochę nim pomogłem. :)

Daily jest dobre nad ujmowaniem tego samego innymi słowami. Wraz z niewielkim zaangażowaniem można wykonać swój pierwszy i powazny krok na drodze soft skills tak, aby w pracy w końcu brzmieć jak prawdziwy profesjonalista. Określanie rzeczy we właściwszy sposób ułatwia kontakt z ludźmi pod wieloma względami.

Też się powoli zrażam do Scrum. Na papierze wygląda fajnie, ale żeby to zadziałało trzeba świadomego biznesu, ogarniętego PM i zespołu z zaangażowaniem. Niestety zazwyczaj trafisz w projekcie 0 lub 1 z 3.
Idea sprintów nie przeżywa zderzenia z rzeczywistością i to jest chyba największą słabość Scrum. Kanban wydaje się mieć bardziej realistyczne założenia, ale musi być ktoś z batem aby nie skończyło się na ciągłych zwrotach akcji.

Najslabszy element układanki zwanej zarządzaniem projektami to chyba programiści, którzy na spotkaniach w większości się nie odzywają, a potem między sobą narzekają. Widzą błędy zarówno w biznesie jak i zarządzaniu projektem, ale nie widzą, że sami muszą też czasami się odezwać i o zgrozo powalczyć o swój punkt widzenia.
Gdyby programiści nie byli w swojej masie tak upośledzeń społecznie jak są to wiele projektów by się potoczyło inaczej. Niestety maks na co stać przeciętnego programistę to zwrócenie raz uwagi na jakis problem i potem narzekanie, że nikt go nie posłuchał jak mówił. Pół biedy jak mówił to w obecności PM, a nie na przerwie kawowej.

Najslabszy element układanki zwanej zarządzaniem projektami to chyba programiści, którzy na spotkaniach w większości się nie odzywają, a potem między sobą narzekają. Widzą błędy zarówno w
biznesie jak i zarządzaniu projektem, ale nie widzą, że sami muszą też czasami się odezwać i o zgrozo powalczyć o swój punkt widzenia.

Muszę się nie zgodzić.
Ta niechęć i brak wkładu wynika najczęściej z mojej obserwacji na tym, że już przerabiany był dany temat na poprzednich 20 retro i zero efektu oraz refleksji.

Byłem w kilku takich zespołach, gdzie ciągle wytykaliśmy Analitykowi/PM/PO rzeczy które u nas nie działają i musimy poprawić i efekt był zerowy.
Za to zawsze mieli dobrą wymówkę, która najczęściej polegała na tłumaczeniu, że to

• chwilowe, bo robimy duży feature i jest zamieszanie
• chwilowe, bo klient nieprzyzwyczajony
• chwilowe, bo nowy PO i musi się wdrożyć
• chwilowe, bo przerabiamy moduł
• chwilowe, bo PM był na urlopie
• chwilowe, bo był ciężki okres
• chwilowe, bo było dużo do zrobienia

Tak, dobrze myślicie, ten chwilowy okres trwa w firmach wieczność :)

Non stop od ludzi ogarniających rzeczy nieprogramistyczne trafiają się wymówki, mające to samo sedno - są najczęściej

• leniwi
• niekompetentni
• nie wiedzą co robią
• nie chce im się
• zwalają na programistów
• wymuszają na programistach branie zbyt dużej ilości backlogów, mimo stanowczego sprzeciwu
• dorzucają backlogi po zaplanowaniu i rozpoczęciu sprintu
• tracą czas na spotkania o dupie maryny, z których nic nie wynika, a są tylko pretekstem do unikania ciężkich tematów, gdzie trzeba podjąć konkretną decyzję

Po 20 takich wspaniałych sprintach programiści już się nawet nie odzywają, tylko mają to w dupie, bo szukają nowej pracy :)

Nie żebym gardził PO/PM/Analitykami.

Bardzo cenię sobię pracę kompetentnych w/w osób, a nie kolejnych królewiczów zdziwionych, że muszą coś ogarniać, a nie tylko przesuwać tickety po tablicy i dopytywać się o status.

Zacznijmy od tego że Scrum Master to nie miało być stanowisko tylko przechodnia rola między członkami zespołu developerskiego (programiści i testerzy, może analitycy), a zobaczymy jak bardzo Scrum został... zepsuty

Ogólnie scrum ma sens, gdy członkowie zespołu biorą na siebie odpowiedzialność, czyli jeśli od błędu dowolnej osoby liczy się los całej grupy. Problem scruma polega na tym, że jak byłem etatowym programista to praktycznie nie czujem na sobie żadnej odpowiedzialności, żadnego ryzyka, ani też powodu abym miał na tym stracić lub jakoś znacząco zyskać. Uczestniczyłem w scrumie, bo w firmie innego wyboru nie miałem.

Najlepszą częścią scruma jest daily. Nie, żeby to miało jakiś znaczący wpływ na pracę. Natomiast z perspektywy kogoś kto więcej czasu przebywa przy komputerze niż wśród ludzi to daily daje okazje, aby za pomocną innych słów ująć to samo. To są dobre warunki, aby poćwiczyć i popełniać błędy w przekazaniu myśli w możliwie klarowny sposób, taka autoprezentacja bywa pożyteczna jeśli w życiu chce się coś więcej robić niż tylko wypełniać czyjeś polecenia.

hadwao napisał(a):

Najslabszy element układanki zwanej zarządzaniem projektami to chyba programiści, którzy na spotkaniach w większości się nie odzywają, a potem między sobą narzekają. Widzą błędy zarówno w biznesie jak i zarządzaniu projektem, ale nie widzą, że sami muszą też czasami się odezwać i o zgrozo powalczyć o swój punkt widzenia.
Gdyby programiści nie byli w swojej masie tak upośledzeń społecznie jak są to wiele projektów by się potoczyło inaczej. Niestety maks na co stać przeciętnego programistę to zwrócenie raz uwagi na jakis problem i potem narzekanie, że nikt go nie posłuchał jak mówił. Pół biedy jak mówił to w obecności PM, a nie na przerwie kawowej.

Trochę się z Tobą zgodzę ale nie do końca. Otóż fakt nie wszyscy programiści mają skille o których piszesz. W sumie to nie tyle chodzi o programistów, po prostu taki ktoś ma typ osobowości (polecam książkę Otoczeni przez idiotów), który czyni go tym co go czyni. Można z tym walczyć, pracować itpe. no ale to nie o tym mowa ;)

Problemem często jest biznes, bo to im się płaci kupę szmalcu aby UMIELI ZARZĄDZAĆ LUDŹMI. To oni mają wykrywać problemy i je rozwiązywać. Jeżeli na stanowisku PM jest osoba niekompetentna lub typowy handlowiec, to nie ma prawa się to udać.

Często ludzie mówią co im nie pasuje ale jak widzą, że nic się nie zmienia i te uwagi ludzie na górze mają w dupie, to drugi raz się już nie odezwą, bo to dla nich strata czasu. Osobiście to przerabiałem i wiesz co? Nie mam ochoty się kopać z koniem. Ani to przyjemne ani zdrowe. No i najważniejsze - to nic nie zmieni, serio. Zmienić może tylko odejście z pracy do miejsca, gdzie patologii nie ma :)

Problem z projektami często wynika z tego, że jest niedoszacowany na początku. Potem jest ciśnienie bo się ludzie nie wyrabiają. No ale jak mogą jak ktoś ustala termin bazując na swoim widzimisie?
Oczywiście problem jest dużo bardziej złożony, do pieca dodają też developerzy. Jednak za to się płaci gruby szmalec osobom od zarządzania aby to robił a nie tworzył patologię.

.andy napisał(a):

No nie.. Scrum jako "scrum" nie jest zły. To ludzie, którzy go źle implementują powodują że staje się patologicznym bytem...

To zupełnie jak z komunizmem! Ale jeszcze tylko pięć lat towarzysze i się uda! Pamiętacie jak pięć lat temu staliśmy na krawędzi przepaści, ale dzięki wspólnej pracy udało nam się zrobić ogromny krok naprzód?!

Chodzi o to aby dana iteracja dowiozła wartość biznesową a nie sam kod, który od strony biznesowej może nic nie robić.

Niestety rzeczywistość jest taka, że istnieje całkiem sporo kodu, który sam w sobie nie dostarcza wartości biznesowej. A scrum (jak to utopie mają w zwyczaju) dzielnie udaje, że tak nie jest.

Klient płaci np. za dorobienie archiwum dokumentów i ma dojechać archiwum dokumentów a nie połowa, czy 1/3 archiwum.

Wychodzi na to, że jeśli nie da się zrobić archiwum w ramach jednego sprintu, to nie można go w zrobić w ogóle. Klient zapewne zrozumie, że nie możemy mu dostarczyć produktu, bo metodyka, w której pracujemy ma takie zasady.

Nie wszystkie firmy maja SM, zamiast nich tę rolę poniekąd pełni PO. Stundup jest moim zdaniem dobrym wyjściem, bo każdy mówi co zrobił, z czym ma problem i co będzie robił następnie. Jak ma z czymś problem to natychmiast są korygowane inne rzeczy. Oczywiście jak ktoś i tego nie zmiętoli...

Jak coś zrobię, to ustawiam na done i informuję osobę odpowiedzialną za weryfikację.
Jak mam z czymś problem, to od razu piszę na Slacku do osoby, która jest za dany temat odpowiedzialna, albo do swojego TL, albo do zespołu.
Nie widzę sensu w czekaniu aż do następnego poranka.

Nie do końca się zgodzę. Powiedzmy, że zaczynasz nowy projekt, jakaś aplikacja od zera. Są wstępne założenia co ma być jej rdzeniem. Tworzysz wymagania, rozpisujesz i implementujesz. Kiedy dochodzi nowa funkcjonalność to oplatasz ją o ten rdzeń.

Tylko, że rdzenia nie można nigdy zrobić dobrze, bo trzeba ciągle coś dostarczać dla biznesu, więc dług techniczny narasta, a kolejne ficzery powstają wolniej niż by mogły.

trybuszon napisał(a):

W Scrumie chodzi tak naprawdę nie o te wszystkie zasady, spotkania, role itd. tylko o:

• Dbanie o to, żeby dział się PROCES EMPIRYCZNY, czyli żeby ludzie nie latali z łopatami i taczkami non-stop, tylko od czasu do czasu zastanowili się, co my do cholery robimy źle i zaczęli to poprawiać.
  [...]
• Zmniejszenie ryzyka straty kasy do kilku tygodni (czyt. spotkanie się z klientem raz na jakiś czas i pokazanie mu, jak to wszystko na teraz wygląda, a nie płakanie, że 6 miesięcy pracy w błoto, bo w kontrakcie jakieś niedopowiedzenia były).
• Żeby manager i inne dziwne osoby nie wpieprzały Ci się w pracę co chwilę, bo chcesz coś w końcu zakodzić porządnie.
  [...]
• Posiadanie DoD, w którym wyraźnie powiesz, że nie zgadzasz się na g**no kod bez testów i refactoringu tego szamba, do którego musiałeś wskoczyć. Nie interesuje Cię, że klient tam czeka na nowy feature, bo to, co do tej pory zrobiłeś, nie jest skończone i się pod tym nie podpisujesz.
  [...]
• Zapewnienie, że to programiści mówią JAK wykonać robotę, bo są z tego rozliczani, sami ją robią i nikt im w tym nie przeszkadza (np. PO czy manager, który był kiedyś programistą i ma swoje cenne rady/opinie).

Te wszystkie punkty to nie jest scrum, tylko agile właśnie.

hadwao napisał(a):

Idea sprintów nie przeżywa zderzenia z rzeczywistością i to jest chyba największą słabość Scrum. Kanban wydaje się mieć bardziej realistyczne założenia, ale musi być ktoś z batem aby nie skończyło się na ciągłych zwrotach akcji.

Ale jakie właściwie zwroty akcji w Kanbanie?

Najslabszy element układanki zwanej zarządzaniem projektami to chyba programiści, którzy na spotkaniach w większości się nie odzywają, a potem między sobą narzekają. Widzą błędy zarówno w biznesie jak i zarządzaniu projektem, ale nie widzą, że sami muszą też czasami się odezwać i o zgrozo powalczyć o swój punkt widzenia.

Dlaczego jako programista miałbym walczyć o nowy jacht prezesa?

Gdyby programiści nie byli w swojej masie tak upośledzeń społecznie jak są to wiele projektów by się potoczyło inaczej. Niestety maks na co stać przeciętnego programistę to zwrócenie raz uwagi na jakis problem i potem narzekanie, że nikt go nie posłuchał jak mówił. Pół biedy jak mówił to w obecności PM, a nie na przerwie kawowej.

Wiele projektów potoczyłoby się inaczej, gdyby management nie był upośledzoną społecznie masą, i słuchałby programistów.
Pytanie komu powinno zależeć?

@somekind:

somekind napisał(a):

Pytanie komu powinno zależeć?

No właśnie do tego się sprowadzają wszystkie metodyki zwinne, że powinno zależeć wszystkim - inaczej nie ma to sensu.

To co ja widzę w projektach to w 80% są albo programiści, którzy w ogóle mają blazę albo trochę im zależy, ale nie mają siły przebicia. Często nie potrafią przekształcić swojego narzekania w konstruktywne argumenty. Niestety komunikacja zazwyczaj właśnie tak wygląda, że strony mają swoje zdania i muszą się nawzajem przekonać do zmiany postępowania.
Wielokrotnie już byłem w sytuacji, gdzie chodziłem za jakimiś zmianami na których zespół postawił już dawno kreskę i zazwyczaj po odpowiedniej ilości powtórzeń udawało się uzyskać przychylność góry. Inna sprawa, że mimo przychylności góry kończyło się na chęciach z powodu ciągłej bieżączki, ale przynajmniej potem przynajmniej obie strony miały świadomość czemu jest jak jest.

Żeby nie było, że twierdzę, że tylko my zawalamy. Wielokrotnie spotkałem się już z patozarządzeniem, gdzie PM był jak dziecko we mgle. Zgadzam się, że to PM powinien być wyczulony na sygnały z zespołu i liczyć się z brakiem soft-skili części technicznej zespołu. O klientach sabotujących własny projekt można by książki pisać.
Niestety to jest po prostu rzeczywistość i żadne z ogniw nie jest doskonałe i bez winy. Niemniej jeśli chcemy uchodzić za profesjonalistów, to powinniśmy zawsze trzymać fason, dawać jasny feedback, starać się naprawiać to co nie funkcjonuje dobrze - po prostu woda drąży skałę.

Jest to legenda o ktorej kazy slyszal ale nigdy jej nie widzial zeby sie spelnila :>

Pracowałem w tym samym projekcie przed i po wprowadzaniu scruma. Abstrachując od tych wszystkich spotkań i narzekań. Udało się zmniejszyć TTM z 9-12 miesięcy do 3 miesięcy. Ja wiem, że dało by się to i bez scruma ale łatwiej się to mówi niż wprowadza w życie :).

Scrum to wygodne narzędzie dla tzw. biznesu aby móc w wymierny i przejrzysty sposób kontrolować pracę programistów. Programiści z założenia to święte krowy, które nic nie robią tylko piją yerba matę i grają w piłkarzyki w godzinach pracy. Aby zatem zmusić ich do robienia czegoś, wielcy tego świata postawili na 100% transparentny proces, który sprzyja wynaturzeniom w postaci obstawiania dobrze płatnych etatów kolesiami, którzy nigdy w danym projekcie nie brali udziału by mogli stać z batem nad głową nad koderami i nazwano ich mistrzami tej ceremonii :)

Przynajmniej tak sobie wyobrażam, że powinna brzmieć definicja scruma, bo zawsze scrum master był przeciwko developerom w każdym zespole, w którym byłem. Teraz nie pracuję w scrumie i mam z tego wiele radości :)

DKN napisał(a):

Pracowałem w 3 miejscach. W każdym używało się Scruma i w każdym wyglądało to inaczej...

Bo w firmach "Scrum" jest używane jako magiczne zaklęcie mające sprawić, że wszystkie problemy znikają. W szczególności te, które w całości leżą poza zakresem metodyki.

Są ci którzy krytykuja scruma i którzy zachwalają, natomiast chciałbym się cofnąć krok do tylu i zapytać co to dla was oznacza Scrum i kiedy Waszym zdaniem warto zostać formalista technik scrumowych a kiedy wyluzować i dać ludziom pracować albo się opieprzać.

Nie ma co sie rozwodzić nad tym. Scrum to metodyka pracy zespołu zgodna ze Scrum Guide.

Duzo osób pisze, ze scrum jest dobry dla mniej zorganizowanych i leniwych zespołów, bo porządkuje chaos i konkretyzuje etapy, natomiast traci to sens gdy mamy fajny zespół ambitnych ludzi. Wtedy jakikolwiek formalizm jest zbędny a nawet szkodliwy i kosztowny.

I tutaj robi się ciekawie. Jak masz zespół, który potrafi pracować "w czyms tam" i jest w stanie robić to efektywnie, to po co wprowadzać Scrum? Chyba tylko po to, żeby jakiś Scrum Master miał niby-robotę. Przecież skoro radzą sobie dobrze, to narzucanie im formalnych wymagań dotyczących sposobu jak mają robić coś, na czym się znają musi się skończyć katastrofą. Dla odmiany mając zespół, gdzie nie wiadomo co ma być zrobione, nie wiadomo jak, nie wiadomo przez kogo, skorzystanie z czegoś gotowego może być pożyteczne, bo skoro tak czy inaczej trzeba zmienić sposób pracy, lepiej zmienić go na coś ktoś już przemyślał. Ważne, żeby po osiągnięciu jakiejś tam efektywności wyluzować, bo jak zespół zaczyna ogarniać robotę, to nie ma co narzucać mu głupot typu daily, sprint planning, poker i inne zabawy dla przedszkolaków.

Natomiast właśnie..
Totalnie nie jestem w stanie odpowiedzieć na pytanie, które techniki scruma są zawsze ważne a które mniej. W tym obszarze jest dość duży szum informacji, który powoduje, ze sam nie wiem co tym scrumem, na co warto zwracać uwagę itd..

Nie ma ważnych i nie ważnych technik. Jak projekt ma problem z definiowaniem zadań, to konieczność cyklicznego pałowania PO może spowodować, że scrum planning ma znaczenie. Jak terminy gonią, to może dla odmiany da się odnaleźć jakiś sens w planning poker (żart, akurat to zawsze jest bzdurą). W skrócie - trzeba patrzeć jakie problemy ma zespół, a nie jakie niedoskonałości ma Scrum.

Pipes napisał(a):

Przynajmniej tak sobie wyobrażam, że powinna brzmieć definicja scruma, bo zawsze scrum master był przeciwko developerom w każdym zespole, w którym byłem. Teraz nie pracuję w scrumie i mam z tego wiele radości :)

W pracy to nie Ty masz mieć z pracy wiele radości tylko właściciel firmy i klient

ToTomki napisał(a):

Pipes napisał(a):

Przynajmniej tak sobie wyobrażam, że powinna brzmieć definicja scruma, bo zawsze scrum master był przeciwko developerom w każdym zespole, w którym byłem. Teraz nie pracuję w scrumie i mam z tego wiele radości :)

W pracy to nie Ty masz mieć z pracy wiele radości tylko właściciel firmy i klient

Co za Januszowe podejście xD Jak widać to nie jest oczywiste, że zmotywowany, zadowolony ze swojej pracy pracownik jest wydajniejszy i bardziej produktywny, a miejsca pracy, które to zapewniają ściągają do siebie bardziej wartośćiowych pracowników.

Nie mówię, że to nie jest ważne, tylko że celem pracy jest przyniesienie korzyści właścicielowi. Twoje zadowolenie może wesprzeć przedsiębiorstwo, ale wtedy trzeba sprawdzić wartość wnoszoną przez zmianę metodyki pracy i ew. ją skorygować o satysfakcję z pracy pracownika (nie wiem czy to się da jakkolwiek zrobić), natomiast to co napisałeś nie brzmi tak jakbyś próbował ocenić wartość zmiany metodyki, a raczej jak "scrum jest głupi, bo bez niego mi się pracuje lepiej", a jak napisałem po co jest praca, to jeszcze załączył Ci się jakiś pierwotny instynkt obronny i od razu zacząłeś kogoś od Januszów wyzywać. To wskazuje, że faktycznie na pewno to ze WSZYSTKIMI scrum masterami zajmującymi się organizacją Twojej pracy było coś nie tak, a nie z Tobą :)

@ToTomki: to nie ja pisałem o Scrumie, pisałem tylko w kontekście tego, że nie jest istotne, żeby pracownik był zadowolony. Poza tym to wcale nie byłoby zaskakujące, gdyby wszyscy SM pracujący z @Pipes byli słabi.