Jak ma się u was SCRUM w 2025?

U mnie oficjalnie jest scrum, nieoficjalnie to praktycznie SAFe z większością ceremonii - co kwartał planowane jest który task ma zostać zrobiony w której iteracji i takie tam. Ale estymaty są robione na refinemencie przed iteracją, co oznacza, że w sumie nieważne, na ile co wyestymujesz. A skoro tak, to 95% tasków jest estymowane na 5SP.

Jak ma się u was SCRUM w 2025?

Nie praktykujemy od kilku lat. Mamy tablicę z zadaniami, jakieś ad hoc planawowanie jak potrzeba i tyle. Żadnych sprintów itp.

nikt raczej nie wpada na pomysł zrobienia retrospektywy

Retrospektywa to akurat najlepszy meeting w tym całym scrumowym wynalazku jeśli zakończy się konkretnymi akcjami. Jest to dedykowany czas żeby się wyżalić bez konsekwencji i można nawet wrzucić coś poza normalnym trybem żeby polepszyć sytuację. Zresztą, nawet jak którymś razem nie będzie akcji to ma to działanie terapeutyczne. Tylko nie można tego robić za często. Obecnie sprintów nie praktykujemy, ale retrospektywę raz na dwa miesiące mamy i jest git. Jakbyście sobie zrobili rektrospektywę gdzie wszyscy przybilibyście sobie piątkę jak to fajnie bez scruma to pewnie morale by wzrosło :D

Za resztą scruma nie tęsknie. Może tylko tablicę z jako tako uporządkowanymi zadaniami fajnie jest mieć.

SCRUM i wiążąca się z nim taskoza zupełnie nie nadają się do pracy produktowej.

