Zostań Scrum Masterem

Ale ze Scrumem jest bardzo podobnie jak z Komunizmem. Jak nie działa to należy powiedzieć że to nie był prawdziwy Scrum/Komunizm tylko jakieś jego wypaczenie a potem próbować od nowa! :D

jarekr000000 napisał(a):

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.

Owszem, idzie nie tak. Plan idzie nie tak.
Plan jest podstawą jakiegokolwiek przedsięwzięcia. Plan zakłada wykonanie wszystkiego we właściwym czasie. Każde działanie zaplanowane dobrze ma większą szansę powodzenia niż zaplanowane źle.

Ty sobie tak lekko podchodzisz do zmieniających się decyzji, ale prawda jest taka, że decyzji nie zmienia się ot tak sobie, dla kaprysu, tylko zazwyczaj dlatego, że kogoś coś zaskoczyło, że czegoś w planie nie uwzględniono. I stąd właśnie bierze się większość priorytetowych zadań - ze wcześniejszego zaniedbania. Stąd, że komuś budującemu dom skończyły się cegły w połowie ściany, i musi lecieć i kupować zanim mu zaprawa stężeje, bo nie zadał sobie trudu by policzyć dokładnie ile mu potrzeba. Albo nie zabezpieczył ich, i mu ukradli. Może Ty i firmy, w których pracujesz macie wywalone na plany, przewidywania,a gaszenie pożarów to norma, w końcu jesteście "elastyczni". Tam gdzie ja pracuję przykłada się do tego wagę.

I to właśnie miałem na myśli, pisząc, że coś idzie nie tak. Bo wszystkiego przewidzieć się nie da. Ale jeśli regularnie 50% planu idzie się walić, przez zadania priorytetowe to jest to g. nie plan i trzeba sprawdzić czemu ciągle nas coś zaskakuje.

Shalom napisał(a):

Ale ze Scrumem jest bardzo podobnie jak z Komunizmem. Jak nie działa to należy powiedzieć że to nie był prawdziwy Scrum/Komunizm tylko jakieś jego wypaczenie a potem próbować od nowa! :D

Porównanie do komunizmu już padło w tym wątku, a ja już do tego porównania się ustosunkowałem. Nie jesteś na bieżąco.

somekind napisał(a):

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.

Oczywiście. Znowu argument w stylu: mnie nie potrzeba => nikomu nie potrzeba.

Czyli masz oficjalny zakaz wrzucania nowych tasków w trakcie sprintu, a i tak to robisz?

Nie mam takiego oficjalnego zakazu.

Od tego właśnie jest velocity czyli miara efektywności.

Fajnie. My nie mamy.

To już wasz problem.

GutekSan napisał(a):

I to właśnie miałem na myśli, pisząc, że coś idzie nie tak. Bo wszystkiego przewidzieć się nie da. Ale jeśli regularnie 50% planu idzie się walić, przez zadania priorytetowe to jest to g. nie plan i trzeba sprawdzić czemu ciągle nas coś zaskakuje.

Może was zaskakuje, mnie nie zaskakuje.
Ja po prostu już dawien dawna nie commituje się na żadne plany jak mam jakąs produkcję i prawdziwych użytkowników. Szkoda mi ich by było przez sprint zostawiać na lodzie.
W jednej firmie (przy starej wersji Scruma) SM wypowiadał nawet formułkę - czy wszyscy, z wyłączeniem Jarka, commitujecie się na cel sprintu (po niemiecku to było po prawdzie).
Duma 400%

@GutekSan: na forum są różne osoby. Większość z nich jest anonimowa, nie mamy pojęcia o tym, co sobą reprezentują. Ale akurat @jarekr000000 jest w pewnym sensie forumowym celebrytą - pracuje (i pracował wcześniej) w dość ambitnych miejscach, odwala prelekcje na konferencjach na całym świecie, jakieś książki popełnił. Dlatego do mnie zdecydowanie bardziej przemawia to, co on pisze, niż opinia jakiegoś korporacyjnego Scrum Mastera, którego przeszkolono na weekendowym kursie scrumowania i który się cieszy, bo ma pracę-ściemę za niezłą kasę. Wybacz, ale podważanie opinii Jarka jest trochę dziwne. Oczywiście - masz prawo, ale akurat ten człowiek wie, co mówi, nie jest to jakiś domorosły filozof, który obejrzał kilka filmów na YT i teraz zgrywa cwaniaka.

A porównanie tworzenia aplikacji z budową domu jest mocno chybione. Chciałbym napisać, że podczas budowy, jak masz projekt, to nie powinno być niespodzianek, ale to nie jest prawda. Można z grubsza zaplanować/przewidzieć ilość materiałów oraz potrzebny czas, przy czym i tak realnie będą pewne rozjazdy. Niemniej programowanie to nie budowa chatki, ale raczej chirurg usuwający guzy nowotworowe. Może mniej-więcej wiedzieć, czego się spodziewać, pewnie jakieś prześwietlenia wcześniej robił, ale dopiero gdy rozkroi pacjenta to widzi, co jest w środku, a także może ocenić zakres prac. Ale to też tylko na chwilę obecną, bo zaraz może się coś skomplikować, może pojawi się jakieś krwawienie albo znajdzie jeszcze jakieś przerzuty na innym narządzie. I to wcale nie świadczy o tym, że to zły lekarz, a jedynie wynika z charakteru jego pracy.

cerrato napisał(a):

Wybacz, ale podważanie opinii Jarka jest trochę dziwne.

Podważanie opinii Jarka i kogokolwiek jest jak najbardziej słuszne. Tu dyskutujemy na argumenty, a nie na doświadczenie i czyj TATO jest ważniejszy.

Shalom napisał(a):

Ale ze Scrumem jest bardzo podobnie jak z Komunizmem. Jak nie działa to należy powiedzieć że to nie był prawdziwy Scrum/Komunizm tylko jakieś jego wypaczenie a potem próbować od nowa! :D

Nie przeczytałeś całego tematu, prawda?

cerrato napisał(a):

