Witam,
Kolejny artykulik z cyklu, dlaczego scrum ssa. Napisz mi coś czego nie wiem! :) Ale, imo, warto.
https://rethinkingsoftware.substack.com/p/why-scrum-is-stressing-you-out
Programming today is stressful — way more stressful than I remember it in the 90s and early 2000s when I was just starting out.
https://rethinkingsoftware.substack.com/p/why-scrum-is-stressing-you-outKlasyczny WTF w Scrumie..
Nasza Scrum masterka pochwaliła dzisiaj nasz zespół za to, że mamy ….
…. najlepsze velocity wsród zespołów w firmie. Management podliczył zrobione story pointy i wyróżnił nasz zespoł. Velocity odczuwalne jest jednak zupełnie inne. To ten sam zespół, gdzie jest koleś, któremu „się skasował” projekt.
No i skończyło się uczciwe wycenianie. Przy następnej wycenie, daję minimum 1000 SP na taska.
@Miang: I znowu dyskutujesz z czymś co sobie uroiłaś, a nie z czymś co ja napisałem. Na 15 osób technicznych w projekcie, 1 programista ma 2.5 roku doświadczenia. Większość 5-10 lat doświadczenia kilka osób około ~25 lat doświadczenia. Każdy ma przyzwoite zrozumienie domeny, w której działa projekt i daje z siebie tyle, na ile go stać. Nadal, pytanie czy dostarczenie jakiejś funkcjonalności potrwa rok, czy 2 lata nie ma sensu, bo analiza tego będzie trwała miesiące, a wynik dalej będzie zgadywaniem. Serio, prościej jest podzielić duży kawałek na mniejsze, oszacować je relatywnie (np. S, M, L) zrobić to co jest niepewne/trudne najpierw i przeliczyć szacowaną datę końca. Nie będę pytał o rzeczy typu "ile zajmie ci integracja z systemem X", bo jaka odpowiedź nie padnie, odpowiadające będzie się czuł zobowiązany dostarczyć tę pracę w terminie, który podał, a mi zależy na nie zafałszowanym pomiarze ile takie moje przykładowe "M" wymaga pracy.
nie moze sie skasowac projekt bo na git trzeba wpisac nazwe projektu zeby go skasowac.
Straszny bullshit wg mnie. Współpraca z klientem dzień w dzień? Ciekawe gdzie to tak wygląda. PO to ktoś od marketingu? What? Budżety ustalane przez teamy? Hmmm. I w sumie dalej nie wiem na czym ten Agile polega, robimy wszystko na gut feeling i jakoś to będzie? To może przez chwilę zadziałać w małym teamie z ogarniętymi seniorami (nie tylko technicznie ale też organizacyjnie), gdzie biznes wie czego chce i nie ma większych komplikacji.
Budżety teamu to chyba bardziej w stylu miesięcznej puli na dowolne wydatki - konferencje/podróże służbowe itp.
Ale może faktycznie się za bardzo podjarałem, jak na zakup odkurzacza za 8000PLN od domokrążnego sprzedawcy.
Jak już narzekamy na scruma Stało się. Trafiłem do tego... to też taka moja anegdotka :)
W jednym z zespołów Scrum Master był odpowiedzialny za... drukowanie karteczek na tablicę :) Tak więc, zdarzały się takie oto historie: "ja robię takiego taska, ale SM nie zdążył wydrukować i dlatego nie ma go na tablicy". Piękna wymówka zwalająca na kogoś innego, że samemu się czegoś nie ogarnęło :D
Ja do samego Scruma nie mam nic, nawet dobrze się w tym pracuje, ale musi być to dobrze zrobione, bo w przeciwnym wypadku ludzie zaczynają mówić, że Scrum jest do bani. I w tych przypadkach będą mięli rację!
Stało się. Trafiłem do tego słynnego patoscruma. Scrum Master z rocznym doświadczeni...
https://4programmers.net/Mikroblogi/View/120384Stało się. Trafiłem do tego słynnego patoscruma. Scrum Master z rocznym doświadczeniem w scrumie jest moim szefem do którego raportuję. Na swoich daily wywołuje po kolei wszystkie osoby z osobna do podawania swoich statusów. Retrospektywy wyglądają tak, że SM pyta się tłumu ludzi czy mają coś do dodania i oczywiście wszyscy milczą. Product Ownerzy są wiecznie zapracowani i nie można doprosić się z nimi calla, żeby dowiedzieć się co jest dokładnie do zrobienia i jak użytkownicy zamierzają tego używać. W zamian, Product Ownerzy wiedzą dokładnie jak coś zaimplementować. Na 30 osób wszyscy robią wszystko i jest jakiś spaghetti code gdzie deployment robi się przez kopiowanie kodu do innego repozytorium.
Na moje pytania o gitops, kubernetes, bdd, budowanie artefaktów, słowniczki pojęć oraz dokumentację słyszę od wszystkich, łącznie z headem, że mam porozmawiać z X, on wie jak to jest zrobione. Ja wiem jak oni to robią bo przeczytałem już ich kod, nie rozumiem tylko jakie powody ich blokują przed migracją do czegoś nowego?
Na rozmowie rekrutacyjnej? Mamy scruma, przestrzegamy ceremonii, mamy product ownerów i chcemy wdrażać nowe technologie.
Następne miesiące będę znowu spędzał na powolnej ewangelizacji, o ile nie nadepnę komuś na odcisk i mnie nie zwolnią lub sam się nie zwolnię.
@twoj_stary_pijany: ja bym tak ostrożnie z tym feedbackiem jak jesteś nowy w zespole. Zawsze jest pokusa, żeby komuś powiedzieć, że można robić coś lepiej. Z doświadczenia wiem, że dobrze jest ten miesiąc zagryźć zęby i dopiero się otworzyć jak już zobaczysz jak firma/ludzie działają. Feedback od pierwszego dnia tylko spowoduje, że ludzie zamkną się na twoją konstruktywną krytykę, niestety mamy wbudowany z defaultu soft, który każe nam się prężyć i bronić jak ktoś nowy mówi nam jak mamy żyć.
@daniel1302: to ja jestem TL :) I też mnie to zdziwiło, że gość pełniący funkcję SM jest moim przełożonym :) A migrować się powinni bo mi tak powiedzieli na rozmowie. Nie interesuje mnie czy się migrują tylko czy kod zarabia już jakieś pieniądze, jaki jest plan i wymagania, żebym odpowiednio dostosował plan.
Zasłyszane w biurze ;)
@devRandom: u mnie ostatnio ktoś zrobił spotkanie o 8:00. Architekt odpowiedział że o 8 to on córkę do przedszkola zawozi i może być na 9:00 :D
Scrum masterzy, product ownerzy, managerowie, architekci - oni mogą mieć wiele daily dziennie. Tylko czemu ktoś chciałby z takimi rozmawiać w kuchni?
Nie ma takiego słowa jak
ssa
— scrum to trzecia osoba w liczbie pojedynczej (to), więc poprawna odmiana słowassać
w tym przypadku tossie
, czyli powinieneś napisaćdlaczego scrum ssie
. ;)