Scrum nie działa

Odpowiedz Nowy wątek
2018-02-11 18:39
19

Na razie tu, a w razie czego się przeniesie do Flame.

Pracowałem w kilku firmach, które mniej lub bardziej próbowały być "agile". Obserwacje:

  1. Estymacja wielkości zadań była bezużyteczną stratą czasu. Nigdy estymaty się nie zgadzały z rzeczywistością, niezależnie od stopnia zaawansowania osoby estymującej. Jedyne, co działało, to podział zadań na "łatwe, znam rozwiązanie", "wiem jak to zrobić, ale to duże zadanie" i "nie mam pojęcia jak to zrobić / poprawić, zajmie od 5 minut do 5 miesięcy".

  2. W praktyce nie jest możliwe sensowne zaplanowanie rozwoju złożonego produktu planując w sprintach po dwa tygodnie. Taki system planowania ma tendencję do skupienia się na celach krótkoterminowych i gubienia całościowego obrazu budowanego systemu.

  3. Każde zadanie niby da się podzielić na N małych zadań. Gorzej jak się nie da. Przymus dzielenia zadań na małe zadania powoduje, że duże zadania których nie da się łatwo podzielić, wymagające np. zmian w architekturze / projekcie nigdy nie wychodzą poza backlog. Premiowane są taski trywialne, które dają efekty szybko i zrobią dobre wrażenie w trakcie retrospekcji.

  4. Agile manifesto zakłada, że interakcje są ważniejsze niż proces. Tymczasem w wielu implementacjach Scrum widziałem coś zupełnie odwrotnego. Proces ważniejszy niż ludzie, do poziomu religijnego wręcz - "nie możesz robić tego zadania, bo nie było zaplanowane na ten sprint!" wtf?

  5. Standupy - marnowanie czasu zespołu. Bo niby jak programista nie opowie co robi, to będzie cały dzień oglądał koty w internecie?

  6. Zbyt duży wpływ klienta na planowanie, zbyt mało swobody dla programistów / architektów / analityków. Klient często g*** wie. Jakby Ford słuchał klientów, to musiałby im dać "szybsze konie". Nie twierdzę, że klienta nie należy słuchać, ale mam wrażenie, że Scrum jest oparty na błędnym założeniu że programista nie jest w stanie pojąć, czego chce biznes.

  7. Zbytni nacisk na implementację i deprecjonowanie wagi procesu wstępnego projektowania i roli indywidualnych talentów. Wiele genialnych systemów powstało jako projekt jednego człowieka lub małej grupy ludzi. Klasyczny przykład: TeX. O ile pisać kod można wspólnie, to nigdy nie widziałem, aby wspólne projektowanie się udało. Projektowanie wymaga czasu i nie zawsze daje się je zmienić w kawałku sprintu.

  8. Brak własności kodu i rozmywanie odpowiedzialności. Założenie, że każdy może grać na każdej pozycji jak piłkarze reprezentacji Niemiec w piłce nożnej nie działa w IT. Owszem, mogę usiąść do każdego kawałka naszego kodu i coś w nim poprawić, ale zajmie mi to 5X tyle czasu niż w kodzie, który sam pisałem / projektowałem. Założenie takie jest nieefektywne.

Podsumowując: Scrum szkodzi. Leczenie waterfalla scrumem to jak leczenie dżumy cholerą.

Oczekuję konstruktywnej polemiki. Może u Was Scrum / agile działa?

