Scrum nie działa

21

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?

0

Po tych obserwacjach - jakie sugerujesz zmiany?

2

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

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.org/we-fired-our-top-talent-best-decision-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.

1

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.

2

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

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?

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.

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.

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.

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 !

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ś?

0
Shalom napisał(a):

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.

Albo jak programiści uczą się technologii dopiero, wtedy też nie wiadomo, jak coś zrobić, a jak coś sie zrobi to potem okaże się, że trzeba by było jednak to zrobic inaczej.

2

Hmm, piszecie, że Scrum nie działa w projektach gdzie programiści dopiero się uczą lub w projektach badawczych. W porządku, jestem w stanie się zgodzić.
Tylko w takiej sytuacji: po co w ogóle Scrum? Jeśli projekt jest przewidywalny, wymagania dobrze znane i rozumiane oraz mamy doświadczonych programistów, to po co w ogóle stosować jakąkolwiek metodykę tego typu? Programiści po prostu muszą to zakodować i sprawa załatwiona. Wiedza, co trzeba robić.

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

Dlaczego? Może bo Scrum nie działa?
Poza tym stacje kosmiczne akurat powstają iteracyjnie. Ale nie w sensie scruma, tylko w sensie takim, że są etapy i każdy etap jest projektowany, testowany i implementowany z dużą starannością i naciskiem na jakość.

Po tych obserwacjach - jakie sugerujesz zmiany?

  1. Używać zdrowego rozsądku. Każdą regułę można złamać, dysponując odpowiednim uzasadnieniem.
  2. Zatrudniać programistów / projektantów / architektów, których nie trzeba prowadzić za rączkę. Niekoniecznie samych seniorów. Bardziej chodzi o podejście tj. ludzi, którzy nie boją się wziąć odpowiedzialności za swój kod, którzy są zainteresowani projektem i są zarazem dojrzali, więc nie będą się obijać nawet niepilnowani.
  3. Mieć w zespole kogoś bardziej doświadczonego (tech leada) od rozwiązywania trudniejszych problemów technicznych i podejmowania decyzji technologicznych / rozstrzygania dyskusji w stylu "czy piszemy to w Basicu czy PHP". Doświadczonych programistów może być więcej, jednak ważne jest, aby była osoba decyzyjna i aby dyskusje "PHP czy Basic" nie ciągnęły się w nieskończoność.
  4. Mieć w zespole sensownego managera od pilnowania bieżącego postępu projektu i komunikowania się ze światem zewnętrznym. Kogoś, kto umie się efktywnie komunikować z programistami oraz klientem, głównie w stylu 1:1 lub małych grupach, aby nie tracić czasu na wielkie i częste spotkania. Musi nie być upierdliwy (nie "mikrozarządzać") ale musi być dobrze zorganizowany i wiedzieć co się dzieje w projekcie i kto jest za co odpowiedzialny.
  5. Utrzymywać cały czas działający projekt i starać się rozwijać projekt przyrostowo. Zaczynać od czegoś małego i prostego. Tak, to się akurat pokrywa z agile. Z drugiej strony jednak pozwolić małym grupkom bardziej doświadczonych programistów lub nawet pojedynczym inżynierom pracować nad czymś większym i dać im pewną swobodę nawet we wprowadzaniu rewolucji. Jeśli czasem trzeba się cofnąć o dwa kroki, przepisać jakiś fragment na nowo i nawet zepsuć kilka testów po drodze, to w dłuższej perspektywie to się może opłacać, bo takie rewolucje zwykle poprawiają strukturę projektu i eliminują dług techniczny.
  6. Mieć gałąź stabilną projektu i gałąź (lub kilka gałęzi) eksperymentalną. W gałęzi eksperymentalnej dozwolone jest tymczasowe psucie czegoś, aby coś innego działało lepiej. Można potraktować gałezie eksperymentalne jako takie dłuższe topic-branche (epic).
  7. Mieć osobny zespół pilnujący jakości w gałęzi stabilnej m.in. za pomocą automatycznych testów funkcjonalnych i wydajnościowych.
  8. Angażować programistów w spotkania z klientem, jeśli wymaga tego sytuacja. Jeśli pojawia się wątpliwość, np. jak zrobić funkcję X, to bierzemy na spotkanie np. tech leada, kluczowego programistę odpowiedzialnego za funkcję X oraz managera, ale nie ciągniemy całego zespołu.
  9. Żadnych rytuałów. Brak sprintów, brak codziennych spotkań. Nacisk na komunikację bezpośrednią + utrzymanie aktualych informacji w trackerze projektu (np/ Github/Jira). Spotykamy się jak jest potrzeba, a nie bo "minęły 24h". Jeśli zmieniła się sytuacja w połowie tyogodnia, i ktoś odkrył poważny bug, to naprawiamy od razu, a nie czekamy na kolejne spotkanie planowujące, aby to oszacować.
  10. Programiści mogą wprowadzać drobne ficzery / poprawki bez uzgadniania z klientem/managerem. Widzisz, że jest coś źle, to poprawiasz i już. Minimum gadania, maksimum efektów.
  11. Taski, które lubimy/chcemy zrobić priorytetyzujemy wyżej niż te których nie lubimy, chyba że jest bardzo ważny powód, aby robić coś innego (uzasadniona presja klienta itp). Programiści są 10x bardziej efektywni kiedy robią coś co lubią.
  12. Za dany ficzer / zadanie odpowiedzialna jest zawsze jedna osoba, najlepiej za całość tj. analizę wymagań / projekt / implementację i testowanie. Oczywiście jest wskazana współpraca tj. można robić spotkania / recenzje projektu / kodu / dyskutować rozwiązania, ale ostatecznie jedna osoba jest odpowiedzialna za kształt komponentu. Wymiana wiedzy zachodzi podczas spotkań i code-review, ale zasadniczo dążymy do specjalizacji. Korzyści ze specjalizacji są IMHO znacznie większe niż okazyjne spowolnienie, które specjalizacja spowoduje, jeśli programista odejdzie z zespołu i trzeba będzie go zastąpić. A dzięki code-review jakość kodu powinna być na wystarczająco wysokim poziomie, aby nowy programista szybko się wdrożył.

