Ja Cię bardzo przepraszam, ale jak on ma umrzeć skoro nigdy go nie było? Były co najwyżej korporacyjne nakładki na Waterfalla z udawaniem jaka to firma/zespół nie są "zwinne" bo z jakiegoś powodu takie fandzolenie się sprzedawało.

Scrum biznesowi wydaje się fajny, bo dzięki wszystkim mutacjom i degenaracji dla nich scrum == ciągła zmiana wymagań po analizie taska i rozpoczęciu pracy nad nim, bo jesteśmy super edżajl. Niestety tak to wygląda w dużej części firm jak nie większości.

Czy wjechalibyście na most, mając wiedzę, że został wybudowany w metodologii "scrum"?

Nie znam się na Scrumie. Mam takie pytanie do osób, które coś wiedzą ( @.andy ?): kto w firmie powinien ustalić, że praca ma przebiegać w Scrumie od teraz?

@Silv: zarząd ogólnie decyduje o tym jak firma ma pracować - w tym przypadku np. na jakich metodykach mają być robione poszczególne projekty.

Problem jest inny. Wyobraź sobie, że jako firma starasz się o kontrakt na budowę oprogramowania. Znasz na początku tylko ogólne zarysy tego co ma system robić - na tej podstawie nie da się stworzyć dokładnego punktu czasowego do jakiego to oprogramowanie wytworzysz.
Teraz najlepsze. Firmy często na tym etapie podpisują umowę z harmonogramem! :D Jest deadline na produkcje oprogramowania gdzie nie masz kompletnej analizy!

Potem zarząd daje to do implementacji i zespół zaczyna prace. Najpierw są spotkania gdzie pozyskuje się informacje co tak na prawdę ma być i iteracyjnie się dowozi poszczególne elementy systemu i pokazuje na demo.
Konkretne iteracje mogą być powtarzane jak się okaże, że nie o to chodziło itd.

Cała patologia polega często na tym, że metodykę zwinną stosuje się do projektów, gdzie mamy z góry ustalony konkrety termin nie znając kompletnych wymagań. To tak jak byś budował dom bez planów na początku :D

Do tego wszystkiego dochodzi cała ta patologia zarządzania czyli wdrażanie metodyki do wszystkiego nie patrząc czy w tym konkretnym elemencie ona się nadaje.
Często organizacje je wdrażają bez pomocy z zewnątrz i wychodzi patologia.

Co firma to inna wersja scruma. Sęk w tym, że zamiast podporządkować się pod konkretną metodę, to "modyfikuję" się ją pod własne widzi mi się. Efektem są scrumo-podobne twory totalnie odbiegające od domyślnych standardów oraz niosące za sobą więcej chaosu niż pożytku.

@ledi12: tu nie chodzi o to że metodykę się dostosowuje do organizacji a o patologiczną implementację.

Scrum jest sam w sobie ok, tylko problem pojawia się jak ktoś w zwinny sposób chce dostarczać oprogramowanie tak jakby pracował w waterfallu. Z jednej strony dajmy "zarządzanie" i produkcję zespołowi ale z drugiej i tak mają na to X dni przy Y zasobach :D

Praca w trybie zwinnym polega na tym że rozpisując poszczególne funkcjonalności (we współpracy z klientem) są one wyceniane i do momentu wyceny nie wiadomo ile zajmie ich wytworzenie.
Sama wycena zazwyczaj nie zawsze może oddawać faktycznie czas wytworzenia danego elementu. Do tego wydajność zespołu mierzona historycznie, wiec jak masz nowy zespół, to nawet nie wiesz ile jesteś w stanie obrać ziemniaków w sprincie.

Teraz jak ktoś z biznesu, nie mając pojęcia o tym ile poszczególne funkcjonalności zajmą może wpisać datę oddania na umowie?

Potem mamy stres, nadgodziny, odejścia ludzi...

