[teddybear69]

Wiecie co jest rakiem tej branży? Agile, Scrum i te wszystkie dziwactwa. Bo klient musi sobie co tydzień pooglądać i podotykać niepełnoaprawną apkę i przez to zamiast normalnie zaplanować i zrobić projekt to ja mam co tydzień rozpierdziel i osiem godzin spotkań z project managerem.

#programowanie #programista15k #gorzkiezale #takaprawda #komputery #scrum #agile

[teddybear69]

@yggdrasil no, to trafiamy w sedno. IT wmawia klientom, że mogą coś budować nawet nie wiedząc co to jest. To zwykle oszustwo. No i oczywiście wtedy tradycyjne metody nie działają, więc zamiast pójść po rozum do głowy i zastanowić się co cię chce zrobić to wymyśla się takie chimery żeby usprawiedliwić robienie klienta w c---a.

[y.....l]

@teddybear69: Tylko taki jest stan faktyczny czy Ci się podoba czy nie. W taki przypadku scrum jest całkiem spoko.

[Madbest]

@teddybear69: Do zarządzania 1000 osobowym projektem jest np SAFe. Jego zadaniem jest organizacja pracy pomiędzy wieloma zespołami. Zależnościami między nimi, ryzykami, planowanie itd.
W ramach SAFe'a może istnieć wiele zespołów. Każdy z tych zespołów może korzystać z takiej metodologii która mu pasuje ale z zasady powinna być ona raczej Agile'owa (nie da się wtedy za bardzo waterfalla w takim wypadku wkleić w środek). I taki mniejszy zespół może korzystać z np Scruma. Agile'a da się skalować ale jest to bardzo trudne ponieważ prowadzenie 1000 osób jest zwyczajnie trudne.
Jakie są zalety Scruma według mnie nie patrząc na to książkowo:
Ułatwione zarządzanie postępem projektu
Równomierne, zgodne z umiejętnościami rozłożenie pracy pomiędzy członków zespołu
Po x iteracjach wiedza jakie możliwości przerobowe ma zespół. Po x+x iteracjach możliwość sprawdzenia czy zespół się rozwija/jest w stagnacji/jest

[d.....z]

@yggdrasil: Scrum na duże zespoły jest jak mus programowania obiektowego na duże projekty. Ten sam dobór narzędzia do problemu - nie uwzględnia niczego, strzela na ślepo, bo gdzieś mogło się udać lub "inni tak robią". Tak jak kazać kafelkarzowi zrobić drogę - zrobi zgodnie ze swoją najlepszą wiedzą, czyli położy kafelki zamiast asfaltu. Ale kładzenie kafelek gdzieś się sprawdza, a gdzieś nie. I podobnie jest ze Scrumem i każdą inną metodyką.

A wszystkie te metodyki nie uwzględniają, że ludzie są inni, jeden lubi codziennie opowiadać co robi, drugi woli z nikim nie rozmawiać przez tydzień, a robić. Jeden pewnie się czuje w A, drugi w B, trzeci może nie chcieć znać pierwszego itp. Zespoły to są miksy tego typu indywidualności i teraz wkracza jakaś metodyka, nawet elastyczna i ustala to czy tamto, że wszyscy w zespole pracują według jakichś, nawet w miarę elastycznych procedur. Części się to spodoba, części nie - ta druga będzie w jakiś sposób mniej lub bardziej świadomie sabotować metodyke, bo jej nie będzie chciała się podporządkowywać i będzie na to celowo "przepalać" swój czas, zamiast tracić go na pracę samą w sobie.

Ja wolę estymacje na zasadzie pełnej odpowiedzialności za działkę: znasz/znacie się na czymś, jesteś za to odpowiedzialny. Powiedz mi więc czy feature X jest możliwy i na kiedy, co Ci potrzeba, a czego nie chcesz w trakcie. Czy X nie jest za duży i nie lepiej zacząć od Y. Sam wyznacz termin kiedy jest jakiś checkpoint, w którym powiesz jak idzie praca i jak to widzisz dalej.
W ten sposób, dajmy na to, osoba A, robi feature X, potrzebuje na to 2 dni (według niej), druga Y i potrzebuje nawet miesiąc. A Scrum zakłada jakiś uniwersalizm w obrębie teamu nawet jeśli team woli pracować w zupełnie innym rytmie. I tak, każda firma robi Scrum dobrze/źle

[teddybear69]

@devopsiarz XD, następny mądry. Masz oficjalny podręcznik do Scruma gdzie piszą - zespół deweloperski do 9 osób się sprawdza. No faktycznie mus na duże zespoły :p

[teddybear69]

@yggdrasil aha, czyli mam się godzić na to, że rynek taki jest i mamienie klienta za jego własny hajs to standard? No sorry, ale ja cicho siedzieć nie będę :p

[d.....z]

@teddybear69: proponuję przeczytać mój wpis z większym zrozumieniem.

[teddybear69]

Scrum na duże zespoły jest jak mus programowania obiektowego na duże projekty.

@devopsiarz no wyjaśnij mi co źle przeczytałem w tym zdaniu?

[y.....l]

@teddybear69: Nie piszę, żeby mamić klienta.

Tylko klient zleca Ci dane funkcjonalności i za 3 miesiące przychodzi, że jednak np. zmieniło się prawo i musisz przerobić. Rozumiem, że mówisz mu, że spec był inny i nie zmienisz i nara?

Co jak firma ma własny produkt? Pracowałeś w takiej? Wydaje mi się, że pracujesz w outsourcingu czy software house. Nie zawsze jest tak, że wymagania się nie zmieniają.

[teddybear69]

@yggdrasil a to aplikacji się nie da przebudować bez Scruma jak się wymagania zmienią? Bo to jakieś brednie są

[vlodar]

Wiecie co jest rakiem tej branży?

@teddybear69: programiści którym się wydaje że zrozumieli to, co się im 20 razy tłumaczyło i pokazywało, a tak naprawdę to c---a zrozumieli

[uketrab]

@teddybear69: Metodologia z więzienia lub z obozu pracy, owinięta w marketingowe g---o i sprzedawana pelikanom, którzy kupią każde g---o odpowiednio zareklamowane.
Celem tych metodologii jest tylko i wyłącznie kontrolowanie i trzymanie za mordę ludzi. Powinno to być zakazane.

[c.....b]

@teddybear69: Scrum sam w sobie jak dla mnie okej, to co przeszkadza najbardziej to właśnie nadmierna ilość spotkań

[mirasKo-Kalwario]

@teddybear69: samo pisanie kodu w dzisiejszych czasach już nie zrobi z ciebie programisty, bez chodzenia na spotkania i rozmów oraz negocjacji z biznesem zależy to jak rozwijać produkt, bo celem programisty jest dowieźć produkt a nie napisać zajebiscie dobry kod w za długim czasie. Ty się za bardzo fiksujess na pisaniu kodu a już od jakiegoś czasu bycie do bycia programista trzeba czegoś więcej, a przynajmniej do bycia dobrym programistom,

[teddybear69]

@mirasKo-Kalwario XD, fajnie, że po tygodniu odpowiadasz na zarzutkę :p

[mirasKo-Kalwario]

@teddybear69: musialem rozchodzić żenadę