Często jest tak że w trybie produktowym to inżynierowie wychodzą z propozycjami usprawnień pracując nad daną funkcjonalnością. Ja jestem jeszcze młody, ale widziałem starszych kolegów którzy pracując z product design'erami oraz dyskutując z użytkownikami potrafili zupełnie zmienić koncepcje działania danej funkcjonalności. Sporo usprawnień w produkcie też wychodziło z dogfood'ingu lub z hackatonów - gdzie ludzie dodawali funkcjonalności często pod siebie (np. możliwość dodawania tagów poprzez wpisanie w tekście #tag a nie wyboru w osobnym polu).

SCRUM często wiąże się z tym że nad jedną funkcjonalnością pracuje kilka osób. Brzmi dobrze z POV managera ale powoduje że nikt nie jest tak naprawdę odpowiedzialny za daną cechę produktu. Często jest to też rozwój oprogramowania w trybie: "aby z rąk" - zrobiłem taska, reszta mnie nie interesuje. Działa wolno, koślawo? Na to trzeba zrobić kolejnego taska. Jest nieobsłużony przypadek którego nie wykryliśmy wcześniej? Nowy task i do backloga. W trybie projektowym nie ma na coś takiego miejsca. Jeżeli dowieziesz coś "half baked" to twoi klienci mogą stracić do ciebie zaufanie. Oczywiście czasami robi sie MVP jakiejś większej funkcjonalności lub nawet PoC na produkcji, ale zawsze jest to odpowiedź na żądanie konkretnego klienta lub nowy dodatek do aplikacji - prawie zawsze darmowy i oznaczony jako beta.

Inaczej to wygląda gdy rozwija się oprogramowanie na potrzeby wewnętrzne - gdzie głównym czynnikiem jest koszt vs. oprogramowanie na potrzeby rynku gdzie głównym czynnikiem jest utrzymanie istniejących oraz przyciągnięcie nowych klientów. Nawet jak internal software jest fatalne to często i tak będzie używane przez dekadę kosztem ergonomii pracy czy błędów ludzkich, na rynku coś takiego jest nie do pomyślenia. Nawet giganci IT nie mogą spać spokojnie: MS miał Office, teraz Google ma również swój pakiet biurowy - klient ma wybór. MS Teams konkuruje ze Slackiem, Zoom z Meets. Im większa konkurencja na rynku tym lepszy musi być produkt. Scum z wiążącym się z nim szuflatkowaniem na role oraz podziałem na małe pod-zadania po prostu nie jest w stanie wytwarzać produktów dobrej jakości. Przynajmniej takie są moje doświadczenia.

Na koniec dodajmy że nie ma sposobu żeby pogodzić Springty i planowania z pracą w trybie OnCall oraz współpracą z Supportem. Jeżeli ważny klient skarży się że applikacja nie działa i blokuje to mu pracę to jest to absolutny priorytet. Nie wolno z takim zadaniem czekać do następnego planowania, ciężko taką pracę też wycenić. Tutaj Kanban naprawdę lśni.

Ostatecznie Scrum został stworzony aby kontrolować konsulatantów - czyli ludzi na dłuższą metę nie związanych ani z firmą ani z produktem ani z domeną. Konsultant ma przyjść i zrobić swoją robotę. Pracowałem z kilkoma konsulatantami i niestety jakość kodu była bardzo mizerna. Zadania robili szybko ale ich horyzont czasowy to czas trwania ich kontraktu. Z tym kodem praktycznie nie dało sie pracować. Bardzo szybko firma się z nimi pożegnała. Natomiast Scrum zdawał się świetnie działać w tym środowisku - bo skoro masz programistów na godziny to chcesz żeby każda z tych godzin była dobrze wykorzystana. Daily ma wtedy też sens bo mamy grupę ludzi którzy często siebie nie znają jak również nie znają nikogo w firmie więc mogą mieć problemy z proszeniem o pomoc. W przypadku pracowników w firmie produktowej, często jest tak że można umówić się na spotkanie od ręki z UX, DS czy innym działem - przynajmniej ja nigdy nie miałem z tym problemu. Wszyscy sie znają i wiedzą że ich dobrostan zależy od jakości produktu który firma sprzedaje.

Nie lubię być wylewny, ale strasznie mnie ten SCRUM "ztriggerował".

crestfallen napisał(a):

SCRUM i wiążąca się z nim taskoza zupełnie nie nadają się do pracy produktowej.

Często jest tak że w trybie produktowym to inżynierowie wychodzą z propozycjami usprawnień pracując nad daną funkcjonalnością. Ja jestem jeszcze młody, ale widziałem starszych kolegów którzy pracując z product design'erami oraz dyskutując z użytkownikami potrafili zupełnie zmienić koncepcje działania danej funkcjonalności. Sporo usprawnień w produkcie też wychodziło z dogfood'ingu lub z hackatonów - gdzie ludzie dodawali funkcjonalności często pod siebie (np. możliwość dodawania tagów poprzez wpisanie w tekście #tag a nie wyboru w osobnym polu).

no bo korpo do Polski przenosi proste klepanie, ma tu nie być ludzi decyzyjnych
janusze naśladują to co widzą z metod zarządzania z kotpo , czyli jak są zarządzani pracownicy najniższego szczebla, a nie jak przebiega praca tam gdzie są podejmowane decyzje, i próbują to narzucić także inżynierom. cargo cult nie ma prawa zadziałać

@crestfallen: Moim zdaniem niewłaściwie interpretujesz sens stworzenia SCRUM'a, jako narzędzia ucisku developerów, którzy mają wywalone na projekt. Ta metodyka została stworzona w jednym celu - zarobić kasę. To nie jest nic wyjątkowego, bo praktycznie każda formalna metodyka została stworzona w tym samym celu. Książki, podręczniki, szkolenia, certyfikacje,

Moim zdaniem, SCRUM, jako taki powstał ewolucyjnie w jakimś zespole całkiem ogarniętych programistów. Zwyczajnie stwierdzili, że w ich projekcie, zespole, itd. warto spotkać się na 15 minut dziennie i uzgodnić kto co zrobił, czego nie zrobił, z czym ma problem, kiedy wydaje mu się, że skończy to na co czeka ktoś inny, albo co go blokuje. Doszło do tego planowanie pracy, bo przecież trzeba wiedzieć co trzeba zrobić, a na koniec retrospektywa, bo warto też czasami usiąść i zastanowić się co można robić lepiej, wydajniej, albo czego nie należy robić, bo przeszkadza w pracy. Pewnie nawet doszli do wniosku, że można nadać tym czynnościom jakąś kadencję, bo zawsze są rzeczy pilniejsze do zrobienia niż np. przegadanie tasków, które dopiero wejdą.

Jak już udało im się coś zrobić, a wiadomo, że w IT jest to osiągnięcie, wpadli ludzie, którzy opisali metody metody, zrobili scrum guide, dorobili branding i rozkręcili interes na konsultacjach. Trochę marketingu, pierniczenia o tym jak to ich cudowny pomysł sprawia, że projekty rozwoju oprogramowania zaczną się nagle udawać w 80% a nie w 20% i powciskali to zarządom firm.

Przecież ludzie kierujący firmami doskonale zdają sobie sprawę, że coś z tą produkcją oprogramowania jest nie tak. Jak kierujesz taką Biedronką, to sadzasz nowego pracownika na kasie, mówisz co i jak ma być robione i o ile nie jest to kompletny idiota, to po kilku dniach będzie to samodzielnie robił, a po miesiącu osiągnie biegłość. A z drugiej strony, mają jakiś tam dział IT, co ma im zrobić "coś" i Nie wiadomo co zostanie zrobione, ile to będzie kosztowało i czy w ogóle coś użytecznego powstanie. Kiedy z firmy odejdzie jakaś pojedyncza osoba, to nagle projekt, w który wpakowano sporo kasy potrafi się rozpaść w pył.

Ludzie od zarządzania (jakieś tam studia, MBA itp.) są uczeni pewnych nawyków i metod działania. W biznesie wszystko musi być zaplanowane. Otwierasz sklep, to zaczynasz od biznes planu - co będziesz sprzedawać, jaki jest rynek, jakie przychody i marżę możesz uzyskać, jakie będą koszty prowadzenia działalności, w jaki sposób dotrzesz do klientów, co zrobisz jeżeli koszty wyjdą poza zakres, albo jakie działania przewidujesz jeżeli klientów będzie za mało. Na jakim etapie dokonasz oceny wykonania planu itd. Drugim nawykiem jest procesowe podejście do działania firmy, czyli to co próbuje wciskać ISO 9000 - wszystkie istotne działania w firmie są opisane. Jeżeli wdrażamy jakąś zmianę, to wiemy na czym ona polega, wiemy jak mierzyć to co chcemy zmienić i dokonać oceny, czy zmiana była pozytywna, czy negatywna.
I teraz wyobraźcie sobie, że wpada w to IT. Będzie jak zrobimy, jeszcze nie wiemy jak będziemy pracować, wyjdzie jak wyjdzie, nie wiemy dlaczego się udało, nie wiemy dlaczego się nie udało. Jak z firmy odejdzie Zenek, to mamy przerąbane, bo na 100% nie znajdziemy osoby z takim zestawem umiejętności, jakie on ma.

Z punktu widzenia zarządu, SCRUM jest jak życie wieczne w chrześcijaństwie. Warto poświęcić dużo, żeby je dostać. Przecież sytuacja w której mamy projekt, w którym nie ma Zenka, Mietka, Baśki i Julki, a zamiast tego mamy standardowe role product ownera, scrum mastera, java developera, "dev opsa" itd. to nirwana. Któryś z nich zrezygnuje, to zamawiasz w kontraktorni kolejnego, sadzasz przy tej wirtualnej taśmie produkcyjnej i projekt jedzie dalej.

Sam nawet nie jestem jakimś wyjątkowym przeciwnikiem SCRUM'a. Widziałem sporo całkiem sprawnych programistów, którzy kompletnie nie mieli pomysłu na to jak wspólnie pracować. Przed aktualną korektą rynku było też całkiem sporo takich delikatnie mówiąc mniej ogarniętych. Uważam nawet, że SCRUM jako taki może być właściwą metodyką od której zespół zaczyna. Jeżeli faktycznie spotka się na 15 minut dziennie, raz na 2 tygodnie przegada kolejne taski, sprawdzi co zostało zrobione, a co nie i zastanowi się dlaczego, to nikomu się krzywda nie stanie. Po 2 sprintach, może sobie zacząć dostosowywać metody pracy do specyfiki zespołu/projektu i wywalać co się komu podoba.
Problem z tą metodyką polega w gruncie rzeczy na czymś innym i jest to fakt istnienia, a raczej poziom scrum masterów. Kiedyś dorabiałem sobie nauczaniem pływania. Moje kompetencje w tym zakresie, to ileś tam tysięcy godzin w wodzie, parę startów w zawodach, kurs ratownictwa, jakieś tam przygotowanie z metodyki nauczania. Z drugiej strony, mam ~25 lat doświadczenia w IT, ileś tam projektów i firm w CV. Nie jestem może wybitnym programistą, ale coś działającego w życiu napisałem. Nie wiem w jaki sposób miałaby mi pomóc osoba, która wiedzę o rozwijaniu oprogramowania czerpie jedynie z książek, a najczęściej jednej książki.

kelog napisał(a):

Jakbym usłyszał, że dany ficzer musi być do końca miesiąca na produkcji, bo próbujemy podejść nowego klienta i jak nam się uda tym ficzerem go podejść, to dostanę osobiście na konto 10 tys. złotych premii, to wiem o co toczy się gra.

Spoko, pod warunkiem, ze w przeciwnym przypadku biezesz na klate bez slowa fakt iz na koniec miesiaca nie zobaczysz nawet zlotowki.
Typowe podejscie Kalego. Partycypowac w profitach: "moja chce", ponosic konsekwencje porazki: "moja nie chce w zadnym przypadku".

kelog napisał(a):

Firma wygrywa, ja wygrywam. A jak widzę info o kolejnych dedlajnach, i że jak nie dowieziemy to się świat zawali, to wiem, że przekroczyliśmy już mnóstwo dedlajnów i jakoś do 10. wypłata jest, taka sama zawsze. I teraz też raczej będzie. Więc pora na cs-a.

Z robienie "swoje" od 09.00 do 17.00 firma placi Ci zgodnie z umowa ktora podpisales. Ty natomiast oczekujesz dodatkowych benefitow za to ze w ogole dotrzymujesz warunkow umowy.
Dobre.

piotrpo napisał(a):

@crestfallen: Moim zdaniem niewłaściwie interpretujesz sens stworzenia SCRUM'a, jako narzędzia ucisku developerów, którzy mają wywalone na projekt. Ta metodyka została stworzona w jednym celu - zarobić kasę. To nie jest nic wyjątkowego, bo praktycznie każda formalna metodyka została stworzona w tym samym celu. Książki, podręczniki, szkolenia, certyfikacje,

Moim zdaniem, SCRUM, jako taki powstał ewolucyjnie w jakimś zespole całkiem ogarniętych programistów. Zwyczajnie stwierdzili, że w ich projekcie, zespole, itd. warto spotkać się na 15 minut dziennie i uzgodnić kto co zrobił, czego nie zrobił, z czym ma problem, kiedy wydaje mu się, że skończy to na co czeka ktoś inny, albo co go blokuje. Doszło do tego planowanie pracy, bo przecież trzeba wiedzieć co trzeba zrobić, a na koniec retrospektywa, bo warto też czasami usiąść i zastanowić się co można robić lepiej, wydajniej, albo czego nie należy robić, bo przeszkadza w pracy. Pewnie nawet doszli do wniosku, że można nadać tym czynnościom jakąś kadencję, bo zawsze są rzeczy pilniejsze do zrobienia niż np. przegadanie tasków, które dopiero wejdą.

Żaden ogarnięty programista nie wymyślił takiej głupoty chyba że chciał strollować szefa. Syndrom Sztokholmski że sobie racjonalizujesz że na pewno to programiści wymyślili?

Jak już udało im się coś zrobić, a wiadomo, że w IT jest to osiągnięcie, wpadli ludzie, którzy opisali metody metody, zrobili scrum guide, dorobili branding i rozkręcili interes na konsultacjach. Trochę marketingu, pierniczenia o tym jak to ich cudowny pomysł sprawia, że projekty rozwoju oprogramowania zaczną się nagle udawać w 80% a nie w 20% i powciskali to zarządom firm.

no to w końcu ogarnięci czy uważali że jak coś zrobili to jest osiągnięcie? ;)

Ludzie od zarządzania (jakieś tam studia, MBA itp.) są uczeni pewnych nawyków i metod działania. W biznesie wszystko musi być zaplanowane. Otwierasz sklep, to zaczynasz od biznes planu - co będziesz sprzedawać, jaki jest rynek, jakie przychody i marżę możesz uzyskać, jakie będą koszty prowadzenia działalności, w jaki sposób dotrzesz do klientów, co zrobisz jeżeli koszty wyjdą poza zakres, albo jakie działania przewidujesz jeżeli klientów będzie za mało. Na jakim etapie dokonasz oceny wykonania planu itd. Drugim nawykiem jest procesowe podejście do działania firmy, czyli to co próbuje wciskać ISO 9000 - wszystkie istotne działania w firmie są opisane. Jeżeli wdrażamy jakąś zmianę, to wiemy na czym ona polega, wiemy jak mierzyć to co chcemy zmienić i dokonać oceny, czy zmiana była pozytywna, czy negatywna.

g* tam wiedzą, te procesy to taki dupochron a jak nie ma tam nikogo kumatego to nie wiedzą co za zmianę wprowadzają mimo że mają opisane co jest czajnikiem do kawy wiec błędu http 418 nie dostaną

I teraz wyobraźcie sobie, że wpada w to IT. Będzie jak zrobimy, jeszcze nie wiemy jak będziemy pracować, wyjdzie jak wyjdzie, nie wiemy dlaczego się udało, nie wiemy dlaczego się nie udało. Jak z firmy odejdzie Zenek, to mamy przerąbane, bo na 100% nie znajdziemy osoby z takim zestawem umiejętności, jakie on ma.

bo się zatrudnia skończoną liczbę studentów a wywala fachowca więc wtedy naprawdę nie wiedzą co robią

Z punktu widzenia zarządu, SCRUM jest jak życie wieczne w chrześcijaństwie. Warto poświęcić dużo, żeby je dostać. Przecież sytuacja w której mamy projekt, w którym nie ma Zenka, Mietka, Baśki i Julki, a zamiast tego mamy standardowe role product ownera, scrum mastera, java developera, "dev opsa" itd. to nirwana. Któryś z nich zrezygnuje, to zamawiasz w kontraktorni kolejnego, sadzasz przy tej wirtualnej taśmie produkcyjnej i projekt jedzie dalej.

Vorbis ze Świata Dysku z takim rozumowaniem
progmofo to Brutha

Sam nawet nie jestem jakimś wyjątkowym przeciwnikiem SCRUM'a. Widziałem sporo całkiem sprawnych programistów, którzy kompletnie nie mieli pomysłu na to jak wspólnie pracować. Przed aktualną korektą rynku było też całkiem sporo takich delikatnie mówiąc mniej ogarniętych. Uważam nawet, że SCRUM jako taki może być właściwą metodyką od której zespół zaczyna. Jeżeli faktycznie spotka się na 15 minut dziennie, raz na 2 tygodnie przegada kolejne taski, sprawdzi co zostało zrobione, a co nie i zastanowi się dlaczego, to nikomu się krzywda nie stanie. Po 2 sprintach, może sobie zacząć dostosowywać metody pracy do specyfiki zespołu/projektu i wywalać co się komu podoba.
Problem z tą metodyką polega w gruncie rzeczy na czymś innym i jest to fakt istnienia, a raczej poziom scrum masterów. Kiedyś dorabiałem sobie nauczaniem pływania. Moje kompetencje w tym zakresie, to ileś tam tysięcy godzin w wodzie, parę startów w zawodach, kurs ratownictwa, jakieś tam przygotowanie z metodyki nauczania. Z drugiej strony, mam ~25 lat doświadczenia w IT, ileś tam projektów i firm w CV. Nie jestem może wybitnym programistą, ale coś działającego w życiu napisałem. Nie wiem w jaki sposób miałaby mi pomóc osoba, która wiedzę o rozwijaniu oprogramowania czerpie jedynie z książek, a najczęściej jednej książki.

jakiej książki? jak przeczyta ulotkę z kursu to dobrze

Miang napisał(a):

bo się zatrudnia skończoną liczbę studentów a wywala fachowca więc wtedy naprawdę nie wiedzą co robią

Skoro ten "fachowca" publicznie glosi koniecznosc zakladania zwiazkow zawodowych, to nadwyraz dobrze wiedza co robia.

hyper-stack napisał(a):

Skoro ten "fachowca" publicznie glosi koniecznosc zakladania zwiazkow zawodowych, to nadwyraz dobrze wiedza co robia.

Trochę nie na temat, ale zabawne jest, jak branża IT w ciągu 3 lat potrafiła przejść z twardego monetaryzmu do obrony praw pracowniczych.

Natomiast już w temacie:

@Miang napisał(a):
bo się zatrudnia skończoną liczbę studentów a wywala fachowca więc wtedy naprawdę nie wiedzą co robią

To jest miara postępu. Kiedyś kucharze musieli umieć gotować. Dzisiaj większość stołówek i fast foodów może zatrudnić każdego z książeczką sanepidu.

Praca w takim trybie (scrumie) jest dla mnie osobiście irytujaca. Pojawianie sie menadżerów bądź tzw. team coach'ów na daily i czepianie się dlaczego dany task jeszcze nie jest na jirze w kolumnie: 'In review' sprawia, że ja jako developer czuję ciągła presję. Nadmiar niepotrzebnych spotkań, na których ja jako developer muszę brać czynny udział (mam na myśli pokazywanie rezultatu jakiegoś zadania przed biznesem i tłumaczyć inne rzeczy). Zabawne jest szerzenie informacji, że takie podejście ułatwia pracę i praca staje się bardziej przewidywalna.

Najlepsze jest to że Ci co chcą kierować zespołami programistów, wprowadzać Agile, mierzyć efektywność, usprawniać procesy w życiu nie napisali ani jednej linii kodu.

W wielu poważnych branżach by coś takiego nie przeszło, np. nie wyobrażam sobie by na oddziale zamiast ordynatora (który był wcześniej lekarzem) była kobieta po 3 miesięcznym kursie.

Tak samo w fabrykach, nie wyobrażam sobie by kierownikiem zespołu elektryków był gość po kursie zarządzania.

Tylko w IT się taka patologia zrobiła bo był olbrzymi deficyt ludzi i naciągnęło pełno ludzi z innych branż.

No i potem powstają kwiatki że Julka po kulturoznawstwie bawi się w IT i będzie Ci mierzyć efektywność i decydować o Twojej podwyżce.

Mbappe_koksik napisał(a):

No i potem powstają kwiatki że Julka po kulturoznawstwie bawi się w IT i będzie Ci mierzyć efektywność i decydować o Twojej podwyżce.

To nie są kwiatki tylko proste wprowadzenie eugeniki populacyjnej tylnymi drzwiami.

Badania jasno wskazują że korelacja IQ - wygląd jest wyjątkowo mocna. Zdarzają się wyjątki ale wyjątki potwierdzają regułę. Chcemy utrzymać ogólny trend Flynna w populacji a nie przekierować nadwyżek produkcji do niechcianej puli genetycznej w której przez przypadek z gwiazd narodził się geniusz - zresztą jest spora szansa że ten przypadek genów nie przekaże dalej więc te nadwyżki zostaną zjedzone przez jego najbliższych wzmacniając miernotę genetyczną.

Julki nie są głupie - ewolucja naszego gatunku już o to zadbała :)

