Scrum nie działa

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

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-02-13 13:36
4

ja tam lubie korpo scruma, bo wprowadza jeszcze mniejsza przejrzystosc tego co sie tak naprawde dzieje.
oczywistym minusem sa planningi, standupy itp ale mialam szczescie ze wystarczylo dac telefon na mute i robic swoje zanim sie reszta przestanie jakac.
przy odpowiedniej znajomosci projektu bylam zawsze w stanie dostarczyc duzo story pointow, czasem wiecej niz reszta teamu, zajmujac sie glownie tym co mi sie podoba (i 80% moich jir zalozona przeze mnie, biznes happy ze takich zaangazowanych programistow ma ;))

Pozostało 580 znaków

2018-02-13 13:48
2

No dobra popłakaliśmy, to spójrzmy na alternatywy - waterfall? Już zapomnieliście projekty co po kilku latach pełnego sukcesu rozwoju produktu dostarczały coś co nie działa? A może wręcz przeciwnie - żadna tam metodyka, czyste nap....e kodu - debeściaki nie planują? Projekt za 10 baniek w twardej walucie do przepalenia i przez 2-3 lata na wszelkie pytania góry odpowiadamy w zależności od okoliczności:
"będzie pan zadowolony",
"będzie jak napiszemy, nie da się oszacować",
"my wiemy lepiej czego potrzeba w elektrowni atomowej, nie miejcie nas za idiotów, każdy miał fizykę w liceum",
"mój kod trzymam u mnie na dysku, bo jak ktoś czyta, to później tylko marudzi, albo jeszcze coś zmieni i zepsuje".

Pozostało 580 znaków

2018-02-13 14:06
2

@piotrpo:

Odpowiedź jest prosta - codzienna harówka ze wszystkich stron, bez korpobullshitu.

  1. Daily meetingi na których ludzie się deklarują, co zamierzają robić i ile im to zajmie.
  2. Analitycy odpowiedzialni za wymagania.
  3. Programiści odpowiedzialni za swoją pracę.
  4. PM odpowiedzialny za pracę całego zespołu.
  5. Im większy projekt tym większa faza zerowa - projektowanie i spisywanie wymagań.
  6. Dostarczanie jakiegoś kawałka co wyznaczony czas jest ok. Przy czym głupoty typu retro można olać.
  7. Zespół wycenia wymagania na bieżąco, w razie problemów wie że może zadzwonić do analityka lub nawet klienta żeby dopytać ocb.
  8. I przede wszystkim - jasno wyznaczamy odpowiedzialnych za zadania. Nie ma "my, zespół", jest "programista nie dowiózł", ewentualnie "analityk późno dostarczył wymagania", a nawet "klient wysłał je o dwa dni za późno".
  9. Tzw. transparency przede wszystkim, kiedy ktoś coś zawalił to mówi się o tym głośno. Kiedy coś nie pasuje - mówi się o tym głośno.
  10. Założyłem że zespół składa się z osób dojrzałych. Osoby zachowujące się jak dzieci położą każdy projekt, niezależnie od metodyki.

Jest to w jakimś sposób zwinne, ale nie jest to Scrum.

edytowany 1x, ostatnio: wartek01, 2018-02-13 15:00
Tylko większość tych rzeczy jest zgodna ze scrum - w każdym razie wg. mojej ograniczonej wiedzy. - piotrpo 2018-02-13 14:38
ad. 1. co to znaczy się deklarują ? - jarekr000000 2018-02-13 14:58
No, tak jak zmienne się deklaruje tak oni sami się deklarują :) poprawiłem - wartek01 2018-02-13 15:00
@piotrpo nigdy nie twierdziłem, że wszystkie elementy Scruma są złe. On jako całość jest zły. - wartek01 2018-02-13 15:02
@piotrpo: te elementy były znane długo przed scrumem. I całośc ma tyle wspólnego ze scrumem co np. pisanie kodu. To, że w projektach scrumowych tez się pisze kod, nie oznacza, że każdy projekt gdzie kod się piszę jest wzorowany/zgodny ze scrumem. - jarekr000000 2018-02-13 16:59
No przecież pisałem, że jeśli projekt który Scrumem nie jest się uda to jest to zasługa elastyczności tej metodyki ;) - wartek01 2018-02-13 17:48

Pozostało 580 znaków

2018-02-13 21:42
1

