Menedżer produkcji pomaga zespołowi w wypuszczeniu nowej funkcjonalności

@Polasz streamable.com #heheszki #pracabaza

Opis musi być

  •  

    pokaż komentarz

    W każdej robocie znajdzie się co najmniej jeden taki mega ściemniacz.(⌐ ͡■ ͜ʖ ͡■)

  •  

    pokaż komentarz

    tyle co się wokół tego naskakał to więcej się narobił jakby faktycznie miał pomagać

  •  

    pokaż komentarz

    Dobry fachowiec. Zabezpieczał transport z każdej strony.
    Pamiętajcie. BHP najważniejsze.

  •  

    pokaż komentarz

    Miałem napisać, że pracował tak jak 90% Scrum Masterów, których spotkałem. Ale jednak nie do końca, bo człowiek z filmiku przynajmniej nie przerywał pracy i nie zajmował w moędzyczasie zespołu żadnymi grami czy quizami.

    •  

      pokaż komentarz

      90% Scrum Masterów,

      @tomp3: wczoraj trafiłem na taki filmik dwóch kolesi, którzy zajmują się Agile i generalnie zarządzaniem tworzenia oprogramowania. I też odnosili się do Scrum jako raka, który obecnie toczy świat IT. Że idea Scrum jak i wg nich nawet Agile. Zostały tak wypaczone, że obecni przynoszą one więcej strat niż korzyści.

      A twój komentarz jest potwierdzeniem tego co mówili. ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @szopa123: Już 7 lat temu, jeden z współtwórców The Manifesto for Agile Software Development (Dave Thomas), opowiadał, jak bardzo obecne pojmowanie Agile odbiegało od tego, co "twórcy" chcieli przekazać.
      https://m.youtube.com/watch?v=a-BOSpxYJ9M

      Martin Fowler (kolejny z autorów manifestu), również kilkukrotnie się odnosił do kultu Agile w podobnym tonie.
      https://martinfowler.com/articles/art-agile-foreword.html

      Ile to ja już miałem dyskusji ze Scrum Masterami w stylu:
      DEV: Potrzebujemy tego hot fixa wgrać jak najszybciej. Zrobimy na wstępie jakieś canary deployment, żeby ograniczyć wpływ i jak będzie ok, to udostępniamy stopniowo na całość.
      SM: Nie możemy tak zrobić, bo nie przeszliśmy fazy akceptacji testów na środowisku developerskim.
      DEV: Ale ten problem występuje tylko na produkcji. Nie mamy teraz czasu na odtworzenie błędy na dev, a widzimy, że ten konkretny fragment spowodował błąd. W testach jednostkowych to już uwzględniliśmy i po poprawce działa. Mamy już zgodę PO, bo "gorzej i tak nie będzie". A na devie to odtworzymy później, na spokojnie.
      SM: Ale to niezgodne z procedurami. Scrum Guide mówi, że XYZ.
      DEV: Ale czy Scrum nie miał być agilową metodyką pracy?
      SM: Miał być i jest! Przecież to jest właśnie całe clue Agile.
      DEV: Mhmm... A kojarzysz może taki krótki tekst The Manifesto for Agile Software Development?
      SM: Co za głupie pytanie. Przecież to jest fundament, o który opiera się Scrum.
      DEV: Mhm... To tam jest taki punkt "Individuals and interactions over processes and tools". Jak to się w tym momencie ma do naszych procedur?
      SM: Ale Scrum Guide mówi...

    •  

      pokaż komentarz

      @tomp3: ale tak jest generalnie ze wszystkim obecnie. Tępaki z tytułami naukowymi, który wykuły pewne regułki, powtarzają je bez zrozumienia jak mantre.
      Jakakolwiek polemika spotyka się albo z brakiem odpowiedzi, albo powtarzaniem regułek, że niby one są odpowiedzią. ( ͡° ͜ʖ ͡°)

      Wg moje teorii wypaczenia. Każda, nawet najbardziej szczytna idea. W określonym czasie x, ulegnie takiemu wypaczeniu, że jej działanie będzie odwrócone o 180 stopni.

      Co obecnie można odnieść do b. wielu rzeczy. Np. 'wojownicy o wolność i równouprawnienie' atakują każdego, kto ma inne zdanie. Oraz żądają specjalnego traktowania siebie i swoich wybrańców. ( ͡° ͜ʖ ͡°)

      Czy np. idea demokratycznych rządów, gdzie rząd z definicji powinien służyć swoim obywatelom. A obecnie traktuje obywateli jak bydło i generalnie służy tylko sobie. ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @tomp3: nie wiem co to za SM, ale scrum guide nie mówi nic o konkretnych procesach wytwórczych. W szczególności nie mówi nic o jakichkolwiek testach.
      Jeśli zaś to wynika tylko i wyłącznie z ustalonych przez Was procedur, to warto dodać do każdej tego typu procedury listę sytuacji, kiedy można ją zignorować i dlaczego - i przy każdej kolejnej sytuacji to dopisywać. O ile scrum tego nie wymaga, o tyle życie pokazuje, że bez tego typu rygorów ludzie bardzo szybko się rozleniwiają i zaczynają z byle powodu robić wyjątki. A jak to zacznie się dziać to chaos się prędzej czy później sam pojawi.

    •  

      pokaż komentarz

      @tomp3: lol, ale robisz podstawowy błąd, stąd się bierze twoje zdziwienie, zresztą ten SM też tego nie rozumie, bo go k!##a nigdy nie nauczyli samodzielnego myślenia. Agile to filozofia, zaś Scrum to narzędzie, które implementuje jakąś część tej filozofii, ale są to generalnie dwie niezależne sprawy powstałe równolegle. Scrum może istnieć bez Agile Manifesto, bo Agile Manifesto to nic innego, jak krótki zbiór przemyśleń, mający się nijak do ich implementacji w rzeczywistości.
      Powiem nawet więcej, Scrum nie jest do końca agile per se. Nie możesz zamienić kierunku w środku sprintu. Nie możesz wyjść poza ramy Scrum i dalej nazywać to scrumem. To nie jest agile w rozumieniu Agile Manifesto. Po prostu. Agile i Scrum to troszeczkę inne rzeczy, mylnie wrzucane do jednego worka przez ludzi, którzy do końca nie rozumieją tych idei.

    •  

      pokaż komentarz

      @tomp3: miałem podobną sytuację. Naturalnie w pracy jakoś wyszło, że testerka zaczęła zapisywać różnego rodzaju drobne błędy na białej tablicy. Mi to też pasowało bo kątem oka widziałem czy warto przerywać to co obecnie robię aby to naprawić albo gdy już się trochę tego nazbierało.

      Oczywiście scrum masterka musiała wejść cała na biało i pokazać że jest ważna, że tak nie można, że musi być wszystko w jirze, że to niezgodnie z Agile, bla bla bla.

      Zacytowałem ten sam fragment pokazując na tablicę, testerkę i mnie jako "Individuals and interactions" a jirę i ją jako "processes and tools" - zatkało i był koniec tematu, że możemy robić tak jak nam wygodniej ;)

    •  

      pokaż komentarz

      @Brother_of_Steel: Ok, rozumiem rozróżnienie. Tylko tak się jakoś składa, że wszyscy SM z jakimi pracowałem wmawiają mi, że Scrum to metodologia Agileowa, i że pracuję wtedy w Agile.

      Inna sytuacja z poprzedniej pracy. Był upgrade infrastruktury i coś poszło nie tak, przez 4 dni nie działało środowisko. Developerzy pracowali normalnie dalej, no ale PO chciał zobaczyć wytworzone feature jednak na środowisku, zanim to zatwierdzi. Środowisko zaczęło działać, ale potrzebne były 3-4 dni, żeby to wszystko zweryfikować na środowisku przez testera i PO. Zespół zaproponował, żeby nie kończyć w takim razie sprintu, tylko przesunąć go o tydzień. Z PO się dogadaliśmy, że jak skończą nam się zadania, to moglibyśmy dobrać drobiazgi, na które wcześniej nie było czasu, a da się je zrobić szybko i ich testy to chwilka.
      Wszedł SM i mówi, że tak nie można, bo nie wolno ot tak sobie modyfikować sprintów. Stwierdził, że lepiej zamknąć sprint z porażką i popsuć ludziom morale, niż cokolwiek modyfikować w trakcie trwania sprintu. No i zakończyliśmy, a potem musieliśmy się jeszcze tłumaczyć, dlaczego dostarczyliśmy tylko 20% zadeklarowanych SP i dlaczego nie mamy prawie nic do pokazania na demo. I to wszystko pomimo tego, że codziennie zgłaszaliśmy ten problem i mieliśmy dodatkowe spotkanie z PO i SM, na którym to omawialiśmy.
      Na tłumaczenie, że rzeczywistość jest trochę inna niż w teorii Scruma, SM tylko się irytował.

    •  

      pokaż komentarz

      @tomp3: Scrum jest sztywnym narzędziem które jest traktowane jak religia. Jak się zaczniesz modlić do młotka, skończy się to podobnie. Po tylu doświadczeniach powinieneś już zrozumieć, że Scrum na tyle wspólnego z Agile Manifesto, jak stokrotka z kwiatem. Stokrotka jest kwiatem, ale kwiatów są tysiące i każdy bardziej lub mniej ładny. Mówiąc kwiat bez nazwania go konkretnie, opisujemy wszystkie kwiaty, natomiast mówiąc stokrotka, konkretnie mówimy o jakimś kwiecie z nazwy, mając przed oczyma jego wygląd i to jak go odbieramy. Zastosuj to samo do Scrum i Agile. Agile definiuje zbiór, a jedną z jego implementacji jest Scrum. Scrum jest konkretną implantacją agile i jako taka nie musi być zgodna w 100% z ogólnymi założeniami.
      Już naprawdę prościej nie umiem.
      Po prostu robisz błąd logiczny.

    •  

      pokaż komentarz

      @Brother_of_Steel:
      Zawsze wydawało mi się, że implementacje / definicje bardziej szczegółowe powinny spełniać wymagania tych bardziej ogólnych.
      Jeśli mówimy, że stokrotka to kwiat, to powinna ona spełniać definicję kwiatu.
      A tu, Scrum, nie spełnia reguł Agile, więc jak może w ogóle nazywać się Agile?

    •  

      pokaż komentarz

      @Brother_of_Steel: Dla mnie to jest trochę, jakby ktoś przyszedł i powiedział mi, że rower to taki samochód.
      No nie do końca, bo samochodem nie pojadę po chodniku czy ścieżce dla rowerów, a rowerem nie pojadę po drodze szybkiego ruchu.
      Oba to pojazdy, ale jednak znacząco różne. Pomimo tego, że część funkcji i charakterystyk jest wspólnych, nadal różnią się znacząco.
      I mam wrażenie, że gdy SM mówi, że Scrum to Agile, to bardziej pasuje mi właśnie to porównanie.

    •  

      pokaż komentarz

      @tomp3: pracuję w zespole, który praktycznie od roku nie ma oficjalnego Scrum Mastera, wcześniej tą rolę miał soft-dev, który się zwolnił, w tym czasie odeszły osoby z doświadczeniem, przyszli nowi, zmienił się product owner, którego współdzielimy z innym zespołem i jakoś świetnie sobie dajemy radę. Kluczem jest elastyczny, samoorganizujący zespół z poczuciem ownershipu ( ͡° ͜ʖ ͡°)
      Tak naprawdę Scrum Master nie powinien być na stałe, to powinien być coach, który nauczy zespół jak pracować w Scrumie, trochę zorganizuje zespół, wprowadzi procedury i rozwiązania, które UPROSZCZĄ codzienną pracę (a nie ją skomplikują), a kiedy zespół do tego dojrzeje to Scrum Master odchodzi by naprawiać świat gdzie indziej.

    •  

      pokaż komentarz

      Zawsze wydawało mi się, że implementacje / definicje bardziej szczegółowe powinny spełniać wymagania tych bardziej ogólnych.

      @tomp3: masz rację, wydawało ci się. Czasem implementacje biorą tylko wycinek, to albo bazują tylko na idei. W tym jest właśnie clou tego twojego problemu. Masz złe założenia.
      Agile jest filozofią, zaś Scrum metodologią. To są zupełnie dwa różne światy, filozofię można interpretować wielorako, a ty chcesz się do niej modlić. Zabawne, bo sam nie jesteś agile w pierwszej kolejności.

    •  

      pokaż komentarz

      @Brother_of_Steel: Dzięki za wyjaśnienia. W takim razie, po prostu wkurza mnie wrzucanie Scruma wszędzie, nawet tam, gdzie nie pasuje. I uwielbienie procedur przez SM, które bardzo trudno zmienić, nawet gdy 99% zespołu popiera zmianę, no SM mówi, że nie wolno.

      Ile to mieliśmy batalii z SM o to, by nie wdrażać kolejnego narzędzia do statycznej analizy kodu w naszym procesie CI. I tak już mieliśmy 2 inne narzędzia do tego, ale SM się uparł, że trzeba wdrożyć kolejne, które w dodatku mieliło każdą najdrobniejszą zmianę przez 20-30 min., a reguły konfigurował jakiś osobny zespół ds. jakości aplikacji.
      I reguły oczywiście były niedopasowane do składni naszej wersji języka (bo mieliśmy nowszą wersję języka w naszych projektach), więc co chwie nawalone hinty, żeby ignorować konkretne reguły dla konkretnych fragmentów kodu. I wynik działania tego narzędzia musiał być oczywiście blokujący merge / akceptację pull requesta, w celu zapewnienia "należytej jakości aplikacji". Także każda drobna zmiana była wydłużana o ok. 30 min.
      Okazało się, że na jakimś spotkaniu z biznesem SM wymyślił, żeby pokazywać biznesowi raporty z narzędzi do statycznej analizy kodu i w ten sposób móc oceniać naszą pracę. I akurat w tym narzędziu były najładniejsze raporty. Na szczęście, to narzędzie było płatne i po okresie trialowyn i otrzymaniu wyceny od producenta, biznes stwierdził, że nie potrzebuje takiego narzędzia, a my mogliśmy przywrócić naszego CI do poprzedniego stanu.

      Agile jest filozofią, zaś Scrum metodologią. To są zupełnie dwa różne światy, filozofię można interpretować wielorako, a ty chcesz się do niej modlić. Zabawne, bo sam nie jesteś agile w pierwszej kolejności.

      Po prostu nie rozumiałem tego, że Scrum może być Agile, jednocześnie nie spełniając założeń Agile. Dlatego twierdzenie Scrum to Agile wywoływało zawsze u mnie dysonans.
      Ja się nigdzie nie zamierzam modlić do Agile czy jakiejkolwiek innej metodologii. Dopóki widzę sens w procedurach i ktoś mi nie utrudnia pracy, to nie mam z tym problemu. Ba, nawet mogę czasem przystać na jakieś niedogodności, argumentowane "bo tak", bo czasem rozumiem, że ktoś ma w tym jakiś cel, którego nie jestem w stanie pojąć.
      Tylko z reguły wyglądało to tak, że ktoś mi mówi, że pracujemy w metodologii X i mówi, że czegoś się nie da, bo takie są reguły. Mówi dalej, że to implementacja Agile. No to ja mówię - jak to się ma do Agile, skoro nie spełnia wielu jego podstawowych reguł?

      Teraz, dzięki Tobie, już wiem, że Scrum jest Agile, tylko nie spełnia wskazówek z The Manifesto for Agile Software Development.

    •  

      pokaż komentarz

      @tomp3: wiesz, jest powód, dla którego nie startuję już na pozycję Scrum Mastera, choć byłem jedną z pierwszych osób, która zaczęła go wdrażać zaraz po tym jak oficjalnie pojawiła się pierwsza wersja Scrum Guide. Z większości rozmów o pracę po prostu wychodziłem w trakcie, słysząc te wszystkie straszne bzdury, które mi ludzie opowiadali na temat Scrum'a chwaląc się, jak to u nich "super" działa. Dochodzę do wniosku, że teraz po prostu modnie jest mieć Scrum, bo wszyscy w tym robią, bez żadnej refleksji co i jakie problemy ten Scrum może u mnie rozwiązać. Pamiętam jak po mojej prelekcji na temat case study, w którym pokazałem, że w chwili odpowiedniego przygotowania da się przewidzieć kiedy wstąpią konkretne milestone'y w projekcie ustawiła się do mnie kolejka, bo przecież to tym managerom narzucającym miary waterfall na coś co nie jest w ogóle związane z czasem, wydawało się rewolucją na miarę wynalezienia maszyny parowej. A te całe frameworki w dużych organizacjach, typu SAFe, to dopiero jest patologia.
      Wszędzie tam, gdzie za agile i Scrum się wezmą organizacje, to wszystko sp!!?$!!ą. Dobrym przykładem jest proces certyfikacji, k?%%a, dwustopniowa certyfikacja PSM z kilkunastustronnicowej broszurki Scrum Guide plus poboczne odchyły w stylu professional product owner to po prostu jest szczyt. Jeden wielki scam. "Nie musisz być inżynierem rakietowym, żeby pomóc zespołowi budować rakietę", kiss my ass. Jakbym był inżynierem rakietowym, to bym pogonił jakiegoś lamusa który mi mówi, jak mam budować rakietę. Tylko że developerzy są w większości introwertykami i nie umieją się postawić. A powinni już dawno wyj%#@ć tych darmozjadów żerujących na ich pracy na zbity ryj. Taka prawda.

  •  

    pokaż komentarz

    Widziałem kilka podobnych filmików, mógłby ktoś podesłać bo wyjątkowo mi sie podobały.