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 ( ͡°͜ʖ͡°)
@cwlmod: Myślę, że nasz case jest taki, że ktoś powiedział u góry, że ma być i tyle. Idea scruma mi pasuje, ale nie mam np. wpływu na to, że dostajemy na sprint same bugi do ogarnięcia. Największym problemem w scrum to dla mnie ilość spotkać a co za tym idzie context switchingu.
@sudety: Przerabiałem to już setki razy, jak ludzie nie są przekonani do estymat to nie ma bata ale
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ł.
@zibizz1: Zgadzam się. Liczbę podałem może z tyłka, bo w poprzedniej robocie po prostu mieliścmy jeszcze functional architektów (2) i głównego manadżera (byliśmy jedynym zespołem w Polsce robiącym dane zadania). Oni akurat nie przeszkadzali w organizacji,
Myślę, że nasz case jest taki, że ktoś powiedział u góry, że ma być i tyle. Idea scruma mi pasuje, ale nie mam np. wpływu na to, że dostajemy na sprint same bugi do ogarnięcia. Największym problemem w scrum to dla mnie ilość spotkać a co za tym idzie context switchingu.
@archvile: Bo scrum się sprawdza tam gdzie zadania są proste i wszyscy wszystko wiedzą. Ja doceniam znaczenie daily, bo jednak
@cwlmod: Zdecydowanie... Ze spotkań które bym zostawił to status, ale max 3 razy w tygodniu. I tak na slacku non stop piszemy żeby być na bieżąco. Retro też: ale nie w formie "jakim zwierzęciem jesteś i jakie masz uczucia" - tylko kawa na ławe: co jest nie tak i jak to rozwiązać.
@archvile: BTW Chyba teraz pracuje w kanbanie czyli przesuwam taski po tablicy i mamy tylko daily. Przyznam, że lepiej mi się tak pracuje, a wystarczy tylko jakiś sporadyczny planing, głównie na start projektu, by oszacować jego skalę. Nie widzę specjalnie sensu rozdrabnianie się w poszczególne małe taski.
Często w scrumie miałem tak że albo zostawały taski z poprzedniego sprintu albo się kończyły i co wtedy? Przecież sprint ma być self contained
@archvile: celem scruma jest wyciśnięcie większej efektywności z zasobów ludzkich, pod pozorem tworzenia narracji że to dla ich dobra. tutaj opisałem jak scrum jest sprzedawany biznesowi: https://www.wykop.pl/wpis/66475123/#comment-235793677 wiadomo że zasoby ludzkie chciały by pracować w swoim tempie, ale jak komuś płacą to pierwsze pytania ile to kosztuje, czemu tak drogo, i kiedy to będzie zrobione. A nie że możesz sobie Pan robić swoim tempem jak panu płace za zrobienie np
Wg mnie dużo tu zależy od produkt ownera i tego jak planowana jest praca już poza zespołem. Jak dostajemy same bugi albo np. featurey ale każdy pracuje nad swoją rzeczą?! Wg mnie nie ma to sensu.
@archvile: PO swoją drogą, ale skoro zespół wykonuje zadania, to nie mogą być one planowane po za nim. Dlatego właśnie odbywa się refinement i estymacje. Pierwsze, żeby zespół zapoznał się z zadaniami i ew. dopytał,
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 fixowanie się
@archvile: Przecież scrum nie ma nic wspólnego z oryginalnym agile manifesto. Pierwotnym celem było dostarczania produkty co określony czas, w samo-organizujących się zespołach, które będą w stanie utrzymać swoje tempo pracy w nieskończoność i stabilnie dostarczać oprogramowanie/produkt, który jest miarą sukcesu.
Pracowałem w scrumie, scrumbanie, pracowałem w yolo development i innych. Ale szczerze powiedziawszy to najlepsza praca była w momencie, gdy mamy jakiś odgórnie narzucony cel, a następnie seniorzy danego działu
@young_fifi: Z punktu widzenia deva to co opisujesz jest spoko. Ale ktoś daje na to kasę i chciałby mieć wgląd i wpływ na prowadzone prace. Nie da się też dobrze z góry zaplanować pracy na rok do przodu dla 4-5 zespołów. Potrzebujesz wtedy jakiś ram działania i uszczegóławiasz kolejne aspekty równolegle z już rozpoczętą pracą. Do tego dochodzą zmiany w przepisach, które mogą mieć wpływ na oryginalny plan, działania konkurencji, które
@Majkel2008: Po pierwsze, to ja w większości odpowiedzi tutaj zaznaczam, że scrum nadaje się do konkretnych projektów, a nie wszystkich i w zależności od tego co jest do wykonania są inne, często lepsze metodologie. Bo to po prostu fakt. Kolejne co robię, to pokazuje dlaczego nawet jeżeli coś ma nazwę jak w scrumie, ale nie jest wykonywane z prawidłową intencją i w prawidłowy sposób to też ciężko winić o to samą
- 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
@sudety: Przerabiałem to już setki razy, jak ludzie nie są przekonani do estymat to nie ma bata ale
@zibizz1: Zgadzam się. Liczbę podałem może z tyłka, bo w poprzedniej robocie po prostu mieliścmy jeszcze functional architektów (2) i głównego manadżera (byliśmy jedynym zespołem w Polsce robiącym dane zadania). Oni akurat nie przeszkadzali w organizacji,
@archvile: Bo scrum się sprawdza tam gdzie zadania są proste i wszyscy wszystko wiedzą. Ja doceniam znaczenie daily, bo jednak
Często w scrumie miałem tak że albo zostawały taski z poprzedniego sprintu albo się kończyły i co wtedy? Przecież sprint ma być self contained
@archvile: sam nie, ale jeśli wszyscy są na nie to istnieje cień szansy
wiadomo że zasoby ludzkie chciały by pracować w swoim tempie, ale jak komuś płacą to pierwsze pytania ile to kosztuje, czemu tak drogo, i kiedy to będzie zrobione. A nie że możesz sobie Pan robić swoim tempem jak panu płace za zrobienie np
@archvile: PO swoją drogą, ale skoro zespół wykonuje zadania, to nie mogą być one planowane po za nim. Dlatego właśnie odbywa się refinement i estymacje. Pierwsze, żeby zespół zapoznał się z zadaniami i ew. dopytał,
Pracowałem w scrumie, scrumbanie, pracowałem w yolo development i innych. Ale szczerze powiedziawszy to najlepsza praca była w momencie, gdy mamy jakiś odgórnie narzucony cel, a następnie seniorzy danego działu
@archvile: brzmi jak socjalizm