Wątek przeniesiony 2021-06-05 16:46 z Inne języki programowania przez cerrato.

Co to ten scrum, bo już nie wiem.

1

Ja napisałem moją definicję, bo rozumiem że scrum może być dobry, ale nie spotkałem się z dobrą implementacją ;)

4
hadwao napisał(a):

No właśnie do tego się sprowadzają wszystkie metodyki zwinne, że powinno zależeć wszystkim - inaczej nie ma to sensu.

Więc trzeba wywalić z pracy cały middle level management. Bo programistom często nawet zależy na tym, na czym zależy zarządowi - na działającym sofcie. Niestety wszystko rozbija się o indolencję, ignorancję i wyścig szczurów uprawiany właśnie przez różnych kierowników i kierowniczków.

To co ja widzę w projektach to w 80% są albo programiści, którzy w ogóle mają blazę albo trochę im zależy, ale nie mają siły przebicia. Często nie potrafią przekształcić swojego narzekania w konstruktywne argumenty. Niestety komunikacja zazwyczaj właśnie tak wygląda, że strony mają swoje zdania i muszą się nawzajem przekonać do zmiany postępowania.

To nie jest kwestia zdań - po prostu z jednej strony są fakty, a z drugiej ich ignorowanie.

Wielokrotnie już byłem w sytuacji, gdzie chodziłem za jakimiś zmianami na których zespół postawił już dawno kreskę i zazwyczaj po odpowiedniej ilości powtórzeń udawało się uzyskać przychylność góry.

A pozwolili Ci chociaż polizać zdjęcie tego jachtu? :P

Mnie nauczono, że jeśli ktoś za trzecim razem nie łapie, to wymaga specjalnych metod dydaktycznych, do których wdrażania ja po prostu nie mam kompetencji. Oligofrenopedagogika to są bardzo ciężkie studia.

Żeby nie było, że twierdzę, że tylko my zawalamy. Wielokrotnie spotkałem się już z patozarządzeniem, gdzie PM był jak dziecko we mgle. Zgadzam się, że to PM powinien być wyczulony na sygnały z zespołu i liczyć się z brakiem soft-skili części technicznej zespołu.

Mam wątpliwości, czy w sytuacji, gdy PM nie słucha, to nie programistom brak umiejętności miękkich.

Niestety to jest po prostu rzeczywistość i żadne z ogniw nie jest doskonałe i bez winy. Niemniej jeśli chcemy uchodzić za profesjonalistów, to powinniśmy zawsze trzymać fason, dawać jasny feedback, starać się naprawiać to co nie funkcjonuje dobrze - po prostu woda drąży skałę.

A po wodzie pływa jacht. Nie Twój. :P

Jak rozumiem jesteś taką Matką Teresą Projektów IT i chcesz je bezinteresownie poprawiać. Może po prostu jeszcze Ci się chce, bo np. nikt Ci nigdy nie powiedział, że jesteś od roboty a nie od myślenia, albo zawsze trafiasz na niepatologiczne kierownictwo - ale w tej sytuacji powinieneś grać w totka, bo to niesamowity fart życiowy.

Programista może naprawiać to co nie funkcjonuje dobrze w kodzie i dookoła niego, ale nie na poziomie organizacji pracy, bo nie ma tam mocy decyzyjnej, a jeśli proces jest oparty o jakąś sektę typu scrum, to i tak się go nie pokona. Nawet nie warto zaczynać dyskusji, że da się inaczej, bo zostanie się zjedzonym.

4

@somekind: z dobrym soft skillem jesteś w stanie pracować z 80% osób powszechnie uznawanych za toksyczne. Ja w ostatnich latach nie trafiłem nigdy na sytuację aby ktoś otwarcie podważył mój autorytet czy kompetencje albo powiedział mniej lub bardziej otwarcie, że mam się zamknąć i robić swoje. Oczywiście są jednostki, które są tak patologiczne, że się po prostu nie da, ale to jest margines i póki co w IT jeszcze nie miałem okazji takiej spotkać nawet w kilku krótkich epizodach z korpo.

Co do tego czy w projekty angażuję się charytatywnie... Głupio się przyznać, ale tak - po prostu mam taką naturę, że jak coś nie działa to nie potrafię koło tego przejść obojętnie + jak to kiedyś określiła jedna HRk'a mam taką zdolność, że nawet o problemach mówię tak, że ludzie się cieszą, że będą mogli je rozwiązać.