Disklejmer: to nie jest dokładnie proces który mamy w firmie, gdzie pracuję (z drugiej strony nie używamy też Scruma) Są to moje prywatne przemyślenia.

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.

Jak napisałem wyżej, jestem ogólnie za tym, aby mieć ciągle działający produkt. Ale z drugiej strony awersja do ryzyka i działanie przyrostowe to bardzo prosta droga do zabicia innowacji w projekcie oraz zniechęcenia ambitniejszych programistów. Lepszych w tym sensie, że są ludzie, którzy potrafią zrobić rewolucję w projekcie, ale jednak dociągnąć ją do końca i ostatecznie projekt działa lepiej. Duża liczba małych przyrostowych zmian często prowadzi do powstawania bałaganu (przecież klas na 2000 linii nie napisał nikt jednego dnia, tylko powstawały przez dorzucanie po 10 linii przez różnych ludzi w ciągu kilku lat).

No i jest jeszcze aspekt taki, że "iteracyjność" może być różna na różnych poziomach projektu. Np. na poziomie kompilacji projektu mogę się poruszać bardzo małymi kroczkami - tak że projekt się kompiluje cały czas. Na poziomie testów czasami już mogę coś chwilowo bardziej zepsuć (np. nie przechodzą jakieś testy), wiec te iteracje między działającycmi wersjami mogą być dłuższe. Natomiast na poziomie funkcjonalnym (biznesowym), mogę pracować przez 3 miesiące, zrobić 1000 committów, a dla klienta nadal ficzer nie będzie prezentował wartości, dopóki go nie skończę.

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.

Pracuje w zespole międzynarodowym i też mogę napisać na Slacku "Mietek, możesz już testować tego taska". Tak na wypadek, jakby Mietek nie zauważył, że się status w Jira zmienił i że powiadomienie przyszło. Właśnie nie bardzo widzę sensu wymuszania konunikacji codziennie, skoro ludzie i tak się komunikują. A w razie jak się nie skomunikują, to manager się dopyta - "Józek, jak z tym taskiem, bo Mietek mógłby już testować". Od tego chyba jest manager?

18

Zwykle w dyskusji nad agile Scrumem wklejam wideło Erika Meijera - One Hacker Way.
Ale teraz wkleje coś od siebie - przeszedłem już Scruma w kilku firmach i kilku projektach. Tak gdzieś w 2007-2010 po szkoleniach itp byłem zachwycony i wiadomo ogłupiony. ... ale potem z wolna przeszło.

Problemy Scrum

  1. Banda pasożytów:Scrum Masterów, PO, prowadzących szkolenia itd. - inaczej Agile Klaunów, żyjąca z tego - kosztuje czas i pieniądze,
  2. Masa nonsensownych spotkań - od daily standupów do retrospektyw itp. Spotkanie jest nonsensowne jak generuje więcej strat niż korzyści.
  3. Absurdalne metryki typu story pointsy, velocity, burndown charty - strasznie dużo czasu zajmuje przekonywanie managmentu, żeby je sobie wsadzili w d**y.
  4. Masowe wykorzystanie Scruma w projektach gdzie nie ma sensu: maintenance, fixed price (to nie żart).

