Jak byłem SM, to w jednym zespole gdzie przeciągały się dayli, był wprowadzony stoper liczący w dół 2 min. To był czas żeby powiedzieć co wczoraj zrobiłeś żeby sprint poszedł do przodu i co dziś zrobisz i czy nie masz problemu. Jak były problemy to pamiętałem i po dayli rozmawiałem z programista Ew zapraszałem jeszcze 2-3 osoby. Dayli to spotkanie synchronizujące stan sprintu a nie przedstawienie technologiczne jak się zrobiło temat lub technicznie co dziś zrobię. Na spotkania zawsze do uczestników wysyłałem agendę z podziałem ile czadu mamy na jakiś problem i stoper na rzutniku. Każdy przygotował się przed spotkaniem bo wiedział co będzie, przemyślał tak ze nie wymyślał na gorąca, a reżim czasowy dyscyplinował przed schodzeniem z tematu. Nawet jak prezes był na spotkaniach to trzeba było go sprowadzać na ziemie, że to nie czas i miejsce o gadaniu o żaglach. SM musi mieć jaka i utrzymać porządek, bo praca to nie kawiarnia tylko mamy skupiać się na pracy a nie na spotkaniach i gadaniu. Ofc po jakimś czasie stopery stały się zbędne bo jazdy pamiętał ze czas leci, ale agendy zawsze były obowiązkowe. Osobiście unikam tez spotkań gdzie nie wiem po co i o czym dokładnie będzie. Czasami wystarczy asertywność a wszystkich spotkań w kalendarzu nie trzeba akceptować.
tymczasem na innym forum:
zostan programista
moja znajoma tylko zawsze grala w gierki, smialismy sie z niej ze ciekawe co po maturze bedzie robic, chyba tylko meza szukac bo inaczej to jedynie pilnowac dzieci albo sprzatac, teraz nawet w sklepie o wyksztalcenie pytaja.
a teraz zczajcie akcje, ze 2 lata po liceum wyjechala do uk do pracy jako programiska. z angielskiego ledwo zdawala, na informatyce doom3d no po prostu zero ambicji a dzisiaj sie dowiedzialem ze ona po roku pracy kupila w krakowie mieszkanie za gotowke. ja teraz zaczalem splacac 40 lat kredytu za moja kawalerke jak ten idiota a moglem po prostu wyjechac i udawac "specjaliste" w jakims zachodnim korpo
tl;dr - gamon gapiacy sie caly dzien w ekran zarabia wiecej niz ty
:D
co do samego scruma - wystarczy sie nauczyc go ignorowac i robic swoje, zwlaszcza w korpo :) nikt mi nie wmowi ze ludzie potrzebuja frameworka do tego zeby sie dogadac, najwydajniejszy korpo zespol w ktorym pracowalam to 5 programistow + 1 koles biznesowy z ktorym organizowane bylo jedno 10 minutowe spotkanie tygodniowo. mielismy delivery pare razy wieksze od typowego zespolu z sasiedztwa, nie mowiac o satysfakcji z pracy.
Do tego jeszcze co tygodniowe spotkania na wycenę trwające po 2-3h.
Czy ktoś może mi opisać jak wyglądają estymaty i wyceny w Agile i Scrumie?
Organizacja spotkania całego zespołu, który wspólnie przez 2-3h wycenia i ile zajmą zadania wydają się lekko mówiąc absurdem.
Mój znajomy mi opowiadał, że mieli identyczną sytuację u niego w firmie. Mały oddział zagranicznej firmy w dużym mieście.
Dziewczyna odbiera maile, zamawia bilety, kupuje snacki programistom i zamawia knajpy, w których jedzą obiady w sumie to jest po prostu takim "supportem" - Zarabia jakieś 8 tysięcy brutto na uop...
leczo napisał(a):
Mój znajomy mi opowiadał, że mieli identyczną sytuację u niego w firmie. Mały oddział zagranicznej firmy w dużym mieście.
Dziewczyna odbiera maile, zamawia bilety, kupuje snacki programistom i zamawia knajpy, w których jedzą obiady w sumie to jest po prostu takim "supportem" - Zarabia jakieś 8 tysięcy brutto na uop...
No a co Cię tak boli? Programiści zarabiają po 15 tysięcy brutto na uop, a są dla biznesu po prostu takim "supportem". Ich kompetencje to klikanie w komputer i przepisywanie na inny język czegoś, co w dokumentacji przygotował ktoś inny...
Bez scruma było źle, ze scrumem jest źle.
Nie jestem wielkim fanem całego procesu ale widzę i negatywne, i pozytywne elementy.
Dobry scrum master nie przeszkadza, bardzo dobry potrafi pomóc.
Co do tego ile zarabia - ilu z was opłaca tych ludzi z własnej kieszeni?
var napisał(a):
Co do tego ile zarabia - ilu z was opłaca tych ludzi z własnej kieszeni?
Prawie wszyscy?
Ale tak po prawdzie zarobki, mi ne przeszkadzają. Dramat ile Ci ludzie (z nudów) generują problemów.
Przykład: lubię dokumentować zadania w Jirze (czy czymkolwiek).
Kiedyś widziałem, że trzeba wrzucić jakieś 3 linijki poprawki w kodzie, który nie był bezpośrednio związany z mim zadaniem to
tworzyłem ticket jira i wpisywałem o co chodzi. Potem commit z numerem taska i mam historię dla przyszłych pokoleń - po co i dlaczego.
Teraz dostaje zakaz tworzenia ticketów, bo z każdym razem nie zgadza się jakiś epic, story nie tak zdokumentowane, nie te co trzeba estymacje itp.
Scrumowa policja (tak ich tu nazywamy) czuwa.
W związku z tym commity lecą przypisane do zupełnie innych zadań - potem ktoś za to podziękuje.
To akurat przykład z firmy gdzie jest patologia, ze scrumem mająca wspolnego tylko nazwę. Tak to typowo w korpo się kończy.
Ale nawet jak byłem w normalnym scrumie to oczywiście ktoś musiał te dodatki i reguły do jiry dorypać. Żeby było łatwiej. Więc nie miałem zakazu wrzucania tasków, a tylko musiałem się za każdym raczem chwilkę domeczyć :/
GutekSan napisał(a):
jarekr000000 napisał(a):
@GutekSan: zarzucasz mi nieprawdę, ale w sumie nie wiem w czym, bo gdzieś musiałbym skłamać, a nie widzę
gdziew Twoim poście.W pierwszej wersji chciałem Ci zarzucić nie "nieprawdę" a po prostu "bzdury", z tym że nie chciałem zaogniać tej dyskusji i zastąpiłem to słowo pierwszym lepszym eufemizmem, który mi przyszedł do głowy. Faktycznie, trudno przypisać obiektywną prawdę czy nieprawdę stwierdzeniom:
scrum to defokusacja od biznesualbowyciąganie ludzi z zespołów jest pożądane, natomiast bliżej im po prostu do zwykłych bzdur. Nie uznaję tych bzdur jednak jako przejaw głupoty, bardziej chęci pokazania zabawnej i prowokacyjnej kontrowersyjności.
Widzę, że jak ktoś ma inne zadanie o Scrumie, od Ciebie to znaczy, że musi być głupi, albo prowokator. Może zdrajca sprawy agilowej. Zapluty karzeł waterfalla.
IMO zdradzasz objawy religijności. Może czasem jadę po bandzie w pojedynczych wypowiedziach - wstawianych osobno (tak jak ta o braku szacunku do sm), ale starałem się normalnie dyskutować. To, że w każdej książce scruma stoi jak wół jak to agile i scrum zbliżają użytkowników i biznes - to nie znaczy, że tak faktycznie jest. Mam inne obserwacje.
Ze szczególnym uwzględnieniem Individuals and interactions over processes and tools, bo chyba nawet 20 lat temu - w czasam przed agile nie spotkałem ludzi tak mocno trzymających się procesów, jak w scrumowych teamach.
W każdym razie religijne podejście powoduje, ze nie bardzo jest sens dyskutować.
jarekr000000 napisał(a):
Widzę, że jak ktoś ma inne zadanie o Scrumie, od Ciebie to znaczy, że musi być głupi, albo prowokator. Może zdrajca sprawy agilowej. Zapluty karzeł waterfalla.
Nie znaczy, bo często ja sam mam inne zdanie od siebie samego ;). Za to mierzi mnie gdy widzę, że niektórzy są już tak przekonani o własnej mądrości, że mylą własne opinie z obiektywnymi faktami.
IMO zdradzasz objawy religijności.
Typowy numer - przykleić łatkę "religijnego oszołoma". To już Schopenhauer wymienił ten zabieg w swoich metodach erystycznych. Zabawne jak szybko to następuje, gdy tylko podrażni się czyjeś ego.
Nigdy nie zainicjowałem dyskusji o Scrumie. Większość z nich nawet omijam. Włączam się dopiero po kolejnym, nagrodzonym aplauzem forum dowodzie anegdotycznym na to, że Scrum jest zły, a który pokazuje po prostu albo niezrozumienie autora, albo bohatera anegdotki. To jest wg Ciebie objaw religijności? Że reaguję, gdy na moich oczach dość inteligentni ludzie poklepując się po pleckach wbijają sobie do głowy głupie stereotypy, wynikające często z jawnie manifestowanej pogardy wobec wszystkiego czym sami się nie zajmują, czyli tego co nie jest typowo techniczne w branży IT?
Może czasem jadę po bandzie w pojedynczych wypowiedziach - wstawianych osobno (tak jak ta o braku szacunku do sm), ale starałem się normalnie dyskutować.
Jak godzisz wewnętrznie "jechanie po bandzie", pisanie że ktoś "jest zerem" z normalną dyskusją?
To, że w każdej książce scruma stoi jak wół jak to agile i scrum zbliżają użytkowników i biznes - to nie znaczy, że tak faktycznie jest. Mam inne obserwacje.
Nawet najlepszy pomysł da się wprowadzić w życie tak by był koszmarem jeśli zabraknie zdrowego rozsądku. Przykład strajku włoskiego pokazuje, że robienie czegoś "jak należy" prowadzi często do paraliżu. A robienie "scrum by the book" jest w mojej opinii takim właśnie strajkiem włoskim.
Ze szczególnym uwzględnieniem
Individuals and interactions over processes and tools, bo chyba nawet 20 lat temu - w czasam przed agile nie spotkałem ludzi tak mocno trzymających się procesów, jak w scrumowych teamach.
Bo paradoksalnym błędem Scruma jest to, że został tak dokładnie opisany i sprocesowany, zamiast pozostać ideą. Oczywiście gdyby to nie nastąpiło, pies z kulawą nogą by o nim nie usłyszał, a tak to powstał wokół niego niezły biznes, który daje ludziom przekonanie, że Scrum ma odpowiedź na każde pytanie. Dlatego właśnie ludzie tak ściśle się go trzymają.
Ja się formalnych zasad nie trzymam. Przeczytałem kiedyś jakiś 10 minutowy wstęp do Scruma, byłem z kolegami na może 2 szkoleniach. Trochę mało jak na religijnego dogmatyka, nie? Za to trzymam się i bronię idei. Cały mój pogląd na jego temat wynika głównie z doświadczenia pracy w różnych projektach. Przez 10 lat pracowałem z kilkoma SM w różnych projektach, firmach, krajach. Żaden nie był głupi czy nieudolny, widziałem wkład każdego z nich. Widziałem też trochę marnowania czasu ale do tego prowadził zazwyczaj czyjś brak przygotowania, albo folgowanie sobie w gawędzeniu, a nie proces sam w sobie. I widziałem do czego prowadzi brak retro w sytuacji, gdy mamy do czynienia z autorytarnym kierownikiem.
Kiedyś widziałem, że trzeba wrzucić jakieś 3 linijki poprawki w kodzie, który nie był bezpośrednio związany z mim zadaniem to
tworzyłem ticket jira i wpisywałem o co chodzi. Potem commit z numerem taska i mam historię dla przyszłych pokoleń - po co i dlaczego. Teraz dostaje zakaz tworzenia ticketów, bo z każdym razem nie zgadza się jakiś epic, story nie tak zdokumentowane, nie te co trzeba estymacje itp.
I słusznie, bo sam w tym momencie propagujesz jakieś biurokratyczne kuriozum - tworzyć ticket na każdy commit? To nie commity mają być źródłem ticketów, tylko tickety commitów. A jak chcesz by uzasadnienie zmiany zostało dla potomności - od tego jest commit message. Przeglądając kod nikt nie będzie czytał historycznych ticketów.
Zastanawia mnie jakim cudem tak wielu z Was ukończyło ciężkie studia informatyczne, przebrnęło przez masę przedmiotów matematycznych, jakieś logiki, algebry i tak dalej, a jest tu tak wiele osób, które są w stanie skreślić całą metodykę pracy na podstawie argumentacji w rodzaju "a bo u nas coś tam". Ja bym się nie zdziwił jakby u większości z takich osób wdrażanie metod pracy było nie tylko nie-scrumem, ale też bardzo dalekie od nazwania tego Agilem. Robienie nieefektywnych durnot jest tak samo sprzeczne z głównymi założeniami Agile'a jak przepychanie się przez tłum ludzi i trącanie ich łokciami tylko dlatego, że zgodnie z savoir vivrem to facet powinien otworzyć drzwi, a z przodu tłumu akurat kobieta by była. No ludzie, rozsądku trochę.
Właśnie dlatego że ukończyliśmy te studia nie dajemy się nabrać na modne terminy które nic nie znaczą, tylko szukamy co kryje się pod powierzchnią
ToTomki napisał(a):
Zastanawia mnie jakim cudem tak wielu z Was ukończyło ciężkie studia informatyczne, przebrnęło przez masę przedmiotów matematycznych, jakieś logiki, algebry i tak dalej, a jest tu tak wiele osób, które są w stanie skreślić całą metodykę pracy na podstawie argumentacji w rodzaju "a bo u nas coś tam".
No właśnie dlatego.
Niektórzy ludzie żyją ideałami, iluzją i wyobrażeniami - są chodzącymi przykładami powiedzienia jeśli fakty przeczą teorii, to tym gorzej dla faktów. Tacy ludzie z gatunku komunizm okazał się klapą, bo tak naprawdę nigdy nie był wprowadzony, musimy spróbować jeszcze raz i na pewno się uda!
Inni z kolei jak widzą, że coś raz i drugi nie wychodzi, to nie próbują w kółko powtarzać tego samego licząc, że za setnym razem dostaną pożądany rezultat :P
Miang napisał(a):
Właśnie dlatego że ukończyliśmy te studia nie dajemy się nabrać na modne terminy które nic nie znaczą, tylko szukamy co kryje się pod powierzchnią
Ależ wcale nie szukacie! :) Większość z tu wypowiadających się patrzy tylko na scrumową obrzędowość, która faktycznie, przez nadgorliwych wyznawców bywa rozdmuchana ponad proporcje.
superdurszlak napisał(a):
Niektórzy ludzie żyją ideałami, iluzją i wyobrażeniami - są chodzącymi przykładami powiedzienia
jeśli fakty przeczą teorii, to tym gorzej dla faktów. Tacy ludzie z gatunkukomunizm okazał się klapą, bo tak naprawdę nigdy nie był wprowadzony, musimy spróbować jeszcze raz i na pewno się uda!Inni z kolei jak widzą, że coś raz i drugi nie wychodzi, to nie próbują w kółko powtarzać tego samego licząc, że za setnym razem dostaną pożądany rezultat :P
Ale wiesz, że ci co w kółko powtarzają, za 100-nym razem dostaną jednak ten pożądany rezultat? :D
Zapytaj się dowolnego muzyka, czy nie powtarzał czegoś w kółko 100 razy. A Edison ze 100 razy próbował zrobić żarówkę.
Powiesz mi, że to co innego. Nie, to jest to samo. Sekret polega na tym, że nigdy niczego nie powtarza się identycznie. Choćby dlatego, że fizycznie się nie da powtórzyć. Zawsze masz nieco inne warunki, coś zrobisz inaczej, użyjesz elementów o nieco innych parametrach. Na tym polega większość eksperymentów.
Co do wspomnianego przez Ciebie komunizmu - tak, okazał się klapą, choćby dlatego, że wyrósł z rewolucji, a rewolucje mają to do siebie, że po nich rządzą ci, co przeżyli. A to zazwyczaj oznacza jednostki najbardziej bezwzględne i pozbawione skrupułów, a nie najmądrzejsze. Co prawda komunizm zdefiniowany przez Marxa był ściśle związany z rewolucją, więc to go z gruntu skreśla. Jednak pod hasłem komunizm sporo osób ma na myśli każdą ideę lewicową, a tych akurat udało się parę wprowadzić z sukcesem. Wprowadzenie danego ustroju zależy w dużym stopniu od mentalności i dojrzałości społeczeństwa, jego doświadczeń i jego bogactwa. Czyli zawsze masz inne warunki. Jak będziesz wprowadzał socjalizm/komunizm tam gdzie ludzie byli od pokoleń okradani i są podszyci nieufnością, to będziesz miał klapę. Ale jak wprowadzisz idee lewicowe w kraju nie zniszczonym, w którym panuje duża empatia społeczna, to będziesz miał sukces jak w Szwecji. Podobnie jest z Agilem. Jak go wprowadzisz w firmie, w której panowała kultura obrzędów, biurokracji i marnowania czasu to będziesz miał obrządkowość, biurokrację i marnowanie czasu. A jak wprowadzisz w firmie, w której ludzie rozumieją po co się robi to co się robi, to będziesz miał efekty.
Wiecie co zreflektowałem się. Niech dzbany pracują za 15000 brutto co mi do tego ile firma chce płacić moderatorom spotkań. Natomiast moja wartość właśnie wzrosła i idę po podwyżkę. Jak dzbanom płacą tyle a mi nie dadzą więcej to czas zmienić firmę.
A ja ostatnio polubiłem scruma.
Przyszedł do mnie (nie fizycznie na szczęście, jeno na slacku) architekt frontendowców i powiedział, że potrzebują małej zmiany w sortowaniu po stronie API. (Zamiast po nazwie to po jakimś innym parametrze.)
No, więc powiedziałem architektowi, że sorry, ale my jesteśmy Agile™, my mamy Scruma™, wczoraj zaczęliśmy nowy sprint (to chyba nie ma™), mamy commitment™, no i sorry, ale nie możemy tego zrobić. Jak chce mieć wbitkę, to niech załatwia sobie z SM-BA. No i poszedł (w sensie też na slacku), jaka to była piękna awantura... miałem nadzieję, że się pozabijają, i będę wreszcie mógł normalnie pracować. Niestety nie przeszli do rękoczynów... :( Ale i tak było przyjemnie być świadkiem tego.
Architekt ostatecznie poszedł do PO, ten zatwierdził wbitkę, wszystko oczywiście musiało być zrobienie zgodnie z doskonałymi agilowymi procesami, powstało story w jira, ktoś je zaimplementował i w końcu trafiło na produkcję - dwa dni później niż by mogło, gdybyśmy nie byli Agile™. Wiwat elastyczność w imię produktywności!
To było pół linijki kodu, które za 30 minut mogło być na produkcji. Przynajmniej tak bym zrobił w normalnych warunkach, czyli wtedy, gdy mogę być elastyczny, realizować wymagania biznesowe i ułatwiać pracę innym. Bo ja wiem, czy coś można bezpiecznie zrobić ad-hoc, czy poświęcenie czasu na dany task zagrozi deadlinom ważniejszych zadań. Ja - programista, a nie PO, nie PM, nie SM, nie BA, ani nie banda juniorów grająca w planning pokera i udająca software development.
No, ale jak ktoś chce się bawić w metodologie i procesy, to niech się bawi. Ja tam nawet polubiłem obserwowanie tych małp w cyrku.
Dogmatyzm zaszkodzi nawet najlepszej metodologii. Jeśli wciągnięcie nieprzewidzianego, ale drobnego zadania do sprintu i założenie storki w Jirze pochłonęło dwa dni, to dla mnie coś jest nie tak z zespołem. To pachnie jakimś strajkiem włoskim albo pasywną agresją. Zwłaszcza skoro sam sugerujesz, że były jakieś awantury i zabijanie się.
Na takiej zasadzie można by przytoczyć historię, że Czesiek i Grzesiek dwa dni kłócili się, czy zmienną nazwać alpha, czy azimuth. I to dowodzi, że code review jest stratą czasu :)
Dodałbym, że widziałem niejeden fakap spowodowany taką właśnie "pół linijką", co ekspresowo lądowała na produkcji. Bo jeden kolega poprosił drugiego pomiędzy kawą a siusiu, i na tym się proces decyzyjny zamknął. Być może przez to jak nie jestem fanem biurokracji, tak entuzjastą takiego kowbojskiego podejścia - też niespecjalnym....
V-2 napisał(a):
Dogmatyzm zaszkodzi nawet najlepszej metodologii. Jeśli wciągnięcie nieprzewidzianego, ale drobnego zadania do sprintu i założenie storki w Jirze pochłonęło dwa dni, to dla mnie coś jest nie tak z zespołem.
Oczywiście, że jest coś nie tak. Jest w nim zbyt wielu fanów scruma, których kompetencje ograniczają się do bycia fanatykami scruma.
Na takiej zasadzie można by przytoczyć historię, że Czesiek i Grzesiek dwa dni kłócili się, czy zmienną nazwać alpha, czy azimuth. I to dowodzi, że code review jest stratą czasu :)
To zależy. Np. jeśli CR robi osoba nie znająca technologii albo biznesu to jest on stratą czasu.
I ja nie chcę udowadniać, że scrum jest stratą czasu. Takie udowadnianie jest stratą czasu. :) Jest fantastyczny, jeśli tylko umie się skierować dogmatyków przeciwko certyfikowanym fachowcom - wtedy normalni ludzie mogą spokojnie pracować. :)
Dodałbym, że widziałem niejeden fakap spowodowany taką właśnie "pół linijką", co ekspresowo lądowała na produkcji. Bo jeden kolega poprosił drugiego pomiędzy kawą a siusiu, i na tym się proces decyzyjny zamknął. Być może przez to jak nie jestem fanem biurokracji, tak entuzjastą takiego kowbojskiego podejścia - też niespecjalnym....
Wiesz, też widziałem takie fakapy. Tylko akurat rozłożenie produkcji przez zmianę sortowania w jakimś słowniku, który jest jednym z najmniej ważnych endpointów jest wysoce nieprawdopodobne.
somekind napisał(a):
V-2 napisał(a):
Dogmatyzm zaszkodzi nawet najlepszej metodologii. Jeśli wciągnięcie nieprzewidzianego, ale drobnego zadania do sprintu i założenie storki w Jirze pochłonęło dwa dni, to dla mnie coś jest nie tak z zespołem.
Oczywiście, że jest coś nie tak. Jest w nim zbyt wielu fanów scruma, których kompetencje ograniczają się do bycia fanatykami scruma.
Tylko że źle rozumianego. Mawia się na to zombie scrum.
https://www.scrum.org/resources/blog/zombie-scrum-symptoms-causes-and-treatment
Jak by nie było scrum jest metodyką agile, a tu jedna z pierwszych wyjściowych zasad mówi "individuals and interactions over processes and tools" (Agile Manifesto). Z tego, co opisałeś, można zrozumieć, że traktowano to dokładnie odwrotnie.
dwa dni później niż by mogło, gdybyśmy nie byli Agile™. Wiwat elastyczność w imię produktywności!
A byliście? Bo nie w rozumieniu Agile Manifesto. Więc to TM jest nieco naciągane. Raczej zawiodło was wasze edżajl; taka że tak powiem lokalna podróba :)
Nie zrozum mnie źle, piętnowanie takich patologii jest ze wszech miar słuszne, i nie twierdzę nawet, że to rzadkość. Tylko nie obwiniałbym za to scruma, bo wygląda mi to raczej na zjawisko z kategorii "cargo cult".
Dodałbym, że widziałem niejeden fakap spowodowany taką właśnie "pół linijką", co ekspresowo lądowała na produkcji. Bo jeden kolega poprosił drugiego pomiędzy kawą a siusiu, i na tym się proces decyzyjny zamknął. Być może przez to jak nie jestem fanem biurokracji, tak entuzjastą takiego kowbojskiego podejścia - też niespecjalnym....
Wiesz, też widziałem takie fakapy. Tylko akurat rozłożenie produkcji przez zmianę sortowania w jakimś słowniku, który jest jednym z najmniej ważnych endpointów jest wysoce nieprawdopodobne.
Pewnie tak. Tylko obawiam się, że to jest taka równia pochyła. Czlowiek to leniwa bestia, a chodzenie po skrótach bardzo wchodzi w krew. W środę wrzuci się coś absolutnie nieszkodliwego, w czwartek coś, co nie powinno nic popsuć, w piątek kod, który wygląda bezpiecznie. A w weekend rozpętają się ciekawostki :) Skoro zaś ma swoich fanatyków scrum, to podejście "na szybkiego Billa" też takich znajdzie...
Scrum ma sens jedynie jeśli faktycznie masz dowozić coś w miarę regularnych, ale niedużych interwałach. Takiej apki do AppStora nie zrobisz ContinousDelivery. Ale dla apek webowych tylko continous delivery, z DoD na produkcji. Więc po kij komu 'sprint' który powoduje tylko stratę czasu i usztywnianie się. Więc lepsze coś a'la Kanban.
V-2 napisał(a):
Jak by nie było scrum jest metodyką agile, a tu jedna z pierwszych wyjściowych zasad mówi "individuals and interactions over processes and tools" (Agile Manifesto).
Ale komu tak mówi? Bo na pewno nie korporacjom czy menadżerom, którzy wdrażają scruma bo w dzisiejszych czasach po prostu trzeba mieć scruma, bez względu na to, czy to ma sens, czy nie. Po prostu ma być scrum: planowanie, poker, standupy, retro i cały zestaw ról. Ale już jaki tego jest cel, to nikogo nie obchodzi. Ważne, że mamy scrum, więc jesteśmy agile.
A byliście? Bo nie w rozumieniu Agile Manifesto. Więc to TM jest nieco naciągane. Raczej zawiodło was wasze edżajl; taka że tak powiem lokalna podróba :)
Czy w tamtym moim poście było za mało drwiny i sarkazmu? Oczywiście, że podążając za utrudniającym pracę procesem nie jest się agile. Ale jest się korpoagile, a korpo to lubi.
My byliśmy bardzo agile (chociaż się tym nie chwaliliśmy, bo i po co?), zanim nie dowalono nam do teamu kilku gołębi, oraz naciskających na podejście scrumowe PM i BA. Nie mieliśmy planowań, retrospektyw, iteracji - i wszystko dowoziliśmy na długo przed jakimikolwiek deadlineami, mimo wielu wpadających pobocznych tasków. A jakiekolwiek problemy rozwiązywaliśmy na bieżąco - bo to jest najbardziej efektywny sposób rozwiązywania problemów, a nie czekanie dwa tygodnie na retro.
Nie zrozum mnie źle, piętnowanie takich patologii jest ze wszech miar słuszne, i nie twierdzę nawet, że to rzadkość. Tylko nie obwiniałbym za to scruma, bo wygląda mi to raczej na zjawisko z kategorii "cargo cult".
Owszem. Czyli tak jak scrum w praktyce wygląda w większości przypadków.
Pewnie tak. Tylko obawiam się, że to jest taka równia pochyła. Czlowiek to leniwa bestia, a chodzenie po skrótach bardzo wchodzi w krew. W środę wrzuci się coś absolutnie nieszkodliwego, w czwartek coś, co nie powinno nic popsuć, w piątek kod, który wygląda bezpiecznie. A w weekend rozpętają się ciekawostki :) Skoro zaś ma swoich fanatyków scrum, to podejście "na szybkiego Billa" też takich znajdzie...
Jesteś może managerem? Bo nie znasz sytuacji, biznesu, technologii, nie widziałeś kodu na oczy, a myślisz, że wiesz lepiej od gościa, który napisał połowę aplikacji.
Tam wszystko było oczywiste - trzeba zmienić pole, po którym sortowane są dane. To jest pół linijki kodu. Potem commit, review i testy na dwóch środowiskach. To po prostu malutka zmiana, a nie żadne chodzenie po skrótach.
Jeszcze jedna rzecz mnie ciekawi. Bo zastanawiałem siekiedy w ogóle Scrum jest użyteczny i wydawało mi się, że są takie rzadkie, ale jednak występujące przypadki. (i nawet kiedyś je na tym forum spisałem).
Ale nie uwzględniłem wtedy jednego - produkcji. Otóż w prawie każdym projekcie, w którym biorę udział mam pecha i trafiam na produkcję.
Pojawiają się wtedy realni użytkownicy i czesto się okazuje, że mają potrzeby inne niż PO, do tego jeszcze (o zgrozo) mamy błędy.
I co wtedy? Użytkownik Zenek właśnie sie pyta co się stało z jego danymi. Ma czekać dwa tygodnie, na koniec sprintu, żeby nie defokusować zespołu?
Ćwiczyłem różne rozwiązania, w tym to oczywiste, że był zespół rozwoju (Scrumowy) i zespół utrzymania (Kanban) - z tego wyszedł dopiero prawdziwy rak.
Walczyłem, żeby to ubić - jak zespół rozwoju coraz bardziej kładł lachę na jakąkolwiek jakość, bo przecież maintenance team przyjdzie i wyrówna... (byłem w zespole rezwoju :-) ). O dziwo retro nie pomagało.
Przeważnie ta produkcja (czasem jako pilot), pojawia się już po kilku miesiącach - powiedzmy trzech. Nawet jak projekt jest wieloletni. Więc na czysty, niezakłócany Scrum mało tego czasu zostaje :-(
Btw. nic mnie tak nie śmieszy jak zespoły scrumowe z 3-4 tygodniowymi sprintami. Robimy 3 sprinty i koniec projektu... Po co się w to nawet bawić? Moja dusza javowca ciężko akceptuje cykle ponad tygodniowe. Aczkolwiek, jakbym rył na glinianych tabliczkach w C - to bym tak długich cykli potrzebował.
A to i tak prosta sytuacja. Często jest tak, że robimy aplikację / serwis jedną z kilkudziesięciu składających się na produkcję. I w tych innych bywają pożary. I czasem trzeba przerzucić ludzi na gwałt. Dużo czasu zajęło mi przekonanie SMów i PO, że takie przerzucanie ma sens z wielu powodów.
Jaki jest sens dorabiać nowe ficzery do systemu, dla nowych klientów, jak produkcja (jeden z serwisów backendowych) się wali pod ciężarem obecnych i nie przyjmie już nikogo nowego.... Tu ciekawostka: przerzucanie okazało się rewelacyjne ze względu na wymianę wiedzy w firmie i zostało przyjęte jako norma. Planowe (lekkie( miksowanie ludzi co kilka miesięcy, oprócz tego ad hoc - przy pożarach.
Teraz, u jednego klienta, jestem w wielkim projekcie na kilkanaście pseudo-scrumowych zespołów. W zasadzie tylko my wylądowaliśmy na produkcji i tylko nam ten Scrum jakby przeszkadza. Cała reszta zespołów chyba jest szczęśliwa, niektórzy już chyba trzeci raz przepisują swój podsystem i kombinują pretekst, żeby przepisać po raz czwarty. Nigdy nie wlezą na produkcję to i Scrum jest zupełnie fajny. Btw. tak naprawdę to nie jest fajny - mają najgorszą odmianę/wynaturzenie korpo scruma z 2 godzinnymi spowiedziami zwanymi daily, od których puchna mi uszy, jeśli akurat przechodzę w pobliżu :-(
Ale policja scrumowa się ich nie czepia.
Sytuacja opisana wyżej przez @somekind przypomina mi zabawy dzieciaków we wciskanie przycisków windy na każdym piętrze wieżowca, a potem cieszenie japy gdy wszyscy pasażerowie psioczą. No kupa śmiechu! Bo po co tyle przycisków montowali, skoro ja mieszkam na pierwszym? A tak w ogóle to normalni ludzie chodzą schodami!
Scrum został wymyślony jako narzędzie obrony developerów przeciw zapędom kierownictwa i innych interest-holderów do obciążania ich nadmierną pracą. Oczywiście nie jest wielkim odkryciem, że prawie każde narzędzie obrony można wykorzystać do ataku, czy może w tym przypadku pasywnej agresji, co zostało nam zademonstrowane. Opisane sytuacje zdarzają się i mnie, pracuję w Scrumie i o dziwo, rozwiązanie trafia na produkcję jeszcze tego samego dnia. Bo chociaż mam świadomość, ze pod osłoną Scrumu mogę się przed taką wrzutką obronić, to tego nie robię, bo rozumiem że rozwiązanie jest ważne. Dorzucam wtedy zadanie do sprintu, zaburzając plan, albo czasem w ogóle go nie ujmuję, zwłaszcza gdy tak jak opisał somekind, jest to zadanie, które nie przekracza 1SP, czyli nie powinno naszych szacowań zaburzać. Czasem antycypujemy takie zdarzenia na planningu robiąc taski - placeholdery dla podobnych wrzutek. Zresztą Scrum też nie zakłada 100% efektywności, wiadomo, że ludzie idą na urlop, chorują, mają zebrania. Od tego właśnie jest velocity czyli miara efektywności. Gdy pojawi się coś priorytetowego, to się to robi, to zaburza velocity, a potem SM czy PO ma wskazówkę, że coś idzie nie tak, i przeciwdziała takim sytuacjom. No ale żeby do tego tak podejść to trzeba a) trochę pomyśleć b) mieć dobrą wolę c) nie być trollem d) nie cierpieć na autyzm.
somekind napisał(a):
Nie mieliśmy planowań
Niektórzy chyba dalej nie mają, albo grają na nich w węża, jeśli są takie sytuacje, że frontendowcy nagle się budzą, że potrzebna im jest jakaś zmiana w API (do wykonania sprintowego zadania jak mniemam, bo innymi nie powinni się zajmować, jeśli nie jest to awaryjna sytuacja z bugiem) ;) Czyli planowania nie zrobiono, albo zrobiono je na odwal.
jakiekolwiek problemy rozwiązywaliśmy na bieżąco - bo to jest najbardziej efektywny sposób rozwiązywania problemów, a nie czekanie dwa tygodnie na retro.
To znów jest nierozumienie tego, jak powinien działać scrum. Nie powinieneś obwiniać korporacji czy Bóg wie kogo o to, że sam nie odrobiłeś zadania domowego. Rozwiązywanie problemów nie ma być odwlekane do retro. Problemy się rozwiązuje w sprincie i na bieżąco. Retro służy identyfikacji problemów i sformułowaniu pewnych postanowień. Nie ma żadnego zakazu, by zająć się nimi wcześniej, jeżeli zidentyfikują sie same. Wręcz przeciwnie, należy to robić.
Nie zrozum mnie źle, piętnowanie takich patologii jest ze wszech miar słuszne, i nie twierdzę nawet, że to rzadkość. Tylko nie obwiniałbym za to scruma, bo wygląda mi to raczej na zjawisko z kategorii "cargo cult".
Owszem. Czyli tak jak scrum w praktyce wygląda w większości przypadków.
Na pewno w większości przypadków, gdy ktoś nie rozumie zasad scruma; i czemu trudno się dziwić.
Poza tym scruma chcesz oceniać mówiąc o tym, jak wygląda "w większości przypadków" (odkładając na bok, czy rzeczywiście tak jest) - niby sensownie.
No, a jak w większości przypadków sprawdza się taka praca prowadzona bez planowania, z "wieloma wpadającymi pobocznie taskami", improwizowana z dnia na dzień?
Otóż w typowym przypadku nie prowadzi ona do szczęśliwych rozwiązań na długo przed deadlinem, tylko do kumulacji długu technicznego i kompletnej niemożliwości biznesowego oszacowania, kiedy zadanie X będzie gotowe.
Gratuluję, że wasz przypadek typowy nie był, ale porównywanie z jednej strony scenariusza szczęśliwego, a z drugiej - wykoślawionego przez cargo cult, to chyba nie jest racjonalny sposób na porównanie dwóch różnych sposobów pracy.
Tam wszystko było oczywiste - trzeba zmienić pole, po którym sortowane są dane. To jest pół linijki kodu. Potem commit, review i testy na dwóch środowiskach. To po prostu malutka zmiana, a nie żadne chodzenie po skrótach.
W porządku. Przy normalnie prowadzonym scrumie wdrożenie takiej zmiany, w zgodzie z wszystkimi procedurami - założyć ticket, wciągnąć do sprintu, to wszystko - nie generuje dwóch dni opóźnienia.
GutekSan napisał(a):
Sytuacja opisana wyżej przez @somekind przypomina mi zabawy dzieciaków we wciskanie przycisków windy na każdym piętrze wieżowca, a potem cieszenie japy gdy wszyscy pasażerowie psioczą. No kupa śmiechu! Bo po co tyle przycisków montowali, skoro ja mieszkam na pierwszym? A tak w ogóle to normalni ludzie chodzą schodami!
Dziwaczna metafora, ale niech Ci będzie. A więc kontynując - jeżeli manager nakazuje Ci wciskać wszystkie przyciski zawsze po wejściu do windy, to tak robisz czy nie?
Scrum został wymyślony jako narzędzie obrony developerów przeciw zapędom kierownictwa i innych interest-holderów do obciążania ich nadmierną pracą.
Nie bardzo widzę czemu akrat Scrum miałby mnie przed tym chronić. Ja sobie bardzo dobrze daję z taką obroną radę sam.
Bo chociaż mam świadomość, ze pod osłoną Scrumu mogę się przed taką wrzutką obronić, to tego nie robię, bo rozumiem że rozwiązanie jest ważne. Dorzucam wtedy zadanie do sprintu, zaburzając plan, albo czasem w ogóle go nie ujmuję, zwłaszcza gdy tak jak opisał somekind, jest to zadanie, które nie przekracza 1SP, czyli nie powinno naszych szacowań zaburzać.
Czyli masz oficjalny zakaz wrzucania nowych tasków w trakcie sprintu, a i tak to robisz?
Od tego właśnie jest velocity czyli miara efektywności.
Fajnie. My nie mamy. No i ogólnie z wykresów wynika, że niczego nie robimy (bo większość tasków spada na następny sprint).
Gdy pojawi się coś priorytetowego, to się to robi, to zaburza velocity, a potem SM czy PO ma wskazówkę, że coś idzie nie tak, i przeciwdziała takim sytuacjom. No ale żeby do tego tak podejść to trzeba a) trochę pomyśleć b) mieć dobrą wolę c) nie być trollem d) nie cierpieć na autyzm.
To ja wybieram e) nie mieć scruma, wtedy punkty a-d realizują się automatycznie.
V-2 napisał(a):
Niektórzy chyba dalej nie mają, albo grają na nich w węża, jeśli są takie sytuacje, że frontendowcy nagle się budzą, że potrzebna im jest jakaś zmiana w API (do wykonania sprintowego zadania jak mniemam, bo innymi nie powinni się zajmować, jeśli nie jest to awaryjna sytuacja z bugiem) ;) Czyli planowania nie zrobiono, albo zrobiono je na odwal.
Nie mam pojęcia, co robią frontendowcy na swoich planowaniach. Może i masz rację, że grają w węża (tych akurat mają chyba pod dostatkiem). Ale mają oddzielnych SM i na pewno mają więcej spotkań, więc sa nawet bardziej agile od nas.
A w teamie złożonym z rozumiejących biznes i znających technologię programistów oraz BA, który dokładnie opisuje taski, nie trzeba spędzać kilku godzin na próbach odgadnięcia przy pomocy kart na kiedy da się zrobić taska.
To znów jest nierozumienie tego, jak powinien działać scrum. Nie powinieneś obwiniać korporacji czy Bóg wie kogo o to, że sam nie odrobiłeś zadania domowego.
Ale kto nie odrobił? Ja, nieustannie kpiący z tej patologii, czy managerowie, którzy wprowadzają mikromanagement wymieszany z waterfallem i nazywają go scrumem?
Na pewno w większości przypadków, gdy ktoś nie rozumie zasad scruma; i czemu trudno się dziwić.
Owszem, w większości przypadków góra wprowadzająca scruma do firmy nie rozumie jak to ma działać i stąd się biorą patologie.
Dlatego, jak już pisałem, gdy widzę że firma się chwali agilem i scrumem, to zakładam z dużą pewnością, że tak naprawdę mają szambo pokryte marketingiem.
No, a jak w większości przypadków sprawdza się taka praca prowadzona bez planowania, z "wieloma wpadającymi pobocznie taskami", improwizowana z dnia na dzień?
Ale ja nie pisałem o czymś takim. Ja pisałem o braku uświęconych scrumowych meetingów i agilowych procesów, a nie nie niezorganizowanej pracy. Jeśli dla Ciebie brak scruma oznacza automatycznie brak jakiegokolwiek planowania i improwizację, to jesteś fanatykiem.
Gratuluję, że wasz przypadek typowy nie był, ale porównywanie z jednej strony scenariusza szczęśliwego, a z drugiej - wykoślawionego przez cargo cult, to chyba nie jest racjonalny sposób na porównanie dwóch różnych sposobów pracy.
A czy racjonalne jest udawanie, że patogliczny korposcrum nie istnieje? Albo, że scrum jest jedyną drogą? Albo twierdzenie, ze skoro coś nie działa, to dlatego, że scrum nie został wdrożony, a jeśli coś działa, to dlatego, że został wdrożony podświadomie?
Ja wierzę, zarówno Tobie jak i @GutekSan, że gdzieś tam istnieje unicorn-scrum, który jest zgodny z ideą, wspaniale działa i developerzy są szczęśliwi, i Wy też. Ja piszę o tym, jakiego scruma sam widziałem, i moje odczucia sa jakoś zgodne z odczuciami wszystkich programistów, których znam osobiście. Była sobie zapewne szczytna idea, która została powszechnie zgwałcona i jej powszechny odbiór jest teraz inny niż twórcy zakładali.
somekind napisał(a):
na pewno mają więcej spotkań, więc sa nawet bardziej agile od nas.
Zero wspólnego ze scrumem
A w teamie złożonym z rozumiejących biznes i znających technologię programistów oraz BA, który dokładnie opisuje taski, nie trzeba spędzać kilku godzin na próbach odgadnięcia przy pomocy kart na kiedy da się zrobić taska.
Jeśli estymacje zajmują kilka godzin, niewiele ma to wspólnego ze scrumem
kto nie odrobił? Ja, nieustannie kpiący z tej patologii, czy managerowie, którzy wprowadzają mikromanagement wymieszany z waterfallem i nazywają go scrumem?
Ale ty też konsekwentnie nazywałeś to (w tym wątku) scrumem. Stąd moje uwagi
góra wprowadzająca scruma do firmy nie rozumie jak to ma działać i stąd się biorą patologie.
Od tego jest dół - i zasada samoorganizującego się zespołu - żeby się douczyć i ustawić to sobie dobrze, a nie pasywnie przyjmować błędy i wypaczenia góry.
Ja pisałem o braku uświęconych scrumowych meetingów i agilowych procesów
Procesy, którymi - jak wynika z twoich opisów - zastąpiono poprzedni model pracy, nie są agilowe!
A czy racjonalne jest udawanie, że patogliczny korposcrum nie istnieje?
Oczywiście że istnieje. Nieracjonalne jest jednak upieranie się - na podstawie wyłącznie doświadczeń anegdotycznych, z cyklu "ja i moi koledzy" - że ta patologia jest normą w całej branży.
Tymczasem zapewniasz konsekwentnie i gorąco, że tak jest "w większości",* "powszechnie"* itp.
A przeświadczenie to opierasz na tym, że tak jest u ciebie w firmie i u "programistów, których znasz osobiście". Rozumiem frustrację, ale nie bądźmy dziećmi :)
Albo, że scrum jest jedyną drogą?
Nikt tego nie twierdzi. Ma pewne oczywiste słabości i nie do każdej sytuacji się nada
Ja piszę o tym, jakiego scruma sam widziałem
Nie widziałeś żadnego scruma (w świetle tego, co mówią twoje własne wpisy)
V-2 napisał(a):
Zero wspólnego ze scrumem
Nadal nie łapiesz ironii? No cóż...
Jeśli estymacje zajmują kilka godzin, niewiele ma to wspólnego ze scrumem
Management zapłacił grubą kasę za szkolenia i certyfikaty, a Ty twierdzisz, że nie mają scruma. Powodzenia w przekonywaniu ich.
Ale ty też konsekwentnie nazywałeś to (w tym wątku) scrumem. Stąd moje uwagi
Management i scrummasterzy to konsekwentnie nazywa scrumem.
Przecież niemożliwe, żebym ja wiedział lepiej od certyfikowanych ekspertów czym jest scrum. Ty też zresztą nie wiesz. No chyba, że masz certyfikat.
Od tego jest dół - i zasada samoorganizującego się zespołu - żeby się douczyć i ustawić to sobie dobrze, a nie pasywnie przyjmować błędy i wypaczenia góry.
Co, jaka zasada? Nie po to zapłacili grubą kasę certyfikowanym konsultantom za wdrożenie scruma, żeby zespół miał sobie coś organizować.
Procesy, którymi - jak wynika z twoich opisów - zastąpiono poprzedni model pracy, nie są agilowe!
To tylko Twoja opinia. Fakty są takie, że sa agilowe, bo zostały wprowadzone przez fachowców od agile, za grubą kasę.
Nieracjonalne jest jednak upieranie się - na podstawie wyłącznie doświadczeń anegdotycznych, z cyklu "ja i moi koledzy" - że ta patologia jest normą w całej branży.
Jest Was w tym wątku dwóch obrońców scruma, cała reszta ludzi z różnych technologii, branż, państw ma dosyć sceptyczny stosunek i każdemu scrum kojarzy się z patologiami.
A przeświadczenie to opierasz na tym, że tak jest u ciebie w firmie i u "programistów, których znasz osobiście". Rozumiem frustrację, ale nie bądźmy dziećmi :)
Jaką frustrację? :| Ty wiesz, co to słowo w ogóle znaczy?
Nie widziałeś żadnego scruma (w świetle tego, co mówią twoje własne wpisy)
To tylko Twoja opinia. Managerowie wiedza lepiej za co zapłacili.
A teraz bez sarkazmu. Tak, to nie jest agile, to nie jest scrum, ale jest tak nazywane przez ludzi, którzy mają władzę i pieniądze. Trzeba być niezwykle naiwnym, aby wierzyć, że betonowych managerów wychowanych w biurokracji przekonasz racjonalnymi argumentami i faktami. Faktura z certyfikatem są ważniejsze od faktów.
No to jeszcze jeden sceptyk scruma.
Być może to nigdy nie był "prawdziwy scrum", ale zwykle im bardziej była podkreślana "scrumowatość" projektu tym większe poczucie BS miałem.
Nie wiem, może to ze mną coś nie tak, może to ja jestem rakiem, ale nie znoszę sztywnych ram, procesów, prób narzucania. Uważam, że w robieniu
software najwięcej zależy od zaangażowania, wiedzy i doświadczenia robotników. To nie jest fabryka gdzie jest mało istotne kto w danym momencie stoi
przy taśmie gdzie ważniejsze jest zarządzanie, proces. A ludzie jakoś tam zajarani scrumem mają często zwyczaj podkreślania świętości tego procesu,
co jest raczej śmiechu warte.
W zasadzie w scrumie nie odpowiada mi nic.
daily meetings - jeśli ktoś ma potrzebę wiedzieć czym zajmują się inni to może zobaczyć board w JIRZE czy innym toolu. Albo zapytać.
Jeśli ktoś ma problem i potrzebuje pomocy, to powinien to zgłosić. Jeśli jest potrzeba porozmawiać to się rozmawia.
Nie ma potrzeby rozmawiać codziennie o 10:00 - 10:15 w przeciwnym razie zamienia się to w farsę typu "ja wczoraj zrobiłem zadania nr 1234 i 4356, teraz robię 4728. No impediments",
której nikt nie słucha.
estymowanie / planowanie. Estymowanie jest trudne, to zawsze jest strzał. Programiści zmuszani do estymowanie zwykle dodają sobie zapas, co prowadzi do spadku wydajności.
Zresztą:
retro - to też dla mnie dziwny pomysł. Na problemy trzeba reagować wtedy kiedy występują.
To też najczęściej jest farsa. W ostatnim moim projekcie trzeba było śpiewać piosenkę jeśli nie miało się żadnych pomysłów. W innym kolega zawsze otwierał swoje notatki i czytał
co mu się nazbierało przez ostatni miesiąc.
Poza tym demokracja nie sprawdza się co do zasady. Byłem świadkiem sytuacji, w której grupa świeżaków przegłosowała jakieś idiotyzmy, z którymi fundamentalnie nie zgadzał się
najlepszy i najbardziej doświadczony programista w zespole. Koleś był zdecydowanie najważniejszą postacią w zespole i jego zaangażowanie było bezcenne. Ale cóż - zespół zadecydował,
koleś wyraźnie się z tym nie mógł zgodzić co spowodowało najpierw jego zniechęcenie a potem odejście.
itd, itd.
Ciekawe jest, że choćby ten wątek pokazuje sporą niechęć programistów do scruma. I nie jest to jakaś wyjątkowa sytuacja. Czasem robię test "agilowości scruma" - zwykle nie mam problemów
z przekonaniem kolegów do bezsensu tego czy tamtego elementu procesu ale sugestia żeby z tego zrezygnować zwykle jest nie do przyjęcia "bo to nie byłby scrum".
Czyli jednak process over people :D
Sytuacja opisana wyżej przez @somekind przypomina mi zabawy dzieciaków we wciskanie przycisków windy na każdym piętrze wieżowca, a potem cieszenie japy gdy wszyscy pasażerowie psioczą. No kupa śmiechu! Bo po co tyle przycisków montowali, skoro ja mieszkam na pierwszym? A tak w ogóle to normalni ludzie chodzą schodami!
Scrum został wymyślony jako narzędzie obrony developerów przeciw zapędom kierownictwa i innych interest-holderów do obciążania ich nadmierną pracą. Oczywiście nie jest wielkim odkryciem, że prawie każde narzędzie obrony można wykorzystać do ataku, czy może w tym przypadku pasywnej agresji, co zostało nam zademonstrowane. Opisane sytuacje zdarzają się i mnie, pracuję w Scrumie i o dziwo, rozwiązanie trafia na produkcję jeszcze tego samego dnia.
Bo chociaż mam świadomość, ze pod osłoną Scrumu mogę się przed taką wrzutką obronić, to tego nie robię, bo rozumiem że rozwiązanie jest ważne. Dorzucam wtedy zadanie do sprintu, zaburzając plan, albo czasem w ogóle go nie ujmuję, zwłaszcza gdy tak jak opisał somekind, jest to zadanie, które nie przekracza 1SP, czyli nie powinno naszych szacowań zaburzać.Czasem antycypujemy takie zdarzenia na planningu robiąc taski - placeholdery dla podobnych wrzutek. Zresztą Scrum też nie zakłada 100% efektywności, wiadomo, że ludzie idą na urlop, chorują, mają zebrania. Od tego właśnie jest velocity czyli miara efektywności. Gdy pojawi się coś priorytetowego, to się to robi, to zaburza velocity, a potem SM czy PO ma wskazówkę, że coś idzie nie tak, i przeciwdziała takim sytuacjom. No ale żeby do tego tak podejść to trzeba a) trochę pomyśleć b) mieć dobrą wolę c) nie być trollem d) nie cierpieć na autyzm.
Przeczytałem w połowie i już mi się podoba
poczekaj chwilkę, idę tylko fixnąć kilka wrzutko-bugów 4-5h, przełożyć taska z tamtego sprinta i zaraz doczytam
GutekSan napisał(a):
i. Gdy pojawi się coś priorytetowego, to się to robi, to zaburza velocity, a potem SM czy PO ma wskazówkę, że coś idzie nie tak, i przeciwdziała takim sytuacjom. No ale żeby do tego tak podejść to trzeba a) trochę pomyśleć b) mieć dobrą wolę c) nie być trollem d) nie cierpieć na autyzm.
I te zdania to kwintesencja jak dla mnie odjechania scrumowego. Nie chodzi o ten autyzm.
Gdy pojawi się coś priorytetowego to znaczy, że sie pojawiło coś priorytetowego, to nie oznacza, że coś idzie nie tak. To oznacza, że zmieniają się decyzje, a my elastycznie reagujemy.
Kiedyś coś takiego nazywało się agile.
Scrum został wymyślony jako narzędzie obrony developerów przeciw zapędom kierownictwa i innych interest-holderów do obciążania ich nadmierną pracą.
Tak samo można powiedzieć, że np. komunizm został wymyślony jako narzędzie obrony pracowników przeciw zapędom pracodawców i innych właścicieli kapitału do obciążania ich nadmierną pracą.
I pewnie w określonym momencie historycznym (XIX wiek, przemiany industrialne itp.) komunizm mógł mieć sens.
Tak jak pewnie Scrum mógł mieć sens w latach 80 czy 90 (przynajmniej tak wikipedia podaje, że wtedy się to zaczęło https://en.wikipedia.org/wiki/Scrum_(software_development) ), bo i ogólne praktyki wytwarzania w firmach były inne i ogólne zbiorowe doświadczenia programistów pewnie były inne, więc pewnie z jakichś względów tym ludziom, którzy wtedy pracowali już jako programiści, wydawało się słuszne (bo może wtedy było jeszcze gorzej?).
No ale teraz wiemy to, co wiemy, i że Scrum jest jak komunizm - czyli generuje więcej problemów niż rozwiązuje, więc to, co ludzie kiedyś nazywali "waterfallem", dzisiaj się nazywa Scrumem.
Więc oddajmy Scrum do muzeum, bo tam jest jego miejsce, podobnie jak np. miejsce popiersia Lenina.