Ja wiem, że to znowu post w stylu scrum tak, wypaczenia nie itp, ale patrzę na to z perspektywy takiego Prince II (moda sprzed 15 lat), że o jakichś tam RUP tylko wspomnę. Ilość pracy wkładana w samo liczenie metryk i wypełnianie dokumentacji, której nikt nie czytał spokojnie wystarczyła by na zamknięcie niewielkiego projektu. Oznacza to, że dla mnie Scrum jest gigantycznym skokiem w stosunku do poprzednich podejść. Jeżeli nie da się jak ktoś tu twierdził oszacować zadania w perspektywie 2 tygodniowego sprintu, to spróbujcie oszacować je w perspektywie 2 letniego projektu, a tego przecież oczekiwano od PMa. W tej chwili scrum, czy agile generalnie wchodzi w fazę w której staje się obiektem memów i dobrze, za kilka lat przyjdzie moda na nową, odważną metodykę będącą odpowiedzią na problemy Scruma i wprowadzającą swoje własne.

Pozostało 580 znaków

2018-02-13 23:30
0

Już zapomnieliście projekty co po kilku latach pełnego sukcesu rozwoju produktu dostarczały coś co nie działa?

Można wcielić metody lean i rozwój produktu potraktować jako pole do eksperymentów - np. robisz jakiś proof of concept czy MVP (minimum viable product) i potem patrzysz, czy jest to, czego potrzebujesz, wypuszczasz, patrzysz jak użytkownicy reagują. I produkt ewoluuje, nabywa kolejnych użytkowników itp. Masz cały czas działający produkt i nie masz wtedy sytuacji, w których budujesz przez kilka lat coś, a potem to nie działa.

Zamiast wymyślonych "punktów historii" licytowanych w planning pokerze czy w innej karciance, to można liczyć bardziej realne metryki, np. liczbę ściągnięć aplikacji czy przepływ hajsu (co też rodzi potem różne patologie, że ludzie się skupiają na jakichś mikrooptymalizacjach w stylu przesunęliśmy o 10 pikseli banner na stronie i nasze przychody z reklam wzrosły o 0.001% Idziemy do przodu! , ale to juz inny temat).

Zamiast planowania backloga na 1000 zadań do przodu, jak to się robi w waterfall Scrumie, można powoli rozwijać produkt i "reagować na zmiany".

Większym problemem wydaje się być biznes/klienci, którzy nie umieją schować swoich ambicji i zamiast zamówić prosty MVP, który potem wypuszczą i który będzie się potem rozwijać, to każą wypuścić od razu dopracowaną na tip-top aplikację z mnóstwem ficzerów. A takie aplikacje robi się przez kilka, kilkanaście miesięcy, zanim ujrzą światło dzienne.

To jest jeden z powodów, dla których pozorny "agile" zamienia się w "ukryty waterfall" :/

Oznacza to, że dla mnie Scrum jest gigantycznym skokiem w stosunku do poprzednich podejść.

Przed Scrumem był jeszcze ruch Agile, który gdzieś się zatarł i nikt już o nim nie pamięta (Scrum to dla mnie trochę takie przeciwieństwo Agile'a, bo zasady Scruma przeczą kilku punktom manifestu Agile). Poza tym też kiedyś był XP (Extreme Programming), który jak dla mnie ma zasady o wiele bardziej sensowne niż Scrum (może dlatego, że XP to zasady programistyczne, a Scrum to po prostu kolejna korpo polityka). Poza tym ruch Lean Startup też próbuje odpowiedzieć na bolączki poprzednich podejść...


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 3x, ostatnio: LukeJL, 2018-02-13 23:33

Pozostało 580 znaków

2018-02-13 23:45
11

SCRUM i żadna inna, (nowa) metodyka nie będą (uniwersalną) odpowiedzią na problemy. Projekty są różne.
Metodyki wytwarzania powinny być dostosowane do

  • projektu,
  • zespołu i jego doświadczenia,
  • kultury firmy
  • klienta
  • narzędzi
    I jeszcze paru innych rzeczy.

SCRUM jest CIEŻKĄ metodyką, która ma jakiś sens przy mało doświadczonym/zgranym zespole, w projekcie gdzie można manipulować scopem i przy średniej wielkości firmie. Klient musi też być wystarczająco sensowny, żeby nie popadł w samozachwyt nad swoją zwinnością.

Bardziej doświadczone zespoły powinny iść w kierunku programming motherfucker i upraszczać proces .
Małe sturtupy i januszsofty w zasadzie skazane są na: metodykę BIN. To mniej więcej to samo co programming motherfucker tylko robione przez amatorów. Po prostu muszą liczyć na szczęście i zapał komandosów.... Żadna metodyka nie zastąpi doświadczenia, a wprowadzanie przez niedoświadczonych ludzi zabawy w agile skutkują tylko dodatkowym nakładem pracy i defokusacją.

Projekty typu "maintenance" powinny raczej z metodyk typu kanban coś brać.

Projekt fixed price jest w zasadzie skazany na jakiś waterfall - i tak nie jesteście agile i cała zabawa tylko stratą czasu. Serio. Można zrobić ten waterfall ludzkim. Ciekawostka: chociaż słyszałem o legendarnych projektach waterfall - to jednak taki waterfall z agilowego obrazka: 2 lata robimy ficzery i na koniec kompilujemy i prezentujemy przed klientem istnieje głównie w wyobraźni klaunów. W praktyce już od lat 90-tych zeszłego wieku były promowane wszelkiego rodzaju procesy iteracyjne/sprialne Co kilka tygodni była normalna prezentaja wynków /postępu prac. Korpa, które się tego nauczyły zmieniły tylko w dokumentach szyld RUP na SCRUM, iteracja zmieniła się w sprint i zostało po staremu)