@GutekSan: na forum są różne osoby. Większość z nich jest anonimowa, nie mamy pojęcia o tym, co sobą reprezentują. Ale akurat @jarekr000000 jest w pewnym sensie forumowym celebrytą - pracuje (i pracował wcześniej) w dość ambitnych miejscach, odwala prelekcje na konferencjach na całym świecie, jakieś książki popełnił. Dlatego do mnie zdecydowanie bardziej przemawia to, co on pisze, niż opinia jakiegoś korporacyjnego Scrum Mastera,

@cerrato: ale ja nie jestem żadnym Scrum Masterem, nie mam nawet żadnego certyfikatu. Pisałem zresztą o tym, przewidując, że taki argument padnie :)

Niech Cię przekonują argumenty, nie autorytet. Zwłaszcza, że @jarekr000000 jest może autorytetem w kwestiach języków programowania, ale nieznane mi są jego osiągnięcia w kwestii Agile'a. Zresztą gdyby tu nagle zaczął wypowiadać się taki Agile'owy odpowiednik Jarka, guru jeżdżący na Agile'owe konferencje na całym świecie, mający bogate doświadczenie i osiągnięcia, to i tak dla ludzi z tego forum byłby tylko "dzbanem".

Oczywiście - masz prawo, ale akurat ten człowiek wie, co mówi, nie jest to jakiś domorosły filozof, który obejrzał kilka filmów na YT i teraz zgrywa cwaniaka.

Czyli z faktu, że zna się np. na Javie, wnioskujesz od razu, że zna się na Agile'u? Na czym jeszcze wg Ciebie się zna? Na medycynie? Inwestowaniu? Botanice?

A porównanie tworzenia aplikacji z budową domu jest mocno chybione. Chciałbym napisać, że podczas budowy, jak masz projekt, to nie powinno być niespodzianek, ale to nie jest prawda. Można z grubsza zaplanować/przewidzieć ilość materiałów oraz potrzebny czas, przy czym i tak realnie będą pewne rozjazdy.

Oczywiście, że czasem tak bywa. Ale takie sytuacje to może 5% pracy. Ja pisałem o sytuacji, w której sytuacje priorytetowe dominują, ludzie są zmuszani do zmiany planu na każdym kroku, bo ciągle są czymś zaskakiwani.

Niemniej programowanie to nie budowa chatki, ale raczej chirurg usuwający guzy nowotworowe.

Nie zgodzę się.

Może mniej-więcej wiedzieć, czego się spodziewać, pewnie jakieś prześwietlenia wcześniej robił, ale dopiero gdy rozkroi pacjenta to widzi, co jest w środku, a także może ocenić zakres prac.

Co to za porównanie? Kod programu nie jest schowany pod skórą. Nie musisz mu dawać narkozy, żeby do niego zajrzeć i bać się, że się z niej nie wybudzi. Programista zazwyczaj może dowolnie zmodyfikować implementację z zachowaniem API, chirurg nie ma tego komfortu. Jeśli tak do tego podchodzisz, to po prostu nie znasz systemu nad którym pracujesz.

somekind napisał(a):

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.

Nie, było nas więcej: @ToTomki, @somedev. Zostali w którymś momencie zbluzgani przez zacietrzewionych przeciwników Scruma, więc nie dziwię się, że nie mają ochoty kontynuować tej dyskusji.

Ja zresztą nie uważam siebie za "obrońcę Scruma". Zacząłem jako obrońca retrospektywy i idei Agile'a, potem zakwestionowałem poglądy typu: Scrum to defokusacja od biznesu. Po chwili zaczęły się komentarze w stylu co też Scrum nie robi z ludzi, oto przykład Scrumowego odjechania, itp. Nie po raz pierwszy spotykam się z takim przyklejaniem łatki. Zdarzało mi się przy jakiejś dyskusji na innym forum wytknąć komuś atakującemu religię błąd logiczny, choć generalnie nie uważam się za religijną osobę. To jednak wystarczyło, by mnie wyzwano od "siorbiącego pytonga katabasom na kruchcie", itp. Najwyraźniej niektórzy lubią ulegać pokusie antagonizowania się, sądziłem jednak, że inteligentni ludzie są nieco bardziej na to odporni.

GutekSan napisał(a):

Oczywiście. Znowu argument w stylu: mnie nie potrzeba => nikomu nie potrzeba.

Bynajmniej, ja nie wnikam w to, co jest komuś potrzebne i nie oceniam cudzych działań. Opisuję wyłącznie swoje, bo ja wiem, co mi jest potrzebne.
A Ty próbujesz mi sprzedać korposcruma, więc przedstaw mi tego zalety.

Czyli masz oficjalny zakaz wrzucania nowych tasków w trakcie sprintu, a i tak to robisz?

Nie mam takiego oficjalnego zakazu.

To po co w ogóle porównujesz w takim razie dwie zupełnie różne sytuacje?

Fajnie. My nie mamy.

To już wasz problem.

Nie, to jest tylko i wyłącznie Twój problem, bo u nas to nikogo nie obchodzi, za wyjątkiem pary wyznawców scruma, którym się jakieś wykresy źle przecinają.
Wyrabiamy się na długo przed deadlinami, biznes dostaje ficzery na czas, a programiści generalnie mają plażę. Jedyne problemy ma dwóch zboczeńców od scruma i kilka osób z tego forum, które nie są w stanie ogarnać, że moja droga może być bliższa idei agile, niż scrum.

Nie sugerowałem że Ty @GutekSan jesteś SM, może trochę mi się niezręcznie napisało. Chodzi o to, że (jak zresztą już kilka osób w wątku pisało wcześniej) mając po dwóch stronach barykady SM'a, którego zadaniem oraz sensem istnienia jest udowodnić, że jest potrzebny, oraz wysokiej klasy fachowca, który twierdzi, że scrum to ściema - zdecydowanie łatwiej jest mi stanąć po stronie opcji numer 2.