Pokaż pozostałe 19 komentarzy
Nie wiem jak inni mogą, ale ja nie mam z tym problemu. Do wczoraj nie widziałem na oczy kodu RxJava. Wczoraj znalazłem i poprawiłem tam dwa błędy ze współbieżnością mimo że kod jest znacznie poniżej mojego akceptowalnego poziomu jaki puszczam na review. Podobnie miesiąc lub może dwa miesiące temu dorzuciłem coś do Netty, też wcześniej nie znając kodu. Właśnie code-review ma duży sens jeśli jest robiony przez osobę nieznającą szczegółów projektu. Jeśli ta osoba nie może zrozumieć jak coś działa, to najpewniej kod jest napisany źle. - Krolik 2018-02-15 11:59
Ale swoim komentarzem potwierdziłeś moje słowa. Lepiej, żeby ktoś miał coś zrobić w projekcie (jak np. Ty znaleźć błąd w kodzie), niż robić code review. Przecież nie robiłeś code review nikomu, tylko szukałeś "dziury w całym". Jakbyś miał zobić code review pierwszego lepszego merge requesta do Rxjavy, to pewnie nie miałbyś pojęcia co tam recenzować. A tak, robiąć coś, poznałes już kawałek kodu i zorientowałeś się w strukturze projektu. Następny ticket zrobisz jeszcze szybciej bo już wiesz na co patrzeć! - Thyliamris 2018-02-15 13:05
Wszystko zgoda, tylko gdzie ja napisałem, że własność kodu wyklucza aby inni robili w nim jakieś zadania? - Krolik 2018-02-15 14:04
myślę, że osoby, które nie znają projektu i tak mogą skorzystać z code review, choćby na zasadzie zadawania pytań i pisania komentarzy typu "dlaczego zrobiłeś to w ten sposób?", dzięki temu zarówno oni zdobędą trochę wiedzy o projekcie, jak i twórca kodu musząc coś wytłumaczyć drugiej osobie może nabędzie większego wglądu w to, co robi. mOże osoba nowa mu zwróci uwagę na coś ważnego, nad czym się nie zastanawiał wcześniej? - LukeJL 2018-02-15 14:05
Nie mówiąc już o rzeczach, które są uniwersalne. Jak ktoś np. chamsko przekopiował kod, to nawet nie znając projektów można stwierdzić "ej, to jest kopiuj-wklejka" (owszem, niektóre kopiuj-wklejki są uzasadnione, ale zakładam, że code review to również pewien dialog, wymiana opinii na temat projektu i twórca kodu może bronić swoich decyzji w kodzie). - LukeJL 2018-02-15 14:08

Pozostało 580 znaków

2018-10-07 11:07
1
Wibowit napisał(a):

Ależ story pointy, velocity i tym podobne pierdoły są narzucane przez Scruma.

Nie do końca - Scrum jako taki nic nie mówi o story, czy pointach. Wszystko co musisz, to wziąć na siebie tyle pracy, żeby ją wykonać w planowanym czasie i żeby wszyscy mieli co robić. Ktoś gdzieś wpadł na pomysł planning pokera (może nawet sensowny w tym konkretnym zespole / projekcie), ktoś inny uznał, że jemu się też przyda a reszta świata naśladuje to bez większego sensu, często kompletnie wypaczając pierwotne pomysły do postaci jakichś lokalnych frankensztajnów - np. u nas MUSIMY estymować wszystko w SP, które są przeliczane 1:1 (takie ustalenia na poziomie korpo) na dni pracy (1SP = 1MD) a później liczymy sobie velocity w MD / MD co według naszych agile gurus jest absolutely halal. Proces planowania w praktyce wygląda tak, że bawimy się w pokera, ale głównym zajęciem w tym czasie jest rozkmina o co właściwie biega w tych user stories, później patrzymy co można faktycznie zrobić przez 2 tygodnie w rozpisaniu na ludzi a na koniec przeklepujemy część estymat na takie, o dadzą właściwą sumę końcową.
Czyli w skrócie, ponownie: jak masz ogarnięty zespół, któremu nikt nie wcisnął jakiegoś dogmatycznego kapłana od scruma to sobie siądzie na chwilę oszacuje kto co może zrobić i pójdzie pracować. Jak masz zespół koncentrujący się na scrumie (w ich własnym rozumieniu) a nie na pracy to zaczynają się patologie a na wyjściu masz słupki a nie produkt, ale przynajmniej dano d**y zgodnie z procedurą.