Duże korpa niestety są zawsze skazane na klęskę - jakby genialny proces nie wymyśleć to zeżre go management we własnych zabawach.

Takie rzeczy jak review, dod, sprawna komunikacja w zespole, kontakt z klientem przydają się zasadniczo w każdego rodzaju projekcie (nawet w fixed price).

Polecam też jedną rzecz eksperymentować. NIe znajdziecie swojej dobrej metodyki jak nie przeprowadzicie kilku eskperymentów i będziecie się trzymać książki.
Sprinty jednodniowe, brak sprintów, standupy co godzinę - dały mi całkiem ciekawe efekty.

I na koniec ważny fakt. Jak zespół jest dobry i zgrany to mu nawet SCRUM nie przeszkodzi.
Często nowe metodyki sa testowane przez doświadczone , zgrane zespoły, na projektach, które nie są obciążone politycznie, i nie są krytyczne dla klienta.
Prawie zawsze z tego wychodzi sukces story, które można prezentować na konferencjach. Niestety, Ty w swoim korpo raczej tego nie powtórzysz.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 6x, ostatnio: jarekr000000, 2018-02-13 23:53
definition of done - jarekr000000 2018-02-13 23:49
if you know what I mean... - LukeJL 2018-02-14 00:00
chociaż nie, bo tamto jest doa - LukeJL 2018-02-14 00:00

Pozostało 580 znaków

2018-02-13 23:59
0

Przed Scrumem był jeszcze ruch Agile

A przed ruchem Agile przez duże A był jeszcze agile software development, tutaj fajne omówienie jak przez niezrozumienie idei (albo celowe działanie) powstała z tego gałąź biznesu i kult cargo:

Tutaj inny wykład tego gościa, omawiający temat z pozoru inny, ale mocno obrazujący bezsensowność jednolitych procesów:

https://www.infoq.com/present[...]eloping-Expertise-Dave-Thomas

edytowany 2x, ostatnio: Maciej Cąderek, 2018-02-14 00:02

Pozostało 580 znaków

2018-02-14 12:13
2
piotrpo napisał(a):

No dobra popłakaliśmy, to spójrzmy na alternatywy - waterfall? Już zapomnieliście projekty co po kilku latach pełnego sukcesu rozwoju produktu dostarczały coś co nie działa? A może wręcz przeciwnie - żadna tam metodyka, czyste nap....e kodu - debeściaki nie planują?

No tak, jeśli ktoś nie jest za PiS, to jest za PO.
Ale można też nie popadać w skrajności i stosować pragmatyzm oraz zdrowy rozsądek. I nie szukać na siłę nazw na wszystko.

piotrpo napisał(a):

za kilka lat przyjdzie moda na nową, odważną metodykę będącą odpowiedzią na problemy Scruma i wprowadzającą swoje własne.

Obym tylko nie musiał się dostosowywać do żadnych mód i dalej pracować normalnie.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2018-02-14 23:02
Pozdr
0

Skupcie się na czytaniu kodu ze zrozumieniem. Działa poprawnie napisany kod. Proces nie napisze kodu sam. Myślenie że słabi programiści pracujący w super procesie stworzą coś dobrego to mit. Te procesy to bzdury.
Linux kernel jaki ma proces ? Jaki proces używają naukowcy jak piszą algorytmy?

Pozostało 580 znaków

2018-02-14 23:23
1

Linux kernel jaki ma proces ?

To co widać na listach dyskusyjnych to code review, pull requesty, poprawki i tak w kółko. Co się dzieje w firmach, które zatrudniają programistów Linuksa to nie widać wprost.

Jaki proces używają naukowcy jak piszą algorytmy?

Ale konkretnie co? Większość prac naukowych zawiera krótkie programy pisane przez jedną lub dwie osoby. Algorytm wrzucany do pracy naukowej to zupełnie inna skala niż projekt pisany przez wiele lat przez wiele osób, które muszą się zgrać.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2018-02-14 23:24

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: Googlebot