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-11 18:43
0

Po tych obserwacjach - jakie sugerujesz zmiany?

edytowany 5x, ostatnio: WeiXiao, 2018-02-11 18:45

Pozostało 580 znaków

2018-02-11 19:38
1

Jestem po dwudniowym szkoleniu na Scrum Mastera to się wypowiem :-)

Krolik napisał(a):

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

Zależy jak się ją robi. Estymacja wzorowana na punktach funkcyjnych i trzypunktowa mi się sprawdzały - zależy od typu zadania. Wiadomo że im większe zadanie tym większe ryzyko odchylenia.
Scrumowski poker traktuję raczej jako spotkanie towarzyskie niż coś użytecznego, zresztą z tego co wiem jest opcjonalny w Scrum.

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

W Scrum chodzi o to żeby mieć ciągle działający produkt. Duże, niepodzielne zadanie oznacza że nie jest to zmiana iteracyjna tylko rewolucyjna, z czym wiążą się wszystkie możliwe ryzyka.

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

To już zależy chyba od tego kto na tej retrospekcji jest obecny. Jeśli ludzie dla których ważny jest tylko frontend to może być nawet ciężko przepchać taski backendowe, nie mówiąc o architektonicznych.

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

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

Gdyby chodziło o brak zaufania do członków zespołu to byłoby wbrew założeniom Scruma.
Jako TL (mamy niepełny Scrum) lubię wiedzieć co kto robi. Jeśli jest jakaś wymiana wiedzy w zespole to developerzy raczej też lubią.

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

W takim książkowym Scrumie klient wywiera naciski tylko na PO, a team bierze to pod uwagę tylko na spotkaniach z PO (np. Spring Planning).
Jeśli klient wywiera presję w trakcie Sprinta to chyba coś nie tak?

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

Tu się zgodzę. Są produkty, które nie powinny powstawać iteracyjnie (np. stacja kosmiczna).

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

Jeden spec od rzeczy X robi zadania z nią związane n razy szybciej, ale przez to może blokować pracę zespołu, a gdy odejdzie z zespołu generuje spore opóźnienia. Jakimś kompromisem jest zaprzęganie 2 ludzi na zmianę do jednego tematu i przypisanie 2x więcej takich tematów.
Patrz: https://medium.freecodecamp.o[...]ion-we-ever-made-4c0a99728fde

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

U nas jest dopiero wprowadzany. Na razie działamy iteracyjnie, niektóre zespoły mają daily scruma.

edytowany 1x, ostatnio: vpiotr, 2018-02-11 19:38
"W Scrum chodzi o to żeby mieć ciągle działający produkt. Duże, niepodzielne zadanie oznacza że nie jest to zmiana iteracyjna tylko rewolucyjna, z czym wiążą się wszystkie możliwe ryzyka." Zgodzę się na 100%, dlatego przy projektach zaczynających się od 0% postępu, bez poprawnie wykonanej analizy zagadnienia i rozważenia wszystkich możliwych komplikacji będzie to działać (ale bardzo kulawo) tylko dzięki dobrej woli zespołu. Przy czym opóźnienia będą kosmiczne, a i wkurw nie mniejszy (i to wszystkich uczestników po kolei) - maniutek20 2018-02-13 23:47

Pozostało 580 znaków

2018-02-11 20:02
Trzeźwy Karp
0

Podpisuje sie pod tym rekami i nogami. Widzialem firmy, w ktorych wprowadzenie scruma pograzalo cala organizacje.
A najlepsze jest to, ze jak scrum nie dziala to zaraz znajdzie sie jakis fanatyk, ktory bedzie [CIACH!] ze nie dziala bo zespol byl za malo agile. W idealnym scrumie wszystko powinno dzialac, a jak nie dziala to to nie jest scrum. Sprobuj walczyc z takim rozumowaniem.

Pozostało 580 znaków

2018-02-11 20:25
cw
0

Ja tam sugeruję zupełnie inne podejście. Nie tracić czasy na bzdury tylko zatrudnić na kierownika człowieka, który ma wrodzony dar do kierowania zespołem i umie dobrze zorganizować pracę.

Pozostało 580 znaków

2018-02-11 20:28
0

Wedlug mnie dziala, tylko nie mozna byc scrumowym faszystą ;)

No chyba, ze mialbym zespol samych wymiataczy, wtedy pewnie bym olal.

W standupach mozna szybko zweryfikowac czy ktos potrzebuje pomocy. Trwa to jakies 10 minut. Wiec nie widze za bardzo problemu. Duzo lepsze sa standupy jesli gdzies mozna zwizualizowac obecnego scrum boarda.

