Jak wygląda u was scrum ?

Riddle napisał(a):

Miang napisał(a):

ale przecież wyżej piszesz że to zespół decyduje a nie senior

Nie. Doczytaj uważnie moje posty. Ja napisałem że "zespół decyduje, a nie manager/szef/klient" - zespół.

jeżeli tenże junior wchodzi w skład zespołu to łatwo menago mu może wcisnąć swoje wizje, i piszę tu z przykrego doświadczenia. Potem młody rzuca buzzwordami że wie jak zrobić ale jak przycisknąc do ściany to widać że ich nie rozumie

Czyli klient/szef/manager przychodzi z requirementem "chcemy żeby userzy mogli share'ować swoje ustawienia" a cały zespół decyduje jak to najlepiej wykonać. Wtedy seniorzy i juniorzy razem pracują nad tym jak dowieźć taki feature, przy czym juniorzy biorą udział w całym procesie dostarczania feature'a i się uczą - piszą testy, rozmawiają z klientem, robią mvc, dodają implementację, wrzucają na środowisko testowe, a potem uczestniczą w release'ie. To jest zdrowe podejście.

obiecują klientowi złote góry.....

Jak szef przychodzi i mówi do juniora: "na tym ekranie dodaj taki przycisk, tutaj wyślij taki request, a tutaj dodaj taki obrazek"; to tym samym wyłącza go z procesu developowania, a to znaczy że taki junior nigdy się nic nie nauczy, i na zawsze pozostanie niekompetentny. Jeśli sprowadza się juniora do "klepacza kodu", i nie pozwala mu się testować i wdrażać rozwiązań ani doprecyzować wymagań z klientem/użytkownikiem, to na zawsze pozostanie bez potrzebnych umiejętności. Na zawsze nie będzie miał skillsów, więc nie będzie można mu ufać, więc nie będzie można mu powierzyć odpowiedzialności, więc nie zespół nigdy nie wytworzy sobie zdrowego procesu, więc taki zespół będzie ciągle niewydajny. To jest patola.

PS: @Miang Popracuj nad umiejętnością czytania ze zrozumieniem, bo mam wrażenie że umyka Ci połowa rzeczy które piszę i potem wkładasz mi słowa w usta których nie napisałem.

ja po prostu patrzę z punktu widzenia jak wygląda rzeczywisty zespół a nie z wieży z kości słoniowej gdzie masz ten zespół idealny ;)

Miang napisał(a):

jeżeli tenże junior wchodzi w skład zespołu to łatwo menago mu może wcisnąć swoje wizje, i piszę tu z przykrego doświadczenia. Potem młody rzuca buzzwordami że wie jak zrobić ale jak przycisknąc do ściany to widać że ich nie rozumie

No to jest przykład dysfunkcyjnej pracy.

Dlatego nie zostawia się juniora samego, tylko on ma pracować z resztą zespołu.

Miang napisał(a):

ja po prostu patrzę z punktu widzenia jak wygląda rzeczywisty zespół a nie z wieży z kości słoniowej gdzie masz ten zespół idealny ;)

Jestem tak zmęczony tym argumentem, że aż mi szkoda transferu.

Rozumiem że miałaś niefarta pracować w 5-10 firmach które nie umieją dobrze wytwarzać oprogramowania, dlatego masz przekonanie teraz że nigdzie tak nie ma. A jak ktoś (jakiś @Riddle ) mówi że się da, to znaczy że to musi być przeidealizowany jednorożec którego się nie da mieć.

Tymczasem wiele firm działa w normalny sposób, czyli pozwalają juniorom się uczyć w pracy.

Daily we wtorki i czwartki po 5 minut. Raz na 2 tygodnie może 30 minut przekładnia tasków z backlogu.

Zasada jest taka, że taski w backlogu są posortowane od najważniejszych do najmniej ważnych. Zrobisz taska albo jesteś zblokowany to bierzesz kolejnego taska z backlogu i elo. Na daily mówimy jakie problemy są albo co nowego wyszło.

duck napisał(a):

