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-05 19:43
0
GutekSan napisał(a):

Jarku, ale wiesz co ma najniższą jakość?
Coś czego w ogóle nie ma.
Kluczem jest tu słowo wystarczająco, które oznacza, że coś spełnia ustalone standardy jakości. A te standardy też zostały określone w procesie planowania przy tworzeniu Definition of Done dla danego User Story. I tak rozumiem określenie wystarczający, a nie jako posiadający pozory bycia skończonym. Tymczasem przedłużanie pracy w celu maksymalizowania jakości prowadzi do tego, że albo dostajemy doskonały produkt, którego nikt już nie potrzebuje, albo w ogóle nie dostajemy nic, bo niczego nie udało się skończyć.

Programiści czasem zapominają, że nie są artystami, i nie tworzą dzieła sztuki, tylko produkt biznesowy.

Akurat artysta ma prościej, bo jego praca polega na tworzeniu setek małych greenfieldów, z których większość jest g*wniana, ale to nie szkodzi, bo g*wniane zostaną zapomniane, a porządne zostaną dobrze sprzedane. Programista pracuje nad jednym dużym projektem, więc musi się mocniej zastanowić zanim wyprodukuje kupę. Inaczej będzie ciągła rzeźba w brązie i biadolenie na forum.

Nie spotkałem się jeszcze z definition of done, które zahaczałoby o standardy jakości kodu czy ogólnie o dług techniczny. U nas teraz DoD = jest na prodzie, klient może używać funkcjonalności. Na szczęście odpadło nam szacowanie historyjek i mierzenie velocity. Widocznie komuś już przestał stawać na widok słupków. Zamiast tego to programiści decydują ile czasu trzeba poświęcić na zrobienie funcjonalności porządnie, a analityk biznesowy nakreśla jakie funkcjonalności są potrzebne. Do tego oczywiście trzeba najpierw udowodnić, że jest się profesjonalistami, czyli że czas poświęcony na dopracowanie funkcjonalności skutkuje zmniejszoną ilością problemów na produkcji.

Ja bym powiedział, że w wielu przypadkach coś co źle działa oznacza gorszą jakość całego systemu niż brak danej funkcjonalności. Nie tylko w danym momencie (bo klienci są beta-testerami którzy marnują swój czas na kopanie się z niedoróbkami) ale też w przyszłości, bo programiści zostali z długiem technicznym który zmniejsza ich efektywność. Nie ma prostej metody by powiedzieć kiedy należy skończyć pracować nad zadaniem. Od tego jest doświadczenie programisty (senior developer itd), by ten sam był w stanie osiągnąć pożądany kompromis między jakością kodu, a szybkością dowożenia funkcjonalności.


"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 2x, ostatnio: Wibowit, 2018-10-05 19:46

Pozostało 580 znaków

2018-10-05 20:26
0

Definition of Done to patologia, bo działa odwrotnie niż się wydaje, że działa.

Teoretycznie wydaje się, że DoD dookreśla to, czy coś jest zrobione czy nie. No bo "definicja". Patrzcie jacy jesteśmy zorganizowani, nie ma niejasności, wszystko jest określone.

Tylko, że w praktyce to czasem działa sposób, że DoD swoją drogą, tylko, że biznes i tak się nie stosuje do tego. Pracowałem w zespole, gdzie np. PO potrafił cofnąć taska z kolumny Done do In Progress, bo tak (pomimo, że task spełniał DoD). Bo DoD swoją drogą, ale i tak biznes ma ostateczne zdanie.

I potem, żeby tego zapobiegać zespół myśli nad bardziej sprawną Definition of Done, żeby było naprawdę dookreślone wszystko...

W rezultacie Definition of Done jest ruchomym celem. I staje się z biegiem czasu coraz bardziej restrykcyjnie, aż do przesady. Gdzie rosną kolejne patologie typu "wymóg code review" jako jeden z warunków DoD (i przez to potem kilka gotowych tasków leży i nie może być zmerdżowanych bo czekają kilka tygodni na code review. A przecież DoD to "świętość", czyli "task, mimo, że został wykonany, to nie jest wcale uznany za zrobiony, bo tak mówi jakaś głupia regułka DoD").