Poza tym... Jestescie pewni, ze bez scruma pracowalibyscie lepiej?

edytowany 4x, ostatnio: karsa, 2018-02-11 20:37
Pracowałem i w scrumie i bez, i każdy scrum po pewnym czasie się degenerował do czegoś dziwnego. Tzn. zwykle pozostawał cargo-kult, który tylko stanowił niepotrzebne obciążenie. Albo programiści i tak robili wszystko po swojemu i olewali scruma, albo dochodziło do wypaczeń typu "nie możesz wziąć tego tasku, bo wyczerpaliśmy limit na ten sprint". Albo na standupach połowa osób odpowiadała "to samo co wczoraj, brak problemów". :D - Krolik 2018-02-12 10:12
no to olewanie nie musi byc takie zle w takim razie ;) ja to traktuje jak framework, biore z niego co potrzebuje ;) - karsa 2018-02-12 10:54

Pozostało 580 znaków

2018-02-11 20:40
0

Działa. Obserwacje i dane statystyczne z runku na to wskazują. Inną sprawą jest to że to metodyka wytwórcza a nie projektowa (a nawet to nie każdy rozumie), jeszcze inną sprawą jest to że to... metodyka. To oznacza że ma ograniczenia o których nie mówi (bo ich nie widzi), luki których nie adresuje i granice zastosowań.
Fanatyzm w stosowaniu ideologii nie tylko projekty kierował w ścieżkę "alternatywnego sukcesu - wiele śmy.. .się nauczyli" ale upadlał narody.


Każdy problem w informatyce można rozwiązać, dodając kolejny poziom pośredniości,z wyjątkiem problemu zbyt dużej liczby warstw pośredniości — David J. Wheeler
"dane statystyczne z runku na to wskazują" coś więcej napiszesz? Nie widziałem nigdzie sensownych badań, które wykazałyby że scrum działa. - Krolik 2018-02-12 10:12

Pozostało 580 znaków

2018-02-11 21:18
0

Moim zdaniem Scrum ogólnie działa - ale jako styl prowadzenia projektu, a nie religia. Z tym, że nie działa szacowanie złożoności i związane z tym patologie, czyli promowanie prostych zadań. Dlatego my w firmie mamy Scruma, ale trochę olaliśmy szacowanie bo mimo nacisków ze strony menedżera (który chciał mieć ładne wykresiki do pokazania kadrze wyższego szczebla) i wielu planning pokerów precyzja szacunków się nie poprawiała. Ponadto nasz zespół jest dość mocno asertywny, więc problemów z komunikacją nie ma jakoś specjalnie dużo - to się akurat poprawia wraz z dojrzewaniem zespołu.


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

Pozostało 580 znaków

2018-02-11 21:22
3

@Krolik w skrócie: moim wszystko zależy od rodzaju projektu. Scrum sprawdza się w sytuacjach kiedy wiadomo jak należy klepać system bo np. kolejny raz klepiecie coś podobnego. Sprawdza sie też kiedy rozwijacie istniejący produkt przez dodawanie małych dodatków, bo wtedy znów wiadomo jak to zrobić, da się to podzielić na małe kawałki, da się oszacować nakład pracy itd.

Scrum sprawdza się słabo jeśli masz projekt "badawczy" tzn taki gdzie w zasadzie nie wiadomo jak coś zrobić i czy się w ogóle da, bo nagle nie da się za bardzo zaplanować tasków, a często nie da się nawet podzielić pracy na małe fragmenty, bo nie wiesz co to będą za fragmenty zanim nie zaczniesz przy tym pracować. W podobnej sytuacji zresztą nie sprawdza się też TDD.


Na PW przyjmuje tylko (ciekawe!) zlecenia. Masz problem? Pisz na forum, nie do mnie.
myślę, że nawet projekty, które są "raczej monotonne" (np. kolejna apka webowa) wcale nie są tak monotonne, tylko zawierają w sobie wiele niewiadomych, dlatego w rezultacie każdy projekt jest do pewnego stopnia badawczy. - LukeJL 2018-02-12 18:49

Pozostało 580 znaków

2018-02-11 21:45
1
  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".

<3 100% racji - chociaż mnie najbardziej rozbraja tłumaczenie się scrum kołczów że ten problem można rozwiązać przechodząc np: ze story pointów na koszulki XD XD XD plis, programming mother fu!@#rs !

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

