Codzienny Refinement zajmujący godzinę czasu oraz Daily 30 minutowe i wiele innych spotkań

0

Cześć,

Niedawno dołączyłem do projektu jako Java Developer i mamy w zespole codziennie Refinement zajmujący godzinę czasu o godzienie 14.00 do godziny 15:00. Oraz codziennie Daily od godziny 10:00 często to 10:30. W sumie w ciągu dnia wychodzi 1.5h spotkań.

Pomnożone to razy 10x1.5h=15h spotkań na Sprint. Do tego dochodzi jeszcze jeden cały dzień na Planning + Spring Review 8h.

Zaokrąglając można powiedzieć że 24h spędzamy na samych spotkaniach czyli 3 dni w Sprincie.

Dzień zaczynam około 8 rano, pracuję zazwyczaj do Daily czyli do 10 rano. Tutaj mam dwie godziny pracy (2h).
Potem zazwyczaj po Daily następuje jakaś rozmowa pomiędzy pracownikami zdalnie, co jak trzeba zrobić, albo komunikuję się z kimś z biznesu, mamy tylko jednego Product Ownera.

Od 10:30 Dość szybko mija mi czas do 12:00 gdzie zazwyczaj wchodzę w porę obiadową którą trzymam równo do 12:30. Potem mam znów takie półtorej godzinki na pracę i nagle cyk o 14:00 refinement do 15:00.
Po refinemencie jestem już wypruty umysłowo że ciężko cokolwiek mi coś zrobić do 16, w ciągu ostatniej godziny.

No i dochodzi, że wymagania stawiane mi pod względem pisania kodu są bardzo duże, z kolei ja przez takie coś mega tracę na produktywności. Pragnę zaznaczyć, że w zespole nie mamy biznes analityków, testerów (tę odpowiedzialność przejmują programiści).

Piszę to ponieważ, tak jak powiedziałem jest to dla mnie dość duże zaskoczenie, wcześniej miałem jeden refinement na tydzień, a spotkania z innymi ludźmi organizowałem sobie sam 1-1 gdy omawiałem jakieś taski. Np. zdzwaniałem się do biznes analityka i mówił mi co mam robić i robiłem, czy z testerem, czy też... devopsem... architektem itd. Tutaj zgoła jest inaczej.

Co myślicie w ogóle o czymś takim? Szczerze to trochę ciężko mi się przez to wyrobić z normalną pracą. Jak to u Was wygląda w firmach?

6

Ja myślę, że masz ochotę się stamtąd urwać. Widocznie masz powód.

4

Podałeś dość szczegółowo tryb pracy, ktoś może Cię rozpoznać w firmie.

Moim zdaniem wygląda jak januszostwo. W normalnych czasach bym polecił uciekać.

3

Zglos na retro ze nie pasuje Ci ilosc spotkan, ew. dostosuj do tego estymaty. Albo zmien prace.

1

u mnie daily przedłużało się czasami do 45kij i zgosiłem to na retro i wypracowaliśmy model żeby znowu trwało 15 min a duże tematy są parkowane po daily dla zainteresowanych.
Biorąc cały Twój opis nie chciałbym pracować w takim systemie pracy jaki masz.

5

Na c**** robić codziennie refinement? Refinement zeszłego dnia nie przyniósł efektów, że trzeba go powtarzać kolejnego dnia? Czy też macie milion zadań do przegadania na 10 lat do przodu, których wymagania się pewnie i tak zmienią, nie zostaną zrobione nigdy, bo okażą się zbędne albo zrobi je osoba, która tam jeszcze nie pracuje i trzeba będzie w tym celu znowu zrobić refinement? xD

Sposób funkcjonowania firmy, w której pracujesz jest nieefektywny. Refinement powinien być raz na 2 tygodnie - godzina max, standup może być codziennie i trwać 15 minut - max. Przy dobrej organizacji pracy i przepływie informacji, standup można wg mnie nawet pominąć. Opcjonalnie można zrobić retrospektywę raz na 2 tygodnie - godzina max. Reszta spotkań ad-hoc - godzina max. Pamiętam, że kiedyś w niektórych projektach miałem czasami spotkania, które trwały np. 2h albo i więcej, była to męczarnia i nie pamiętałem po nich jak się nazywam xD.

4

Jezu, jak to czytam to mam wrażenie, że nigdy nie odejdę z obecnej roboty. Jedno spotkanie w tygodniu, godzinne. I tyle ze scrumowych zbiorowych rytuałów. I jakoś wszystko da się dogadać na ad-hoc organizowanych spotkaniach, albo asynchronicznie na czacie. Ja to gdy mam jakieś spotkanie umówione na godzinę, to co najmniej kwadrans wcześniej już nic nie robię, bo mam wrażenie że nie warto łapać flow, bo zaraz mnie z tego wyrwą. No chyba, że akurat dokończę coś co robiłem. A ile to ma zalet dla elastycznego czasu pracy...