Z Definition of Done jest jeszcze inny problem. A mianowicie pytanie o to, czy w ogóle większe projekty software'owe w dzisiejszych czasach mogą być kiedykolwiek "done"?

Duży software to ciągły rozwój i pomijając rzeczy binarne (np. fixowanie buga - jest bug=>nie ma buga) to ciężko stwierdzić, że jakakolwiek duża aplikacja została "zrobiona", albo czy jakikolwiek ficzer w aplikacji został "zrobiony", tak definitywnie do końca.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 5x, ostatnio: LukeJL, 2018-10-05 20:33
Z tym czekaniem na review to nawet pamiętam. Niezła patologia. Najgorsze, że review to zwykle jedna z najbardziej prostych zasad do wdrożenia. Jak się tego nie da to i wielu innych rzeczy nie ma sensu. - jarekr000000 2018-10-05 21:59

Pozostało 580 znaków

2018-10-05 21:06
2

Dla odmiany, w projekcie gdzie nie ma DoD ostatnio oddawany kod w praktyce nie musi się nawet kompilować. Niestety autentyk.

Pozostało 580 znaków

2018-10-05 21:43
0

Są różne patologie XD


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);

Pozostało 580 znaków

2018-10-05 21:53
2

DOD powinno być proste.

Widziałem już DOD , gdzie bylo narypane reguł, że pokrycie testami, że sprawdzone przez użytkownika. Potem sie okazuje, że mamy taska - zmień reguły firewalla, dopisz skrypt migrujący dane - jak tu pokryć testami (czasem się da... ale często nie warto), jak tu dostać akcept od użytkownika? Potem mamy 4 różne DOD (naprawdę), w zależności od rodzaju taska. Albo taski, które ze względów technicznych nie mogą spełnić DOD, bo np. nie można ich uruchomić na preprodukcji.., choć są zrobione.

Wszelkie koncepcje, typu musi być uruchomiony na serwerze testowym, gdzie deploymenty są tylko w piątek to zabójcy efektywnej pracy. Jak reguły DOD są takie, że zespół nie może przysiąść i zrobić i zamknąć w dowolnie wygodnym dla siebie momencie - to potem mamy 20 otwartych tasków, przy których nikt nie pracuje...

W praktyce reguła typu - musi być review zrobione i zadanie zaakceptowane przez kogoś z zespołu to już całkiem dużo - w wielu projektach wystarcza.
Dorzucanie coraz większej ilości kruczków, punktów itp. to jest zwykle ładny objaw choroby i próba zaklinania rzeczywistości.Dopisywanie reguł nie pomoże, jak zespół juz zaczął olewać to co tworzy... bo jest przytłoczony.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2018-10-05 21:55

Pozostało 580 znaków

2018-10-06 11:08
3

Tylko, że przynajmniej w teorii, to zespół scrum'owy określa co wg. niego oznacza "done". Problem w tym, że na początku często znajdzie się ktoś, co to naczyta się jakiś tam pierdół, był na 3 konferencjach o metodykach zwinnych a jego ambicje jeszcze się nie roztrzaskały o fiaska 5 projektów i wpada na jakieś dziwaczne pomysły typu wymogi, że kod składający się z rzeczy nietestowalnych jednostkowo ma być pokryty jak Sasha Grey u schyłku kariery. Albo jakiś manager chce być "lepszy" niż kolega z pokoju obok i wymyśla dziwactwa. Tylko to wszystko jest raczej wynikiem niekompetencji niż tego, że stosuje się taką czy inną metodykę pracy. Scrum, kanban i co tam jeszcze jest jak by nie patrzeć nie każe mieć bzdurnej DoD.

Pozostało 580 znaków