"@jarekr000000 jest może autorytetem w kwestiach języków programowania, ale nieznane mi są jego osiągnięcia w kwestii Agile'a." mam wrażenie, że to był właśnie przykład samozaorania z Twojej strony ;) Bo tak naprawdę po co są te wszystkie scrumy i wynalazki pokrewne? Żeby programowanie szło dobrze. Więc skoro da się to robić dobrze (zdaniem niektórych - nawet lepiej) bez agile'owości, to po co to wprowadzać? Trochę mi się to kojarzy ze słynnym cytatem z Kisielewskiego " W socjalizmie ofiarnie pokonujemy trudności, których nie ma w innym ustroju", a ten przywołany przez Ciebie agilowy guru idealnie się wpasowuje w ten cytat - pokaże, jak można skrócić i uprościć procedury, których w ogóle by nie musiało być.

"Czyli z faktu, że zna się np. na Javie, wnioskujesz od razu, że zna się na Agile'u" - w żadnym wypadku takiego wniosku nie powinno się wyciągać. Owszem, z jego wypowiedzi można wywnioskować że miał parę razy z tym do czynienia, można także odnieść wrażenie, że ma do tego tematu dość sceptyczny stosunek ;) Ale nie o to chodzi, tylko o fakt, że można sobie doskonale radzić bez tych nowoczesnych wynalazków, które w najlepszym razie są niepotrzebne, a zdaniem wielu (większości?) osób tu piszących raczej dezorganizują prace, zamiast ją ułatwiać.

"pisałem o sytuacji, w której sytuacje priorytetowe dominują" - nie trzeba żadnego scruma angażować, żeby stwierdzić, że taka sytuacja jest niedobra i świadczy o kiepskim planowaniu w projekcie, niezależnie od tego, w jakiej technice jest prowadzony. Może się źle zrozumieliśmy (jeśli Ci wciskam w usta rzeczy, których nie miałeś na myśli, to przepraszam), ale ja odebrałem to, co pisałeś wcześniej prawie że na zasadzie, że chcesz mieć praktycznie wszystko ustalone z góry, w chwili rozpoczęcia projektu. Jeśli tak nie uważasz, to uznajmy, że tego wątku nie było ;)

"Co to za porównanie? Kod programu nie jest schowany pod skórą." - owszem, nie jest schowany, bo go póki co jeszcze wcale nie ma, dopiero powstaje. W międzyczasie ulegnie 20 razy zmianie, bo klient wpadnie na parę fajnych pomysłów, okaże się, że będzie jednak inna baza danych, a do tego jeszcze trzeba będzie zmienić wersję mobilną, bo właśnie google wypuścił nowego androida, na którym aplikacja się wiesza, bo zmienili jakieś uprawnienia ;) Podtrzymuję porównanie z chirurgiem. I przy tworzeniu aplikacji, i przy operacji można sobie z grubsza zgadywać co się stanie, ale i tu i tam masz tak wiele czynników, że praktycznie nierealne jest uwzględnienie wszystkiego. A nawet jeśli by się to jakimś cudem udało, to podczas pracy sytuacja może się mocno zmienić, a co za tym idzie zakres prac oraz termin ich wykonania.

somekind napisał(a):

GutekSan napisał(a):

Oczywiście. Znowu argument w stylu: mnie nie potrzeba => nikomu nie potrzeba.

Bynajmniej, ja nie wnikam w to, co jest komuś potrzebne i nie oceniam cudzych działań. Opisuję wyłącznie swoje, bo ja wiem, co mi jest potrzebne.

Ale sabotujesz procesy, które mogą mieć dla innych wartość.

A Ty próbujesz mi sprzedać korposcruma, więc przedstaw mi tego zalety.

niczego nie próbuję Ci sprzedać.

Czyli masz oficjalny zakaz wrzucania nowych tasków w trakcie sprintu, a i tak to robisz?

Nie mam takiego oficjalnego zakazu.

To po co w ogóle porównujesz w takim razie dwie zupełnie różne sytuacje?

Dlaczego różne? Z punktu widzenia zaistniałego problemu, sytuacje były tożsame. Różniły ją przyjęte zasady. Ale te zasady to nie jest coś na co nie ma się wpływu - to element kultury firmy, który wszyscy mogą współtworzyć. Pokazałem, że można przyjąć takie zasady, pozostając wiernym pewnej idei, że osiągnie się efekt korzystniejszy dla wszystkich.

Fajnie. My nie mamy.

To już wasz problem.

Nie, to jest tylko i wyłącznie Twój problem,

Mój? Mnie nie obchodzą wasze problemy.

cerrato napisał(a):

"@jarekr000000 jest może autorytetem w kwestiach języków programowania, ale nieznane mi są jego osiągnięcia w kwestii Agile'a." mam wrażenie, że to był właśnie przykład samozaorania z Twojej strony ;) Bo tak naprawdę po co są te wszystkie scrumy i wynalazki pokrewne? Żeby programowanie szło dobrze.

No właśnie nie tylko. Przede wszystkim, żeby biznes szedł dobrze, a nie programowanie. Popełniasz chyba ten sam błąd co większość na tym forum dla których "biznes programistyczny"=programowanie. Nie mam wątpliwości, że bez scruma programistom programowanie by szło wyśmienicie, tylko nie jestem przekonany co do jego efektów.

Więc skoro da się to robić dobrze (zdaniem niektórych - nawet lepiej) bez agile'owości, to po co to wprowadzać?

Scrumy i wszystkie wynalazki pokrewne są kompromisem w osiąganiu kilku celów na raz: temu by programowało się dobrze, temu by klient widział postępy prac i mógł korzystać możliwie szybko z efektów, żeby dało się przewidzieć termin zakończenia, i żeby cały proces był odporny na nieprzewidziane sytuacje. Ja wiem, że programiści chcieliby najlepiej żeby klient powiedział raz czego chce, a potem zamknął mordę i czekał aż artyści dadzą mu swoje dzieło, kiedy będą gotowi.

Trochę mi się to kojarzy ze słynnym cytatem z Kisielewskiego " W socjalizmie ofiarnie pokonujemy trudności, których nie ma w innym ustroju",

uwierz, że są. Tylko, że część zdążyła już o nich zapomnieć, albo nigdy nie doświadczyła.

a ten przywołany przez Ciebie agilowy guru idealnie się wpasowuje w ten cytat - pokaże, jak można skrócić i uprościć procedury, których w ogóle by nie musiało być.