Widzę, że firmy przechodzą przez kilka etapów SCRUMencji.
Obrazek jest wyidealizowany - bo każda firma i projekt to trochę inna historia, ale wygląda tak.

  1. Radość entuzjastów. Kilku sceptyków, ale ogólnie zachwyt, wiara, że teraz będzie lepiej. Cała energia idzie w przekownywanie sie kto jest bardziej agile i dlaczego nasz SCRUM nie jest dość SCRUMMy.
    Typowe symptomy:
  • dużo klaunow wierzących w lepszą przyszłośc,
  • eksplozja DOD: porażki przekładają się w coraz bardziej zbiurorkatyzowane definition of done,
  • retrospektywy z toną wniosków, które nie są wprowadzane,
  • przygotowanie dema rozbija cały plan i ciąg pracy,
  • oglądanie burndown chartów, velocity i wyciąganie z nich wniosków
  • sprinty 3 tygodniowe - 2- miesieczne (w javie to nie ma sensu),
  • zabawy w planning poker itp.
  • eksplozja biurokracji i sformalizowania - dodatkowe meetingi
  • managerowie przychodzą na wszystkie możliwe spotkanie (w razie czego tylko popatrzyć),
  • naciąganie wyników pod charty,
    Co się odbywa:
    To tak naprawde waterfall with standups.

Niektróre firmy w tej fazie tkwią latami.

  1. SCRUM optymalizujący.
    Developerzy zaczynają regularnie olewać SCRUM, koniec zachwytu, managerowie zaczynają olewać velocity, burndown charty
    Symptomy:
  • zaczynają sie uproszczenia w procedurach,
  • robi się pair programming,
  • spotkania zaczynają się trochę skracać,
  • wywala się wszystkich niezwiązanych z teamem ze spotkań,
  • na daily zaczyna się mówić o tym co jest istotne dla pracy,
  • zaczyna się ostra krytyka scruma,
  • skracanie sprintów,

Co się odprawia:
Tak naprawde wychodzi taki SCRUM by the book.

Da sie w nim wytrzymać, o ile jakoś pasuje do firmy i projektu.
NIektóre firmy i projekty do tego etapu dochodzą.

  1. Post scrum (tylko raz tam byłem),
    Symptomy,
  • Nikt już nie robi dramy ze spotkań,
  • planingi, retrospektywy sa dla chętnych, (jak pół zespołu ma jasną sytuację na najbliższy tydzień to olewa planowanie),
  • daily formalnego nie ma, choć w zasadzie trwa cały dzień. Jak coś masz to mówisz
  • robimy eksperymenty z procesem,
  • wywalamy klaunów (SM itd.),
  • bezpośredni kontakt z userami to norma,

Co się odprawia:
Programming motherfucker

1

ja szacowalem w zespole w dniach jako sprint pointy i w miare to wychodzilo i trwalo to dosc szybko.

a do estymacji ogolnie polecam https://www.random.org/ ;]

a zeby wylac troche wiadro pomyj to polecam:

ps. ogolnie imo bierzemy wszystkie manifesta craftsmanship, agile, programming motherfucker i wypracowywujemy zloty srodek ;)

5

Ogólnie jeśli już masz całkiem zrypany process to SCRUM może się podobać. W średniej wielkości firmie, (100-200 developerów), gdzie coś poszło nie tak, można jedną chorobę: jakiś waterfall wyleczyć drugą (SCRUM).
Jeśli ktoś wprowadza SCRUM w małym startupie to generalnie uprawia sabotaż (SCRUM jest całkiem cięzki i to kolejna rzecz do defokusowania zespołu, a zwykle startup sobie na to nie może pozwolić).
W dużym korpo SCRUM to kolejne narzędzie walki miedzy sobą dla managementu. Developerzy będą tylko przypadkowymi ofiarami.

0

@Krolik: Scrum jest spoko, ale jak sie go odpowiednio zaimplementuje (w sensie zupelnie inna wersje niz oryginalna scrum). Dokladnie te wady ktore wymieniles, czesto mozna spotkac w prawie kazdym Scrumie.
Teraz pracuje przy projekcie (w metodologi Scale Agile) ktory ma jakies 30 repo, mniej wiecej 70 solucji i okolo 500 projektow. Sa fragmenty kodu gdzie po prostu nie mam pojecia co sie dzieje i musze isc sie pytac kogos kto przy tym robil, ale. Odpowiadajac na kazdy punkt z osobna

Estymacja wielkości zadań była bezużyteczną stratą czasu
Nie zgadzam sie, proces ktory u nas dziala (bo estymujemy na prawde dobrze. Jedynie gdy zewnetrzne czynniki na nas wplywaja, to wtedy ta estymacja nie jest realna)

  1. Przed groomingiem dostajemy dokument / link ktory opisuje biznesowa wartosc dla produktu. Ale na tyle szczegolowy by wiedziec gdzie zmiany w kodzie maja byc zrobione
  2. Spedzam max 20 min na zobaczenie co trzeba zmienic
  3. Pytania sa wyjasnianie na groomingu
  4. Wtedy mozna wyestymowac, bo +- wie jakie zmiany trzeba wprowadzic, jakie jest ryzyko wprowadzenia zmian i nie ma zadnych pytan (nie powinno)
    Robilismy projekty ktore trwaly po pol roku a czasami niektore ktory byly do zrobienia na dwa dni. Jakos bardzo nigdy nie bylismy z estymacja. Duzo czasu nad tym nie spedzilismy, a przynajmniej bylismy miarodajni (wiarygodni) z nasza estymacja.
    Nasza estymacja nie wyglada typowo scrumowa. Raczej staramy sie planowac na dni/godziny zamiast na effort/story points. Wiem, ze tego nie powinnismy robic. Ale effort/story points jest niemiarodajne gdy Twoj team sie ciagle zmienia, oraz zmienia sie temat nad ktorym pracujesz (raz finanse, raz HR, raz co innego)