Zasada jest taka, że taski w backlogu są posortowane od najważniejszych do najmniej ważnych. Zrobisz taska albo jesteś zblokowany to bierzesz kolejnego taska z backlogu i elo. Na daily mówimy jakie problemy są albo co nowego wyszło.

To znaczy, że musicie mieć bardzo dobrze opisane taski. Kto się tym zajmuje i kiedy to robi?

somekind napisał(a):

duck napisał(a):

Zasada jest taka, że taski w backlogu są posortowane od najważniejszych do najmniej ważnych. Zrobisz taska albo jesteś zblokowany to bierzesz kolejnego taska z backlogu i elo. Na daily mówimy jakie problemy są albo co nowego wyszło.

To znaczy, że musicie mieć bardzo dobrze opisane taski. Kto się tym zajmuje i kiedy to robi?

A jeśli w issue jest opisany target/cel, np "aktualnie użytkownicy mogą uploadować tylko jpg i png, a powinno się dać móc też uploadować webp (żyg)", to taki task chyba może wziąć każdy i po prostu "make it happen". Po co to dokładniej opisywać?

ArchitektSpaghetti napisał(a):

każdy ma dyżur na sprint

To akurat bardzo dobra praktyka. Jeżeli programiście nie zakomunikujesz że praca zespołowa to także jest jego praca, to on zamknie się w swoim klepaniu kodu.

Nie ma nic gorszego niż programista skupiający się na pisaniu kodu.

Teraz (na szczęście) mam jakiś pseudoscrum gdzie sprinty są tylko w jirze - mam tylko status meeting i jakieś spotkania w miarę potrzeby tylko z osobami które są zainteresowane (szalone, prawda?), w sumie jakieś 3h spotkań w tygodniu.
W poprzednim projekcie miałem średnio 1h spotkań dziennie, jakieś 10h na sprint. Scrum masterem była na stałe jedna osoba z teamu.

Daily praktycznie nigdzie gdzie pracowałem to nie było daily standup choć tak się nazywało w kalendarzu, zawsze trafiła się osoba która przez 10 minut gadała o swoim tasku i w sumie z pogaduszkami trwało co najmniej pół godziny, plus w połowie firm w spotkaniu uczestniczył manager / team lead który sam nie podawał statusu i któremu się spowiadało i bez którego spotkanie się w ogóle nie odbywało.

Riddle napisał(a):

somekind napisał(a):

To znaczy, że musicie mieć bardzo dobrze opisane taski. Kto się tym zajmuje i kiedy to robi?

A jeśli w issue jest opisany target/cel, np "aktualnie użytkownicy mogą uploadować tylko jpg i png, a powinno się dać móc też uploadować webp (żyg)", to taki task chyba może wziąć każdy i po prostu "make it happen". Po co to dokładniej opisywać?

No to akurat jest dobrze opisany task, tylko że w bardzo prostym projekcie. Zazwyczaj wymagania biznesowe są dużo bardziej skomplikowane

obscurity napisał(a):

No to akurat jest dobrze opisany task, tylko że w bardzo prostym projekcie. Zazwyczaj wymagania biznesowe są dużo bardziej skomplikowane

No właśnie z mojego doświadczenia wynika że zazwyczaj są bardzo proste.

Jednak zazwyczaj osoba która je zgłasza nie mówi wprost co chce (np. "chcę zgłosić wulgarny post"), tylko tłumaczy to niepotrzebnie na techniczny język, np. "dodaj przycisk, który wyśle powiadomienie z frontu do serwera, i to ma się potem zapisać, bla, bla".

Potem ktoś kto czyta taki techtask nie ma szansy na kreatywne rozwiązanie tego problemu tylko followuje ślepo intrukcje.

Riddle napisał(a):

A jeśli w issue jest opisany target/cel, np "aktualnie użytkownicy mogą uploadować tylko jpg i png, a powinno się dać móc też uploadować webp (żyg)", to taki task chyba może wziąć każdy i po prostu "make it happen". Po co to dokładniej opisywać?

Jak sobie radzisz z nieuchronnym narzekaniem, że taski są zbyt ogólnikowe? Ile tu już było narzekania, że w JIRA taski to jedno zdanie…