Nie, ten agile'owy guru dopasuje procedury do ludzi w danym środowisku, żeby wszyscy byli możliwie zadowoleni: klienci, menedżerowie, pracownicy. Gdyby procedury dało się skrócić i uprościć uniwersalnie, to by to zrobiono. Cały problem polega na tym, że każda firma, dział w tej firmie, czy każdy zespół ma swoją osobowość i swoją kulturę. Są firmy, które robią proste i powtarzalne rzeczy, i takie, które mają projekty, przy których pracuje naraz 10 tys. osób. Są zespoły w których ludzie się dogadują, i takie w których się drażnią. Takie, w których ludzie mają dusze artystyczną i takie, w których są wyrobnikami. Nie da się stworzyć jednej metody pracy dla wszystkich.

"Czyli z faktu, że zna się np. na Javie, wnioskujesz od razu, że zna się na Agile'u" - w żadnym wypadku takiego wniosku nie powinno się wyciągać.

A wydaje mi się, że właśnie wyciągnąłeś taki wniosek.

Ale nie o to chodzi, tylko o fakt, że można sobie doskonale radzić bez tych nowoczesnych wynalazków, które w najlepszym razie są niepotrzebne, a zdaniem wielu (większości?) osób tu piszących raczej dezorganizują prace, zamiast ją ułatwiać.

Przekonanie o "niepotrzebności" tych wynalazków wynika z nieco wybujałego ego programistów i nieliczeniu się z potrzebami innych włączonych w ten biznes: klientów, menedżerów.

"Co to za porównanie? Kod programu nie jest schowany pod skórą." - owszem, nie jest schowany, bo go póki co jeszcze wcale nie ma, dopiero powstaje. W międzyczasie ulegnie 20 razy zmianie, bo klient wpadnie na parę fajnych pomysłów, okaże się, że będzie jednak inna baza danych, a do tego jeszcze trzeba będzie zmienić wersję mobilną, bo właśnie google wypuścił nowego androida, na którym aplikacja się wiesza, bo zmienili jakieś uprawnienia ;) Podtrzymuję porównanie z chirurgiem.

A ja podtrzymuje porównanie z budowaniem domu, bo analogiczne do opisanych przez Ciebie problemów prędzej będą miały miejsce na budowie niż na stole operacyjnym.

A jak to wygląda w innych krajach / większych firmach?

@Afish @katelx nie wiem kto jeszcze

GutekSan napisał(a):

Przekonanie o "niepotrzebności" tych wynalazków wynika z nieco wybujałego ego programistów i nieliczeniu się z potrzebami innych włączonych w ten biznes: klientów, menedżerów.

OT

Nie chce mi się włączać w całą tę dyskusję, ale wg mnie w punkt - na forum można zaobserwować to zjawisko wybujałego ego co poniektórych osób.
Niektórzy tutaj (nie w tej dyskusji - ogólnie) chyba zapominają po co ktoś nas w ogóle zatrudnia - żeby zbudować, dostarczyć i utrzymywać produkt.

Mam wrażenie, że duża część osób ze środowiska ma podejście typu, że oni do pracy chodzą się bawić jak do piaskownicy np. coraz nowszymi zabawkami, a reszta jest po to żeby im tę 8 godzinną zabawę finansować (i broń boże nic nie zmieniać, nie wtrącać się i nie narzucać - bo programista, zbawca świata, strzeli focha). Jak się programista znudzi, albo skopie projekt, to wtedy najwyżej ucieknie do innej firmy. Zero ryzyka przecież w naszym zawodzie, co nie?

Odnoszę wrażenie, że niektórym brakuje tutaj empatii, wyjścia ze swojego ego i spojrzenia z innej perspektywy.
Perspektywy np indywidualnego klienta, który inwestuje własne pieniądze ponieważ chce mieć gotowy produkt - jakieś urzeczywistnienie swojej idei/pomysłów.

Jego nie interesuje czy programista lubi zmiany, czy lubi scruma, albo czy chce spróbować hiper nowego framweorka w Kotlinie/Scali/Ceylonie napisanego przez 2 studentów po godzinach. On chce dostać stabilne rozwiązanie, za które płaci ciężkie pieniądze. Chce stabilnych rozwiązań i procesów. Nikt nas nie zatrudnia po to, żebyśmy się dobrze bawili.

Więcej empatii i spojrzenia z kilku perspektyw, a mniej podejścia typu "Jestem super programistą, wszystko jest gówniane, leave me alone albo ucieknę do innej firmy!", które widzę już w którymś z kolei wątku.

EOT

GutekSan napisał(a):

Ale sabotujesz procesy, które mogą mieć dla innych wartość.

Niczego nie sabotuję, działam dla dobra projektu. Ty tylko ignorujesz kontekst i skupiasz się na tym, że ja krzywdzę Twojego scruma, a nie interesuje Cię po co w ogóle tworzony jest soft i kto tak naprawdę się tym zajmuje.

niczego nie próbuję Ci sprzedać.

Czemu zatem piszesz elaboraty na temat wybitnej przydatności Scruma w życiu każdego programisty?
I czemu nie odpowiedziałeś na proste pytanie, czemu akurat Scrum ma to zapewnić, a nie coś innego? Czemu ludzie nie mogą sami sobie ułożyć jakiegoś procesu, bez udziału certyfikowanych mistrzów młyna?

Dlaczego różne? Z punktu widzenia zaistniałego problemu, sytuacje były tożsame. Różniły ją przyjęte zasady.

Aha, istnienie zakazu i brak zakazu to tożsame sytuacje. Muszę sobie zapamiętać. :)

Ale te zasady to nie jest coś na co nie ma się wpływu - to element kultury firmy, który wszyscy mogą współtworzyć.

Jesteś totalnie oderwany od rzeczywistości i bardzo niedoświadczony, skoro uważasz, że w każdej firmie jest to możliwe.

Pokazałem, że można przyjąć takie zasady, pozostając wiernym pewnej idei, że osiągnie się efekt korzystniejszy dla wszystkich.