Mbappe_koksik napisał(a):

Najlepsze jest to że Ci co chcą kierować zespołami programistów, wprowadzać Agile, mierzyć efektywność, usprawniać procesy w życiu nie napisali ani jednej linii kodu.

W wielu poważnych branżach by coś takiego nie przeszło, np. nie wyobrażam sobie by na oddziale zamiast ordynatora (który był wcześniej lekarzem) była kobieta po 3 miesięcznym kursie.

Tak samo w fabrykach, nie wyobrażam sobie by kierownikiem zespołu elektryków był gość po kursie zarządzania.

Tylko w IT się taka patologia zrobiła bo był olbrzymi deficyt ludzi i naciągnęło pełno ludzi z innych branż.

No i potem powstają kwiatki że Julka po kulturoznawstwie bawi się w IT i będzie Ci mierzyć efektywność i decydować o Twojej podwyżce.

Masz bardzo słaba wyobraźnię. Albo raczej wiedzę o świecie. Budową kierują inżynierowie którzy nigdy nie w bili gwoździa. A ty tu jesteś od wbijania gwoździ o nie od mierzenia efektywności. Trzeba było is na kulturoznawstwo.

Pracowałem kiedyś w firmie w której każdy team manager dla zespołu programistów musiał obowiązkowo przejść coding interview. Był płacz że 80% ludzi nawet do tego nie podchodzi, a przechodziło taką rekrutację może z 5% managerów - niemniej firma była nieugięta. CEO nie był programistą ale był człowiekiem technicznym (sysadmin) i wiedział że zarządzać programistami może tylko osoba która wcześniej sama programowała.