2018-10-06 12:46
2

A czy osoba, która nie potrafi sensownie zorganizować zespołowi pracy w scrumie, albo zespół, który wymyśla sam sobie absurdalne regułki, będą w stanie efektywnie organizować sobie pracę i realizować projekt w jakiejś innej metodyce?

Jak ktoś ma fiziu miziu na punkcie tego, że do wszystkiego muszą być akurat 4, 8, 16 lub 32 unit testy, bo go rajcują potęgi dwójki, i potem wszyscy się z tym męczą, to chyba nie jest wina scruma?

Jak teamowi brakuje samodyscypliny i nie pisze testów, a potem trzeba wymyślać jakieś zasady dodatkowe, żeby jednak testy były napisane, to problem nie leży w scrumie.

Jak ktoś stwierdził, że buildy tylko w piątek, bo tak i koniec i potem wszyscy czekają jak na zbawienie to nie jest problem scruma.

Jak ktoś robi tygodniowy sprint, który zaczyna się w czwartek i potem w poniedziałek wszyscy gapią się w monitory i zastanawiają, na czym skończyli robiąc taski w piątek, to nie jest wina scruma.

Jak ktoś rozrzuca story pointy po taskach z precyzją rozrzutnika do gnoju, to też nie ma co winić scruma. U nas story pointy rozkładane są tak, że bierzemy taska, dyskutujemy nad nim, ile może zająć, czego wymaga, co jest wiadome, a co nie i jak się ma do tego, co już wyestymowaliśmy, a potem głosujemy czy task jest XS, S, M, L czy XL. Liczba punktów jest mniej istotna. Jak głosy są podzielone, to prawie zawsze na dwie sąsiednie kategorie, więc po prostu wybieramy ostatecznie jedną. Póki co to się sprawdza.

Jak ktoś nie dopuszcza do siebie myśli, że można wrzucić do backlogu refaktoring i jeszcze go przepchnąć powyżej ficzerów, a na domiar złego dorzucić do kolejnego sprintu, to chyba nie jest wina scruma tylko ludzi. Trzeba też umieć powiedzieć:

Słuchajcie, możemy rzeźbić od razu kolejny XYZ*, a potem kolejny i mieć to w dupie. Ale teraz wyrzeźbienie XYZ zajmuje 2-3 o-dni** co najmniej, a jak poświęcimy 2-3 o-tygodnie na taki a taki refaktor, to będziemy mogli dostarczać nowy XYZ w góra 1 o-dzień, plus dostajemy za darmo to, to i to i już nie trzeba będzie do tego wracać w nowych XYZach ani utrzymywać w wielu miejscach w starych.

Jak ktoś ma olej w głowie, to nawet jeśli się z tym nie zgodzi, to przemyśli sprawę i będzie miał jakieś w miarę sensowne uzasadnienie. A jak nie, to ponownie nie jest to winą scruma.

* - moduł, ficzer, cokolwiek
** o-X -> osobo-X -> X pracy jednej osoby


Prosząc o pomoc w wiadomości prywatnej odbierasz sobie szansę na otrzymanie pomocy od kogoś bardziej kompetentnego :)
edytowany 2x, ostatnio: superdurszlak, 2018-10-06 12:49

Pozostało 580 znaków

2018-10-06 13:19
0

Jak ktoś rozrzuca story pointy po taskach z precyzją rozrzutnika do gnoju, to też nie ma co winić scruma. U nas story pointy rozkładane są tak, że bierzemy taska, dyskutujemy nad nim, ile może zająć, czego wymaga, co jest wiadome, a co nie i jak się ma do tego, co już wyestymowaliśmy, a potem głosujemy czy task jest XS, S, M, L czy XL. Liczba punktów jest mniej istotna. Jak głosy są podzielone, to prawie zawsze na dwie sąsiednie kategorie, więc po prostu wybieramy ostatecznie jedną. Póki co to się sprawdza.