Niby tak, ale nie do końca :D nie wiem jak pracujecie z bazą danych bo to fizycznie jeden produkt (a może jest inaczej?) - ja mam odczucie że budując dość dużego SAAS'a w kilka zespołów jesteśmy w stanie dostarczać jakieś tam end-to-end ficzery, ale może dlatego że to w takiej biznesowej apce po prostu łatwiej dostarczyć :D klepnięcie get'a z bazy a wrzucenie paxosa w baze to troche inna skala.
Mnie jednak kłuje coś innego, że te ficzery są dostarczane jako MVP .... wszystko jest u123A MVP, po co optymalizować, zrobić performance testy, uj, MVP !

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

Każde zadanie da się podzielić np: to https://issues.apache.org/jira/browse/CASSANDRA-10989 - wydaje mi się, wielka zmiana architektoniczna, a jednak da się podzielić na taski :) dzielenia na mniejsze taski jest spoko, i nawet nie chodzi o to że się dzieli - tylko o to że łatwiej potem to trackować i jak widać że ktoś się pali a honor mu nie pozwala przestać to można szybko zainterweniować.

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

niech spłonie każde manifesto.

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

ja lubie standupy - cena 15min za generalne skupienie myśli i podzielenie się problemami i planami ? opłaca się ! może złe rzeczy omawiacie na standupach
Największym marnotrawstwem czasu jest dla mnie planning i grooming, grrrrr !!!!111

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

ヽ( ͠°෴ °)ノ

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

+1

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

+Integer.MAX_INT

Może u Was Scrum / agile działa?

jeszcze się turla, ale tytanic też płynął i na początku nawet nieźle mu szło !


small data and high latency
edytowany 1x, ostatnio: rubaszny_karp, 2018-02-12 01:36

Pozostało 580 znaków

2018-02-12 01:26
2
Krolik napisał(a):
  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".

Obecnie mam podział na banalne (wiadomo co robić, zajmie 10 minut do 1 dnia), normalne (wiadomo co robić, zajmie 1-3 dni) i trudne (albo dłuższe niż 3 dni albo dotykające legacy kodu albo wymagające jakiejś zmiany architektonicznej). W przypadku "nie mam pojęcia", to się po prostu robi PoC (góra dwa dni).
Generalnie każdy rozumie projekt na tyle, żeby wiedzieć do jakiej grupy dany task należy, więc na żadne pokery i przekomarzanie się czasu nie tracimy, estymacja sprintu zajmuje nam 30-40 minut. W sumie nie wiem po co to szacowanie, u nas się żadnych wykresów nikomu nie pokazuje, biznes interesują dowiezione ficzery. A mnie interesuje czym potencjalnie będę się zajmował w ciągu najbliższego czasu.

W poprzedniej firmie, która bardzo chwaliła się byciem Agile, planowanie zajmowało cały dzień, a poziom granulacji tasków był taki, że zamiast "dodaj jakiś ficzer do systemu", było: "1. dodaj checkboxa na GUI, 2. dodaj CSS do checkboxa, 3. zmapuj w JS, 4. zmapuj w kontrolerze, 5. zmapuj w serwisie aplikacyjnym, 6.....12 dalsze mapowanie, 13. dodaj do konfiguracji ORM, 14. dodaj kolumnę tabeli, 15. napisz testy do JS, 16. napisz testy do kontrolera, 17-25. reszta testów....".

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

Serio istnieją organizacje tak głupie, że nie planuje się niczego rocznie/półrocznie/kwartalnie tyko w oparciu o same sprinty?

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

Bo ludzie w IT to w większości niemyślące samodzielnie matoły, które do wszystkiego muszą mieć instrukcję, a jak już mają, to się jej kurczowo trzymają. Stąd bezmyślne używanie technologii, nieprawidłowe implementacje prostych wzorców projektowych, ślepe podążanie za modami, czy fanatyczne trzymanie się wszystkich zasad Scruma.

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

To akurat jest chyba jedyna sensowna rzecz w tej metodologii, bo to wymiana informacji. Mnie np. interesuje co na temat problemów z wdrożeniem ma do powiedzenia programista, który fizycznie może kopnąć devopsa, albo chcę poinformować BA i QA, że mój ficzer jest już gotowy (albo nie).
Z tymże ja to doceniam tylko dlatego, że pracuję w zespole międzynarodowym. Jakby cały team siedział w jednym pokoju w jednej strefie czasowej, to bym po prostu krzyknął: "Mietek, możesz już testować tego taska." i żadne specjalnie nazwane konferencje nie byłyby do tego potrzebne.

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

To prawda... tylko z drugiej strony nie można zakładać, że każdy będzie pracował w projekcie wiecznie.

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

No to jest wiadome od wielu lat, tylko czemu akurat dzisiaj to zauważyłeś?


"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

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: Scoop