•  

    pokaż komentarz

    Ja jestem programistą i piszę najpierw kod na brudno na kartce a później przepisuje. Nigdy mi się nie zdarzyło przetestować kodu na brudno, nad czym ubolewam. Pozdrawiam z krainy szaleństwa.

  •  

    pokaż komentarz

    Połowa tych zwierzątek jest zbędna, wręcz nawet przeszkadzająca w projekcie.
    Liczy się tylko grupa ogarniętych programistów z pragmatycznym PM i zdolnym QA i Testerami
    Zero p!%%?!%enia (╯°□°)╯︵ ┻━┻
    Zero skrumów (╯°□°)╯︵ ┻━┻
    Zero korpo-planingów (╯°□°)╯︵ ┻━┻
    Zero udawania technik zarządzania

    Tyko czysty plan+kontrola planu+ analiza jakości

    •  

      pokaż komentarz

      Zero skrumów

      @snup-siup Ktoś Ci wyrządził krzywdę :(

    •  

      pokaż komentarz

      Tyko czysty plan+kontrola planu

      @snup-siup: a ten plan to się tworzy według jakichś zasad czy na oko, ewentualnie na żywioł?

    •  

      pokaż komentarz

      @snup-siup: a potem ktoś musi ten cud techniki utrzymać

    •  

      pokaż komentarz

      @snup-siup: I tak sobie robisz projekt który w założeniu ma być wdrożony w okresie 3 lat bez żadnego planingu, scrumów i zarządzania? Po pół roku wesołej twórczości panuje taki burdel, że nikt nie wie o co chodzi.
      Poza tym jak nie chcesz planingów robić, to jak chcesz kontrolować plan? Jaki plan?

    •  
      Xyyyyyz

      -3

      pokaż komentarz

      @Mave: Ścisłe plany są dobre jak robisz coś nudnego i powtarzalnego wtedy realnie możesz coś oszacować inaczej moim zdaniem planowanie to porażka znaczy kończy się na crunchu by dotrzymać terminu i dostarcza się słabej jakości produkt.

      co do tego co mówił @snup-siup to google tak na początku pracowało, tylko to działa jeśli masz dobry zespół

    •  

      pokaż komentarz

      @snup-siup: Project Managerem to Ty chyba nie jesteś, mam rację? ( ͡º ͜ʖ͡º)

    •  

      pokaż komentarz

      @mich160:

      Comarch
      Grupa ogarniętych programistów

      Tam student z rocznym doświadczeniem jest już seniorem xD.

    •  

      pokaż komentarz

      @Flypho: Wiem, wiem. Żartuję sobie. (⌐ ͡■ ͜ʖ ͡■)

    •  

      pokaż komentarz

      Poza tym jak nie chcesz planingów robić, to jak chcesz kontrolować plan? Jaki plan?
      @Mave: stary dobry waterfall ( ͡° ͜ʖ ͡°)

      Zero skrumów
      > Ktoś Ci wyrządził krzywdę :(


      @pokrakzx: nie wiem skąd przekonanie że scrum to złoty środek. Czasem firmy nasłuchają się jaki to jest wspaniały, a potem biznes potrafi wyskoczyć z niespodzianką, że chcą nagle zmienić działanie aplikacji. Od której mogą zależeć już inne aplikacje. Niby da się, ale może to być dodatkowy koszt, którego da się uniknąć.

      Wszystko jest spoko jeśli pracujesz z ludźmi którzy scruma rozumieją, ale kiedy udział biorą osoby trzecie, to już nie sprawdza się tak dobrze.

    •  

      pokaż komentarz

      nie wiem skąd przekonanie że scrum to złoty środek. Czasem firmy nasłuchają się jaki to jest wspaniały, a potem biznes potrafi wyskoczyć z niespodzianką, że chcą nagle zmienić działanie aplikacji. Od której mogą zależeć już inne aplikacje. Niby da się, ale może to być dodatkowy koszt, którego da się uniknąć.

      @Paczek_w_masle: Powiedziałbym, że właśnie w takich sytuacjach scrum w pełni pokazuje swoje zalety. Zmiana i szybka reakcja na zmianę leży wręcz u podstaw scruma :) Właśnie dlatego iteracje mają być krótkie, właśnie po to się robi po każdej iteracji review w którym uczestniczą interesariusze (stakeholders). Pozwala to wprowadzać konieczne zmiany i minimalizować ich koszty.

      Wszystko jest spoko jeśli pracujesz z ludźmi którzy scruma rozumieją, ale kiedy udział biorą osoby trzecie, to już nie sprawdza się tak dobrze.

      @Paczek_w_masle: co masz na myśli pisząc "osoby trzecie"?

      Generalnie pisząc pozytywnie o scrumie mam na myśli prawdziwy scrum. Ten w którym zarówno Scrum Master jak i Product Owner znają swoje role, rozumieją je, wykonują swoje obowiązki poprawnie i są w stanie wyegzekwować od reszty organizacji ich poszanowanie. Ten w którym nikt spoza zespołu nie ma prawa w żaden sposób wywierać żadnych nacisków zewnętrznych na devteam.

      Głównym problemem scruma jest to, że jest często potwornie niezrozumiany i ludzie są zmuszani do pracowania w jamiś gównie nazywanym scrumem, ale ze scrumem nie mającym nic wspólnego.

    •  

      pokaż komentarz

      @Xyyyyyz: Od kiedy scrum to ścisłe planowanie? Chyba nie wiesz na czym polega agile.

    •  

      pokaż komentarz

      @Paczek_w_masle: @pokrakzx: problem polega na tym, że wszyscy od dawna pchają się w SCRUMA, a dwie bardzo ważne (może nawet najważniejsze) rzeczy, czyli review & retro są zlewane, albo robione na odp!%#%%%. Klientów nie da się tak często (co iterację) zaprosić na demo. Retro: co poszło dobrze? (nic), co poszło źle? (wymyślanie na siłę), to wszystko? Wracamy do pracy. A spróbuj starej gwardii (50+) wytłumaczyć co to jest story point do tego stopnia, żeby świadomie go używali...

    •  

      pokaż komentarz

      @pokrakzx: przez osoby trzecie mam na myśli biznes. Mamy PO, który wie co robi. Ale co z tego, skoro biznes chce zmianę na już. Czasem zaburzają sprinty bo coś jest super pilne. A czasem nie da się podzielić zadań tak, żeby były kompletne po jednym sprincie i robota leży przez jakiś czas.

      I tutaj @enceladus71 ma rację: code review jest zlewany. A jak ktoś powie że coś do poprawy, to nie ma czasu i wdrażaj tak. Po co to jest, to nie wiem. Tak samo retro. Jaki jest sens jeśli nikt nie zamierza nic zmienić? Tak samo wyceny. Dlaczego ktoś pyta o wycenę, jeśli każe ją zaniżyć bo drogo, a potem wielkie zdziwko że sprint się nie udał.

      Pamiętam, że w jednym z zespołów doszło do dość komicznej sytuacji. Wszyscy co sprint narzekali na organizacje zadań i to że to nie jest prawdziwy Scrum. Co zrobiło kierownictwo? Przysłało nam zespół specjalistów od Scruma. Oni tylko złapali się za głowę i w sumie przekazali górze to samo co mówiliśmy od dawna. Oczywiście nic się nie zmieniło.

    •  

      pokaż komentarz

      code review jest zlewany

      @Paczek_w_masle: sprint review*

      pokaż spoiler chociaż jeśli code review jest zlewany to ratunku już chyba nie ma ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      a dwie bardzo ważne (może nawet najważniejsze) rzeczy, czyli review & retro są zlewane, albo robione na odpierdol

      @enceladus71: wówczas mamy do czynienia z gównem, które ludzie nazywają scrumem, ale które scrumem nie jest.

      Klientów nie da się tak często (co iterację) zaprosić na demo

      @enceladus71: jak dla mnie wymówka. Klient nie musi uczestniczyć fizycznie (chociaż byłoby to skądinąd świetne), telekonferencja sprawdza się wystarczająco dobrze. Tylko zasady współpracy trzeba ustalić na początku i trzeba wyjaśnić klientowi dlaczego jest to takie ważne.

      A spróbuj starej gwardii (50+) wytłumaczyć co to jest story point do tego stopnia, żeby świadomie go używali

      @enceladus71: jeżeli zespół nie rozumie czym są storypointy to można je po prostu olać i estymować w dniach lub godzinach pracy. Jak im wygodnie. Sposób estymacji ma tutaj tak naprawdę drugorzędne znaczenie - to co jest naprawdę istotne to przewidywalność. O to, żeby poszczególne user story były możliwe do zamknięcia w jednej iteracji i żeby do iteracji wrzucić realistyczną liczbę user stories.

    •  

      pokaż komentarz

      @enceladus71: no cóż, nikt siłą nie trzyma ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      Pamiętam, że w jednym z zespołów doszło do dość komicznej sytuacji. Wszyscy co sprint narzekali na organizacje zadań i to że to nie jest prawdziwy Scrum. Co zrobiło kierownictwo? Przysłało nam zespół specjalistów od Scruma. Oni tylko złapali się za głowę i w sumie przekazali górze to samo co mówiliśmy od dawna. Oczywiście nic się nie zmieniło.

      @Paczek_w_masle: no właśnie... to dlaczego narzekasz na scrum, skoro to na co narzekasz scrumem nie jest? Scrum jest naprawdę fajny - tylko to musi być scrum a nie jakieś nieokreślone coś, co jest błędnie nazywane scrumem. Gó*no nie staje się kwiatkiem nawet jeśli ktoś je zacznie nazywać fiołkiem.

    •  

      pokaż komentarz

      @pokrakzx: Wiesz, jak dla mnie typowy scrum, ma lukę w pozbyciu się architekta i nacisku na dostarczanie nowości, ale jednak zmniejszeniu nacisku na projektowanie i trzymanie jakości w perspektywie całego rozwiązania.
      Scrum w większości przypadków jest stosowany jako złoty młotek do wszystkiego, jako zastępnik myślenia i realnego planowania, bo perspektywa przesuwa się tylko na dany sprint i nikogo praktycznie nie interesuje, co będzie za 1-2 sprinty albo jak dany nowy task wpasowuje się w stan istniejący i złożoność całego rozwiązania.
      Najlepszy jest mix waterfalla ze scrumem, część wykonawcza robiona scrumem, ale jednak jak są osoby, które czuwają nad analizą wymagań, realną realizacją założeń i sterowaniem kierunkiem całego projektu w sposób waterfallowy z uwzględnieniem postępów.

      Nic jednak po prostu nie zastąpi umiejętności ludzi, żadna metodologia nie sprawi, że nagle projekty będą wspaniałe. Jeżeli cały team będzie świetny, to w sposób naturalny wszystko się wyklaruje i zorganizuje, co też było jednym z punktów Agile manifesto, samoorganizujące się teamy.

    •  

      pokaż komentarz

      Wiesz, jak dla mnie typowy scrum, ma lukę w pozbyciu się architekta i nacisku na dostarczanie nowości, ale jednak zmniejszeniu nacisku na projektowanie i trzymanie jakości w perspektywie całego rozwiązania.

      @adiq94: no nie ze wszystkim jestem w stanie się zgodzić (np. scrum na jakość kładzie całkiem spory nacisk), inne wątpliwości próbuje rozwiać filozofia scruma (która zakłada, że najlepszą architekturę tworzy jednak devteam a nie pojedyncze osoby) z tym, że tutaj w sumie dochodzimy do dość subiektywnej oceny czegoś o czym można się długo spierać. Tego typu dyskusje fajnie się prowadzi na żywo, mniej fajnie w komentarzach na wykopie ;)

      To co było dla mnie katalizatorem który pchnął mnie w tę dyskusję była wypowiedź z której pośrednio wynikało, że piszący uważa że scrum jest beznadziejny i do stosowania w normalnej pracy się nie nadaje. Postawy takie wynikają zazwyczaj z tego, że ludzie musieli pracować na jakichś chorych zasadach i ktoś ich skrzywdził nazywając te chore zasady scrumem, przez co zraził ich do naprawdę fajnego systemu pracy. Oczywiście scrum to nie jest panaceum na wszystko. Ma swoje problemy i ma swoje trudności - nie jest idealny. Ale nie zmienia to faktu, że prawidłowo wdrożony i prawidłowo prowadzony ma jednak bardzo wiele zalet zarówno dla zespołu scrumowego jak i klienta, więc takie potępianie w czambuł jest błędem.

    •  

      pokaż komentarz

      @pokrakzx: Wszystko zależy od teamu przede wszystkim, i " prawidłowo wdrożony i prawidłowo prowadzony" jest relatywne, bo musi być zawsze dostosowany do sytuacji. Waterfall może działać równie dobrze co agile, w przypadku świetnego teamu. Skupiać się można nad tym, co się dzieje jak Scrum się degraduje w praktyce pod wpływem różnych czynników, jak choćby samo niezrozumienie metodologii, bo inaczej to równie dobrze możemy rozmawiać o tym, że komunizm to w teorii świetny system ; )

      Fakt faktem, jednak agile > waterfall, tak na ogół wychodzi lepiej w praktyce.

    •  

      pokaż komentarz

      bo musi być zawsze dostosowany do sytuacji

      @adiq94: jeżeli nie jest, to już jest "nieprawidłowy" ;) - z definicji. Scrum wyznacza pewne ramy współpracy, natomiast konkretna implementacja jest uzależnione od środowiska w jakim jest wdrażany. Ta swoboda jest jednocześnie zaletą i wadą, bo skoro nie ma jedynego słusznego sposobu wdrożenia scruma, to zostawia niestety sporo miejsca dla tych, którzy go nie rozumiejąc próbują go wdrażać. To prowadzi do patologii i złych doświadczeń.

      Skupiać się można nad tym, co się dzieje jak Scrum się degraduje w praktyce pod wpływem różnych czynników, jak choćby samo niezrozumienie metodologii

      @adiq94: to jest właśnie zadanie scrum mastera. Wyłapywać takie sytuacje i zaradzać im, żeby się nie zdegenerował. Dlatego właśnie scrum master jest niezbędny w każdym zespole scrumowym - także tym dojrzałym.

  •  

    pokaż komentarz

    Widze, ze nie ma ludzi normalnych. Każdy z jakimś mankamanetem - moglobyc nawet trafne, a tak to troche krzywdzace.

  •  

    pokaż komentarz

    Wszyscy tacy c%$?#wi, jak tu pracować ( ͡° ͜ʖ ͡°)
    A ja zauważyłem ciekawą rzecz - postawa człowieka zależy w dużej mierze od projektu i może się zmienić o 180 stopni w zależności od ludzi z jakimi pracuje i od projektu w jakim jest. Sam się zdziwiłem jak towarzystwo w pracy i organizacja projektu może podwyższyć, lub totalnie obniżyć chęci do realizacji zadań.

    •  

      pokaż komentarz

      @Mave: dokładnie tak, ja spotkałem w swojej karierze kilku nadludzi: developer w projekcie ogarniał więcej managerskiej roboty niż menagerzy, do tego robił wszystkim dokładne CRy i bardzo grzecznie, w łagodnym mentorskim tonie sugerował każdemu w teamie co powinien poprawić, nadzorował refaktoring i do tego wszystkiego sam leciał ze swoimi taskami jak burza.

      Dziwi mnie skąd się tacy ludzie biorą, którzy potrafią bez żadnej spiny pociągnąć najbardziej leniwy projekt i zespół do wzmożonej i zdrowej pracy. Najczęściej to są jakieś dinozaury w młodych zespołach, nie wiem skąd mają na to energię po 20+ latach klepania kodu, ja ledwo do 10 lat w zawodzie dobijam a już mi się powoli odechciewa, ale to prawdziwe skarby. Zatrudnić takiego to jak wygrać na loterii.

    •  

      pokaż komentarz

      Zatrudnić takiego to jak wygrać na loterii.

      @nielegalny_imigrant:
      A potem trafia się menedżer typu
      "Po co te CR, to nie daje żadnej wartości dodanej, idźta kod klepać lepij"
      "Po co ten refactoring, to nie daje żadnej wartości dodanej, idźta kod klepać lepij"
      "Po co testy jednostkowe, to nie daje żadnej wartości dodanej, idźta wincej klepać"

      i do tego wszystkiego sam leciał ze swoimi taskami jak burza
      Następnie do zespołu trafia nowy, błyskotliwy, ambitny, co to zadania robi 3x szybciej. Co z tego, że powtórne wykorzystanie kodu to dla niego kopiuj - wklej, sam nie wie, jak jego procedury działają, a testów nie pisze, bo to przecież strata czasu. Co z tego, że jego kod wykrzacza się co chwila. Szybko awansuje najpierw na lidera zespołu, potem na jakieś stanowisko kierownicze. I pierwsze, co robi, to pozbywa się twojego ogarniętego developera.

    •  

      pokaż komentarz

      @tarrin: na szczęście takie akcje odchodzą tylko w wielkich molochach, z własnego doświadczenia odniosłem wrażenie, że "rockstar devów" można znaleźć w małych kameralnych firemkach

    •  

      pokaż komentarz

      nie wiem skąd mają na to energię po 20+ latach klepania kodu
      @nielegalny_imigrant: No właśnie to ich motywuje - po 20 latach klepania kodu skupiają się w większym stopniu na kwestiach organizacyjnych niż na samym programowaniu, żeby mieć jak najmniej do czynienia z samym klepaniem.

  •  

    pokaż komentarz

    Typowe frustracje waterfall-isty.