Oczywiście, można. A wiesz co trzeba zrobić, żeby to osiągnąć? Usunąć z projektu pasożyty, które wprowadzają idiotyczne procesy zamiast dążyć do wytworzenia softu zgodnie z oczekiwaniami użytkowników i terminami oczekiwanymi przez biznes. Czyli wymyślających głupie zasady i zakazy oszołomów korposcruma.

Mój? Mnie nie obchodzą wasze problemy.

Jak to nie? :D Przecież tylko Ty twierdzisz, że w ogóle jakiś problem jest. :D

Zacznij może wreszcie czytać, co się do Ciebie pisze i zrozum, że nie każda firma i zespół są takie jak Twoje. W betonowej korpo-kulturze scrum też jest betonowy. Liczą się wykresy, procesy i faktury za certyfikaty, a nie jakieś tam agilowe ideały, które management ma gdzieś.

GutekSan napisał(a):

(...)Niech Cię przekonują argumenty, nie autorytet. Zwłaszcza, że @jarekr000000 jest może autorytetem w kwestiach języków programowania, ale nieznane mi są jego osiągnięcia w kwestii Agile'a.

Czy ktoś mi wyjaśni czym są osiągnięcia w kwestii Agile'a? W sensie jak się tym pochwalić, gdyby się takowe miało?

TurkucPodjadek napisał(a):

GutekSan napisał(a):

(...)Niech Cię przekonują argumenty, nie autorytet. Zwłaszcza, że @jarekr000000 jest może autorytetem w kwestiach języków programowania, ale nieznane mi są jego osiągnięcia w kwestii Agile'a.

Czy ktoś mi wyjaśni czym są osiągnięcia w kwestii Agile'a? W sensie jak się tym pochwalić, gdyby się takowe miało?

A czym są osiągnięcia w kwestii wiedzy programistycznej?
Pochwalić się możesz tak samo jak wszystkim innym, czyli gadając o tym na lewo i prawo, wpisując sobie coś w CV, etc.

GutekSan napisał(a):

jarekr000000 napisał(a):

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.

Owszem, idzie nie tak. Plan idzie nie tak.
Plan jest podstawą jakiegokolwiek przedsięwzięcia. Plan zakłada wykonanie wszystkiego we właściwym czasie. Każde działanie zaplanowane dobrze ma większą szansę powodzenia niż zaplanowane źle.

Ty sobie tak lekko podchodzisz do zmieniających się decyzji, ale prawda jest taka, że decyzji nie zmienia się ot tak sobie, dla kaprysu, tylko zazwyczaj dlatego, że kogoś coś zaskoczyło, że czegoś w planie nie uwzględniono. I stąd właśnie bierze się większość priorytetowych zadań - ze wcześniejszego zaniedbania. Stąd, że komuś budującemu dom skończyły się cegły w połowie ściany, i musi lecieć i kupować zanim mu zaprawa stężeje, bo nie zadał sobie trudu by policzyć dokładnie ile mu potrzeba. Albo nie zabezpieczył ich, i mu ukradli. Może Ty i firmy, w których pracujesz macie wywalone na plany, przewidywania,a gaszenie pożarów to norma, w końcu jesteście "elastyczni". Tam gdzie ja pracuję przykłada się do tego wagę.

I to właśnie miałem na myśli, pisząc, że coś idzie nie tak. Bo wszystkiego przewidzieć się nie da. Ale jeśli regularnie 50% planu idzie się walić, przez zadania priorytetowe to jest to g. nie plan i trzeba sprawdzić czemu ciągle nas coś zaskakuje.

Nie mogę się z Wami Panowie zgodzić co do priorytetów. Tutaj podzielam zdanie z @jarekr000000 . Zmiana priorytetów nie oznacza, że planowanie jest złe, oznacza, że coś się zmienia i należy się do tego dostosować.
Najbliższy przykład z mojego otoczenia - pracujemy dla naszego klienta, nagle on podpisuje kontrakt z nowym klientem na miliony. Ten jeden klient będzie dostarczał więcej zysku dla naszego klienta niż wszyscy pozostali. Natomiast ten klient ma dużo różnych wymagań i trzeba zrobić dużo integracji. Nie mogliśmy rozpocząć prac dopóki nie będzie podpisanego kontraktu. Teraz 90% zespołu musiało przerwać swoje zadania, które nawet były planowane na 1 miesiąc i zająć się nowym klientem.
W tym przypadku mamy po prostu zmieniającą się sytuację i suckes. Biznes bardzo szybko potrafi się zmieniać i nie wynika to tylko dlatego, że coś nie jest planowane, albo coś wybuchło na produkcji.

Po prostu tak jest i musimy jako wykonawcy umieć się do tego dostosować. To jest w moim rozumieniu dopiero Agile'a, jak jesteście w stanie z dnia na dzień zmienić kierunek.

somekind napisał(a):

GutekSan napisał(a):

Ale sabotujesz procesy, które mogą mieć dla innych wartość.

Niczego nie sabotuję, działam dla dobra projektu.

niczego nie próbuję Ci sprzedać.

I znowu to przekonanie, że "to co dobre dla mnie, dobre dla projektu". Skończ z tym cynizmem. Dałeś przykład, w którym sam przyznałeś, że pod osłoną procesu opóźniłeś dostarczenie czegoś tam, co jak sami pisałeś mogłeś zrobić w pół godziny. To jest właśnie sabotaż, tylko czystymi rączkami.

Ty tylko ignorujesz kontekst i skupiasz się na tym, że ja krzywdzę Twojego scruma, a nie interesuje Cię po co w ogóle tworzony jest soft i kto tak naprawdę się tym zajmuje.

Mam gdzieś czy krzywdzisz scruma czy nie, który zresztą nigdy nie był "mój". A tworzenie softu nie interesuje mnie tak bardzo jak tworzenie rozwiązań problemów, co z kolei nie interesuje Ciebie.

Czemu zatem piszesz elaboraty na temat wybitnej przydatności Scruma w życiu każdego programisty?

Prostuję jedynie głupie przekonania, które uroiły się programistom z klapkami na oczach.

I czemu nie odpowiedziałeś na proste pytanie, czemu akurat Scrum ma to zapewnić, a nie coś innego?