Jako, że jednak głupi ma zawsze szczęście, to mimo, że robię to charytatywnie to jednak finalnie dobro wraca w postaci $$$. Jachtu może nie mam, ale oprócz pensji w górnych widełkach w mojej technologii mam jeszcze kilka fajnych, wartościowych i dość niespotykanych w IT benefitów. Ale tak jak pisałem to raczej efekt uboczny, gdyby ich nie było też bym się angażował bo to po prostu lubię.

1

@somekind: Nie chcę pisać, że przesadzasz. Nie wiem do jakich firm i zespołów trafiłeś. Od siebie mogę napisać tyle, że poza jakimś polskim piekiełkiem w którym pracowałem lata temu, gdzie faktycznie występował taki feudalny ustrój, że ludzie z działu A nie lubią ludzi z działu B, bo ich managerowie się ze sobą nie potrafią dogadać, spotkałem się jedynie ze sporadycznymi przypadkami ludzi, z którymi nie chcę więcej pracować. Wręcz znam z życia przypadki kiedy takie osoby leciały z roboty, bo nikt z nimi nie chciał pracować. Również na stanowiskach managerskich. Co do samego Scruma, nie przeczę, że spora część adźajl kołczy to szczególna kompilacja braku podstawowej wiedzy o rozwoju oprogramowania, frazesów z podręcznika przygotowującego do certyfikacji, sporych kompleksów i jescze większych ambicji. Z perspektywy iluś tam lat, w każdym z projektów w którym byłem dało się ostatecznie olać scrumowe pierdoły i zacząć robić swoją robotę. Taka ciekawostka, jak zespół dowozi, to absolutnie wszyscy mają wywalone na to jak dobrze działa w nim Scrum. Z drugiej strony, postrzeganie wszystkich ludzi dookoła jako idiotów jest niebezpieczną praktyką. To, że potrafisz coś zrobić, nie znaczy jeszcze, że ktoś z innym zasobem wiedzy i doświadczenia nie ma lepszego pomysłu.

0

Ja tak w sumie patrze z dość specyficznej perspektywy z której niektóre (bo nie te religijne :D) praktyki agilowo-scrumowe nawet mają sens. U mnie problem nie jest taki, że ludzie w zespole są słabi, ale taki, że mamy jakieś 2x więcej projektów niż developerów (podkreślam projektów, nie serwisów, bo tych to mamy pewnie o rząd wielkości więcej, ale developuje się je skokowo, np. N miesięcy rozwijamy X, a potem bierzemy się za Y a do X wrócimy za jakiś czas, więc nawet jak jest dużo to sporo jest zamrożona w konkretnej chwili). Przez projekt, rozumiem zupełnie odrębny system, z innymi "klientami", innym managerem, innymi priorytetami i deadlinami i często zupełnie inną domeną a może i też technologią.

I teraz w takim projekcie masz ludzi przydzielonych na ułamek etatu, zwykle na poziomie 0.1-0.4. Tak, to oznacza że możesz mieć developera który technicznie rzecz biorąc może w ciągu 2 tygodniowego sprintu poświęcić na ten konkretny projekt 1 dzień :D
Że to patologia, to nie trzeba nawet pisać, no ale jest jak jest, tak sobie ludzie poestymowali to tak mają. I teraz w takim układzie bardzo wygodnie mieć pewne jasne struktury, ustalone spotkania, czas na retro itd, bo może tak być, że ciągle "rozmijasz" się z innymi ludźmi z którymi pracujesz w projekcie X, bo akurat jak ty coś robisz w X, to oni robią w Y, albo jedyna osoba która może ci w tej chwili pomóc, klika inny projekt z krótszym deadlinem. Podobnie wcale nie takie oczywiste staje się kto, kiedy i nad czym w danej chwili pracuje, albo z czym ma problem.
Ciekawie robi sie jak deadliny się nakładają i PMowie i Product Ownerzy walczą na gołe klaty o te ułamki developera ;)

2