Scrum polega np. na tym, że jeśli ta metodyka kuleje w naszym zespole, to myślimy co możemy poprawić. Bynajmniej nie jest ona po to, żeby się jej kurczowo trzymać! Kurczowe trzymanie się zasad procesu jest przeciwieństwem scruma.

@PerlMonk: a to nie tak, że jak "mamy" chaos, to szukamy rozwiązania, które od razu da "nam" porządek? Po co "nam" rozwiązanie częściowe? Patrząc z punktu widzenia biznesu.

Scrum to korpo agile czyli oksymoron z definicji, a nietechnicznym scrum masterzy to patologia porównywalna z coachami personalnymi

@PerlMonk: czytałeś w ogóle Scrum Guide? "Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless."

I to jest dokładnie to co @KamilAdam napisał - Scrum nie jest agile w znaczeniu dostosowywania się, bo to do niego trzeba się dostosować. Być może nawet autorzy mają rację, nie wiem, bo jeszcze nie widziałem nie modyfikowanego Scruma, ale te polskie ulepy nie wyglądają na lepszą alternatywę.

@Saalin: no i?

No to, że trzymanie się zasad procesu jest cechą Scruma.

Podejście "my zrobimy swoją wersję Scruma" może i jest ok, ale to co wyjdzie to nie będzie Scrum, bo to nazwa zarezerwowana dla tej konkretnej metodyki opisanej w Scrum Guide.

Nieortodoksyjny Scrum jest jak nieortodoksyjne koszerne jedzenie. Albo cos jest koszerne albo nie jest, to nie jest tak, że każdy ma własną wersję rzeczywistości.

To nie chodzi o lekką modyfikację czy nie. Po prostu często biznes na górze dalej chce pracować jak w waterfall używając metodyk zwinnych :D

To jest właśnie w tym wszystkim najśmieszniejsze. Do tego dochodzi kwestia poruszona w artykule, czyli PO nie jest PO a developerzy tracą kontrolę nad tym jak coś zakodować.

@Saalin: ile trzeba zmienić mercedesa żeby nie liczył się jako mercedes tylko inny samochód? Albo tekst piosenki żeby nie trzeba było płacić tantiem? Ze Scrumem jest jednak inaczej. Często słyszę że jakakolwiek zmiana w Scrumie to już nie jest Scrum. Wiesz gdzie jest podobnie? W religiach wiary. Kapłani religii wiary potrafili nawoływać do wojen z powodu interpretacji jednego zdania. Dlatego uważam ze Scrum to religia a Scrum Masterzy to kapłani

Od lekkiej modyfikacji się zaczyna. Widziałem już nawet Scrum bez planningów.

Wracając jeszcze do Scruma. Miał on rozwiązać problem ciągnących się długo projektów oraz tego, że na koniec efekt docelowy nie do końca mógł być tym czego klient potrzebował.
Do tego dochodzi jeszcze, to że podczas pracy mogą pojawić się zmiany - reagujemy na rynek np.

Dla mnie główne rzeczy w scrumie to:

• iteracyjne rozwijanie softu,
• rozpisywanie funkcjonalności na user story oraz rozmowa o nich całym zespołem aby każdy rozumiał o co chodzi,
• rozpisywanie tasków technicznych do US,
• wycena US,
• wrzucanie tyle US na sprint aby zespół był w stanie to zaimplementować,
• oceny sprintu - co poszło nie tak a co nie, co można poprawić,
• codzienne KRÓTKIE spotkania aby mieć status co kto robił, na jakim etapie jest i czy potrzebuje ewentualnie pomocy.

@Saalin: Z drugiej strony jest trzymanie się scrum nawet, jeśli to nie pasuje do firmy i zespołu. To też nie jest zdrowe. Nie da się wszędzie zastosować scrum bez zmian.

@PerlMonk: ale ja nie twierdzę, że trzymanie się Scruma jest dobre, ani że Scrum jest dobry. Po prostu nazywanie tego co wyjdzie z tych modyfikacji jest mylące, bo ktoś później narzeka na Scruma a tak naprawdę narzeka na zupełnie inna metodykę, nierzadko na jakas formę waterfalla że sprintami.