W praktyce nie jest możliwe sensowne zaplanowanie rozwoju złożonego produktu planując w sprintach po dwa tygodnie.
Tez sie nie zgadzam, Gdy masz zlozony produkt (jako projekt) to

  1. Scrum do tego sie nie nadaje
  2. Duzo przed rozpoczeciem prac zrobic to co w punkcie 1 tylko bardziej globalnie wraz z programistami

Każde zadanie niby da się podzielić na N małych zadań
Nie da sie kazdego. Czasami jedno jest zalezne od drugiego. Wtedy mozna po prostu dac zaleznosc. Tak w scrumie czegos takiego byc nie powinno, ale rzeczywistosc jest inna

Agile manifesto zakłada, że interakcje są ważniejsze niż proces
to juz wszystko zalezy od firmy. My dosc duzo robimy Grimplementing (czyli wyjasnianie w momencie gdy piszemy kod). Co jest jeszcze wieksza strata czasu bo trzeba rzeczy robic po 2-3 razy

Standupy
Gdy masz maly team to zapewne nie jest potrzebne. Ja mam 8 osob i kazdy z nich moze dowiedziec sie czegos ciekawego i wtedy standup sie przydaje.
Ja sam jestem zwolennikiem komunikatorow jak Discord / Slack i tam trzymac wazne informacje przypiete tak gdy kogos nie bedzie, moze to przeczytac.

Zbyt duży wpływ klienta na planowanie, zbyt mało swobody dla programistów / architektów / analityków
Planowanie zadan, ale nie w jaki sposob one beda realizowane. Calkiem normalne, ze jezeli chcesz cos za pol roku to klient moze chciec jakas tam kolejnosc wykonywania zadan.
Pytanie wtedy czy zawsze zgadzacie sie z klientem czy mowicie mu tez nie, to nie ma sensu zrobmy tak?

Zbytni nacisk na implementację i deprecjonowanie wagi procesu wstępnego projektowania i roli indywidualnych talentów
Dokladnie tak jest, ale Scrum to system ktory ma dzialac na duze zespoly. W takich duzych zespolach kazdy jest trybikiem za cos a nie indywidualnoscia. To jest dla firm, ktore chca stworzyc COS, a maja duzo kasy i duzo programistow.

Brak własności kodu i rozmywanie odpowiedzialności
Przy malych teamach to nie ma sensu i sie zgadzam. Ale gdy pracuje sie nad wielkim produktem trzeba wiedze rozpowszechniacz bo moze stac sie sytuacja, ze team odpowiedzialny za dany "projekt" odejdzie i wtedy nikt nic o nim nie bedzie wiedzial. Dla bizesu to jest najgorsze co moze sie stac

Nie jestem fanem scruma, ale niektore rzeczy ktore wykorzystuja mozna jak najbardziej wykorzystac. Estymacja pracy jest spoko. Daje to mniej wiecej lepszy widok co bedzie robione w tym czy nastepnym tygodniu.
Mozna zalozyc milestone (nie jest to scrumowy koncept) na dalekoidace zmiany (3-6-12 miesiecy)
Raporty mozna generowac na podstawie taskow a nie story pointow ktore nie ma jak porownywac...

0

Tym wszystkim mówiącym "Scrum, jeśli się go odpowiednio zaimplementuje, to będzie pomagał" to przypominam, że :

  • Scrum to implementacja Agile, czyli albo masz Scruma, albo coś Scrumopodobnego
  • jeśli masz coś scrumopodobnego i projekt ci się udał to jest to zasługa elastyczności Scruma
  • jeśli projekt nie wyszedł to masz" Scrum in name only"
2
Krolik napisał(a):

Tylko w takiej sytuacji: po co w ogóle Scrum?

To chyba oczywiste - żeby konsultanci i szkoleniowcy mogli zarobić.

przecież klas na 2000 linii nie napisał nikt jednego dnia, tylko powstawały przez dorzucanie po 10 linii przez różnych ludzi w ciągu kilku lat

Nigdy nie pracowałeś z Hindusami, prawda?

Pracuje w zespole międzynarodowym i też mogę napisać na Slacku "Mietek, możesz już testować tego taska". Tak na wypadek, jakby Mietek nie zauważył, że się status w Jira zmienił i że powiadomienie przyszło.

Mnie nie chodziło, o to że w zespołach międzynarodowych standupy są koniecznie tylko o to, że w zespołach nierozproszonych są bez sensu.