edytowany 1x, ostatnio: piotrpo, 2018-10-07 12:46
Wczoraj spotkałem kolejny nieszczęśliwy zespół, który ma story pointsy w MD i liczy velocity w dniach na dzień. Ten genialny koncept jest tak powszechny, że powinien mieć jakąś nazwę. - jarekr000000 2018-10-12 09:48
@jarekr000000: trafilem keidys do projektu gdzie wielkie,straszne legacy, ktorego nikt specjalnie nie rozumial (Corba, Ace Tao, C++, TCL itp do tego mnsotwo kodu operujacego bezposrednio na pakietach wlasnosciowych protokolow, oczywiscie bez komentarzy i znaczacych nazw zmiennych) bylo przepisywane na Jave 8 + JMS (ich tez nikt jeszcze nie znal:) ). To w pewnym momencie zespol tak utknal, ze smialismy sie przez lzy ze estymujemy w iteracjach. Czyli 3 na planowaniu przekladalo sie na 3 iteracje. - WhiteLightning 2018-10-13 09:50

Pozostało 580 znaków

2018-10-13 09:26
Złoty Kot
3

Pracuję w niewielkiej firmie tworzącej dość skomplikowany i wymagający produkt (technicznie/technologicznie).

Są u nas dwa działy od oprogramowania:

  1. oprogramowanie systemowe, embedded
  2. soft webowy, przetwarzanie danych pod klienta itp.

Dział nr 1 działa w metodologii Programming Motherf*cker, w procesie planowania i tworzenia architektury liczy się praktycznie tylko merit, kto ma lepszy pomysł, czyj działa lepiej. Słabsze jednostki albo same odpadają i się zwalniają albo jeśli są do czegoś przydatne to w sposób naturalny przejmują taski, które są w stanie ogarnąć.
Zespół w zasadzie olewa wszystkich nietechnicznych managerów z ich durnymi pomysłami, wszystko za zgodą zarządu firmy gdyż z efektem pracy zespołu nie da się dyskutować.

Jeśli chodzi o dział nr 2 to jest to typowy, młody, dynamiczny zespół pełen pasji i barwnej różnorodności ;-). Przez ponad rok, zespołem większym niż nr 1, nie potrafili zrobić nic co sprawiałoby choćby cień wrażenia działającego. Nie jestem pewien jakich konkretnie metodologii używali ponieważ jest to zbiór ludzi z różnych korp i metodologie w podzespołach były inne jednak wszystkie były edżajl (co podkreślano przy okazji spotkań ogólnofirmowych). W końcu, jako że efektów brak to szef działu (swoją drogą kapłon referencyjny) stwierdził, że dość tego lawirowania i wszyscy przechodzą na scruma! Od tamtej pory trwa nieprzerwane spotkanie, a to w salkach, a to na kanapach, a to jadą gdzieś na "biwak". Przychodzę kiedyś do pracy a tam wszystkie ściany oblepione kolorowymi karteczkami z takimi banialukami, że szkoda było w ogóle produkować ten papier. Oczywiście źJira, pokery, ruletki, retro-wagary i inne zabawy są nieodłącznym elementem pracy.
Efektów nadal brak choć zespół rośnie średnio jedną osobę na dwa miesiące. Zgaduję, że to dlatego, że nie zaimplementowali metodologii w sposób poprawny ;-).

Pozostało 580 znaków

2018-10-13 10:09
3
Złoty Kot napisał(a):

Efektów nadal brak choć zespół rośnie średnio jedną osobę na dwa miesiące. Zgaduję, że to dlatego, że nie zaimplementowali metodologii w sposób poprawny ;-).

Raczej po prostu nie mają certyfikatów SM, PO.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.

Pozostało 580 znaków

2019-04-11 01:21
7

To chyba tutaj pasuje ;)

title

Pozostało 580 znaków

2019-04-16 14:27
0

oczywiście że nie działa, tak samo jak demokracja nie działa; ale tak samo jak dla demokracji nie mamy niczego lepszego tak dla edżajla tyż ni

