Eh... wprowadzili u mnie ostatnio scruma. Wcześniej pracowaliśmy w kanbanie, w poprzedniej firmie było: przejście scrum -> kanban. Scrum to jest po prost krok wstecz.
- Daily: scum master po kolei wywołuje imiona - Demo: nikt nie chce tego robić, a jak już robi to pokazują jakieś terminale albo odpalane testy xD - Retro: podejmujemy jakieś action pointy, nikt nad nimi potem nie pracuje - Estymaty: głosowanie na czacie, ktoś daje 1SP, ktoś daje 5SP: "Dobra, może być 5"
W skrócie to tworzymy sobie sami problemy, żeby potem zatrudnić ludzi, którzy te problemy będą "rozwiązywać". Śmiech na sali.
Estymaty: głosowanie na czacie, ktoś daje 1SP, ktoś daje 5SP: "Dobra, może być 5"
@archvile: To najlepiej pokazuje, że nie załapaliście koncepcji scruma ( ͡°͜ʖ͡°)
Mnie też to męczą te ciągłe planningi ze względu na fakt, że jeśli cały team ma ponad 10 osób to znaczy, że devsów jest z 3/4 czyli zawsze będą robić różne zadania.
Planningi są bardziej potrzebne menagerom, bo po paru
@archvile: bo źle do tego podchodzicie, nie staracie się dostosować procesu dla własnych potrzeb.
głosowanie na czacie, ktoś daje 1SP, ktoś daje 5SP: "Dobra, może być 5"
to jest zwykłe niedbalstwo. Dobre estymowanie nie jest złe, pozwala na wspólne zrozumienie problemu. Same punkty nie są najważniejsze, najważniejsze jest żeby każdy wiedział z czym wiąże się dane zadanie. W opisanym przez Ciebie przypadku gość który dał 1 powinien uzasadnić swoją decyzję, tak
@archvile: No tak, opisałeś jakąś patolę, która pewnie wprowadził ktoś komu ktoś kiedyś coś powiedział, a ze scrumem ma wspólną tylko nazwę. No i dzięki temu ty i cały zespół zawsze będziecie unikać scruma, a nigdy w nim nie pracowaliście. Ale to norma niestety. Bo w projektach o dużej zmienności scrum ma sens i może działać. Co nie znaczy, że jest jedyną metodologia, która ma sens i może działać.
Bo w projektach o dużej zmienności scrum ma sens i może działać.
@Weretek: scrum działa jak cały czas dzieje się to samo i klient chce sobie wybrać priorytety na następny tydzień. W innych wypadkach scrum to zagrożenie dla dużej zmienności, bo debilny podział na iteracje sprawia, że ta koncepcja rozpada się przy jakimkolwiek problemie
@Saly: Wprowadzanie zmian z dnia na dzień, bez przygotowania tych zmian do wprowadzenia to też przepis na porażkę. Czas iteracji może i powinien być wykorzystany na zaplanowanie i opisanie nowych rzeczy. Nieczęsto zmienia się kierunek z dnia na dzień, raczej zmienia się kierunek mniej drastycznie. Ale to metodologię dobiera się do potrzeb, a nie na odwrót. Mamy ich tyle do wyboru i tyle przykładów różnych projektów mniej lub bardziej udanych, że
@ATAT-2: Niestety, ale spotkałem nawet agile coachy i scrum masterów, którzy wprowadzają takie potworki. Ale spotkałem też takich kompetentnych i pracowałem w fajnych zwinnych zespołach. Do tej pory zespół scrumowy, ale nie taki tylko z nazwy to moje najlepsze doświadczenie projektowe.
Mnie też to męczą te ciągłe planningi ze względu na fakt, że jeśli cały team ma ponad 10 osób to znaczy, że devsów jest z 3/4 czyli zawsze będą robić różne zadania.
Zawsze kiedy pojawia się krytyka scruma to wychodzi że nie jest stosowany. Zespoł powyżej 10 osób to nie jest zespół scrumowy. Wiem bo mój ma ponad 20 osób i w nim scrum nie bedzie działał.
@archvile: akurat estymację i refinement to najprzydatniejsze spotkania, za to dla mnie retro mogłoby nie istnieć, podobnie demo czesto
@Tasartico7: A ja się zdecydowanie nie zgodzę. Retro u mnie jest wartościowe - jak masz pomysły lub uwagi to dzielisz się nimi na retro i masz PEWNOŚĆ, że ktoś coś z nimi zrobi.
Demo z kolei pozwala mieć mi pojęcie o tym, co inne zespoły robią i jakie są zmiany w
@archvile: jeśli z kanbanem było wam lepiej i wykonywaliscie robotę to do managementu bym uderzył. Może uda się pozbyć. W moim zespole to sram master był rok ale jakoś udało się szkodnika pozbyć w końcu całym zespołem. Dużo lepiej się zrobiło po tym. Już 1.5 roku bez scrum mastera i nie było gorzej niż jak był do tej pory, tylko lepiej
@Tasartico7: Oczywiście. Kiedyś jeden SM mi powiedział, że najpopularniejszym pytaniem na rozmowach o pracę jest 'Jakbyś musiał pozbyć się jednego scrumowego spotkania, które byś wybrał'. Poprawna odpowiedź to oczywiście 'Zależy od projektu i od tego, jak pracownicy wykorzystują spotkania'.
jeśli z kanbanem było wam lepiej i wykonywaliscie robotę to do managementu bym uderzył.
@dizzy126: Tzn wiesz, op tak mówi (dev czy inny 'szeregowy' pracownik). Równie dobrze kanban mógł być dla niego lepszy bo z ludźmi nie musiał rozmawiać i na spotkaniach się pojawiać.
@ATAT-2: no op mówi też, ze wprowadzili scruma, a scrum jak komunizm, jak nie działa to nie był prawdziwy scrum. Dlatego napisałem by pozbyć się scrum mastera, bo to co wprowadził może nie mieć żadnego sensu
no op mówi też, ze wprowadzili scruma, a scrum jak komunizm, jak nie działa to nie był prawdziwy scrum.
@dizzy126: No nie, nie do końca tak jest. OP narzeka na scrum po czym wypisuje w 4 punktach rzeczy które robią zupełnie niezgodnie z metodyką i jej założeniami (a nawet sobie z tego sprawy nie zzdaje). Jak można w takim momencie winić samego scruma pomijając kulawe zarządzanie i brak elementarnej wiedzy o
@ATAT-2: przecież napisałem, że scrum mastera trza wywalić, bo przez niewiedzę i mode na scruma wrzucają jakieś gówna i to wszedzie gdzie się da. I sam potwierdziłes, ze to nie jest scrum ( ͡°͜ʖ͡°)
- Daily: scum master po kolei wywołuje imiona
- Demo: nikt nie chce tego robić, a jak już robi to pokazują jakieś terminale albo odpalane testy xD
- Retro: podejmujemy jakieś action pointy, nikt nad nimi potem nie pracuje
- Estymaty: głosowanie na czacie, ktoś daje 1SP, ktoś daje 5SP: "Dobra, może być 5"
W skrócie to tworzymy sobie sami problemy, żeby potem zatrudnić ludzi, którzy te problemy będą "rozwiązywać". Śmiech na sali.
#programowanie #programista15k #scrum
@archvile: To najlepiej pokazuje, że nie załapaliście koncepcji scruma ( ͡° ͜ʖ ͡°)
Mnie też to męczą te ciągłe planningi ze względu na fakt, że jeśli cały team ma ponad 10 osób to znaczy, że devsów jest z 3/4 czyli zawsze będą robić różne zadania.
Planningi są bardziej potrzebne menagerom, bo po paru
to jest zwykłe niedbalstwo. Dobre estymowanie nie jest złe, pozwala na wspólne zrozumienie problemu. Same punkty nie są najważniejsze, najważniejsze jest żeby każdy wiedział z czym wiąże się dane zadanie.
W opisanym przez Ciebie przypadku gość który dał 1 powinien uzasadnić swoją decyzję, tak
@archvile: nie zgadzam się, change my mind ( ͡° ͜ʖ ͡°)
@Weretek: scrum działa jak cały czas dzieje się to samo i klient chce sobie wybrać priorytety na następny tydzień. W innych wypadkach scrum to zagrożenie dla dużej zmienności, bo debilny podział na iteracje sprawia, że ta koncepcja rozpada się przy jakimkolwiek problemie
@archvile: Brawo, wypisałeś właśnie całkowicie zyebane podejście do poszczególnych etapów Scruma po kolei i zwalasz to na
@Weretek: Szczególnie na tym tagu ( ͡° ͜ʖ ͡°) Mam wrażenie, że 95 procent osób tutaj najgłośniej krzyczących na scruma ma o nim pojęcie takie jak op
Zawsze kiedy pojawia się krytyka scruma to wychodzi że nie jest stosowany. Zespoł powyżej 10 osób to nie jest zespół scrumowy. Wiem bo mój ma ponad 20 osób i w nim scrum nie bedzie działał.
@Tasartico7: A ja się zdecydowanie nie zgodzę. Retro u mnie jest wartościowe - jak masz pomysły lub uwagi to dzielisz się nimi na retro i masz PEWNOŚĆ, że ktoś coś z nimi zrobi.
Demo z kolei pozwala mieć mi pojęcie o tym, co inne zespoły robią i jakie są zmiany w
@dizzy126: Tzn wiesz, op tak mówi (dev czy inny 'szeregowy' pracownik). Równie dobrze kanban mógł być dla niego lepszy bo z ludźmi nie musiał rozmawiać i na spotkaniach się pojawiać.
@dizzy126: No nie, nie do końca tak jest. OP narzeka na scrum po czym wypisuje w 4 punktach rzeczy które robią zupełnie niezgodnie z metodyką i jej założeniami (a nawet sobie z tego sprawy nie zzdaje). Jak można w takim momencie winić samego scruma pomijając kulawe zarządzanie i brak elementarnej wiedzy o