Właśnie nie bardzo widzę sensu wymuszania konunikacji codziennie, skoro ludzie i tak się komunikują.

Niemniej jednak czasem dyskusja w większym gronie ma sens. Ktoś przysłuchujący się dyskusji dwóch osób może zaproponować lepsze rozwiązanie albo powstrzymać przed popełnieniem błędu. W przypadku komunikacji tylko między dwiema osobami nie jest to możliwe.

A w razie jak się nie skomunikują, to manager się dopyta - "Józek, jak z tym taskiem, bo Mietek mógłby już testować". Od tego chyba jest manager?

Dla mnie rola managera ogranicza się do zatwierdzania urlopów. Od pilnowania tasków jest ich twórca, czyli BA.

fasadin napisał(a):

Dokladnie tak jest, ale Scrum to system ktory ma dzialac na duze zespoly.

Yyy... ale przecież Scrum się totalnie, kompletnie i bezapelacyjnie nie skaluje.

Ale gdy pracuje sie nad wielkim produktem trzeba wiedze rozpowszechniacz bo moze stac sie sytuacja, ze team odpowiedzialny za dany "projekt" odejdzie i wtedy nikt nic o nim nie bedzie wiedzial.

Wielkie projekty nie są Agile.

9
wartek01 napisał(a):

Tym wszystkim mówiącym "Scrum, jeśli się go odpowiednio zaimplementuje, to będzie pomagał" to przypominam, że :

  • Scrum to implementacja Agile, czyli albo masz Scruma, albo coś Scrumopodobnego
  • jeśli masz coś scrumopodobnego i projekt ci się udał to jest to zasługa elastyczności Scruma
  • jeśli projekt nie wyszedł to masz" Scrum in name only"

Czyli dokładnie tak samo jak z komunizmem. Jak coś nie działa, to tylko przez: błędy i wypaczenia.

0

Nie czytałem całego wątku, tylko temat, ale co do pisania wspólnie sprawdziły mi się tylko projekty dwuosobowe poza pracą i tylko wtedy gdy z osobą miałem dobre kontakty - takie projekty powstawały b. szybko i działało to u mnie tak, że najpierw obgadujemy szybko co jest do zrobienia i dzielimy projekt na czysto określone części (np. ty piszesz biblioteke do tego i tego, a ja część która z niej korzysta) - wymaga to, żeby na szybko napisać jakiś interfejs (np. plik H) - to dawało też dużą motywację do skończenia szybko i szczegóły implementacji nas nie obchodziły - zasady są proste - kolega ma swój styl pisania, ja swój, każdy pisze jak lubi, ale interakcja między częściami i output określone są z góry. Jak pojawia się gdzieś bug to nie ruszasz kodu kolegi tylko na niego gadasz że zjeb*** (bez obrazy ofc). Nim więcej zwracania uwagi na styl i inne pierdoły tym mniej skończonych projektów - oczywiście jak kończysz jakiś etap w projekcie (prototyp działa) to trzeba kod wyczyścić, bo za X dni Cię to ugryzie ale zanim działa lepiej się nie rozpraszać. Z resztą punktów mam podobne doświadczenie. Co do gadania na scrumie, z mojego doświadczenia, niektórzy mają lepsze skille w gadaniu od innych, ale nie przekłada się to na output ale management jest bardziej zadowolony.

1

Scrum-Kanban etc... to bezsens - jak masz ludzi co nie kumają jak się pisze to Kanan za nich tego nie zrobi. Dlaczego w Linux kernel NIE MA Kanbanu? Dlaczego doktoranci z profesorami nie maja Kanbanu?

Bo to koporacyjna zabawa dla małolatów, Skaczecie w kółku na spotkaniu też i opowiadacie co was gryzie jak na AA?

0
Krolik napisał(a):

Pracowałem w kilku firmach, które deklarowały prowadzenie projektów scrumowo i agile. Doświadczenia skrajnie różne. Na początek duża polska firma ubezpieczeniowa na 3 litery. Używali, cytuję z pamięci "autorskiego połączenia Prince II i Scrum". Moim zdaniem nie działało.
Druga firma - głównym zadaniem scrum było odnalezienie się w stanie projektu i ew. wychwycenie co kto robi. Projekty dla klienta zewnętrznego (software house) ani nie pomagało, ani za bardzo nie przeszkadzało.
Trzecia firma - korpo starające się robić scrum "by the book" i tutaj, z grubsza rzecz biorąc scrum działał. Ale to też najbardziej ogarnięty zespół w jakim pracowałem i (jak by to patetycznie nie brzmiało) o wysokim morale i motywacji.
Była jeszcze jedna, co pisała, ze używa Scruma, bo nie da się udowodnić, ze nie używa, a coś trzeba napisać.

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

I tak i nie - scrum poker dawał bardzo duży rozstrzał w ramach pojedynczych zadań, ale dziwnym trafem w kolejnych sprintach udawało się "zdobywać" bardzo zbliżone liczby punktó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.

