Dla mnie Scrum to super zjawisko. Zawsze mocno cisnąłem - ten legendarny Crunch - i nigdy nie wiedziałem czy to co dostarczam jest wystarczające. Jak gdzieś utknąłem na kilka godzin, nie daj boże kilka dni, to potem miałem uczucie, że nie dowożę i jeszcze bardziej muszę się spiąć. Mimo że byłem jedną z osób, które najszybciej dowoziły i kod, które dowoziłem zazwyczaj nie miały bugów i był bardzo dobrej jakości, za co byłem chwalony.
Poszedłem do firmy, gdzie mieli Scruma, oprócz tego, że miałem poczucie bezsensu spalanego czasu to nagle okazało się, że muszę zawsze dobierać taski, bo wszystko robiłem szybciej. Po 3-4 miesiącach okazało się, że nie ma tasków. Management nie miał nawet czasu na stworzenie nowych i wycenę w Story Pointach, bo mieli na innej platformie bardziej palące tematy. Sam sobie tworzyłem taski techniczne, ale musiałem czekać na wycenę, bo mieliśmy zasadę, że nie możemy zacząć robić coś bez wyceny.
W następnej firmie, w poprzedniej za bardzo się nudziłem i dostałem ofertę o 65% lepszą, więc nawet za dużo się nie zastanawiałem, mieliśmy również Scruma. Zawsze było pracy okej, żeby porobić swoje, ale żeby się nie zajechać - tam były też inne problemy o których tutaj nie warto pisać, nic znaczącego, więc można było na spokojnie, uczciwie te 6-8 godzin przepracować. Po około pół roku jak tam byłem, zespół był stworzony 2 miesiące wcześniej, więc wszyscy byli dosyć nowi, jednemu z developerów nie udało się dowieźć - faktycznie to był jedyny sprint, w którym ja musiałem mocno się spiąć, żeby dowieźć na swojej platformie. Wtedy zaczęła się pogadanka o tym, że trzeba informować jak nie damy rady (tutaj się zgadzam) oraz o tym, że robimy Sprint Commitment (nawet nie wiedziałem wcześniej), więc trzeba dowieźć, bo są potem terminy, kampanie marketingowe z ustalonym już terminem wejścia i inne biznesowe rzeczy. Wtedy bez żadnej komunikacji w zespole zaczęliśmy wyceniać zadania na trochę więcej, albo je bardziej rozbijać. Jedno zadanie wycenisz na 8 Story Pointów, a rozbite na 3, 3, 5 albo 3, 5, 5. Nasza efektywność na papierze była taka sama, a realnie robiliśmy mniej i wszyscy byli zadowoleni.
Ogólnie nie rozumiem jak można w Scrumie mieć za dużo roboty. Trzeba umieć powiedzieć - "chyba nie dam rady dowieźć tego, wyrzućmy to ze Sprintu i najwyżej dobiorę jak będę miał czas" (oczywiście nigdy nie dobierasz), albo przy Refinmencie dać wyższą estymatę i jak zapytają się czemu taka wysoka to wyjaśnić, jak zespół ją zbije, dostaniesz tego taska do zrobienia i nie dowieziesz to potem na Retro powiesz, że przecież mówiłeś, że dla Ciebie to więcej pracy i wyszły takie i takie problemy jak zresztą przewidywałeś albo przeczuwałeś i jeszcze potrzebujesz 1-2 dni, żeby dokończyć. I tak się można bawić w nieskończoność. Dobry Scrum to taki gdzie realnej pracy jest na 2-4 dni w dwutygodniowym sprincie. Jak musisz pracować ponad 6 dni (mówię o realnej pracy), gdzie realnie masz 8-9 dni sprintu jak odejmiesz spotkania, to znaczy, że już za dużo bierzesz, albo jesteś po prostu słaby i za wolno robisz.
Może ja też jestem trochę inny, bo jak chcę to potrafię cały dzień z przerwami na siku i jedzenie cisnąć kod - mój rekord to z płatnymi nadgodzinami przez miesiąc pracowałem średnio po 11-12 godzin dziennie (od poniedziałku do piątku) napieprzając kod jak małpa - a w międzyczasie robiłem 3 godzinne treningi w tygodniu. Choć tutaj muszę przyznać, że tempo mnie trochę spaliło. I zbudowałem apkę, którą teraz dla porównania w Scrumowym zespole w trzy osoby, a były przez chwilę cztery, budujemy już od pół roku i jest i tak mniejsza niż to co ja sam zrobiłem w miesiąc.