Bardzo fajny tekst nt scruma. Jak słusznie zauważył autor, to nie metodyka jest problemem ale jej błędna implementacja.
Z jednej strony chcą być zwinni ale z drugiej chcą pracować jak dotychczas. To się niestety często nie udaje. Jeżeli taki PO nie ma wpływu na produkt i jest tylko dziewczynką do odbierania zamówień to z czym do ludzi?
Podobnie jest z developerami, którzy mają często z góry nałożone to z czego trzeba korzystać...Dostają też dedline ustalony przez osoby biznesowe, które nie mają o tym żadnego pojęcia.
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.
https://bulldogjob.pl/news/1674-czy-to-juz-rzeczywiscie-koniec-scruma
Sprawdź, dlaczego Scrum staje się coraz mniej popularny wśród specjalistów, a nawet całych organizacji.
https://bulldogjob.pl/news/1674-czy-to-juz-rzeczywiscie-koniec-scrumaNie 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...
@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ę.
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:
@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.
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).
@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ł.
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.
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
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: a co jest złego w presji i wymaganiu dostarczania za zapłacone pieniądze?
@.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".
alagnerJa 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.