Pewnie częściowo jest to prawda, ale trzeba pamiętać, że alternatywą często jest robienie przez 2-3 lata systemu, który na końcu - niespodzianka - nie działa. Wszystkie taski zrobione, budżet przepalony, ludzie już w nowych firmach, generalnie operacja się udała, pacjent nie przeżył.

  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.

Retrospekcja, punkty, scrum meeting to nie są narzędzia do oceny pracownika, tylko do usprawniania procesu, estymacji zadań i komunikacji w zespole. Jeżeli się tych narzędzi używa zgodnie z przeznaczeniem, to moim zdaniem działają.

  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?

A w TV mówili, że w Polsce nie ma faszystów - nie spotkałem się z takim podejściem, ale wierzę, że są takie osoby.

  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?

Długość, czas trwania i sposób prowadzenia standup'ów zawsze można dostosować. To ma być narzędzie, żeby każdy się orientował z grubsza co się dzieje w projekcie, czy zależne od siebie taski idą dobrze i zgodnie z planem, czy nie pojawiły się jakieś problemy itd.

  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.

Jak sobie klienta wychowasz, tak masz. Nie bez powodu agile jest szczególnie zalecany do projektów wewnętrznych.

  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.

Można i należy wydzielić role architekta, lead deva - ich rolą jest projektowania systemu i posiadanie obrazu całości.

  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 może należy ten kod pisać czytelniej, lepiej dokumentować i generalnie nie pozwalać na istnienie jakiś kątów aplikacji znanych i rozumianych tylko przez jedną osobę? Co w przypadku choroby urlopu, albo zwolnienia?

0

I tak i nie - scrum poker dawał bardzo duży rozstrzał w ramach pojedynczych zadań,
ale dziwnym trafem w kolejnych sprintach udawało się "zdobywać" bardzo zbliżone liczby punktów.

Pytanie tylko, dlaczego tak się działo?

  • Może duży rozstrzał wynikał z tego, że robiliście coś, czego do końca nie byliście świadomi jak powinno wyglądać, albo jak to zrobić - stąd duży rozstrzał. W miarę rozwoju projektu praca stawała się bardziej przewidywalna, rutynowa, więc łatwiej było estymować?
  • Albo z jakiegoś innego powodu, może punktacja wpływała na was psychologicznie typu "cholera, mamy za mało punktów, trzeba się wziąć mocniej do roboty" czy "zrobiłem zadanie szybciej niż zwykle, więc mogę się trochę poobijać i trochę zwolnić z robieniem następnego, żeby nie było za szybko"?
  • Może też zaczęliście inaczej to estymować. Tj. może świadomie bądź nie, estymowaliście rzeczy w ten sposób, żeby je wyestymować niżej albo wyżej niż trzeba, po to tylko, żeby zachować podobne velocity? (ja się przyznaję - często licytowałem niżej taski, bo po prostu presja grupy była w stylu "co tak wysoko? Przecież to łatwe" i nie chciałem wyjść na słabego).

Swoją drogą nigdy nie rozumiałem parcia na to, żeby mieć przybliżone "velocity" w każdym sprincie. Wydaje mi się, że bardziej naturalne jest, że w jednym sprincie niewiele się dzieje, a w innym jest przełom. Mierzenie pracy twórczej w podobny sposób, jaki mierzy się pracę pracowników fizycznych (w numerkach na jednostkę czasu, zakładając, że każdego tygodnia pracownik jako jednostka, jak i cały zespół jest tak samo wydajny) to jakaś parodia zarządzania projektami IT.

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

Taki sposób podziału zadań jest najbardziej rozsądny i podobnego używam (dokładniej to takiego: trivial ~ godzinka, małe~ dzień , duże ~ kilka dni, w ch..~ pewnie więcej niż kilka dni, nie wiem ~ nie wiem),

Estemacja i planowanie w SCRUMie służy temu samemu co photoshopowane zdjęcia modelek w pismach dla kobiet. Mają was czynić nieszczęśliwymi przez pokazywanie nieosiągalnego ideału.
Macie zostawać po godzinach, żeby zrobić bzdurny "cel", który narzuciliście sobie pokazując, że "macie jaja" i dając niskie czasy/ punkty zadaniom. Idealnie.

Szacowanie jest dlatego zwane szacowaniem, że jest niedokładne - jak ktoś chce dokladne szacowanie to jest to bardzo proste: trzeba zrobić zadanie, a potem powiedziec ile zajęło.
Każdy kótszy czas spędzony na szacowaniu skutkuje automatycznie zmniejszeniem dokładności tego oszacowania.

Największym jednak dowcipem jest uświadomienie sobie: co się w sumie dzieje jak te czasy się nie zgadzają?

Czy jak zadanie było estymowane na 3 story pointy, a wyszło na 5 to czy to pogrąża projekt.
A jak wyjdzie na 8 - co się stanie?
I co by się stało gdy wyjdzie 10? (Wbrew temu,co twierdzą niektórzy klauni agile, liczba 10 istnieje , znalazłem naprawdę zadziwiający dowód tego...).