Ależ story pointy, velocity i tym podobne pierdoły są narzucane przez Scruma. U nas oszacowania nie stawały się coraz lepsze, a zabawy w usprawiedliwianie własnego oszacowania są czasochłonne. Z tego powodu olaliśmy szacowanie prawie całkowicie (w sensie jest tylko zgrubne szacowanie ile komu wrzucić tasków na sprinta podczas planningu, ale wtedy każdy szacuje własną pracę, a nie cudzą). Lepszym rozwiązaniem jest po prostu dzielenie zadań na mniejsze.


"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-10-06 13:25

Pozostało 580 znaków

2018-10-06 21:49
0
Wibowit napisał(a):

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

Ale przywiązujesz do nich wagę na tyle, na ile potrzebujesz, czyż nie? Jak ktoś chce próbować na siłę patrzeć na świat przez pryzmat punkcików w JIRA i nie widzieć nic poza tym, wolna wola.

U nas oszacowania nie stawały się coraz lepsze, a zabawy w usprawiedliwianie własnego oszacowania są czasochłonne.

Stąd proces odwrotny, najpierw dyskutujemy o zadaniu, a dopiero potem je szacujemy i nie ma potrzeby spowiadania się - jak ktoś chciał dorzucić swoje trzy grosze, dorzucił w trakcie dyskusji. Nie ma tak, że jeden oszacuje zadanie na duże i tłumaczy swoje widzimisię, drugi oszacuje na małe i tłumaczy swoje, a potem próbują znaleźć porozumienie.

Lepszym rozwiązaniem jest po prostu dzielenie zadań na mniejsze.

A to się wyklucza z szacowaniem zadań?


Prosząc o pomoc w wiadomości prywatnej odbierasz sobie szansę na otrzymanie pomocy od kogoś bardziej kompetentnego :)

Pozostało 580 znaków

2018-10-06 23:09
0

Scrumowy planning poker czy inne metody szacowania polegają na tym, że każdy programista szacuje każde zadanie, a nie tylko własne.

Generalnie szacowanie zostało u nas zredukowane do pytania: czy uda ci się zrobić jeszcze to jedno zadanie w sprincie? Zadania dodajemy programiście, aż odpowie na pytanie przecząco. W ten sposób planowanie się nie przeciąga godzinami, cały sprint jest zaplanowany, a planowanie odbywa się standardowo raz na sprint.


"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.
Pokaż pozostałe 2 komentarze
U nas np. na planingu planowaliśmy tylko zadania jakie zostaną wykonane, a w trakcie sprintu każdy brał co mu odpowiadało. ;) ale nie wiem jak jest 'zgodnie ze scrumem'. - tdudzik 2018-10-07 00:18
Nie wiem jak jest zgodnie ze Scrumem. Jak widać każdy interpretuje Scruma po swojemu :P - Wibowit 2018-10-07 01:03
Przypisywanie zadań do osób stoi w sprzeczności z samoorganizacją zespołu w scrumie. Wolny programista wybiera sobie task i go robi. - somekind 2018-10-07 01:09
No w sumie przypisywanie taskow w taki sposób może rodzić problemy jak nagle ktoś wyleci ze sprintu, jego taski są priorytetowe, a nikt inny nie jest w stanie ich zrobić wystarczająco szybko (bo np. osoba do której został on przypisany znała temat dogłębnie i oceniła że jest w stanie 'jeszcze ten task zrobić w sprincie', ale była jedyna taka osobą). Nie mieliście takich problemów @Wibowit ? - tdudzik 2018-10-07 09:29
Były podobne, np kolega nie wyrobił się z zadaniem przed urlopem, chociaż na planowaniu twierdził, że się zmieści. Typowym rozwiązaniem jeśli komuś się nie uda zrobić zadania w sprincie jest przeniesienie zadania na następny sprint :) Zdarza się to bardzo często. - Wibowit 2018-10-07 10:56

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: Xenu Link Sleuth (2x)