2

Nie zmienisz tamtego świata w firmie, najlepiej zacznij wysyłać CV (chyba że lubisz te spotkania).

1

@hermans32
Ja tu widzę opis jednej z moich poprzednich firm. Zaimplementowali Scruma w ten sposób, że taski na początku sprintu składały się z jednego zdania a resztę miał uzupełnić developer. Nie było analityków ani testerów. Estymaty punktowe były zaniżone ze względu na znikomą znajomość tego całego legacy w zespole. Zakres sprintu się zmieniał w trakcie sprintu. Mieliśmy na początku sprintu też taski, do których nie było gotowych zależności dostarczanych przez inne zespoły. Na końcu sprintu oczywiście było ględzenie, że nie dowieźliśmy a team przecież zrobił commitment na początku sprintu. No i oczywiście potem retro, które polegało na spuszczaniu ciśnienia z członków zespołu a nie na konstruktywnych zmianach. Aha, do tego mieliśmy takiego kolegę w zespole, co naparzał darmowe nadgodziny po czasie pracy (w czasie pracy był gorącym orędownikiem Scruma i wszystkich ceremonii jego, nawet cisnął, żebyśmy robili extreme programming). Bardziej tam byłem wymęczony i zestresowany niż jak po odejściu robiłem OE na dwie firmy.

Napisz co właściwie robicie na tych spotkaniach. I czy jest podobnie do mojej byłej firmy. I czy to firma z USA. Moim zdaniem nie dasz rady tego naprawić, ale możesz spróbować tych rzeczy:

  1. Zaproponuj, żeby daily było na Slacku. A wszelkie rozmowy nt tasków odbywały się w ramach zainteresowanych osób
  2. Za każdym razem jak góra się czepia, że nie dowozisz to wytykaj, że nie trzymają się prawdziwego Scruma i punktuj ich na spotkaniach 1:1 i na ogólnych (np retro)
  3. Wykorzystaj, że scrum jest z definicji "prodemokratyczny". To zespół ma decydować, w jaki sposób działa Scrum. Czyli ile jest spotkań, jakich i co się na nich robi
  4. Zgłoś, że ktoś powinniście odrzucać niegotowe taski z powrotem do backlogu

Ale ogólnie to zgadzam się z przedmówcami i moim zdaniem nie dasz rady nic zmienić

0

Za dużo tych spotkań, na pewno temat do podniesienia na retro. Tylko pytanie brzmi jaki problem usiłujecie rozwiązać, trzeba ustalić przyczynę. Musicie to zdebugować, jak w programowanku. Podstawa Scruma - inspekcja i adaptacja.

A powodów może być wiele - za duży zespół, za dużo niezależnych ficzerów naraz, nieefektywny research, brak struktury historyjki (dor/dod), niedostępne osoby decyzyjne (np. product owner), itd.

3
  1. To nie jest normalne - to jest totalnie głupie - ale częste.
  2. 1.5 godziny na spotkania oznacza, że tracisz na spotkania 60-85% energii (mimo, że to niby tylko 20% dnia) (choć tu mocno zależy od spotkań - ale im bardziej rutynowe i nudne tym gorzej).
  3. Podstawa scruma to go wywalić/albo przynajmniej wykoleić - trochę się da dzięki retro, ale trzeba mieć szczęście do firmy i ludzi. Jak masz dużo wyznawców, albo jesteś w korpo z własną policją scrumową to niewiele zrobisz.
3

Zanim dołącze do projektu to mam w zwyczaju pytać m. in. o wielkość ekipy, kto tam jest, kogo nie ma i czym jest to podyktowane, jakie mają ceremonie oraz ile mnie więcej ile na to poświęcają oraz czego oczekują od gościa który ma zasilić swoim talentem ich szeregi.

Jak ktoś oczekuje, że będziesz i artystą i programistą i testerem i analitykiem i devopsem i nie wiadomo jeszcze kim to uciekaj z takiego projektu. Takie przedsięwzięcie zakończy się wielkim cyrkiem, a jest niezerowa szansa, że oberwiesz rykoszetem.

4

ja np po 2 godzinach spotkan jestem wypruty z przynajmniej 80% energii do pracy

2