Nigdzie nie twierdziłem, że tylko Scrum ma to zapewnić. Zresztą napisałem już wcześniej. Nie jestem w tej dyskusji "obrońcą Scruma". Broniłem głównie idei Agile i wyjaśniałem celowość pewnych elementów Scruma, co do których padły zarzuty. To wystarczyło Tobie i paru innym osobom do przyklejenia mi łatki obrońcy Scruma. Tak już jest jak ktoś nie umie polemizować z opiniami, tylko polemizuje z ludźmi. Potrzebuje wtedy jakiś stereotypowy model przeciwnika: (np. "lewaka", "religijnego oszołoma", "obrońcy scruma") z którym umie jako tako walczyć, a przy okazji można mu czasem zaserwować wycieczkę osobistą. A że ten ktoś nie pasuje do stereotypu? Trudno, to się go dopasuje...

Czemu ludzie nie mogą sami sobie ułożyć jakiegoś procesu, bez udziału certyfikowanych mistrzów młyna

Jak potrafią, niech układają. Problem w tym, że programiści zazwyczaj nie potrafią zrobić tego tak, żeby zadowolić wszystkich poza sobą.

Dlaczego różne? Z punktu widzenia zaistniałego problemu, sytuacje były tożsame. Różniły ją przyjęte zasady.

Aha, istnienie zakazu i brak zakazu to tożsame sytuacje. Muszę sobie zapamiętać. :)

Czytaj ze zrozumieniem. Napisałem różne z punktu widzenia problemu. Problem w obu przypadkach był identyczny - nagła potrzeba naprawienia czegoś. Różne było podejście do Agile. To sobie zapamiętaj...

Ale te zasady to nie jest coś na co nie ma się wpływu - to element kultury firmy, który wszyscy mogą współtworzyć.

Jesteś totalnie oderwany od rzeczywistości i bardzo niedoświadczony, skoro uważasz, że w każdej firmie jest to możliwe.

Jak ci kultura i charakter firmy czy zespołu nie pasują i nie możesz go współtworzyć to i tak jedynym sensownym wyjściem jest odejście.

Jak to nie? :D Przecież tylko Ty twierdzisz, że w ogóle jakiś problem jest. :D

coś sobie dopowiadasz. Ja pokazuję co można robić gdy jakieś problemy są. Ty rób co ci się podoba.

Zacznij może wreszcie czytać, co się do Ciebie pisze i zrozum, że nie każda firma i zespół są takie jak Twoje. W betonowej korpo-kulturze scrum też jest betonowy. Liczą się wykresy, procesy i faktury za certyfikaty, a nie jakieś tam agilowe ideały, które management ma gdzieś.

Współczuję środowiska pracy.

Wprowadzacie chaos semantyczny.

Agile <> Scrum

nawet jeśli uznać Scrum za metodykę Agile, choć nie wiem jak to możliwe bo Scrum jako ściśle zdefiniowany proces przeczy pierwszemu i najważniejszemu punktowi Agile Manifesto: Individuals and interactions over processes and tools, to scrum może być co najwyżej jednym z podejść do Agile.

Sama idea Agile jest jak najbardziej ok. Scrum moim zdaniem nie.
Dla mnie pięknym wcieleniem Agile było XP (Extreme programming).

Mój znajomy był kiedyś SM. Zarabiał więcej niż większość znanych mi wówczas developerów, pracował 2x w tygodniu po około 40min (jakieś dwa spotkania reszta to było oglądanie youtube w pracy albo praca zdalna gdzie chodził sobie na piwo w czasie pracy). Śmiał się generalnie sam z tego, że płacą mu za nic (był osobą kompletnie nietechniczną). Jak by tego było mało pracując w ten sposób znalazł następnych jeleni i przez około 7-8 miesięcy doił dwie fimy na kontrakcie zgarniając po około 35 tys miesięcznie.

Gdybym go nie znał może uwierzyłbym w sens tej roli ale w rzeczywistości to dymanie prosto w pupsko firmy i dojenie. Te historyjki jaki to scrum nie jest potrzebny itp. są tak śmieszne, że najlepiej podsumował to jakiś koleś poprzednio - jak taki SM idzie na urlop nikt nawet nie zauważa tego.

MuadibAtrides napisał(a):

Nie mogę się z Wami Panowie zgodzić co do priorytetów. Tutaj podzielam zdanie z @jarekr000000 . Zmiana priorytetów nie oznacza, że planowanie jest złe, oznacza, że coś się zmienia i należy się do tego dostosować.
Najbliższy przykład z mojego otoczenia - pracujemy dla naszego klienta, nagle on podpisuje kontrakt z nowym klientem na miliony. Ten jeden klient będzie dostarczał więcej zysku dla naszego klienta niż wszyscy pozostali. Natomiast ten klient ma dużo różnych wymagań i trzeba zrobić dużo integracji. Nie mogliśmy rozpocząć prac dopóki nie będzie podpisanego kontraktu. Teraz 90% zespołu musiało przerwać swoje zadania, które nawet były planowane na 1 miesiąc i zająć się nowym klientem.
W tym przypadku mamy po prostu zmieniającą się sytuację i suckes. Biznes bardzo szybko potrafi się zmieniać i nie wynika to tylko dlatego, że coś nie jest planowane, albo coś wybuchło na produkcji.

Po prostu tak jest i musimy jako wykonawcy umieć się do tego dostosować. To jest w moim rozumieniu dopiero Agile'a, jak jesteście w stanie z dnia na dzień zmienić kierunek.

W kwestiach, które opisałeś generalnie się zgadzam. Wszystkiego przewidzieć się nie da. Chodzi mi tylko o to, żeby pod płaszczykiem tego hasła nie zaniedbywać planowania i przewidywania. Ja od początku pisałem o sytuacjach, kiedy odkrywamy, że tych niespodzianek jest wyjątkowo dużo, i one praktycznie paraliżują realizację planu, i do tego odnosiłem pisząc, że "coś jest nie tak", na co Jarek stwierdził, że jak najbardziej wszystko jest wporzo, bo przecież wszystko się zmienia. Co w sumie może oznaczać, że jak przystąpiliśmy do budowy chatki, zebraliśmy na to fundusze, materiały i ludzi, a w momencie malowania ścian doszliśmy do wniosku, że jednak chcemy pałac, to jest to zupełnie normalne i oczekiwane. No sorry, ale dla mnie nie jest i jeśli ktoś popiera taki system pracy, to się nie dogadamy.