@Saalin: Spoko. Z drugiej strony ja rozumiem, że nie wszędzie da się stosować scrum w 100%, więc nie dziwni mnie, jeśli gdzieś są odstępstwa.

@Saalin: socjalizm tak, wypaczenia nie ;)

Niektórym ciężko jest zaakceptować postęp, Scrum >> Waterfall, ale X >> Scrum, coraz więcej osób zauważa wady Scruma i szuka tego magicznego Xa. Scrum niestety poległ pod wieloma względami w starciu z korporacyjną rzeczywistością, to nic, my iterujemy dalej szukając lepszej metodyki która będzie bardziej odporna na korpo zagrywki i bardziej przyjazna programistom. Oczywiście wiele osób zainwestowało w Scruma stając się couchami, robiąc szkolenia czy pracując jako SM, oni będą bronić Scruma do końca - przecież to ich źródło dochodów. Trzeba wydoić tą krowę do końca. Ja szukam lepszych metodyk, stawiających na większą autonomię i ownership oraz zrozumienie biznesu.

Problemem jest mentalność ludzi, którzy przywiązują wagę do sloganów i szukają srebrnej kuli (podobnie jak z OOP, DDD itp.). Tylko, że to jest strasznie zapośredniczone - ktoś coś wymyślił (np. autorzy Scruma, teoretycy OOP, DDD itp.), a później ktoś o tym czyta/bierze udział w kursie, a potem jest praktyka. I okazuje się, że coś, co było może dobrą ideą w laboratorium/książce, rozwala się w praktyce, bo albo coś obok idealnych idei nawet nie stało (np. "agile" w firmach kontra manifest agile XD) albo odwrotnie - idee są interpretowane zbyt dosłownie (jak często w przypadku DDD, gdzie ludzie próbują 1:1 zaaplikować coś z książki bez pomyślenia "dlaczego". Czyli cargo cult)

Teraz najlepsze. Firmy często na tym etapie podpisują umowę z harmonogramem! :D Jest deadline na produkcje oprogramowania gdzie nie masz kompletnej analizy! jakby tak było tylko z softem... Tyle tylko, że tu dochodzi jeszcze "syndrom utopionych kosztów" (nie wiem jak to się fachowo nazywa): jak sprzedający odpowiednio dużo kasy wyciągnie z klienta to temu już może nie opłacać się zmieniać wykonawcy. BTW, sporo biznesu działa w waterfallu. Kultury organizacyjnej nie przestawisz na modne hasła. Ja zresztą z kaskadą nie mam problemu, nie lubię natomiast jawnego kłamstwa ze strony kierownictwa, które samo zdaje się czasem wierzyć we własne prymitywne metody coachingowe. BTW: najlepszy (tzn. najlepiej zrealizowany) projekt w jakim pracowałem był w założeniach totalnie niezwinny: "macie N czasu na ficzery X,Y,Z na platformie P, a potem: fajnie zrobić A i B, C jest totalnie na inny release. Ale jak jakimś cudem się wyrobicie to super." Spotkania a'la progress report/demo 1x/14 dni, poza tym po prostu dużo bieżącego gadania. biurko w biurko w razie potrzeby. I okazało się, że dowieźliśmy wszystko włącznie z C przed czasem ;P. Ale a. cały zespół to byli bdb fachowcy z zaufaniem do siebie (oraz z kredytem zaufania szefostwa, notabene z backgroundem technicznym również), b. menedżment (skutecznie) starał się nie przeszkadzać, a jak klient robił problemy to gadał z nim żeby nas odblokować zamiast nas naciskać Bóg wie o co. No ale, klient nie był wielki a projekt nie był krytyczny dla firmy, więc spiny nie było. Wszystkie business criticale natomiast to był zawsze pożar w burdelu (no ok, rozumiem, wszyscy się boją) i spychologia (to mniej ok, ale nauczyłem się dużo ludzi w CC maili dodawać). Ale wszystko to łączyło jedno: im większy bajzel tym więcej mądrych nazw/akronimów latało, spotkań (w tym meta) masa, roboty mało. A jak już znajdziesz dziurę w procesie to on jest przecież święty i nie może nie działać, ale retro to oczywiście wartościowe ćwiczenie teoretyczne, ale proces święty, całuj kozła...tzn. proces w d... ;)!