Pozostało 580 znaków

2019-04-16 15:46
1
marian pazdzioch napisał(a):

oczywiście że nie działa, tak samo jak demokracja nie działa; ale tak samo jak dla demokracji nie mamy niczego lepszego tak dla edżajla tyż ni

A skąd jesteście? Bo cały świat ma, tylko Wy nie macie, to to chyba musi być jakaś inna planeta...


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
tak - planeta Rzeczwistość - marian pazdzioch 2019-04-17 09:55
Pozdrawiam z Ziemi! Tutaj istnieje chociażby kanban, który po prostu działa bez żadnych bezproduktywnych scrumowych spotkań i tytułów. - somekind 2019-04-17 11:02

Pozostało 580 znaków

2019-04-24 12:12
2

bo scruma się źle rozumie... ja w jednym zespole standupy miałem na slucku a w innym w ogóle ich nie miałem (był mały zespół). Scrum master winien być raczej rodadcą a niżeli mówić jak powinno się pracować. Ja np teraz planowania robię w ciągu 10 min przy komputerze z kolegą.

You need to find good people who work together at a human level, in the human sense that they can collaborate effectively. The choice what tools they use or what process they should follow is a secondary issue - Martin Fowler

I sformułowanie, które mi osobiście się spodobało: czasami żeby być agile, to trzeba zrezygnować ze scruma. Każdy zespół ma różne potrzeby w i każdej firmie pracują różni ludzie. Ten "wzorcowy" scrum jest jedynie sugestią - można go zmieniać/usuwać/dodawać nowe rzeczy dowoli pod warunkiem, że osiąga się zamierzony cel - biznes jest zadowolony.

Pozostało 580 znaków

2019-04-24 12:52
3

@no_solution_found: to chyba Ty nie rozumiesz jak działa świat. W scrumie nie chodzi o to, żeby programistom pracowało się lepiej, tylko o to, aby ileś firm szkoleniowych zarobiło masę kasy na szkoleniach i certyfikatach dla korporacji.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
w świecie korpo tak jest ze wszystkim. Jak jest jakiś problem to pakują w niego kasę - no_solution_found 2019-04-24 12:53

Pozostało 580 znaków

2019-04-24 13:14
3

I sformułowanie, które mi osobiście się spodobało: czasami żeby być agile, to trzeba zrezygnować ze scruma.

Ogólnie Scrum słabo idzie w parze z podejściem zwinnym, przynajmniej takim jak w manifeście

z manifestu Agile:

Individuals and interactions over processes and tools
...
Responding to change over following a plan

a w Scrumie ważne są procesy i narzędzia, oraz podążanie za planem.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
nie zgadzam się. To bardzo wiele zależy od scrum mastera jak to przedstawi. Jeśli był na kursie i wykuli u niego znajomość wszystkich spotkań bez poczucia po co to w ogóle jest, to się nie dziwię, że ludzie scruma nie lubią :) jeśli w scrumie processes and tools są ważniejsze niż Individuals and interactions, to to nie jest "prawdziwy" scrum. Scrum nie może być spreczny z agile. To jest fundament, której wieeeelu nie rozumie. W tym osoby, które tego scruma wdrażają. - no_solution_found 2019-04-24 15:22
@no_solution_found: I ponieważ narzędzia i procesy się nie liczą, to każdy certyfikowany scrum master dostaje skurczu zwieracza jak mu się powie, że codzienne standupy to przesada a agile poker jest do bani. - piotrpo 2019-04-24 15:44

Pozostało 580 znaków

2019-04-24 17:28
8

Może czas skończyć to pitolenie i zabrać się za kodowanie:
programming_mofo.png

Więcej na http://programming-motherfucker.com/


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
Stare, ale nadal piękne :D - cerrato 2019-04-24 17:39
Z tym byl chyba takie dosyc fajne kursy jezykow: Learn <language name="name"> in Hard Way. Ja sie tak Pythona uczylem. - WhiteLightning 2019-04-24 20:59

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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