[evilonep]

Muszę się wyżalić. Siedzę na szkoleniu z #agile #scrum w tym roku jest to już któreś z kolei. Czy wy też odnosicie wrażenie, że to jest sekta? Nie kumam jak można się masturbowac do skrama, a wydaje mi się, że każdy z tych trenerów to robi po szkoleniach. Na każdym z nich stół #!$%@? sticky notesami jakieś gówno gry i zabawy no tragedia, strasznie teraz cierpię. Czuję się jak na prezentacji Thermomixa
#pracbaza #pracait

[Saly]

ogarnięty team, ogarnięte CI/CD, TDD+ATDD, DDD, małe wdrożenia per feature to najlepsze co może spotkać developera

@git-reset-hard-head: to nie ma nic wspólnego ze scrumem. To co wypisałeś to po prostu mechanizmy, które pozwalają na dużą zwinność tj. ile czasu musi minąć od feedbacku, żeby coś zaimplementować. Przykładowo CI/CD pozwala na dużą automatyzację przez co zaklepanie nowego ficzera jest po prostu szybsze. Mając dobre testy mogę zmienić linię kodu w 5 minut

[TotalDisaster]

W scrumie masz narzut iteracji. Klient coś wymyślił, następnie trafia to do backlogu, jest estymata, trafia do iteracji, iteracja się kończy, jest demo i wracamy do punktu początkowego. Samą istotą scrumu jest właśnie takie ogarnięcie "zwinności" w zafiksowane bloki tego co trzeba zrobić, żeby było w miarę zwinnie i jednocześnie był taki okres w którym nic się nie zmienia, bo to podobno pomaga zespołowi

@Saly: tbh jeśli jest to ważne to

[Saly]

następnym sprincie a sprinty z zasady mają być małe (~2 tyg) więc to i tak jest super szybko jak na warunki biznesowe.

@TotalDisaster: niby tak, z drugiej strony po co 2 tyg jak można szybciej

Pamiętajmy, że scrum powstał gdy domyślnym systemem był waterfall, czyli jak projekt trwał 3 lata i klient miał jakieś uwagi w trakcie to ma pecha

@TotalDisaster: tutaj nie byłbym taki pewny. Z tego co czytałem

[quarien]

Jednym z głównych czynników jest to że Scrum w ogóle nie bierze po uwagę czynnika ludzkiego jak np. masz gorszy dzień, czy mało co spałeś bo małe dziecko płakało w nocy - czyt. masz gorsza efektywność. Z założenia wychodzi że jesteś jak robot.

Jak najbardziej bierze.
Wynikiem Planningu jest... plan.
Masz jakiś plan na dowiezienie XYZ tasków.
Podczas codziennego Daily sprawdzasz czy robota idzie... zgodnie z planem.
Jak nie idzie... to poprawiasz

[Kshaq]

@Saly: Scrum nie mówi nic o tym jak często mają być release. Efekt na koniec sprintu ma być potencjalnie releasowalny produkt. "Potencjalnie" bo PO może zdecydować, że ma MVP, może go przetestować ale jeszcze nie nadaje się na wypuszczenie na proda. Wartością jest tu zebranie feedbacku.

Sprint ma swój określony cel, jeśli jest osiągnięty szybciej to super, można releasować. Co więcej release to nie tylko wielkie zmiany. W sprincie mogą się

[Caishen]

"bo nie #!$%@?śmy wystarczająco szybko"

@quarien: a kto CI powie prosto z mostu, że się #!$%@?ł?

Dlatego pracujemy w zespołach. Dobre Daily to takie gdzie powiesz "panowie, wczoraj dziecko mi płakało, #!$%@? zrobiłem, może ktoś mnie odciążyć?" i usłyszysz "Dobrze mordo, moje ma niższy prio, skupmy się na Twoim".

@Kshaq: gorzej jak nie ma wiedzy w zespole i tylko ta jedna osoba wie jak zrobić taska.

[Kshaq]

@Caishen: to też jest ważna informacja dla zespołu. Pół biedy kiedy dziecko płakało raz i była to wyjątkowa sytuacja a jeśli to się powtarza to jest temat na retro aby zwiększyć tzw. bus factor.

[quarien]

@Caishen:

a kto CI powie prosto z mostu, że się #!$%@?ł?

Tutaj ważne - dlatego SM powinien budować zaufanie w zespole aby bez spiny wychodziły słabsze dni. Programowanie jest praca kreatywna. Są dni lepsze są dni gorsze, jest to coś normalnego. Lepiej zaakceptować to i szukać rozwiązań gdzie indziej niż ujeżdżać ludzi i oczekiwać że będą pracować non stop na pełnych obrotach.

A jeśli ktoś się realnie obija i bierze pieniądze