Ale developerzy wytwarzają produkt - kod dzięki któremu właśnie działalność gospodarcza może funkcjonować i z którego osiąga się przychód. Niezależnie, czy to metodologia pracy taka czy inna, czy ktoś pracuje w 100 osób czy w 1 produkt, który się sprzedaje klientowi to kod (program). Bez tego nie ma biznesu. Jak wywalisz developerów to twoja firma nie funkcjonuje bo nie ma co sprzedawać. A jak wywalisz jakieś scrum wynalazki to możesz nadal funkcjonować ale w inny sposób, lepiej, gorzej, inaczej ale nadal. To taka subtelna różnica.

GutekSan napisał(a):

I znowu to przekonanie, że "to co dobre dla mnie, dobre dla projektu". Skończ z tym cynizmem.

Ja nie mam takiego przekonania, Scrumowcy za to jak widać nim epatują.
Ja po prostu znam sytuację i projekt, więc wiem jakie metodologie pasują, i wiem jak w tym akurat przypadku zorganizować pracę efektywnie. Ja nigdzie nie negowałem, że w jakiś tam projektach gdzieś Scrum może dawać korzyści. Może nawet taki w pełni procesowy, zbiurokratyzowany wykresowo-certyfikatowy też komuś daje korzyści.

Dałeś przykład, w którym sam przyznałeś, że pod osłoną procesu opóźniłeś dostarczenie czegoś tam, co jak sami pisałeś mogłeś zrobić w pół godziny. To jest właśnie sabotaż, tylko czystymi rączkami.

To, że to było wykonalne, nie znaczy, że mogłem to zrobić. Nie mogłem, bo jest proces i reguły.
A, że to jest złe dla projektu? Owszem, ale to nie moja wina tylko tych, którzy je ustalają.
I jest to bardzo dobre w dłuższej perspektywie. Bo teraz można ludziom od produktu uzmysłowić, że w zespole zostały wprowadzone szkodliwe procesy i reguły, więc trzeba się scrumowych szkodników pozbyć.

A tworzenie softu nie interesuje mnie tak bardzo jak tworzenie rozwiązań problemów, co z kolei nie interesuje Ciebie.

Jestem programistą, więc rozwiązuję problemy tworząc soft.

Tak już jest jak ktoś nie umie polemizować z opiniami, tylko polemizuje z ludźmi. Potrzebuje wtedy jakiś stereotypowy model przeciwnika: (np. "lewaka", "religijnego oszołoma", "obrońcy scruma") z którym umie jako tako walczyć, a przy okazji można mu czasem zaserwować wycieczkę osobistą.

Napisał człowiek, który na dzień dobry porównał mnie do dzieciaka bawiącego się przyciskami w windzie, i który nie odpowiada na 2/3 zadanych mu pytań, albo odpowiada na nie pytaniami.

Jak potrafią, niech układają. Problem w tym, że programiści zazwyczaj nie potrafią zrobić tego tak, żeby zadowolić wszystkich poza sobą.

Współczuję programistów.

Jak ci kultura i charakter firmy czy zespołu nie pasują i nie możesz go współtworzyć to i tak jedynym sensownym wyjściem jest odejście.

No i znowu udzielasz rad niepytany. :) A na konkretne pytania nie odpowiadasz.

coś sobie dopowiadasz. Ja pokazuję co można robić gdy jakieś problemy są. Ty rób co ci się podoba.

Nie pamiętasz nawet tego, co sam napisałeś kilkanaście godzin temu: Zostań Scrum Masterem

Współczuję środowiska pracy.

Nie masz współczuć. Masz zrozumieć, że są różne firmy i sytuacje. Że kultura jednego zespołu w firmie, może być zupełnie rożna od kultury innych zespołów. Że zbiurokratyzowany Scrum może być używany przeciwko developerom. Że można wprowadzać scrumowe procesy zupełnie sprzeczne z ideą agile. I to nie znaczy, że developerzy mają klapki na oczach, bo jakby mieli, to by tego nie widzieli i nie krytykowali w tym wątku.
A mi nie ma czego współczuć - mam ciekawą pracę, a wojujący ze sobą i rozwiązujący nieistniejące problemy scrumowi oszołomi to tylko mały dodatek humorystyczny.

Po co scrum masterzy jak można przeszkolić pracowników w scrumie i co jakiś czas zmieniać dyżurnego dewelopera/testera?
Scrum to teoria na kilka godzin nauki, nic więcej.

batchjob napisał(a):

Ale developerzy wytwarzają produkt - kod dzięki któremu właśnie działalność gospodarcza może funkcjonować i z którego osiąga się przychód. Niezależnie, czy to metodologia pracy taka czy inna, czy ktoś pracuje w 100 osób czy w 1 produkt, który się sprzedaje klientowi to kod (program). Bez tego nie ma biznesu. Jak wywalisz developerów to twoja firma nie funkcjonuje bo nie ma co sprzedawać. A jak wywalisz jakieś scrum wynalazki to możesz nadal funkcjonować ale w inny sposób, lepiej, gorzej, inaczej ale nadal. To taka subtelna różnica.

To jest rozkmina w stylu: jeśli wywalisz z samochodu silnik to nie pojedzie, a jak wywalisz opony, to na felgach przetoczysz się te parę metrów (chociaż jeśli zaprząc do samochodu konia, to też się przetoczy bez silnika), więc wywalmy opony. Tylko po co, skoro z oponami pojedzie dalej?
Klienci wcale nie płacą za kod. Klienci płacą za uzyskanie możliwości zrobienia czegoś. To może być kod, może być urządzenie z kodem, może być dostęp do jakiejś usługi. Możesz wywalić deweloperów, jeśli umiesz osiągnąć cel w inny sposób - choćby tworząc narzędzie integrujące gotowy soft czy biblioteki. Można sobie też cały dewelopment wyoutsourcować. Tworzenie kodu to tylko jeden z elementów tworzenia produktu, za który płaci klient.

