Wątek przeniesiony 2021-06-05 16:46 z Inne języki programowania przez cerrato.

Co to ten scrum, bo już nie wiem.

3

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..

10

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.

8

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.

3

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..

0

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

2

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.

6

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.

12

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.

0

Polecam odcinek https://open.spotify.com/epis[...]H8Z?si=SieAVlArSS2jDozR9QSZRA

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

5

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0