Jeżeli manager nie programował to pojęcia takie jak tech debt będą dla niego abstrakcyjne, to samo dotyczy jakości kodu czy QA. Taki manager będzie podążał za dobrymi praktykami wyznaczonymi przez firmę (np. pokrycie kodu > 80%), ale nie będzie wiedział o co naprawdę w tym wszystkim chodzi. Ostatecznie często kończy się to znacznym spadkiem jakości kodu, ucieczką najlepszych ludzi i koniecznością przepisania od nowa.

Nadal szukam pracy i jedna rzecz o którą pytam to właśnie to czy manager miał choćby niewielkie doświadczenie w programowaniu. Uważam też na świeżych managerów dla których taki przeskok to "awans", za duże ryzyko że gościowi woda sodowa do głowy uderzy.

Adin napisał(a):

Masz bardzo słaba wyobraźnię. Albo raczej wiedzę o świecie. Budową kierują inżynierowie którzy nigdy nie w bili gwoździa. A ty tu jesteś od wbijania gwoździ o nie od mierzenia efektywności. Trzeba było is na kulturoznawstwo.

Budową kierują inżynierowie, a nie przypadkowe osoby po miesięcznym kursie zarządzania przedszkolem dla inżynierów.

Żeby dostarczyć dobre oprogramowanie, trzeba:

• dokładnie wiedzieć co ma robić
• napisać oprogramowanie
• udowodnić, że to co zostało napisane robi to co miało robić

Czasami, niektóre z tych kroków mogą wymagać dodatkowych czynności, ale powinny one bezpośrednio wspierać powyższe kroki. Jeżeli z jakiegoś powodu ważna jest wiedza jak duży mamy backlog (czyli jak głęboka jest wiedza "co to ma robić"), to można to oszacować. Jeżeli są problemy z wiedzą co zostało zrobione, to można sobie ustawić jakiegoś kanbana, czy statusy. Problem się zaczyna w momencie kiedy "jak to robimy" staje się ważniejsze od "co robimy i po co".

piotrpo napisał(a):

Adin napisał(a):

Masz bardzo słaba wyobraźnię. Albo raczej wiedzę o świecie. Budową kierują inżynierowie którzy nigdy nie w bili gwoździa. A ty tu jesteś od wbijania gwoździ o nie od mierzenia efektywności. Trzeba było is na kulturoznawstwo.

Budową kierują inżynierowie, a nie przypadkowe osoby po miesięcznym kursie zarządzania przedszkolem dla inżynierów.

Patrząc po niektórych realizacjach to mam wątpliwości. I jak ktoś zatrudnia niekompetentnych ludzi nie znaczy że cos nie działa.