GutekSan napisał(a):

batchjob napisał(a):

Ale developerzy wytwarzają produkt - kod dzięki któremu właśnie działalność gospodarcza może funkcjonować i z którego osiąga się przychód. Niezależnie, czy to metodologia pracy taka czy inna, czy ktoś pracuje w 100 osób czy w 1 produkt, który się sprzedaje klientowi to kod (program). Bez tego nie ma biznesu. Jak wywalisz developerów to twoja firma nie funkcjonuje bo nie ma co sprzedawać. A jak wywalisz jakieś scrum wynalazki to możesz nadal funkcjonować ale w inny sposób, lepiej, gorzej, inaczej ale nadal. To taka subtelna różnica.

To jest rozkmina w stylu: jeśli wywalisz z samochodu silnik to nie pojedzie, a jak wywalisz opony, to na felgach przetoczysz się te parę metrów (chociaż jeśli zaprząc do samochodu konia, to też się przetoczy bez silnika), więc wywalmy opony. Tylko po co, skoro z oponami pojedzie dalej?
Klienci wcale nie płacą za kod. Klienci płacą za uzyskanie możliwości zrobienia czegoś. To może być kod, może być urządzenie z kodem, może być dostęp do jakiejś usługi. Możesz wywalić deweloperów, jeśli umiesz osiągnąć cel w inny sposób - choćby tworząc narzędzie integrujące gotowy soft czy biblioteki. Można sobie też cały dewelopment wyoutsourcować. Tworzenie kodu to tylko jeden z elementów tworzenia produktu, za który płaci klient.

Ja nie mówię, żeby wywalić tylko żeby wiedzieć co jest na ile ważne. Jak już przytoczyłeś przykład auta to zauważ, że silnik jest o wiele droższy niż opony i wymaga większej uwagi (przeglądy itp.). Wyobraź sobie sytuację w której opony są droższe niż silnik - wtf.

A jak wywalisz developerów to również musisz pozbyć się scrum mastera bo co Ci po nim więc trochę nietrafiony argument. Pewnie, że wszystko można wyoutsourcować ale nam chodzi o konkretne stanowisko i patologie z nim związane kiedy staje się ono ważniejsze niż to co powinno.

somekind napisał(a):

Dałeś przykład, w którym sam przyznałeś, że pod osłoną procesu opóźniłeś dostarczenie czegoś tam, co jak sami pisałeś mogłeś zrobić w pół godziny. To jest właśnie sabotaż, tylko czystymi rączkami.

To, że to było wykonalne, nie znaczy, że mogłem to zrobić. Nie mogłem, bo jest proces i reguły.
A, że to jest złe dla projektu? Owszem, ale to nie moja wina tylko tych, którzy je ustalają.

Nie. Po prostu chciałeś pokazać jaki to Scrum jest zły kosztem współpracy z ludźmi. Wymówki zachowaj sobie dla szefa.

A tworzenie softu nie interesuje mnie tak bardzo jak tworzenie rozwiązań problemów, co z kolei nie interesuje Ciebie.

Jestem programistą, więc rozwiązuję problemy tworząc soft.

Od doświadczonych deweloperów normalnie wymaga się nieco szerszego spojrzenia.

Tak już jest jak ktoś nie umie polemizować z opiniami, tylko polemizuje z ludźmi. Potrzebuje wtedy jakiś stereotypowy model przeciwnika: (np. "lewaka", "religijnego oszołoma", "obrońcy scruma") z którym umie jako tako walczyć, a przy okazji można mu czasem zaserwować wycieczkę osobistą.

Napisał człowiek, który na dzień dobry porównał mnie do dzieciaka bawiącego się przyciskami w windzie, i który nie odpowiada na 2/3 zadanych mu pytań, albo odpowiada na nie pytaniami.

W sytuacji przewagi atakujących trudno mi odpowiedzieć na wszystkie pytania, chociaż staram się ustosunkować do wszystkiego. Na wiele odpowiedziałem, a i tak ich nie czytacie.

Jak potrafią, niech układają. Problem w tym, że programiści zazwyczaj nie potrafią zrobić tego tak, żeby zadowolić wszystkich poza sobą.

Współczuję programistów.

Dostrzegasz różnicę między "programiści zazwyczaj" a "programiści w mojej firmie" ?

coś sobie dopowiadasz. Ja pokazuję co można robić gdy jakieś problemy są. Ty rób co ci się podoba.

Nie pamiętasz nawet tego, co sam napisałeś kilkanaście godzin temu: Zostań Scrum Masterem

Doskonale pamiętam. Pisałem co można robić by mierzyć efektywność pracy. Ty stwierdziłeś, że nie korzystasz z tych rozwiązań i ogólnie planowanie rozjezdza się u was z pracą, cyt. "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". No ale rzekomo problemów nie macie i jeszcze próbujesz mi wmówić, że to ja mam jakiś problem! Grunt to iść w zaparte! Przemyśl chłopie trochę swoją logikę i się nie kompromituj

Współczuję środowiska pracy.

Nie masz współczuć. Masz zrozumieć, że są różne firmy i sytuacje.

I doskonale to rozumiem. Chyba lepiej niż większość tu piszących, bo twierdzę, że nie ma gotowych rozwiązań, które można zastosować w każdej organizacji i oczekiwać, że będą efektywne. Za to przeciwnicy Scruma postulują takie właśnie jedno rozwiązanie - brak czegokolwiek, jakichkolwiek procesów, po prostu napie...my kod, hurra i do przodu.

A mi nie ma czego współczuć - mam ciekawą pracę, a wojujący ze sobą i rozwiązujący nieistniejące problemy scrumowi oszołomi to tylko mały dodatek humorystyczny.

Ja również mam ciekawą pracę. Nie widzę niestety żadnych wojenek i rozwiązywania nieistniejących problemów, scrumowych oszołomów też nie widzę. Wątek humorystyczny zapewniam sobie więc czytając to forum :)