U mnie daily przedluzalo sie o 5 min z planowanych 30 na 35 notorycznie. Jeden typ ktory wlasciwie nic nie robi zawsze opowiadal o swoich taskach przez 15 minut podczas gdy inni uwijali sie w 1-3 minuty max. Scrum majster przechodzil przez taski "todo", "done" i "in review" i za kazdym razem glupio sie o nie dopytywal.
Gdy miesiac temu mialem jednego taska na "todo" przez 7 dni roboczych sprintu bo zostawilem go sobie na sam koniec i szóstego dnia spytal o tego taska zapytalem sie go ile razy jeszcze bedzie sie o to samo pytal i tracil czas, skoro mowilem ze zrobie go pod koniec sprintu i jeszcze nie zdarzylo mi sie w mojej karierze zebym z mojej winy nie majac blokera czegokolwiek kiedykolwiek nie dowiózł na czas. Wytknalem obu typom delikatnie na retro ze tak nie moze byc ze w 6 osobowym teamie daily trwa wiecej niz w 20 osobowym teamie w korpo i wlasciwie zarowno te dluzsze wywody jednego typa jak i dopytywanie sie glupie scrum majstra nic nie wnoszą i nagle daily uwija sie teraz w 15 minut. Wytknalem im rowniez to ze pierwsze 5 minut spotkania praktycznie zawsze było spędzane na glupich pogawedkach nie na temat projektu.

0

W takim projekcie to bym od razu przestał dowozić i czekał aż wielmożny Scam Master ogarnie gdzie leży źródło problemu. Dwa przykłady z mojego życia, gdzie musiałem zmienić miejsce:

  • 5 osób w zespole i codzienne daily na 1h. W tym czasie CTO zarzucał pytaniami każdego z osobna. Plus taki, że po 15 minutach można było się właściwie skupić na czymś innym
  • codzienne spotkania (1-3h) w amerykańskim korpo, gdzie głównie produkowały się różnorakie mniejszości. Na plus krótkie standupy bo każdemu było szkoda na to już czasu.
0

Oj tam ja mam spotkan czasami tyle ze na development zostaje 20% dnia. 1.5h spotkan to malutko

2

tak sie zyje

screenshot-20230414112721.png

0
hermans32 napisał(a):

Co myślicie w ogóle o czymś takim? Szczerze to trochę ciężko mi się przez to wyrobić z normalną pracą. Jak to u Was wygląda w firmach?

Ja tu widzę możliwości - albo przynajmniej szansę. Pomyśl np. o sprzęgnięciu DeepFake z video jakichś vlogerów grających w gierki. Tworzysz sobie wirtualną kamerę, przepuszczasz takie coś przez DeepFake i już zyskujesz efektywnie kilka godzin które możesz przeznaczyć na coś produktywnego.

Np. na opakowanie powyższego w jakąś aplikację, założenie projektu, rozpropagowanie go wśród naszej braci, monetyzację i spędzenie reszty życia w błogim spokoju wiedząc że zmieniło się świat na lepsze.

4

Powiedz im prawdę - przez cały dzień masz w głowie tylko te durne spotkania, zamiast pracę. Niby siedzisz przed komputerem z otwartym edytorem kodu i dla nich wyglądasz jak byś pracował. Oni nie rozumieją, że to tak nie działa i że w ciągu dnia każdy ma 2-3 godzinny programistyczny flow, podczas którego robi się 4x więcej niż w ciągu pozostałych 5 godzin, i że jak ten flow się przerwie, to 3/4 dnia idzie w tyłek i firma traci w ten sposób bardzo dużo pieniążków. Managerowie pracują w całkowicie przeciwny sposób - tu coś kliknie, tam coś powie, tam coś napisze, tam zaplanuje spotkanko i jak se trochę pogada, popije kawek i wejdzie na youtube zobaczyć skrót meczu to wcale efektywność mu nie spada, a programistom spada drastycznie jak się ich zagaduje.

2

Swego czasu pracowałem w firmie gdzie była podobna ilość spotkań itp. Na development zostawały max 3-4h dziennie. Żeby było ciekawiej treści omawiane na jednym spotkaniu często dublowały się z treściami na innym spotkaniu. Kilka razy zwracałem uwagę, żeby ograniczyć ilość tych spotkań- bez rezultatu. Oczywiście finalnie zwolniłem się z tej firmy i wyszło mi to na zdrowie, Zgadzam się z przedmówcami, że takie spotkania (czy realne czy calle) strasznie męczą, ja po nich często nie miałem ochoty już nic robić. Jak firma jest niereformowalna, to najlepiej stamtąd uciekać, szkoda zdrowia i nerwów.

1

Uważam, że spotkania popołudniowe powinny być zakazane w kodeksie pracy.

0
Drzewiec napisał(a):