@Shalom: To dłuższy temat, więc już nie w komentarzu. Ja nie widzę większego sensu w większości praktyk scrumowych. Za to widzę wielką wartość w praktykach inżynierii oprogramowania, które powstały ze względu na podejście agile, albo przynajmniej zostały spopularyzowane. Automatyzacja testów, wszystko wokół CI/CD, clean code, całe DevOps, YAGNI mindset to zestaw narzędzi, które nie powstałyby, gdyby nie zwinne podejście do programowania. Zresztą moim zdaniem "agile" kompletnie nie ma sensu jeżeli projekt nie korzysta z podejścia CD, czy automatyzacji testów, bo o jakiej elastyczności mówimy, jak od momentu odpalenia release'a, do momentu pojawienia się produktu na produkcji mijają 2 miesiące, bo tyle trwa przeprowadzenie testów, testów UAT, przygotowanie release notes, wrzucenie na środowisko stabilizacyjne itd. Mało mnie obchodzi czy estymaty są w storypointach, dniach, czy ich (o zgrozo) nie ma. Dla mnie może nawet nie być daily, albo można je ogarnąć na slacku raz na tydzień. Natomiast nie bardzo chcę brać udział w projekcie, gdzie testów jednostkowych brak, testów integracyjnych brak, napisanie prostego ficzera to miesiąc, bo w jednym sprincie ktoś go niby robi, w drugim ktoś go niby testuje itd. W sumie, to jedyna rzecz, która mi weszła, to "transparentność" w sensie nieokłamywania się, że jakiś ficzer jest skończony, jakiś test przeszedł, a jak przerzucimy pół zadania do następnego zadania, to możemy powiedzieć, żę w tym sprincie wyrobiliśmy się z czymś tam.

3

@piotrpo: Jakbym w swoich projektach nie cisnął żeby było CI/CD, testy automatyczne, code-review i clean code to by był jakiś dramat nie do ogarnięcia. A są takie projekty gdzie wiem że tego nie ma i jak tylko wspomnę komuś że fajnie by było jakby dodali nową funkcje, to gościa zlewa zimny pot i bierze urlop zdrowotny ;) Ale ja hołduje pracy u podstaw, powoli trzeba przekonać ludzi dobrym przykładem, że da się lepiej.
Pracuje tu od 2 lat. SVN zamienił się w gitlaba, code review są na porządku dziennym a nie było ich wcale (nie trzeba wiele, ot pingujesz ludzi do merge requesta żeby ci zrobili review i po jakimś czasie sami też zaczynają o to prosić), testy integracyjne i testcontainers jako normalna praktyka, a coś takiego w ogóle nie istniało, metryki, a na co to komu? zamieniło się w narzekanie na retro, że czemu w grafanie brakuje wykresu dla XYZ, blady strach przed deployem zamienił się w automatyczny deploy po mergu do odpowiedniego brancha jak tylko testy przechodzą (bo jak wreszcie zaczęli pisać sensowne testy a nie mocksturbacje, to nagle uwierzyli, że zielony test = ficzer działa i nie trzeba dodatkowo żmudnie sprawdzać "dla pewności").

(nie mówie że to wszystko moja zasługa, może to tylko zbieg okoliczności ;) )

Ale to wszystko są dla mnie technikalia trochę ortogonalne do problemów zarządzania projektem w których pomagaja agilow praktyki.

0

Większość tej dyskusji aktualnie w wątku jest właśnie idealnym przykładam na to co wcześniej napisałem - nie zgłębienie tematu i traktowanie go po macoszemu. O jakich praktykach Scrumowych piszecie? Przecież Scrum to ramy, tam nie ma praktyk innych niż te co sami wniesiecie, jedyne co to pojawia się jakiś rytm konkretnych spotkań które mają zaznaczony cel - ot cała magia. IMHO takie twarde zastosowanie iteracji (żeby nie pisać sprintu) jest właśnie takim "motywatorem" do wprowadzania zmian np. w praktykach inżynierskich o których wspomniał wyżej @Shalom. Jak masz czwartą iterację za sobą i na pytanie "Co udało się zrobić?" (upraszczając), wciąż wzrusza się ramionami zrzucając winę że czegoś nie ma (np. testów, czy jasnych wymagań) na drugą stronę, to odpowiedzialnych za ten stan rzeczy powinno się szukać w wielkim zbiorowym lustrze, a nie w tej czy innej metodzie, szczególnie tak prostej w budowie jak Scrum.

Osobiście myślę, że na wysokim poziomie abstrakcji Scrum nie oferuje nic ponad takie metody jak np. odhaczanie każdego dnia w którym czytałeś książkę i podsumowywanie na koniec miesiąca czy osiągnąłeś efekty które zamierzałeś. Jak nie, to tylko Ty możesz zmieniać swoje praktyki, żadne ✓ w kalendarzu nie zmienią rzeczywistości za Ciebie.

Można by też powiedzieć tak - Scrum to takie własnego mieszkanie, które jest w stanie developerskim, więc jakieś ramy (ograniczenia) ma, ale co do zasady urządzasz je po swojemu, jak zrobisz w nim syf, to nie jest to raczej wina budowlańców którzy postawili 4 ściany.