Otóż - W większości projektów nic się nie stanie, ficzery i taski, kóre były do zrobienia i tak trzeba zrobić. Zwykle w podanej kolejności, która wynika z architektury projektu i piorytetów biznesu...

Jedyne szacowanie jakie jest ważne - to powiedzenie klientowi ile mniej /wiecej bedzie jego życzenie kosztowało, takżeby mógł podjąć decyzję o realizacji i priotyteach. Ale to też wystarczy podać w dniach, tygodniach, bardzo przybliżone. Jak klient potrzebuje DOKŁADNYCH szacunków - to skierujcie się kilka punktów wyżej gdzie napisałem jak je uzyskać. Póżniejsze szacowanie konkretnych zadań w zespole ma tylko pomóc zgrubnie określić które ewentualnie taski sa kluczowe, i które trzeba podzielić. Zbyt duża dokładnośc to STRATA CZASU!

Najbardziej w tym wszystkim zabawni są Scrum Masterzy, którzy potrafią odkryć, że skoro prędkośc zespołu to 52 punkty, a w sprincie jest zadań na 51 - to może warto wyjać jedno dwa zadania po 2 i wstawić jedno za 5 punktów. Normalnie TETRIS!

Jeszcze lepsze jest obserwowanie jak grupa 6 ludzi kłóci się czy zadanie ma 1/2 czy 2 przez 30 minut.... i w tym sumarycznie straconym czasie to zadanie za 2 punkty byłoby już zrobione.

Tak, że ogólnie - wrzućcie na luz z tymi szacunkami, planningami, pokerami itp.

1
Wit Stwosz napisał(a):

Scrum-Kanban etc... to bezsens - jak masz ludzi co nie kumają jak się pisze to Kanan za nich tego nie zrobi. Dlaczego w Linux kernel NIE MA Kanbanu? Dlaczego doktoranci z profesorami nie maja Kanbanu?

Prawie dokładnie to samo chciałem napisać. Dodatkowo - zwróćmy uwagę na to ile osób zajmuje się developmentem kernela - tysiące? I nie trzeba żadnych dziwnych dem ani daily meetingów - a wszystko się kręci. I to jak. Scrum to po prostu strata czasu i nerwów. W niskopoziomowym programowaniu NIE DA się przewidzieć ile czasu zajmie napisanie danego fragmentu kodu. Ten kto pisał sterowniki albo rozszerzał kod kernela wie o czym mowa. A potem są pretensje, że wszyscy inni wyrabiają się w sprincie tylko ekipa niskopoziomowców laguje.

Bo to koporacyjna zabawa dla małolatów, Skaczecie w kółku na spotkaniu też i opowiadacie co was gryzie jak na AA?

Dokładnie - to jest jak przedszkole z zabawą typu "tańczymy labada, małego walczyka". Kółko wzajemnej adoracji.

0

W komentarzach się rozwinęła ciekawa dyskusja o współdzieleniu / posiadaniu kodu.

Wg mnie w posiadaniu kodu nie chodzi o to, aby robić z kodu "twierdzę" albo "wyspę" do której nikt nie ma dostępu.

Chodzi o to, aby do każdego komponentu mieć jedną osobę, która taki komponent ogarnia w całości, łącznie ze stroną architektoniczną (wysokopoziomową), integracyjną (jak się komponent integruje z resztą systemu), implementacyjną i biznesową (jaką rolę dla klienta pełni, jakie są priorytety itp.). Powiedzmy, taki lokalny "tech lead" dla komponentu. Oczywiście inni jak najbardziej mogą w w takim komponencie mieszać, ale robienie znaczących zmian bez uzgodnienia z właścicielem kodu jest bardzo niewskazane. Właściciel kodu może też szybko rozstrzygać spory, tktóre inaczej mogłyby powstać przy wspólnej pracy nad kodem.

Ponieważ jedna osoba ponosi ciężar odpowiedzialności za cały kompoenent i nie ma dużej rotacji, komponenty systemu zachowują dużą wewnętrzną spójość. Nawet jeśli kod komponentu A jest pisany w nieco innym stylu niż kod komponentu B, to dla nowej osoby zaznajomienie się z kodem pisanym przez jednego programistę będzie szybsze niż zapoznanie się ze śmietnikiem pisanym w sposób "demokratyczny".

W drugą stronę bycie właścicielem nie oznacza całkowitej swobody. Nadal właściciel musi dawać swój kod do recenzji, bo inni mogą zauważyć pewne głupoty czy błędy. Jak robię duże zmiany / przeprojektowję coś, to najpierw tworzę odpowiednią dokumentację, w którą każdy ma wgląd i każdy może przedyskutować. Podobnie główny tech lead zespołu też powinien orientować się przynajmniej w wysokopoziomowych aspektach każdego komponentu i jego opinie powinny być brane pod uwagę przez właściciela komponentu. W ten sposób wiedza o komponencie nigdy nie jest ograniczona tylko do właściciela. W razie urlopu / choroby, inni nadal mogą w tym komponencie coś poprawić, choć oczywiście zajmie im to trochę wolniej.