BTW, jestem po twojej stronie.

ArchitektSpaghetti napisał(a):

Riddle napisał(a):

A jeśli w issue jest opisany target/cel, np "aktualnie użytkownicy mogą uploadować tylko jpg i png, a powinno się dać móc też uploadować webp (żyg)", to taki task chyba może wziąć każdy i po prostu "make it happen". Po co to dokładniej opisywać?

Jak sobie radzisz z nieuchronnym narzekaniem, że taski są zbyt ogólnikowe? Ile tu już było narzekania, że w JIRA taski to jedno zdanie…

Nie spotkałem się z czymś, takim, ale myślę że powiedziałbym, coś w tym stylu:

• to nie jest task - to jest spodziewany target
• to Twoja odpowiedzialność żeby znaleźć najlepsze (albo good-enough) osiągnięcie tego celu, po to są programiści w zespołach
• Ty jesteś bliżej pracy, więc Ty znajdziesz lepsze rozwiązanie tego problemu, niż ktoś kto akurat siedzi w jirze
• Chcę żebyś znał big-picture oraz kontekst, bo tego wymaga dobre developowanie software'u - jeśli dałbym Ci wszystkie szczegóły, to uniemożliwiłbym Ci zrozumienie całości i utrudniłbym Ci dostarczenie mi lepszego softu
• w tasku nie może być więcej szczegółów, bo takie szczegóły się odkrywa podczas developmentu taska
• gdyby zawrzeć wszystkie szczegóły w tasku, to równie dobrze mógłbym sam napisać kod

Przez ponad 8 lat pracy zaobserwowałem trzy aspekty które mógłbym w dużym uogólnieniu opisać.

1. Pierwszym aspektem jest samo pojęcie sprintu. Sprint w Scrumie to z góry określony, krótki okres (zwykle 1-4 tygodnie), podczas którego zespół skupia się na dostarczaniu konkretnej wartości dla klienta. Na pierwszy rzut oka wydaje się to być strukturalną i motywującą zasadą. Jednakże, sprinty mogą wprowadzić presję na programistów, gdyż w złożonych projektach mogą być trudne do przewidzenia, a oczekiwania zespołu, co do dostarczenia wartościowej funkcjonalności, mogą być zbyt wysokie.

2. Drugim istotnym punktem jest związek sprintów z kulturą pracy. Scrum promuje zwinne podejście, które ma na celu elastyczność i dostosowanie się do zmieniających się warunków. Jednakże, sprinty mogą stworzyć środowisko, w którym ciągła praca pod presją terminów staje się normą. Programiści często czują się zmuszeni do realizacji wyznaczonego zakresu pracy w bardzo krótkim czasie, co może prowadzić do nadmiernego stresu i utraty jakości.

3. Trzecim aspektem jest problematyka dostarczania wartości. Sprinty w teorii mają pomagać w skupieniu zespołu na osiąganiu celów, co z kolei prowadzi do efektywności. Jednakże, jeśli sprinty stają się wyłącznie narzędziem do ciągłego przyspieszania pracy, może to prowadzić do pomijania aspektów jakościowych, testów czy refaktoryzacji kodu, co w dłuższej perspektywie może być szkodliwe dla produktu.

Riddle napisał(a):

A jeśli w issue jest opisany target/cel, np "aktualnie użytkownicy mogą uploadować tylko jpg i png, a powinno się dać móc też uploadować webp (żyg)", to taki task chyba może wziąć każdy i po prostu "make it happen". Po co to dokładniej opisywać?

Chociażby po to, żeby było wiadomo, który projekt/repozytorium kodu otworzyć, i w którym pliku z kodem/formularzu GUI wprowadzić zmianę. Póki co, z opisu taska to nie wynika.

Po to właśnie są refinementy - żeby taski uściślić tak, żeby wszyscy w zespole, a nie tylko autor, je rozumieli.
Bez refinementów trzeba mieć taski bardzo dokładnie opisane - a to jest trudniejsze zadanie niż się wielu wydaje.