3
hadwao napisał(a):

@somekind: z dobrym soft skillem jesteś w stanie pracować z 80% osób powszechnie uznawanych za toksyczne. Ja w ostatnich latach nie trafiłem nigdy na sytuację aby ktoś otwarcie podważył mój autorytet czy kompetencje albo powiedział mniej lub bardziej otwarcie, że mam się zamknąć i robić swoje. Oczywiście są jednostki, które są tak patologiczne, że się po prostu nie da, ale to jest margines i póki co w IT jeszcze nie miałem okazji takiej spotkać nawet w kilku krótkich epizodach z korpo.

Ja w ostatnich latach też nie, ale na początku kariery różne rzeczy się zdarzały.

Co do tego czy w projekty angażuję się charytatywnie... Głupio się przyznać, ale tak - po prostu mam taką naturę, że jak coś nie działa to nie potrafię koło tego przejść obojętnie + jak to kiedyś określiła jedna HRk'a mam taką zdolność, że nawet o problemach mówię tak, że ludzie się cieszą, że będą mogli je rozwiązać.

Ja też nie przechodzę obojętnie - mówię, że coś nie będzie działać albo jest nieefektywne, mówię jak można zrobić lepiej. Ale jeśli mnie oleją, to nie drążę tematu. Przecież nie zmuszę nikogo, żeby przestał palić swoimi pieniędzmi w piecu.
Szkoda energii, lepiej szerzyć dobre praktyki tam, gdzie są słuchać.

piotrpo napisał(a):

@somekind: Nie chcę pisać, że przesadzasz. Nie wiem do jakich firm i zespołów trafiłeś. Od siebie mogę napisać tyle, że poza jakimś polskim piekiełkiem w którym pracowałem lata temu, gdzie faktycznie występował taki feudalny ustrój, że ludzie z działu A nie lubią ludzi z działu B, bo ich managerowie się ze sobą nie potrafią dogadać, spotkałem się jedynie ze sporadycznymi przypadkami ludzi, z którymi nie chcę więcej pracować. Wręcz znam z życia przypadki kiedy takie osoby leciały z roboty, bo nikt z nimi nie chciał pracować. Również na stanowiskach managerskich.

No cóż, czasy się zmieniają. W jednej mojej byłej firmie, która hasła o agile miała nawet na ścianach napisane, parę lat temu pozwalniali wszystkich SM i AC, uznając, że to zbędny koszt.

Z perspektywy iluś tam lat, w każdym z projektów w którym byłem dało się ostatecznie olać scrumowe pierdoły i zacząć robić swoją robotę. Taka ciekawostka, jak zespół dowozi, to absolutnie wszyscy mają wywalone na to jak dobrze działa w nim Scrum.

Jasne - człowiek, który umie dłubać w kodzie, dostosuje się do nawet najgłupszej patologii organizacyjnej. Dowozić też można - pytanie, czy nie warto byłoby więcej, szybciej albo lepiej.

Z drugiej strony, postrzeganie wszystkich ludzi dookoła jako idiotów jest niebezpieczną praktyką. To, że potrafisz coś zrobić, nie znaczy jeszcze, że ktoś z innym zasobem wiedzy i doświadczenia nie ma lepszego pomysłu.

Na pewno tym kimś jest PM, który kodu nigdy w życiu na oczy nie widział, nie jest w stanie go przeanalizować, ale jak mówię, że jebnie, to ma to gdzieś. :D
Ja nie postrzegam wszystkich dookoła jako idiotów. Ja jedynie niespecjalnie mam ochotę na rozmawianie z ludźmi, którzy nie chcą słuchać.

NightDev napisał(a):

Większość tej dyskusji aktualnie w wątku jest właśnie idealnym przykładam na to co wcześniej napisałem - nie zgłębienie tematu i traktowanie go po macoszemu. O jakich praktykach Scrumowych piszecie? Przecież Scrum to ramy, tam nie ma praktyk innych niż te co sami wniesiecie, jedyne co to pojawia się jakiś rytm konkretnych spotkań które mają zaznaczony cel - ot cała magia.

Proces ustala PM/SM, programista ma robić taski, brać udział w spotkaniach i grać w pokera. Ot, cała magia.
To, że utopia miała wyglądać inaczej to oczywistość wpisana w definicję utopii.

2

Scrum to taki korpo Buzz Word. To tylko sposób ogarniania burdelu w dużych projektach. Wielu robi na tym kasę, Agile coach, Scrum Mastery itp.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0