tl;dr: nie widzę problemu ze scrumem/kanbanem/warterfallem/czymkolwiek innym ale: a. nie udawać pracy w danej metodologii b. "Szabat jest dla człowieka, nie człowiek dla szabatu", nie mam problemu z dostosowywaniem tego pod siebie, liczy się efekt. Przy czym trzeba mieć a. ludzi odpowiedzialnych za własną pracę b. proces wymaga utrzymywania. Jak w tym dowcipie "wg przepisu babci najpierw utnij kurczakowi nogi, upieczesz je potem" "mamo ale dlaczego|" "a spytaj babci jak u niej będziesz" "babciu czemu według twojego przepisu udka z kurczaka piec osobno?" "a bo miałam małą brytfankę i się nie mieścił cały".

Pytanie tylko czy inna metodyka rozwiąże problem? No moim zdaniem nie, bo i ona zostanie zgłwałcona i używana niezgodnie ze swoim przeznaczeniem.

Są metodyki rozwiązujące problem i odporne na gwałt. Np. programming, motherfucker.

Powtarzam jak zwykle - SCRUM nie zastąpił Waterfalla, bo w praktyce nic takiego jak waterfall się nie odbywało (może gdzieś w mitycznych amerykańskich projektach rządowych). Dopiero SCRUMowcy takiego waterfalla wymyślili jako modelowego wroga systemu/ludu.

@jarekr000000: no dobrze, nie było (nie ma) Waterfalla ani SCRUMa; czy można określić jakiekolwiek konkretne metodyki, których używano (używa się)?

@Silv w wersji pro to używano modelu spiralnego. Po prawdzie to inkrementy mapują sie na sprinty. Bywało to nawet skodyfikowane jako np. RUP. Był agile: XP, FDD. A w wiekszosci januszsoftów dominowała metodyka BiN (bierz i napierdalaj).

Dzięki. Dałbym łapkę, ale to ostatnie…

@Silv: masz jeszcze V-model https://en.wikipedia.org/wiki/V-Model_(software_development)

@Silv: a to co Jarek powiedział o BiN to wbrew pozorom bardzo często stosowana praktyka (czy dobra/rozsądna, to osobna sprawa) i nie ma się co oburzać, że tak to nazwał.

@jarekr000000: no w wielu firmach Scrum to nic innego jak właśnie BiN...

@alagner: no ja wiem, ja bym tak tego nie nazwał, ale cóż. :)

v-model to jest w Vue... https://vuejs.org/v2/guide/forms.html#Text

Nie kumam. Nawet jeśli wszystkie firmy na świecie przestałyby korzystać ze Scruma, to samo w sobie nie znaczy że moja firma też ma.

@TomRiddle: odnosisz się do artykułu? Wydaje mi się, że jego grupa docelowa to więcej pomysłodawcy rozwiązań niż ich implementatorzy (= firmy).

Mi się wydaje że waterfall to jakieś '70 a '90 to już niektóre firmy robiły iteracyjnie Analiza -> Design -> Implementacja -> Testy i tak w cyklu np. 6 miechów, przynajmniej świta mi w głowie że MS tak robił. Trzeba też pamiętać że '90 to dystrybucja na dyskietkach i CD więc nie ma czegoś takiego że szybko naprawimy na produkcji, to co poszło na CD musiało działać. Pod tym względem model Scrumowy by się nie sprawdził bo trzeba było mieć solidną fazę (3 - 6 miechów) samych testów, by potem nie mieć fackupy z wycofywaniem CD.