Powiedz im prawdę - przez cały dzień masz w głowie tylko te durne spotkania, zamiast pracę. Niby siedzisz przed komputerem z otwartym edytorem kodu i dla nich wyglądasz jak byś pracował. Oni nie rozumieją, że to tak nie działa i że w ciągu dnia każdy ma 2-3 godzinny programistyczny flow, podczas którego robi się 4x więcej niż w ciągu pozostałych 5 godzin, i że jak ten flow się przerwie, to 3/4 dnia idzie w tyłek i firma traci w ten sposób bardzo dużo pieniążków. Managerowie pracują w całkowicie przeciwny sposób - tu coś kliknie, tam coś powie, tam coś napisze, tam zaplanuje spotkanko i jak se trochę pogada, popije kawek i wejdzie na youtube zobaczyć skrót meczu to wcale efektywność mu nie spada, a programistom spada drastycznie jak się ich zagaduje.

pół żartem, pół serio, ale jakbym tak powiedział w pewnej firmie z początków mojej kariery to by mi Janusz pensję obciął do tych 3 godzin pracy

0
hermans32 napisał(a):

Cześć,

Niedawno dołączyłem do projektu jako Java Developer i mamy w zespole codziennie Refinement zajmujący godzinę czasu o godzienie 14.00 do godziny 15:00. Oraz codziennie Daily od godziny 10:00 często to 10:30. W sumie w ciągu dnia wychodzi 1.5h spotkań.

daily 15-30 minut
refinement gdzieś w połowie sprintu, 1-2h
jak retro i planning to wiadomo że dzień zwalony.
do tego średnio raz dziennie jakiś ad-hoc, jakieś weekly czy monthly czy korpo all-handsy i średnio wychodzi 1.5h dziennie meetów.

Ale codziennie robić refinement to bez sensu, po co?

0
KolkaIKwadraty napisał(a):
Drzewiec napisał(a):

Powiedz im prawdę - przez cały dzień masz w głowie tylko te durne spotkania, zamiast pracę. Niby siedzisz przed komputerem z otwartym edytorem kodu i dla nich wyglądasz jak byś pracował. Oni nie rozumieją, że to tak nie działa i że w ciągu dnia każdy ma 2-3 godzinny programistyczny flow, podczas którego robi się 4x więcej niż w ciągu pozostałych 5 godzin, i że jak ten flow się przerwie, to 3/4 dnia idzie w tyłek i firma traci w ten sposób bardzo dużo pieniążków. Managerowie pracują w całkowicie przeciwny sposób - tu coś kliknie, tam coś powie, tam coś napisze, tam zaplanuje spotkanko i jak se trochę pogada, popije kawek i wejdzie na youtube zobaczyć skrót meczu to wcale efektywność mu nie spada, a programistom spada drastycznie jak się ich zagaduje.

pół żartem, pół serio, ale jakbym tak powiedział w pewnej firmie z początków mojej kariery to by mi Janusz pensję obciął do tych 3 godzin pracy

No bo nie masz tego powiedzieć normalnie, jak do normalnego człowieka, tak jak ja napisałem.

Masz powiedzieć, że rozkład i natężenie spotkań nie jest dostosowane do mojego zegara biologicznego. W trosce o wydajność zespołu proponuję przetestowanie ograniczenia ilości spotkań o połowę i przełożenie ich na godziny poranne, tak aby każdy mógł możliwie najefektywniej zorganizować swój czas pracy.

I potem się dogadujesz z jakimiś normalnymi chłopakami, że po takiej akcji mówicie na zebraniu, że teraz to HOHOHO, od razu wydajniej się pracuje. Do tego szukasz na necie jakiegoś artykułu o jakimś flow state czy coś, żeby każdy programista w zespole miał 3 godziny dla siebie i nie wolno wtedy ich zaczepiać. Jak dobrze to uargumentujesz (pieniędzmi w portfelu prezesa), to wszystko idzie przepchnąć.

2

Pracowałem kiedyś w firmie, gdzie daily było 2 razy w tygodniu, refinement połączony z planingiem (1 na tydzień 1h), retro nie było, ale było coś lepszego - devcon, o technicznych problemach w projekcie i najlepszych rozwiązaniach (researche, dyskusje - 1h na tydzień). W tym modelu mi się dobrze pracowało i naprawdę dużo dowoziłem, ale tam z kolei inne rzeczy nie działały..

2

Ja aktualnie mam w tygodniu dwa daily po 30 minut, jedno 1:1 z managerem (ile potrzeba, przewaznie ok 15 minut), raz na miesiac godzinny status check, cala restza komunikacja async + ew. spotkania wg potrzeb jak trzeba grubszy temat omowic/zaplanowac.I tak szczerze taka ilosc spotkan w zupelnosci wystarczy.
Warto tez pamietac, ze gdy dostajemy zaproszenie na spotkanie mamy opcje: reject.

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