Żeby dostarczyć dobre oprogramowanie, trzeba:

• dokładnie wiedzieć co ma robić
• napisać oprogramowanie
• udowodnić, że to co zostało napisane robi to co miało robić

Scrum master tak naprawdę to niczego ni dostarcza tylko dba o to żeby wszystko byłe zrealizowane w czasie i budżecie. Za jakość odpowiadają programiści testerzy i architekci.

Czasami, niektóre z tych kroków mogą wymagać dodatkowych czynności, ale powinny one bezpośrednio wspierać powyższe kroki. Jeżeli z jakiegoś powodu ważna jest wiedza jak duży mamy backlog (czyli jak głęboka jest wiedza "co to ma robić"), to można to oszacować. Jeżeli są problemy z wiedzą co zostało zrobione, to można sobie ustawić jakiegoś kanbana, czy statusy. Problem się zaczyna w momencie kiedy "jak to robimy" staje się ważniejsze od "co robimy i po co".

Od backloga jest product owner. No ale jak już wspomniałem ze brak kompetentnych ludzi to jest inna sprawa i poza tym co robi ważne tez jest jak żeby okazało się ze na końcu zajęło to 4 razy więcej czsu i projekt przez to jest nie rntowny i wszystkich nalezy wywalić.

Adin napisał(a):

Patrząc po niektórych realizacjach to mam wątpliwości. I jak ktoś zatrudnia niekompetentnych ludzi nie znaczy że cos nie działa.

Jak ktoś zatrudnia niekompetentnych ludzi, to nie działa. To, że korporacyjna zgraja programistów z łapanki pod kierownictwem korporacyjnej zgrai specjalistów od martwienia się o projekt coś tam w bólach urodzi nie oznacza jeszcze, że "działa". Może kiedyś będzie tak jak na taśmie produkcyjnej konserw - pracownik ma stać i pakować puszki do kartonu w tempie taśmociągu, ma wytrzymać 8 godzin dziennie z przerwami regulaminowymi, a jak się zużyje, to go się wymieni. Dzisiaj tak nie jest i jeszcze przez jakiś czas nie będzie.

Scrum master tak naprawdę to niczego ni dostarcza tylko dba o to żeby wszystko byłe zrealizowane w czasie i budżecie. Za jakość odpowiadają programiści testerzy i architekci.

No widzisz, sam sobie odpowiadasz. Tylko zadaj sobie następne pytania. Skoro niczego nie dostarcza, a podnosi koszt projektu, w dodatku zajmuje innym czas, to po co go trzymać?

Od backloga jest product owner. No ale jak już wspomniałem ze brak kompetentnych ludzi to jest inna sprawa i poza tym co robi ważne tez jest jak żeby okazało się ze na końcu zajęło to 4 razy więcej czsu i projekt przez to jest nie rntowny i wszystkich nalezy wywalić.

Czy to jest product owner, product manager, project manager, czy jakiś tam inżynier nie ma znaczenia. Ważne, że nie jest to rola scrum mastera.

Mbappe_koksik napisał(a):

W wielu poważnych branżach by coś takiego nie przeszło, np. nie wyobrażam sobie by na oddziale zamiast ordynatora (który był wcześniej lekarzem) była kobieta po 3 miesięcznym kursie.

Tak samo w fabrykach, nie wyobrażam sobie by kierownikiem zespołu elektryków był gość po kursie zarządzania.

i w polityce

Tylko w IT się taka patologia zrobiła bo był olbrzymi deficyt ludzi i naciągnęło pełno ludzi z innych branż.

nie z powodu deficytu, tylko że zobaczyli kasę i mieli znajomych na wyższych szczeblach zarządzania

No i potem powstają kwiatki że Julka po kulturoznawstwie bawi się w IT i będzie Ci mierzyć efektywność i decydować o Twojej podwyżce.