Ogólnie Scrum i Sprinty to chomąto na programistów, wg mnie Scrum przyjmuje funkcje zarządcza, uciemiężajacą, mająca na celu wywoływać lekką presję,

to nie metodyka jest problemem ale jej błędna implementacja

Czekaj, jak to było? Socjalizm jest dobrym systemem, a wszystkie problemy są wynikiem wypaczania jego idei.

Haha, elegancko zgasiles

Niech fachowcom na budowie wprowadza Sprinty to zobaczą co się stanie xD prędzej budowa stanie niż Ci ludzie pozwolą sobie wejść na głowę, co ma aktualnie miejsce w IT

Już to widzę. Pierwszy sprint - przychodzi PO i mówi, że celem sprintu jest pokazanie klientowi szkieletu domu. Co prawda pracownicy łapią się za głowę i mówią, że to niemożliwe, mimo to niezłomny PO każe im zrobić "demo". No i robią to demo, przychodzi klient, a tam wylewka z samego piasku rozmieszanego z wodą, posklejane taśmą filary, okna ze stretcha kuchennego. PO obiecuje, że to wersja demo, że w kolejnej iteracji to poprawią, jednak w międzyczasie pojawia się kolejny sprint i uwaga... tak zgadliście dzieciaki - nowy cel sprintu. Otóż nowym celem sprintu tym razem już będzie podłączenie kanalizacji do naszej wersji demo. Pracownicy niby oburzeni, bo uwierzyli PO, że to zrobione na kolanie demo to tylko żeby pokazać klientowi, a potem zrobią jak należy, a nie końcowa wersja... ech, Ci naiwniacy :D

Żebyś wiedział że by tak było, niestety w IT teraz PMowie bardzo cisną programistów, jest presja, przez terminy i Estymaty z czapy, nigdy nie było takiej presji na dowożenie jaka jest teraz w IT

z tym scrumem to troche jak z komunizmem - "nigdy nie wprowadzono go poprawnie" więc nie możemy powiedzieć, że to system do 4 liter ;)

@kevin_sam_w_domu: jakby klient odbioru nie podpisał to by się skończyło :p

"scrum" czytane od tyłu brzmi jak Marks. Przypadek?

@kevin_sam_w_domu: a co jest złego w presji i wymaganiu dostarczania za zapłacone pieniądze?

No, w mobbingu nie ma nic złego, przecież pracodawca płaci :)

@.andy: Zapraszam na Przeprogramowanych, zróbmy dwie godziny rozmowy na temat Agile i Scruma - jak widać temat wciąż gorący (sprawdź priv).

tych rozmów już jest tyle że nigdy nic się nie zmieni xD jak jest projekt z góry wyceniony na np na 6 lub 12 msc pracy 5 programistów, to chociaż byś im wynajął hotele, ruletkę, masaże przez piękne kobiety to problem wciąż się sprowadza do tego, że nie da się urodzić w 6 msc dziecka przez 9 kobiet, nawet nie wiem jakie by fikołki robili, a na tym polega większość patologii w Scrumie, że upycha się kolanami to co można zrobić spokojnie w rok, półtora, ale jakiś PM nietechniczny w kontraktornii podpisał projekt MVP już po 6 msc, chcesz przykładów? odwiedź branżę gamedev gdzie też masz Scruma,

swoją drogą popracuj trochę w korpo projektowych/kontraktorniach, fabrykach kodu to zrozumiesz o czym mowie

@kevin_sam_w_domu: wiem wiem, spędziłem trochę ponad rok w takich klimatach ;) Aczkolwiek taki "reset" warto byłoby zrobić - nawet nie z przeświadczeniem jakiejkolwiek misji, ot po prostu celem szerzenia wiedzy innej niż ta "ludowa".

rozumiem, dzieki