somekind napisał(a):

duck napisał(a):

Zasada jest taka, że taski w backlogu są posortowane od najważniejszych do najmniej ważnych. Zrobisz taska albo jesteś zblokowany to bierzesz kolejnego taska z backlogu i elo. Na daily mówimy jakie problemy są albo co nowego wyszło.

To znaczy, że musicie mieć bardzo dobrze opisane taski. Kto się tym zajmuje i kiedy to robi?

Mamy taski „wewnetrzne”, które sami tworzymy dla siebie np. wymagana jest aktualizacja czegoś, zmiana itp. Do tego taski zewnętrzne, które tworzą użytkownicy. Mamy wymóg, żeby był opis jak zreprodukować, jak jest teraz i jak ma być po zrobieniu taska i jak to zwalidowac. Jeżeli tych elementów nie ma to task leci na koniec kolejki i elo. Nauczyli się dobrze opisywać po kilku miesiącach. :)

Kiedyś już to opisywałem, ale hejtowanie scruma zawsze w modzie, więc się powtórze.

• Codziennie daily, które trwa 15-20 min (Sporo osób w zespole plus "gaduły" co malują trawe na zielono
• Raz na dwa tyg retro / demo / planing. Wszystko w akompaniamencie refinmentu i ma miejsce jednego dnia. Cały dzień wtedy to scrumowe [CIACH!].
• do 3 refinmentów godzinnych w ciągu tygodnia w miarę potrzeb... Są one prowadzone w sposó bezsensowny bo za pomocą jakichś zewnętrznych tooli, gdzie przeciąga się karteczki. Generalnie debatuje się na temat głupot i marnuje na to godzinę. Nic tak na prawdę z tego nie wynika, ale scum master uważa inaczej.

Podsumowując. Nieciekawa "implementacja" scruma mi się trafiła aczkolwiek bywałem w gorszych. Gdy by nie relatywny luz w projekcie i całkiem spoko atmosfera, to już bym uciekał.

Najbardziej bezsensowny scrum miałem w firmach z jueseja. Wszyscy o wszystkim dyskutowali co zajmowało tony czasu. Potem i tak trzeba wiele rzeczy dograć na 1n1 czy callach na przykład z architektem czy product ownerem. Mniej albo bardziej połowa sprintu schodziła na gadanie z którego niewiele wynikało.

Teraz odpoczywam w projekcie utrzymaniowym. Mały i sprawny zespół. Mamy daily, refinmenty, planowanie. Raczej wszystko w wersji oszczędnej.

somekind napisał(a):

Po to właśnie są refinementy - żeby taski uściślić tak, żeby wszyscy w zespole, a nie tylko autor, je rozumieli.
Bez refinementów trzeba mieć taski bardzo dokładnie opisane - a to jest trudniejsze zadanie niż się wielu wydaje.

Nie, nie trzeba. Niektóre większe taski architektoniczne warto spisać, po to żeby była jasnośc.
Ale jak to relatywnie prosty task z nową funkcją dla użytkownika to naprawdę nie trzeba się rozpisywać co gdzie i jak.

Zwykle wystarczy krótka rozmowa 1-1 z autorem taska i spisanie istotnych punktów po tej rozmowie (jak coś naprawdę było niejasne).
I tak, raz na jakiś czas jak się wyciągnie coś zakurzonego z backloga to autor nie pamięta co miał na myśli (a task miał tylko prosty tytuł). wtedy zamykamy - widocznie nie było istotne - win/win.

Nie ma scruma, w poniedziałek o 10:00 planujemy co robimy w tym tygodniu i się synchronizujemy zespołowo na 10 minut każdego ranka. I tyle, nie ma deadlinów, bata, scrum mastera. Trzecia firma w Skandynawii z takim podejściem, będzie jak zrobione jak będzie, polecam

u nas 15 min 2x w tygodniu + planning + demo ze spowiedzią czyli każdy się tłumaczy ile zrobił i czemu nie zdążył, ale generalnie nie ma kultu sprintów, czyli możesz coś przenieść na inny sprint.
Generalnie mało scruma.

W poprzedniej firmie natomiast scrum był ważniejszy niż reszta pracy.

Właśnie odgrzebałem notatkę i najdłuższe daily miałem 3h i 2 minuty 46 sekund. Rozwiązywali buga na callu xD

Najszybsze daily miałem 3 minuty i 23 sekundy.

Najdłużej spotkanie trwało 5h i 46 minut z groszami.

A najwięcej spotkań w ciągu sprintu miałem 27h z groszami czyli ponad 1/4 czasu całego sprintu.

W jednym projekcie, jak jeszcze pracowałem jako kontraktor przez te spotkania naprawdę brakowało mi czasu na programowanie, czytanie dokumentacji, ciszy. Nie wiem jak Was, ale mi jak ktoś wrzuci spotkanie np. 1.5h na godzinę 13:00 to tak naprawdę mam dzień stracony trochę. Jedynie z rana coś idzie jeszcze poprogramować, jak będzie spokój.

No i miałem sytuację, że mieliśmy dedykowanego Scrum Mastera no i dla niego takie właśnie spotkania to jest "praca". Udzielanie się na takich spotkaniach, organizowanie ich, spisywanie notatek, przerzucanie tasków na Jirze, aktualizacje statusów.

Sytuacja była dynamiczna wtedy, bo byłem na "deadline" i było ciśnienie na dowożenie. Mimo wszystko pełno tych spotkań było i różnych rozpraszaczy, wstyd trochę mówić, ale by dowozić to po prostu logowałem się wieczorem koło 19-20 jak nikogo nie było i w spokoju kończyłem zadanie. Albo robiłem tak, że zostawałem po prostu do 18 po pracy by skończyć sobie w spokoju.

Podczas tej sytuacji było tak, że Scrum Master powiedział coś takiego "super, że mamy te spotkania, jak chcecie to możemy zrobić ich więcej" (chodziło o refinementy, analizę biznesową, bo pracowaliśmy bez Analityka).

Ja wtedy nie wytrzymałem nerwowo i powiedziałem coś takiego "wszystko spoko, tylko jak są te spotkania i tak dalej to Ty na nich robisz swoją pracę, dla Ciebie tak dni wyglądają, spotkania, Jira, statusy, aktualizacje. Ja potem za darmo po 16 muszę zostawać i pisać kod jeszcze, albo nieraz o 19. Bo przez to wszystko w ciągu dnia nie mam czasu."

Gościowi szczęka totalnie opadła i nie wiedział co powiedzieć. Niestety ludzie, którzy nigdy nie programowali nie zdają sobie sprawy, że to nie jest tak, że ja siadam i piszę jak automat na taśmie. Nie zdają sobie sprawy, że jak ma się takie spotkanie 1h to to wybija z rytmu pracy na 15 minut przed i 30 minut po spotkaniu. Czyli traci się 1.45h.

Tak samo pamiętam jak w jednej korporacji gdzie pracowałem z działu HRów wróciła babka z macierzyńskiego. Niestety nie mieli dla niej już miejsca i wrzucili ją do nas na projekt jako Scrum Masterkę (bo zrobiła sobie certyfikat), ale to już temat na osobną dyskusję.

1 kto prowadzi spotkania scrumowe ?
2 ile godzin scrumu macie co tydzień - mniej więcej i jakie spotkania scrumowe macie

Korpo pracuje w 2 tygodniowych sprintach, ale jako zespół mamy wybór i nie robimy scruma.
Raz na 2 tygodnie demo, ~15min.

Codziennie rano stand-up 30min, czasem dłużej. Na stand up'ie poza tym co kto robi, ogarniamy wszystkie bieżące sprawy, bugi review, priorytety itp.

PawelP6 napisał(a):

Nie wiem jak Was, ale mi jak ktoś wrzuci spotkanie np. 1.5h na godzinę 13:00 to tak naprawdę mam dzień stracony trochę. Jedynie z rana coś idzie jeszcze poprogramować, jak będzie spokój.

Mam DOKŁADNIE to samo. Wybija mnie to całkowicie z rytmu i nie mam potem głowy do efektywnej pracy.

Czy ktoś pracował w scrumie, gdzie sprinty działały tak jak w teorii powinny?
Tzn zespół robi commitment i pod koniec sprintu mamy nowy kawałek, który się pokazuje klientowi?

W praktyce wychodzi tak, że każdy grzebie w swoim kawałku, nie ma jakiegoś wspólnego celu. Wydajemy to, co mamy, bo przecież nie comittujemy zepsutego kodu.

Nigdy nie widziałem dobrze działającego scruma, a przeczytałem kilka książek o tym procesie. I’m calling BS.

ArchitektSpaghetti napisał(a):

Czy ktoś pracował w scrumie, gdzie sprinty działały tak jak w teorii powinny?
Tzn zespół robi commitment i pod koniec sprintu mamy nowy kawałek, który się pokazuje klientowi?

W praktyce wychodzi tak, że każdy grzebie w swoim kawałku, nie ma jakiegoś wspólnego celu. Wydajemy to, co mamy, bo przecież nie comittujemy zepsutego kodu.

Nigdy nie widziałem dobrze działającego scruma, a przeczytałem kilka książek o tym procesie. I’m calling BS.

Nikt nigdy. Dziwi mnie, że ktoś stworzył nowy wątek na temat scruma. Przed bessa to tylko o tym się to gadało, więc wątków jest sporo i w każdym było to samo. Scrum spowalniał i utrudniał pracę programistom, ale PMowie i SMowie mieli jak udowadniać, że coś robią i zarabiali takie same stawki.

Scrum i komunizm działają tylko w teorii. A to temu ze papier wszystko przyjmie a ludzie z krwi i kości już nie.

Te standupy sa najgorsze. Jakbyście robili je tylko z 1-2 na tydzień to by wystarczyło.

@Czitels Taaaaaaaaaa, a potem mój junior który został programista awansem z testera, znowu porwie się z motyką na słonce i będzie juz w połowie drogi. Team @Miang

Ogólnie nie wyobrażam sobie żeby brak daily działa w konfiguracji 100% zdalnie, ludzie z różnymi umiejętnościami, nie trywialne zadania(gdzie problemy bardziej się pojawiają niż są do przewidzenia) oraz założeniem ze jesteśmy samoogranizującym sie zespołem z duża ilością swobody, a nie klepaczami akord.
Jeżeli wiadomo co robić, zadania są proste, dobrze rozplanowane niezależne od siebie i zabierają relativnie duze bloki duzo czasu, to wszystko degeneruje się do 2min, "Robiłem A B C, Nara" i faktycznie można sie spotkać raz na tydzień. Tylko żeby tak było ktoś musi te zadania rozpisać, a jeśli system jest "programiści wymyślcie". To trzeba zrobic planowanie jakoś retrospetywe, bawić sie ceregiele, duzo prościej jest rozmawiać i rozwiązywać problemy na bieżąco.

@_flamingAccount no to rozmawiasz ze swoim juniorem poza daliy. Po co innym zawracać głowę.

jeszcze dopiszę że zaletą ustalania rzeczy na piśmie, w jakimś systemi w których każdy moze sie wypoiedziec albo zadać pytanie konkretnej osobie czyli np. w Mantisie jest:

• asynchroniczność
• możliwość wypowiedzi w godzinach dnia w których najlepiej się właśnie tobie myśli
• możliwość otrzymania odpowiedzi od bardzo zapracowanych osób które scruma oleją bo rozmawiają w tym czasie z kimś ważnym
• możliwość dopisania własnych przemyśleń , bo przeciez najlepsze rozwiązanie wpadnie do głowy godzinę po zebraniu, jak już się wyluzujesz i zgrokujesz cały problem
• łatwość dołączenia multimediów

Miang napisał(a):

jeszcze dopiszę że zaletą ustalania rzeczy na piśmie, w jakimś systemi w których każdy moze sie wypoiedziec albo zadać pytanie konkretnej osobie czyli np. w Mantisie jest:

• asynchroniczność
• możliwość wypowiedzi w godzinach dnia w których najlepiej się właśnie tobie myśli
• możliwość otrzymania odpowiedzi od bardzo zapracowanych osób które scruma oleją bo rozmawiają w tym czasie z kimś ważnym
• możliwość dopisania własnych przemyśleń , bo przeciez najlepsze rozwiązanie wpadnie do głowy godzinę po zebraniu, jak już się wyluzujesz i zgrokujesz cały problem
• łatwość dołączenia multimediów

Najlepsze daily i najbardziej efektywnie to slack daily. W obecnym projekcie jestem oddelegowany również do "pod projektu", gdzie wraz z dwoma data scientistami i jednym qa, sami sobie ogarniamy "sprinty" i "backlog". Raz na sprint spotykamy sie na godzinę, żeby zrobić jakiś planning i przegadać bieżące tematy. Reszta to slack daily, czyli mamy prosta templatke: "1. yesterday, 2. today, 3. help needed". Krotkie, jednozdaniowe opisy i wszystko załatwiamy async / bezpośrednio ze sobą, nie marnując czasu. W głównytm projekcie SM się zesrał na sama myśl o takim podejściu. W sumie nie dziwie się, bo nagle wyszło by, że jest niepotrzebny :/

duck napisał(a):

Mamy taski „wewnetrzne”, które sami tworzymy dla siebie np. wymagana jest aktualizacja czegoś, zmiana itp. Do tego taski zewnętrzne, które tworzą użytkownicy. Mamy wymóg, żeby był opis jak zreprodukować, jak jest teraz i jak ma być po zrobieniu taska i jak to zwalidowac.

Czyli taski od użytkowników to bugi?
Jak to wygląda dla nowych ficzerów?

ledi12 napisał(a):

• do 3 refinmentów godzinnych w ciągu tygodnia w miarę potrzeb... Są one prowadzone w sposó bezsensowny bo za pomocą jakichś zewnętrznych tooli, gdzie przeciąga się karteczki. Generalnie debatuje się na temat głupot i marnuje na to godzinę. Nic tak na prawdę z tego nie wynika, ale scum master uważa inaczej.

Ale co scrum master ma do refinementów?

jarekr000000 napisał(a):

Nie, nie trzeba. Niektóre większe taski architektoniczne warto spisać, po to żeby była jasnośc.
Ale jak to relatywnie prosty task z nową funkcją dla użytkownika to naprawdę nie trzeba się rozpisywać co gdzie i jak.

No i w efekcie relatywnie prosty task wprowadzenia nowych emotek na forum kończy się tak, że przestaje działać funkcja ich wyłączania.

Nie wiadomo kto i kiedy będzie zajmował się danym zdaniem, może to potencjalnie ktoś, kto nigdy nie widział danego projektu na oczy, więc trzeba zawrzeć informacje, gdzie ma szukać. Trzeba też napisać po co się to robi, bo to ułatwia niezepsucie istniejących ficzerów.
Wypada też zrobić code review - nie zrobi się go dobrze nie znając kontekstu, zarówno zadania, jak i projektu, więc o co chodzi w zadaniu musi wiedzieć więcej niż jedna osoba.

bagietMajster napisał(a):

Właśnie odgrzebałem notatkę i najdłuższe daily miałem 3h i 2 minuty 46 sekund. Rozwiązywali buga na callu xD

Długi call w celu rozwiązania buga to nic dziwnego, tylko ciężko to uznać za daily.

ArchitektSpaghetti napisał(a):

Czy ktoś pracował w scrumie, gdzie sprinty działały tak jak w teorii powinny?
Tzn zespół robi commitment i pod koniec sprintu mamy nowy kawałek, który się pokazuje klientowi?

No u mnie w miarę działają - tylko nie mamy commitmentu na każdy sprint (scrum tego nie nakazuje), no i nie pokazujemy klientowi, bo nie mamy klienta (scrum chyba też go nie wymaga).

W praktyce wychodzi tak, że każdy grzebie w swoim kawałku, nie ma jakiegoś wspólnego celu.

To przykre.

U mnie teraz na szczęście nie ma scruma i praca wygląda mniej więcej jak poniżej (i pracuje się zajebiście):

Co tydzień:

• W Pn ok. 1h na "planowanie" - określamy przede wszystkim jaki mamy JEDEN cel w tym tyg do osiągnięcia i mniej więcej wciągamy zadania które go realizują. Wiadomo, zawsze znajdzie się też jakieś 1-2 nie związane, bug czy coś. Ale generalnie nie ma spiny że musimy mieć nabrane zadań na cały tydzień, ot po prostu żeby zacząć. Zazwyczaj to "planowanie" zajmuje nam 30min, ale mamy zasadę, że dłużej jak 1h nie siedzimy.

• Wt - Cz: mamy coś a'la "Daily", zajmuje to nam 5-15min, tylko że zamiast się spowiadać, to zakładamy że statusy itp. są w Jira, a na tym spotkaniu głównie mamy szybkie odbicie ze sobą jak tam stoimy z celem i czy gdzieś potrzebujemy sobie pomóc / inaczej się zorganizować na ten dzień (np. jakiś pair programming). Ofc dużo gadamy / piszemy ze sobą w trakcie dnia i często większość jest już znana / ustalona, a to Daily to głównie taki check kiedy zdzwaniamy się razem.

• W Pt nie robimy Daily, mamy założenie, że pracujemy do obiadu (ok. 13:00) a po obiedzie zdzwaniamy się razem na max. 1h takiego spotkania które określiłbym a'la "mob programming". Generalnie w tym czasie jak trzeba to wspólnie robimy jakieś ostatnie szlify (rzadko to potrzebne), ale głównie przygotowujemy się do podsumowania tygodnia - zazwyczaj po prostu omawiamy co i jak chcemy pokazać aby to spotkanie miało dla nas sens i żebyśmy się nie spowiadali z roboty, tylko pogadali z szerszym biznesem "co dalej".

• W Pt na koniec dnia mamy max 1h podsumowania z biznesem gdzie zazwyczaj Live pokazujemy najważniejsze zmiany i je omawiamy, odpowiadamy na pytania, ale też zadajemy swoje - wszystko po to, żeby w Pn planowanie następnego celu poszło nam jak najsprawniej i żeby zminimalizować ryzyko że obierzemy zły cel. Tydzień zamykamy takim wew. zespołowym spotkaniem ok. 30min gdzie patrzymy bardziej na to jak nam się pracowało przez tydzień (głównie narzędzia i nasze praktyki) i chwilę rozmawiamy czy coś zmieniamy. Zazwyczaj zajmuje nam to dosłownie 10min, ale zdarza się, że coś zmieniamy i wtedy to 30 jest wystarczające aby omówić - kluczowe jest to że ludzie są przygotowani, nie mamy gier i zabaw i od razu idziemy do meritum.

• W ciągu tygodnia łapiemy się też w różnych konfiguracjach na tzw. refinement, ale łącznie rzadko przekracza to 1h.

Całość zajmuje nam w tygodniu ok. 4-5h

Nie wiem jak to nazwać, ale od ok. 9 miesięcy tak działamy i wszystkim pracuje się zajebiście. Weekendy spokojnie można się zresetować i nie martwić że to połowa sprintu czy coś. Wydaje mi się, że taki rytm tygodniowy jest najzdrowszy. Zauważyłem też, że od kiedy tak działamy to biznes bardziej rozmawia z nami o wartości i problemach do rozwiązania, a mniej skupia się na fikołkach "estymacji" i jakiegoś rozliczania. Zdażyło się nam czasami wpaść w jakieś miny i celu nie dowieźliśmy, ale na tyle blisko działamy z biznesem jako zespół, że nie było to problemem - bo co do zasady osiągamy ustalone wspólnie cele.

aa, jeszcze jedno: na tym naszym planowaniu oceniamy sobie wspólnie jako zespół czy cel i ogólnie zarys planu jest realny naszym zdaniem, jak nie to wtedy dla bezpieczeństwa przycinamy / ograniczamy spodziewany scope