Przy okazji dwa słowa w temacie recenzji:
Dla mnie recenzja jest procesem pomagającym autorowi kodu napisać lepszy kod / uniknąć błędów oraz wspomagająca przepływ wiedzy w zespole. Natomiast recenzowanie kodu nie polega na znęcaniu się recenzenta nad autorem i "nie puszczę tego, bo ja bym to napisał inaczej!" Recenzent ma pomagać, a nie torturować. A jak ktoś pisze tak słaby kod, że ciągle wszyscy chcą go torturować, to może powinien zostać spawaczem?

2

Pomysł o którym mówisz odnośnie tego żeby każdy komponent miał swojego właściciela jest bardzo fajną rzeczą i idealnie by było jakby coś takiego dało się zrobić, ale niestety w większości przypadków nie realną. Głównym problemem jest to że jeżeli jedna osoba jest autorem jednego fragmentu to bardzo szybko dochodzimy do sytuacji że tylko ona się na tym 'zna' i tylko ona powinna robić tam zmiany. A to jest bardzo kiepska sytuacja dla zespołu jako całości. Bo popierwsze powoduje że inne osoby nie patrza w ten kod i nie wiedza dokońca jak on działa, a po drugie i co chyba ważniejsze powoduje że osoby chciałby by pobawić się z innym komponentem ale jest to 'nieopłacalne' (bo ktos inny zrobi tego feature/bug 3x szybciej niż oni etc).

Nie mówiąc już o tym że takie zachowanie promuje brak tworzenia dokumentacji (bo ja przecież wiem co napisałem) i brak przekazywania wiedzy w zespole. Co pokazuje bardzo często przypadłość w świecie IT że dostajemy istniejący kod i okazuje się że taniej wyjdzie napisać go od nowa, czy niż utrzymywać w danej formie.

3

Scrum trzeba traktować jak prawa piratów, jak to powiedział kapitan Barbossa, są to luźne wskazówki, a nie sztywne wytyczne ;)

0

Najbardziej w tym wszystkim zabawni są Scrum Masterzy, którzy potrafią odkryć,
że skoro prędkośc zespołu to 52 punkty, a w sprincie jest zadań na 51 - to może warto
wyjać jedno dwa zadania po 2 i wstawić jedno za 5 punktów. Normalnie TETRIS!

Co do zadań tak ogólnie - to o ile dla mnie sama idea "zadań" ad hoc do zrobienia w danym sprincie jeszcze ma sens (każdy wie, co ma robić w danej chwili), to już tworzenie całego backloga i rozpisanie całego długofalowego projektu np. na 1000 zadań nie ma już wielkiego sensu. Systemy informatyczne nie są "zlepkiem ficzerów" (bo np. strona Google miałaby tylko jeden ficzer: "wyszukiwanie" ;) ) , tylko raczej są pewnymi mechanizmami (czyli np. co się dzieje pod maską Google jak klikniesz Szukaj?).

Więcej miało by sensu projektować aplikacje na zasadzie inżynierii, w podobny sposób w jaki się projektuje urządzenia czy budynki, czyli nie na zasadzie dokładania ficzerów przez osoby nietechniczne (budynek ma mieć 70 sedesów, wszystko jedno gdzie zamontujecie, byle było 70 sedesów albo budynek ma mieć sedes na środku salonu, bo tak klient chce), a raczej na zasadzie myślenia całościowego o całym systemie, tego jak wszystko się wiąże ze sobą (sedesy powinny być w łazienkach i powinny być tam rury z wodą, rury te powinny być podłączone do kanalizacji miejskiej).

Jak dla mnie backlog w projekcie nie powinien być traktowany jako zadania do zrobienia, tylko raczej jak lista życzeń, sugestii, co warto zrobić, a to zespół powinien myśleć długofalowo nad architekturą i nad tym, co robić i w jaki sposób, żeby stworzyć aplikację, która będzie robiła to, co jest w backlogu, żeby góra była zadowolona (tak przecież działa wiele projektów open source, że ludzie nietechniczni mogą podsuwać jakieś ficzer requesty, ale to zespół decyduje czy i jak to wprowadzi*****).

Rozwój produktu to maraton, tymczasem jest tak, że dzieli się rozwój produktu na jakieś "sprinty", które wręcz promują krótkowzroczność. Bo masz się skupić na zrobieniu taska na sprint i nic cię nie interesuje. Tzn. sprinty w teorii to bardzo fajny pomysł, ale w praktyce właśnie nie do końca, takie mam wrażenie.

*i tak wiele issues na Githubie jest zamykanych w trybie ekspresowym przez mantainerów, bo po prostu mają władzę nad projektem i prawo do powiedzenia "nie". Tego mi brakuje w tych wszystkich scrumach.

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