[archvile]

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.

#programowanie #programista15k #scrum

[archvile]

@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

[cwlmod]

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

[T.....2]

@sudety: ale w obu przypadkach to jest strata czasu bo w kanbanie jak ktoś sobie nie radzi to poprostu inni pomagają

[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.

@archvile: Bo scrum się sprawdza tam gdzie zadania są proste i wszyscy wszystko wiedzą. Ja doceniam znaczenie daily, bo

[archvile]

@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ć.

[cwlmod]

@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

[d.....6]

Niestety nie mam wpływu na zmiany, jak chciałem coś uwalczyć to: "tak ma być - EOT".

@archvile: sam nie, ale jeśli wszyscy są na nie to istnieje cień szansy

[Jaslanin]

@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

[elf_pszeniczny]

@archvile: .

[Weretek]

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.

[pietryna123]

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ę

[young_fifi]

@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

[Weretek]

@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,

[Majkel2008]

@Weretek: I wjechał klasyczny argument "to nie był prawdziwy komu... scrum". Szkoda, że ten "prawdziwy scrum" nIe istnieje w prawdziwym świecie.

[Weretek]

@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

[a.....e]

W skrócie to tworzymy sobie sami problemy, żeby potem zatrudnić ludzi, którzy te problemy będą "rozwiązywać"

@archvile: brzmi jak socjalizm