julka bierze swoja "wiedzę" z gazetek firmowanych przez ratlerekjob i dlatego kobiety odrzuca na starcie, czego wielu tu kolegów nie zauważa bo "przecież u mnie w korpo jest programistka" zupełnym przypadkiem jest to psiapsiólka julki lub kogoś z dyrekcji

Za jakość odpowiadają programiści testerzy i architekci.

Za jakość odpowiada każdy w firmie od woźnego po CEO. Stąd też duża popularność obecnie tzw. dog-foodingu - czyli używania wewnętrznie swojego produktu, często w wersji ze środowiska stage'ingowego.

Jakość oprogramowania to nie tylko brak błędów czy wycieków pamięci - ale też łady wygląda, przemyślany interface (np. brak przeładowania funkcjami), dobra dokumentacja i dział wsparcia technicznego.

Na koniec dodam że dobry software często oparty jest na genialnym pomyśle - vim, Google Search, Google Docs, Git, JVM, TCP... - Scrum zupełnie nie sprawdzi się tam gdzie trzeba coś wymyśleć, opatentować. Duże firmy IT mogą sobie pozolić na trzymanie naukowców którzy przez 3 lub 4 lata "nic nie robią" żeby w piątym roku wyjść z architekturą transformerów lub algorytmem oszczędnej kryptowaluty.

Adin napisał(a):

Za jakość odpowiadają programiści testerzy i architekci.

Z tym się nie zgodzę. Przypomina mi to obwinianie żołnierzy za to że przegrali bitwę. Podejście typowego Janusza fachowca.

Programiści w korporacji są elementem systemu, który wytwarza oprogramowanie. To, że nie ma jakości nie tylko od programistów zależy, ale także od budżetu, strategii rozwoju, czasu, zaplecza, kompetencji, komunikacji itd.

Długo by wymieniać.

Tak samo jak bitwę przegrywają żołnierze, to zwala się na nich winę, bo najłatwiej, ale nikt nie pomyślał o tym, że może mieli za słabe zaplecze, złą komunikację, za słabe uzbrojenie albo padła zła decyzja od generała o porze ataku.

Za jakość odpowiada cała firma, począwszy od dyrektora skończywszy na testerze, poprzez Agile Coacha, Analityka, skończywszy na HR Managerze.

crestfallen napisał(a):

Pracowałem kiedyś w firmie w której każdy team manager dla zespołu programistów musiał obowiązkowo przejść coding interview. Był płacz że 80% ludzi nawet do tego nie podchodzi, a przechodziło taką rekrutację może z 5% managerów - niemniej firma była nieugięta. CEO nie był programistą ale był człowiekiem technicznym (sysadmin) i wiedział że zarządzać programistami może tylko osoba która wcześniej sama programowała.
Jeżeli manager nie programował to pojęcia takie jak tech debt będą dla niego abstrakcyjne, to samo dotyczy jakości kodu czy QA. Taki manager będzie podążał za dobrymi praktykami wyznaczonymi przez firmę (np. pokrycie kodu > 80%), ale nie będzie wiedział o co naprawdę w tym wszystkim chodzi. Ostatecznie często kończy się to znacznym spadkiem jakości kodu, ucieczką najlepszych ludzi i koniecznością przepisania od nowa.

Problem polegał zatem na istnieniu managerów zarządzających programistami.

Przez prawie 5 lat pracowałem z PO i SM, którzy byli nietechniczni, i żadne z nich nigdy nie poddawało w wątpliwość przeznaczania 10% sprintu na usuwanie długu technicznego.

Po prostu, są projekty IT, i są generyczne projekty z programistami w środku. Trzeba szukać pracy w pierwszych, a nie w drugich.

U mnie w firmie jest projekt waterfall prowadzony w duchu agile. Na szczęście zostałem przeniesiony do małego zespołu w którym nie mamy takich bzdur.

several napisał(a):

Jak ma się u was SCRUM w 2025?

Nie praktykujemy od kilku lat. Mamy tablicę z zadaniami, jakieś ad hoc planawowanie jak potrzeba i tyle. Żadnych sprintów itp.

Nooo to teraz zmieniłem firmę na korpo i właśnie mam szkolenie z jiry i scruma :D

Mbappe_koksik napisał(a):

Adin napisał(a):

Za jakość odpowiadają programiści testerzy i architekci.

Z tym się nie zgodzę. Przypomina mi to obwinianie żołnierzy za to że przegrali bitwę. Podejście typowego Janusza fachowca.

Programiści w korporacji są elementem systemu, który wytwarza oprogramowanie. To, że nie ma jakości nie tylko od programistów zależy, ale także od budżetu, strategii rozwoju, czasu, zaplecza, kompetencji, komunikacji itd.

Długo by wymieniać.

Tak samo jak bitwę przegrywają żołnierze, to zwala się na nich winę, bo najłatwiej, ale nikt nie pomyślał o tym, że może mieli za słabe zaplecze, złą komunikację, za słabe uzbrojenie albo padła zła decyzja od generała o porze ataku.

Za jakość odpowiada cała firma, począwszy od dyrektora skończywszy na testerze, poprzez Agile Coacha, Analityka, skończywszy na HR Managerze.

Zależy co mamy na mysli mówiąc "jakość". Jeśli mówimy o jakości kodu, testów, rozwiązaniach, implementacji, wydajności, etc. to jaknajbardziej odpowiadają za to programiści, można powiedzieć że tylko i wyłącznie.

