generalnie to pracowal ktos w scrumie ktory jako tako funkcjonowal?
Ogólnie to w tej firmie, o której często piszę udało się w pewnym momencie prowadzić SCRUMa prawie by the book
i nawet dużo patologii, takich jak pisałem udało się wyeliminować. I to był też moment, w którym zaczęliśmy tego SCRUma powoli olewać - najważniejsze to wyeliminowanie całego śmiecia - straty czasu na planowanie, retro (jaki nonsens), i daily stan dupy
.
Zrobiliśmy spotkania opcjonalne w większości (daily też). Z nazwy to tam został SCRUM, żeby nikt się nie czepiał. Rozwalanie dużo czasu zajęło, ale SCRUM ma wbudowane opcje ułatwiające destrukcję (na szczęście).
Np.: na każdym retro powtarzałem, że uważam, że retro jest stratą czasu.... - miałem nadzieję, że w końcu się ten postulat uda przepchnąć (rok ponad zajęło, ale się udało).
Przy okazji wcale nie złośliwie bo, skoro ciągle narzekamy na to samo (!), to znaczy, że nie udaje nam się problemow rozwiązać i możemy z nimi żyć i po prostu oszczędzić sobie narzekania.
(mam wrażenie, że norma w wiekszości zespołów).
Przestaliśmy sie przejmować velocity. Nauczyliśmy się nie czekać na DEMO ... z demonstrowaniem. Lepiej pokzać coś zanim jest gotowe, puty jeszcze ludzie (potencjalnie użytkownicy) mają szanse coś zmienić.
Ogólnie powstał jakis nowy proces, ale nie wiem czy jest sens opisywać, specyfika firmy jest taka, że dużo zespołów równoległych działało w tym samy kodzie, albo blisko niego i było dużo zależności. Zrobiliśmy sobie spotkania sync
z innyi zespołami i tam chodziliśmy (jak ktoś miał potrzebę!).
Np. jedno z takich spotkań/process dokładnie zastąpiło retro - wpisywaliśmy po jednym/dwóch największychy problemach z każdego zespołu (w zespole mieliśmy ścianke bólu gdzie każdy ad hoc mógł wpisać jak go coś wkurzyło) i jak się powtarzały (między zespołami) to szedł task do szefostwa - naprawcie nam firmę. A jak nie to się rozchodziliśmy (5 minut i po spotkaniu).
Planingi się zmieniły tak, że po prostu programista z biznesem siadał (czasem na kilka godzin) przed spotkaniem i szacował z nimi jakies punkty na podstawie swojego doświadczenia. Potem na planowaniu mówił - jest takie zadanie i wg mnie tyle to zajmie bo to i to. Był czas, żeby zgłosić uwagi do tego planowania, czy np, o wszystkich problemach pamiętał, robiło to duża oszczędnośc czasu. No i oczywiście koniec dramy z dyskusjami 3 czy 5. Każda wątpliwość przy niezbyt dużych różnicach to liczba większa i nie tracimy czasu na precyzyjne celowanie z szacunkami ( bo i po co).
Udało mi się nawet ze dwa razy przemycić przy szacowaniu liczbę 4 i 10 jako estymatę (musiałem udawadniać, że takie liczby też istnieją... - ale jest zaskakująco prosty dowód tego).
Wydaje mi się, że jeszcze ważniejsze od wypaczenia SCRUMa było wprowadzenie innych reguł, typu: nikt nie koduje taska sam dłużej niż dwa dni
. Czyli jak ktoś przekisi taska 2 dni to dostaje partnera do kodowania i następuje przekazanie taska, ewentualnie robią go dalej 2 osoby. Taki bieda pair programming
, ale realizował cel - o każdym większym tasku miały dogłębne pojęcie przynajmniej 2 osoby.
Jeszcze było kilka innych myków, ale wszystko to związane ze specyfiką firmy i zadaniami (wiele zespołów, bardzo skomplikowana domena, rozwłóczona przez 120 serwisów, paranoiczne security itd). Dlatego, wcale nie sprzedawałbym i nie polecał tego procesu gdzieś indziej.
Najważniejsze wyszło nieźle - można było kodować. Prawie cały dzień. Jak przyszedłem do firmy to w zespole było 18 godzin spotkań na człowieka na tydzień.... Mieliśmy żarty o tym, że już w następną środę na przerwie pomiędzy 2 zebraniami uda nam się może odpalić Intlellij. Były całe tygodnie gdzie odpalenie IDE się nie udawało - mega frustracja.