Jeśli przez "jakość" masz na myśli powstały produkt, dopasowanie do rynku, spełnianie wymagań, UX, to jak dobrze produkt wypełnia niszę, to czy był dostarczony na czas, etc. to faktycznie mogę się zgodzić że nie tylko programiści mają na to wpływ.

@Riddle

Jeśli mówimy o (...) wydajności, etc. to jak najbardziej odpowiadają za to programiści, można powiedzieć że tylko i wyłącznie.

Nie wyłącznie.

Jeżeli chcesz dbać o wydajność na wysokim poziomie przy złożonym produkcie, to musisz mieć do tego infrę i zespół, ktory będą wyłapywać regresję i tworzył raporty wydajnościowe pomiędzy releasami.

Czasami infra do robienia tego typu rzeczy w sensownej skali potrafi być równie skomplikowana co sam produkt.

Riddle napisał(a):

Mbappe_koksik napisał(a):

Adin napisał(a):

Projekt musi być dobry, oraz założenia muszą być dobre

Zależy co mamy na mysli mówiąc "jakość". Jeśli mówimy o jakości kodu, testów, rozwiązaniach, implementacji, wydajności, etc. to jaknajbardziej odpowiadają za to programiści, można powiedzieć że tylko i wyłącznie.

Dostają warunki brzegowe i w ich granicach powinni to zrobić dobrze

Niektórzy potrafią samodzielnie je zmieniać bez powiadomienia nikogo

@Mbappe_koksik

Tak samo musisz mieć budżet i określony czas na development. Ja niejednokrotnie słyszałem, że lepiej zrobić coś teraz szybciej (wspomniałeś o implementacji), a tamto się później poprawi (czyt. nigdy).

Jaki jest najlepszy dług?

Anulowany - podobnie jak kredyt President Joe Biden has now overseen the cancellation of student loans

Czasem naprawdę nie warto spłacać długu technologicznego, bo nierzadko dzieje się tak że projekt jest anulowany, ubijany, klient rezygnuje, itd, itd.

Mbappe_koksik napisał(a):

Tak samo musisz mieć budżet i określony czas na development. Ja niejednokrotnie słyszałem, że lepiej zrobić coś teraz szybciej (wspomniałeś o implementacji), a tamto się później poprawi (czyt. nigdy).

Jasne. W takim wypadku odpowiedzialny programista powinien zrobić tyle feature'ów pisząc kod wysokiej jakości ile się da. Pozostałe "wymagane" feature'y dopisać później, jak będzie budżet i czas.

Często managerowie lub ludzie z góry będą narzucać niemożliwe zadania - zrób mi 20 dodatkowych funkcjonalności w 30 dni - często tego się nie da zrobić. Nieodpowiedzialny programista jest przekonany że nie może powiedzieć "nie" - że musi tak czy inaczej się zgodzić na ten termin.

Warto komunikować "ludziom u góry" ile może zająć wytworzenie takich funkcjonalności.

• Programista: 20 funkcji? To zajmie 60 dni
• Manager: Ale ja to potrzebuję za 30 dni.
• Programista: Za 30 dni mogę przygotować 10 funkcji.
• Manager: Ale ja potrzebuję wszystkie 20.
• Programista: Zrobienie wszystkich 20u zajmie 60 dni.
• Manager: Ale ja to potrzebuję za 30 dni.
• ...btw,, to może trwać chwilę.

W pewnym momencie ludzie u góry zrozumieją, że to czego chcą albo zajmie dłużej, albo będzie mniej funkcjonalności. Wymaga to pewnego obycia i wyrachowania, żeby przeprowadzić taką komunikację, ale jest to do zrobienia.

WeiXiao napisał(a):

Jeśli mówimy o (...) wydajności, etc. to jak najbardziej odpowiadają za to programiści, można powiedzieć że tylko i wyłącznie.

Nie wyłącznie.

Jeżeli chcesz dbać o wydajność na wysokim poziomie przy złożonym produkcie, to musisz mieć do tego infrę i zespół, ktory będą wyłapywać regresję i tworzył raporty wydajnościowe pomiędzy releasami.

Czasami infra do robienia tego typu rzeczy w sensownej skali potrafi być równie skomplikowana co sam produkt.

Tak - jest kilka miejsc które mogą spowolnić performance. W takim wypadku, programiści którzy wytwarzają produkt, moim zdaniem, powinni podczas wdrożenia lub zaraz po nim sprawdzić (manualnie lub automatycznie) wydajność aplikacji na produkcji albo (jeśli się da) w systemie produkcjo-podobnym, i sprawdzić czy wymagania wydajności spełniają pożądane kryteria. Jeśli nie - powinni albo zadziałać żeby je poprawić, albo zakomunikować ludziom od infra i górze co się dzieje.

Nie można powiedzieć że programiści nie są odpowiedzialni za wydajność, bo jeśli będą tworzyć rozwiązania np. które mają O(n^2), to wiadomo że się przyczynią do spadku wydajności. Nie są też całkowicie odpowiedzialni, bo wydajność może tez spaść przez kogoś innego - np. infra nie dostarczy odpowiednich zasobów do maszyn.

@Riddle tylko określenie ile to zajmie zajmuje trzy dni i musi to robić doświadczony programista. Dlatego właśnie makretoidy wolą jeżeli tylko mają na to wpływ zatrudniać juniorów