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.

2

No to jak nie Scrum, to co w zamian? Może warto podyskutować również o rozwiązaniach? :)

9

Ja ostatnio wolę kanban. Sprinty są sztuczne i często powodują wynaturzenia typu sklejanie wszystkiego trytkami aby tylko domknąć sprint. Kanban jest bardziej naturalny i bardziej agile moim zdaniem. Finalnie jednak zawsze sprowadza się wszystko do dobrego PM - metodologia jest drugorzędna. Samozarządzający się developerzy to mit - nawet jeśli takie coś działa to tylko dlatego że ktoś kumaty dobrze pociąga sznurki z tylnego siedzenia.

2

Scrum/Kanban a nawet SAFe nie jest zły. Problemem są ludzie, którzy go tworzą i sprawiają, że absolutnie wszystko co jest przez niego opisane potrafi dojść do poziomu absurdu dokładnie sprzecznego z wymogami agile.

Biznes ma swoje wymagania, czyli w najbardziej ogólnej postaci, chce wiedzieć, kiedy jakaś funkcjonalność będzie dostępna na produkcji. Tutaj pojawia się pierwszy duży problem, bo ktoś gdzieś przeczytał, że jest agile i jest fajne, bo teraz wszyscy tak robią i w na tym skończył zapoznawanie się z dokumentacją. W szczególności, nie doczytał, że inżynieria oprogramowania nie znalazła dobrego sposobu na określenie "kiedy to zrobimy". Produkują jakieś roadmapy, z wpisanymi na sztywno datami i sami wierzą w swoje kłamstwa. Sposób na odpowiedź "kiedy to będzie" jest w agile banalny - trzeba zacząć coś robić, popatrzeć jak szybko postępuje praca i można sobie wtedy estymować kiedy zostanie dostarczony jakiś efekt, jako wypadkowa trendu. Im bliżej do końca i im więcej zostało zrobione, tym bardziej wiarygodna prognoza.

Drugi częsty problem to scrum masterzy o żenującym poziomie. Naczytali się pierdół, poszli na kursy prowadzone przez adżajl kołczy i próbują tłumaczyć ludziom z wielokrotnie większym doświadczeniem jak pracować, a z drugiej strony w projekcie są konkretne patologie jak brak wymagań, narzędzi i kompetencji, żeby pracować chociaż w przybliżeniu efektywnie. W efekcie przewala się 50% czasu na adżajling a wydanie kilku tysięcy złotych na potrzebną licencję, szybki komputer, lub słuchawki z mikrofonem jest problemem nie do przejścia. Oczywiście diagnozą pato-adżajlingowców jest zwykle "za mało scruma w scrumie" i trzeba dorzucić kolejne adżajlowe nabożeństwo.

Więc moja rada jest banalna - scrum może zostać, adżajlowcy wypad. Chyba, że trafi się jakaś naprawdę rozumiejąca swoją rolę, odpowiedzialność i ograniczenia osoba.

3

Myślałem, że to będzie kolejny roast na scruma, ale widzę, że społeczność 4p dorasta już i coraz mniej sprowadza scruma do absurdalnego porównania z komunizmem i tekstem: "teraz na pewno scrum się uda".

Statystyki mówią jasno, że większość projektów IT upada, hejterom scruma wydaje się, że to przez scruma bo nie rozumieją, że korelacja to nie przyczynowość. Agile był odpowiedzią na waterfall, gdzie dostawałeś jakiś grant albo inwestor pakował kasę i mówił, że ma być program, przychodził po roku i jak widział program to mówił, że chodziło mu o coś innego. Dlatego ci mądrzejsi programiści zaczęli rozmawiać z biznesem i pytać na bieżąco czy implementują to co biznes chce. Ale niestety nie każdy programista jest taki świadomy.

Byłbym pierwszy do zrezygnowania z daily gdyby nie to, że ludzie, którzy mówią, że są dorośli nie potrafią komunikować blokerów i trzeba ich pytać wprost nad czym teraz pracują bo inaczej ich duma nie pozwala im powiedzieć, że czegoś nie umieją. Albo ludzie nie rozumieją kompletnie po co się robi jakąś historyjkę, zapytasz czy rozumie co zrobić i jak to zrobić to gość kłamie i przytakuje, a jak zapytasz o to, żeby swoimi słowami opowiedział co trzeba zrobić to już głupieje.

Albo jak jakiś "senior" tworzy jakieś API, które jest super skomplikowane. Jeżeli nie dowiesz się o tym na czas to gość dzień przed demem będzie chciał na siłę zmerdżować kod bez review. Użytkownik zacznie korzystać z tego API, a później wszyscy w projekcie będą cierpieć latami przez takie rzeczy bo zewnętrzne API jest najtrudniej zmienić.

I ktoś powie, że pracujesz ze słabymi programistami i zmień pracę. Ale jak zmienisz pracę na taką gdzie zarabiasz więcej to tę wyższą pensję dostajesz nie tylko za to, że masz wyższy performance, ale za to, że uczysz swoich kolegów z zespołu. A jak masz uczyć ludzi w zespole jeżeli oni nie komunikują problemów?

5
twoj_stary_pijany napisał(a):

Statystyki mówią jasno, że większość projektów IT upada

Można prosić źródło?

hejterom scruma wydaje się, że to przez scruma bo nie rozumieją, że korelacja to nie przyczynowość.

Paraliżowanie pracy jak najbardziej może być przyczyną upadku projektu.

Agile był odpowiedzią na waterfall, gdzie dostawałeś jakiś grant albo inwestor pakował kasę i mówił, że ma być program, przychodził po roku i jak widział program to mówił, że chodziło mu o coś innego. Dlatego ci mądrzejsi programiści zaczęli rozmawiać z biznesem i pytać na bieżąco czy implementują to co biznes chce. Ale niestety nie każdy programista jest taki świadomy.

Owszem - agile, nie scrum. To nie jest to samo!

Byłbym pierwszy do zrezygnowania z daily gdyby nie to, że ludzie, którzy mówią, że są dorośli nie potrafią komunikować blokerów i trzeba ich pytać wprost nad czym teraz pracują bo inaczej ich duma nie pozwala im powiedzieć, że czegoś nie umieją. Albo ludzie nie rozumieją kompletnie po co się robi jakąś historyjkę, zapytasz czy rozumie co zrobić i jak to zrobić to gość kłamie i przytakuje, a jak zapytasz o to, żeby swoimi słowami opowiedział co trzeba zrobić to już głupieje.

Scrum tego w żadnym stopniu nie rozwiązuje.

Albo jak jakiś "senior" tworzy jakieś API, które jest super skomplikowane. Jeżeli nie dowiesz się o tym na czas to gość dzień przed demem będzie chciał na siłę zmerdżować kod bez review. Użytkownik zacznie korzystać z tego API, a później wszyscy w projekcie będą cierpieć latami przez takie rzeczy bo zewnętrzne API jest najtrudniej zmienić.

Tego również.

No niestety, ale roast na scruma będzie tak długo jak:

  • będą istnieli ludzie, którzy nie są leniwi, i nie chcą być blokowani biurokracją;
  • scrum nie będzie miał nic wspólnego z agile;
  • fanatycy scruma nie dojrzeją do zrozumienia, że są inne możliwości.
1

Można prosić źródło?

Kajam się, powiedziałem z głowy i uprościłem. Wg raportu Chaos, około 31% projektów upada, około 53% projektów prawie dwukrotnie przekracza budżet. Wyobraź sobie, że zlecasz komuś wybudowanie domu, wykonawca bierze zaliczkę i mówi, że na 16% zmieści się w budżecie, na 53% przekroczysz budżet prawie dwukrotnie, a na 31% przeje wszystkie pieniądze i nie będziesz miał z tego nic.
https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

Owszem - agile, nie scrum. To nie jest to samo!

No to jak wyegzekwować bycie zwinnym? Jak poprawiać komunikację w zespole? I nie, Kanban nie jest metodyką Agile. Kanban to jest Lean.

Scrum tego w żadnym stopniu nie rozwiązuje.
Tego również.

Konstruktywna krytyka wymaga podanie jakiejś alternatywy. Alternatywa wymiany całego zespołu brzmi kusząco, ale w praktyce jest bardzo kosztowna (koszt rekrutacji + podwyżki, żeby wyciągnąć najlepszych z innych firm).

fanatycy scruma nie dojrzeją do zrozumienia, że są inne możliwości.

Każdy dzisiaj może się określić scrum masterem albo agile coachem. Niby jak oni dostali takie tytuły? Jest taki kierunek studiów? Na egzaminie z certyfikatu zaznaczyli w 16 pytaniu "c" czy "b"? Wróćmy do podstaw, programiści po studiach mają wyższe kompetencje do bycia scrum masterami. Ale czy ja mam brać na siebie niańczenie juniorów i pytanie ich czy mogliby łaskawie zakomunikować czy mają jakiś bloker? Oczywiście, że bym mógł. Ale osobiście wolę mieć taką osobę w zespole, która robi to za mnie.

5
twoj_stary_pijany napisał(a):

Statystyki mówią jasno, że większość projektów IT upada, hejterom scruma wydaje się, że to przez scruma bo nie rozumieją, że korelacja to nie przyczynowość.
Większość projektów ma problem i przekroczenie czasu, budżetu, lub niedowiezienie zakresu było zawsze. Agile nie odpowiada na to w żaden sposób.

Agile był odpowiedzią na waterfall, gdzie dostawałeś jakiś grant albo inwestor pakował kasę i mówił, że ma być program, przychodził po roku i jak widział program to mówił, że chodziło mu o coś innego. Dlatego ci mądrzejsi programiści zaczęli rozmawiać z biznesem i pytać na bieżąco czy implementują to co biznes chce. Ale niestety nie każdy programista jest taki świadomy.

Kompletnie chybiony punkt widzenia. W waterfallu biznes musiał wiedzieć czego chce. Jak nie wie, to żadna metodyka nie jest w stanie uratować problemu. To na co odpowiada agile, to szybkie tempo zmian w otoczeniu. Masz sklep internetowy, konkurencja wprowadza nowa funkcjonalność, więc albo szybko ją zaimplementujesz, albo wypad z rynku. W waterfallu, jak masz plan na kolejne 3 lata, to albo nie zareagujesz, albo rozwalisz cały projekt. W agile przychodzi biznes, mówi olać poprzednie priorytety, zróbcie nam taką funkcjonalność i za tydzień jest.

Byłbym pierwszy do zrezygnowania z daily gdyby nie to, że ludzie, którzy mówią, że są dorośli nie potrafią komunikować blokerów i trzeba ich pytać wprost nad czym teraz pracują bo inaczej ich duma nie pozwala im powiedzieć, że czegoś nie umieją. Albo ludzie nie rozumieją kompletnie po co się robi jakąś historyjkę, zapytasz czy rozumie co zrobić i jak to zrobić to gość kłamie i przytakuje, a jak zapytasz o to, żeby swoimi słowami opowiedział co trzeba zrobić to już głupieje.

Dlaczego uważasz, że KAŻDY zespół projektowy to banda debili? Czemu daily MUSI być codziennie? A nie np. 2 razy w tygodniu (testowaliśmy, działało), albo 10 razy dziennie w postaci kanału na slacku?

Albo jak jakiś "senior" tworzy jakieś API, które jest super skomplikowane. Jeżeli nie dowiesz się o tym na czas to gość dzień przed demem będzie chciał na siłę zmerdżować kod bez review. Użytkownik zacznie korzystać z tego API, a później wszyscy w projekcie będą cierpieć latami przez takie rzeczy bo zewnętrzne API jest najtrudniej zmienić.

Agile w żaden sposób nie chroni cię przed błędami ludzkimi. W szczególności Scrum ma tendencję do pchania ludzi w ściemę (bo trzeba dowieźć) i marnowanie czasu (bo zaplanowaliśmy za mało i teraz przez tydzień nie można niczego dotknąć).

I ktoś powie, że pracujesz ze słabymi programistami i zmień pracę. Ale jak zmienisz pracę na taką gdzie zarabiasz więcej to tę wyższą pensję dostajesz nie tylko za to, że masz wyższy performance, ale za to, że uczysz swoich kolegów z zespołu. A jak masz uczyć ludzi w zespole jeżeli oni nie komunikują problemów?

Dobra, masz zespół kompletnych trolli, nie gadają ze sobą, nie planują w najmniejszym stopniu swojej pracy. Wprowadzasz Scruma, czy tam SAFe w całości - obowiązkowe daily, obowiązkowe sprint planningi, retro i cała reszta Scrum bzdur. Ostatecznie lepsza kiepska metodyka, niż brak czegokolwiek. Dochodzą do momentu kiedy zaczynają gadać, być elastyczni, wymagać dobrej jakości wymagań, są w stanie wprost i natychmiast zgłosić, że coś ich blokuje, a gdzieś potrzebna jest poprawa, bo zespół pracuje przez to nieefektywnie, nawet są w stanie czasami trafić z odpowiedzią na pytanie na kiedy coś tam zrobią. I nagle czar pryska. Okazuje się, że można zmieniać wszystko (jak to w agile), tylko nie Scruma. Propozycja nie robienia sprint planingu spotyka się z oskarżeniem o obrazę uczuć religijnych. Nie robienie daily w środę - też się nie da, bo scrumowy bóg przyjdzie i wybatoży wszystkich po łapach talią kart do scrum pokera. Czyli wszystko jest agile, a nie metodyka. W dodatku nawet tego nie wytłumaczysz osłom, po kursikach bycia "Scrum Masterem", bo oni nie mają zielonego pojęcia na czym polega wytwarzanie oprogramowania. Nie przepracowali w życiu ani jednej godziny, na jakimkolwiek produkcyjnym stanowisku. Mają jedynie głowy wyładowane frazesami z kursu na jakiś tam certyfikat.

2

Dlaczego uważasz, że KAŻDY zespół projektowy to banda debili? Czemu daily MUSI być codziennie? A nie np. 2 razy w tygodniu (testowaliśmy, działało), albo 10 razy dziennie w postaci kanału na slacku?

Jeżeli masz 2 osoby w teamie to łatwo jest robić synca na slacku. Ja jak robiłem projekty sam albo w kilka osób ze znajomymi to miałem synci np. raz w miesiącu i też działało, ale często masz duży zespół i jako jednostka powinieneś też widzieć cały zespół z większej perspektywy. Np. z perspektywy osoby, która dopiero doszła do zespołu i nie rozumie jeszcze powiązań wszystkich komponentów.

bo zaplanowaliśmy za mało i teraz przez tydzień nie można niczego dotknąć

Wczuj się w scrum mastera. Scrum master pilnuje, żebyście skupili się na dowiezieniu tych rzeczy, które zadeklarowaliście, że zrobicie. Jeżeli zadeklarowałeś, że robisz fundamenty w domu i z kolegą się podzieliliście zadaniami tak, że Ty robisz fundamenty kuchni, a on salonu i Ty dowozisz wcześniej fundamenty kuchni to nie bierzesz z backlogu historyjki z sadzeniem kwiatków w ogródku tylko masz pomóc swojemu koledze w robieniu fundamentów salonu. Bo jeżeli zadeklarujesz, że posadzisz te kwiatki i nie dowieziesz tego to macie niedowiezione fundamenty salonu i nieposadzone kwiatki przed następnym spotkaniem z klientem. Deklarujecie się całym zespołem, że coś dowozicie, a nie @piotrpo deklaruje, że robi swoje i ma w dupie wszystko inne.

Niestety tak się dzieje jeżeli management przestaje ufać programistom bo programista lubi się "bawić" nową technologią zamiast dowozić rzeczy. Ja też chcę się pobawić jakąś technologią, ale zawsze w moim teamie pojawia się jakiś gość, który wrzuca słaby kod bez testów byle tylko szybko dobrać fajną historyjkę i nic z tych historyjek nie kończy.

Nie jestem w Twoim projekcie więc nie pogadam z Twoimi managerami. Sam ich musisz zapytać o przyczynę takich, a nie innych decyzji.

1
twoj_stary_pijany napisał(a):

Jeżeli masz 2 osoby w teamie to łatwo jest robić synca na slacku. Ja jak robiłem projekty sam albo w kilka osób ze znajomymi to miałem synci np. raz w miesiącu i też działało, ale często masz duży zespół i jako jednostka powinieneś też widzieć cały zespół z większej perspektywy. Np. z perspektywy osoby, która dopiero doszła do zespołu i nie rozumie jeszcze powiązań wszystkich komponentów.

No i problem ze Scrumem jest taki, że nie możesz. Masz mieć codziennie a nie raz na miesiąc, czy raz na godzinę.

Wczuj się w scrum mastera. Scrum master pilnuje, żebyście skupili się na dowiezieniu tych rzeczy, które zadeklarowaliście, że zrobicie. Jeżeli zadeklarowałeś, że robisz fundamenty w domu i z kolegą się podzieliliście zadaniami tak, że Ty robisz fundamenty kuchni, a on salonu i Ty dowozisz wcześniej fundamenty kuchni to nie bierzesz z backlogu historyjki z sadzeniem kwiatków w ogródku tylko masz pomóc swojemu koledze w robieniu fundamentów salonu. Bo jeżeli zadeklarujesz, że posadzisz te kwiatki i nie dowieziesz tego to macie niedowiezione fundamenty salonu i nieposadzone kwiatki przed następnym spotkaniem z klientem. Deklarujecie się całym zespołem, że coś dowozicie, a nie @piotrpo deklaruje, że robi swoje i ma w dupie wszystko inne.

Pozwolę sobie nie wczuwać się w rolę typowego SM. Pomoc ludziom z zespołu to oczywista oczywistość. Pisze o patologiach typu skończyliśmy spring backlog i nie wolno niczego dotknąć (albo robi się to pod stołem), bo velocity się rozjedzie, burndown chart nie będzie tak piękny jak mógłby być i temu podobne bzdury.

Niestety tak się dzieje jeżeli management przestaje ufać programistom bo programista lubi się "bawić" nową technologią zamiast dowozić rzeczy. Ja też chcę się pobawić jakąś technologią, ale zawsze w moim teamie pojawia się jakiś gość, który wrzuca słaby kod bez testów byle tylko szybko dobrać fajną historyjkę i nic z tych historyjek nie kończy.

Management ma nie wiele do ufania, albo nie ufania. Management się nie zna na naszej robocie.

Nie jestem w Twoim projekcie więc nie pogadam z Twoimi managerami. Sam ich musisz zapytać o przyczynę takich, a nie innych decyzji.

Aktualnie mam całkiem fajnie w projekcie. SEM jest najlepszą osobą w tej roli, w mojej 20+ lat karierze (dlatego zostawałem w firmie, nawet jak były gorsze czasy). Mamy SM z doświadczeniem w programowaniu, po pewnych wstępnych tarciach doszliśmy do etapu w którym na bieżąco dostosowujemy nasz sposób pracy i SAFe nam w niej nie przeszkadza.

1
piotrpo napisał(a):

Aktualnie mam całkiem fajnie w projekcie. SEM jest najlepszą osobą w tej roli, w mojej 20+ lat karierze (dlatego zostawałem w firmie, nawet jak były gorsze czasy). Mamy SM z doświadczeniem w programowaniu, po pewnych wstępnych tarciach doszliśmy do etapu w którym na bieżąco dostosowujemy nasz sposób pracy i SAFe nam w niej nie przeszkadza.

Czyli jednym słowem teraz bijesz chochoła. Nie wiem czy sugerujesz, że porzuciliście całkowicie Scrum czy jak, ale kiedyś miałem daily co dwa dni. I nie rozumiem stawiania równości między daily, a Scrumem. Daily sync jest tylko jednym z narzędzi w Scrumie. To są tylko narzędzia i albo je bierzecie bo Ci pomagają, albo z nich rezygnujecie. Jeżeli nie wiecie po co są daily, retrospekcje, jaka jest rola PO oraz SM w zespole to implementując te narzędzia odprawiacie kult cargo. Zacznijcie sobie zadawać przed każdym spotkaniem pytania: "czy to spotkanie jest niezbędne?" Bardzo przydatną umiejętnością jest zamykanie spotkań kiedy nie ma już tematów do omawiania.

1

@twoj_stary_pijany: Udajesz, czy naprawdę nigdy nie zetknąłeś się z korpo-pato-scrumem, w którym np. niekończące się dyskusje czym jest 1SP przebijały swoim priorytetem załatanie poważnego problemu na produkcji? Bywało, że pracowałem z takim SM, że robiliśmy sprint planning w tajemnicy, bo inaczej się nie dało. Jak zespół jest w stanie dostarczyć na czas to co obiecał, w dobrej jakości, to nic nikomu do tego jak to robi. Jeżeli SM chce być w tym pomocny, to niech pomaga dając podpowiedzi, sugerując jakieś rozwiązania, włączając się w interakcje z innymi zespołami, pilnując, żeby nie wygasały licencje. To jest przydatna praca. Natomiast zetknąłem się też z projektami, które polegały na robieniu scruma, a nie produktu i z perspektywy czasu uważam, że była to wina SM z szybkiego awansu + biznesu, który nie kumał co wprowadził.

6

Wrzucam, z boku, bo nie chce mi się wszystkiego czytać.
Pamiętajcie, że **Waterfall ** został wymyślony przez kultystów agile. Tak jak komuniści wymyślili kułaków - zawsze musi być jakiś wróg ludu.
To nie znaczy, że projektów waterfallowych nie było - były, ale to były jakieś legendarne projekty rządowe, z których absurdu większość się śmiała. (np, na USENEcie).
To nie jest tak, że jak komuś się nie podoba SCRUm czy Kanban czy inny Leszcz to od jedyną alternatywą jest Waterfall - raczej mało komu to przychodzi do głowy (choć boję się, że po tylu latach klepania o Watefallu przez agile kołczów - ludzie zaczną to naprawdę uprawiać).

1

@piotrpo: SM nie jest od tego, żeby ustalać czym jest 1SP. To zespół tworzy skalę. SM jest od tego, żeby zebrać opinie wszystkich członków zespołu. Miałem w zespole takich ziomków, którzy historyjkom, które były na 8SP dawali np. 2SP. Mówiłem im podczas planowania wprost, że to są ich historyjki skoro są tacy do przodu i olewają zależności, które wspomniałem. Później się kajali na retrospektywach, że jednak się srogo pomylili.

Jeżeli SM, który nie jest programistą, sugeruje wam jakie macie dawać estymaty to coś jest fundamentalnie nie tak i powinieneś to zakomunikować podczas retrospektywy pytaniem czy scrum master mógłby wytłumaczyć dokładnie jaka jest jego rola w zespole? Jeżeli scrum master nie wie jaka jest jego rola to chyba nie jest scrum masterem.

Co do estymowania bugów. Ja nie jestem do końca zwolennikiem estymowania bugów bo to tworzy taką sytuację, że zespołowi opłaca się pisać zbugowany kod, żeby później osobno dowozić bugi i podbijać sobie performance, i ostatnio też poruszaliśmy ten temat. Bugów nie da się wyeliminować, ale da się ograniczyć ich ilość robiąc dobre code review i pisząc testy. Wtedy jasno widać, który zespół w firmie jest lepszy, który dowozi szybciej i z mniejszą ilością bugów.

4

To zespół tworzy skalę. SM jest od tego, żeby zebrać opinie wszystkich członków zespołu. Miałem w zespole takich ziomków, którzy historyjkom, które były na 8SP dawali np. 2SP. Mówiłem im podczas planowania wprost, że to są ich historyjki skoro są tacy do przodu i olewają zależności, które wspomniałem. Później się kajali na retrospektywach, że jednak się srogo pomylili.

Tu jest jakiś absurd. Czy ci goście nie byli z zespołu? BO jak byli to przecież mogli utworzyć skalę, w której te historyjki były na 2SP.
I co teraz?

0
twoj_stary_pijany napisał(a):

@piotrpo: SM nie jest od tego, żeby ustalać czym jest 1SP. To zespół tworzy skalę. SM jest od tego, żeby zebrać opinie wszystkich członków zespołu. Miałem w zespole takich ziomków, którzy historyjkom, które były na 8SP dawali np. 2SP. Mówiłem im podczas planowania wprost, że to są ich historyjki skoro są tacy do przodu i olewają zależności, które wspomniałem. Później się kajali na retrospektywach, że jednak się srogo pomylili.

Sam nie wiem, dlaczego w takim razie zmarnowałem sporo swojego czasu i firmowych pieniędzy na dyskusje o tym, że 1SP nie ma nic wspólnego z czasem, ale to jeden osobodzień, bo podręcznik SAFe tak gdzieś miał napisane.

Jeżeli SM, który nie jest programistą, sugeruje wam jakie macie dawać estymaty to coś jest fundamentalnie nie tak i powinieneś to zakomunikować podczas retrospektywy pytaniem czy scrum master mógłby wytłumaczyć dokładnie jaka jest jego rola w zespole? Jeżeli scrum master nie wie jaka jest jego rola to chyba nie jest scrum masterem.

I SM, który nie wie co jest rolą SM to smutna norma a nie osobliwość.

zespołowi opłaca się pisać zbugowany kod

Jeżeli ktoś umyślnie wprowadza błędy w oprogramowaniu, to po pierwsze jest to patologia, która powinna być karana pisaniem wstecznie wymagań na podstawie wietnamskiego kodu. No i coś jednak nie działa, skoro "zaufanie to podstawa". Piękny przykład Scruma w praktyce.

2
twoj_stary_pijany napisał(a):

Kajam się, powiedziałem z głowy i uprościłem. Wg raportu Chaos, około 31% projektów upada, około 53% projektów prawie dwukrotnie przekracza budżet.

Tam nie napisano, że 31% projektów upada. Tam jest mowa o anulowaniu. Anulowanie może mieć różne przyczyny.
No i ta wartość sama w sobie nic nie mówi, bo nie mówi o przyczynach anulowania. Sam brałem udział w projektach anulowanych np. z powodu tego, że jedna firma przejęła drugą.
No i tam nie ma mowy o czasie teraźniejszym, to jakaś przeszłość.

No to jak wyegzekwować bycie zwinnym?

Dobre pytanie. Ale ja mam dwa lepsze:

  1. Po co to egzekwować?
  2. Czy w ogóle da się to egzekwować? Bo moim zdaniem albo jest się zwinnym albo nie, żadne egzekwowanie niczego nie zmieni.

Jak poprawiać komunikację w zespole?

Zatrudniając komunikatywnych ludzi i nie zabraniając im komunikacji.

Scrum tego w żadnym stopniu nie rozwiązuje.
Tego również.

Konstruktywna krytyka wymaga podanie jakiejś alternatywy. Alternatywa wymiany całego zespołu brzmi kusząco, ale w praktyce jest bardzo kosztowna (koszt rekrutacji + podwyżki, żeby wyciągnąć najlepszych z innych firm).

Jaka alternatywa, do czego? Wbrew temu, co twierdzisz, widziałem wielu programistów w scrumowych zespołach, któzy twierdzili, że rozumieją co trzeba zrobić, a potem dowozili nie dość, że coś innego, to jeszcze po czasie. Scrum sam z siebie nie rozwiązuje żadnego problemu.
Ty jesteś wyznawcą, wierzysz w to, że samo wprowadzenie scruma magicznie naprawia wszystkie problemy z wytwarzaniem oprogramowania i w ogóle uważasz, że takie rzeczy jak projektowanie API, code review czy sygnalizowanie problemów są efektem istnienia scruma. Tymczasem nie, to są zupełnie niezależne od scruma kwestie, i ludzie potrafili je robić na długo zanim scrum powstał.

Scrum wręcz upośledza komunikację, bo sprawia, że nie ma sensu proszenie o pomoc w trakcie dnia pracy, trzeba czekać na daily, nie można zgłaszać problemów w momencie ich wystąpienia, trzeba czekać na retro.

Ale czy ja mam brać na siebie niańczenie juniorów i pytanie ich czy mogliby łaskawie zakomunikować czy mają jakiś bloker? Oczywiście, że bym mógł. Ale osobiście wolę mieć taką osobę w zespole, która robi to za mnie.

No to prawda, ale ja też nigdy nie twierdziłem, że Scrum to nie jest doskonała metodologia do mikromanagementu i pracy z juniorami.
Ale nie dla doświadczonych ludzi chcących tworzyć działający soft.

twoj_stary_pijany napisał(a):

Wczuj się w scrum mastera. Scrum master pilnuje, żebyście skupili się na dowiezieniu tych rzeczy, które zadeklarowaliście, że zrobicie. Jeżeli zadeklarowałeś, że robisz fundamenty w domu i z kolegą się podzieliliście zadaniami tak, że Ty robisz fundamenty kuchni, a on salonu i Ty dowozisz wcześniej fundamenty kuchni to nie bierzesz z backlogu historyjki z sadzeniem kwiatków w ogródku tylko masz pomóc swojemu koledze w robieniu fundamentów salonu.

I to jest właśnie chyba najpiękniejsze. Bo w praktyce, to robienie fundamentów jednego pomieszczenia to robota dla jednej osoby. Dwie wchodzą sobie w drogę i nawzajem przeszkadzają, więc w efekcie robią dwa razy dłużej i się nie wyrabiają na czas. Ale najważniejsze, że były zgodne z religią.

twoj_stary_pijany napisał(a):

I nie rozumiem stawiania równości między daily, a Scrumem. Daily sync jest tylko jednym z narzędzi w Scrumie. To są tylko narzędzia i albo je bierzecie bo Ci pomagają, albo z nich rezygnujecie.

Nie, nie, nie, nie. Ty w ogóle nie rozumiesz. :D
Nie po to firma wydała setki tysięcy dolarów na wdrożenie agile, zatrudnienie agile coachy i scrum masterów, żeby sobie jacyś programiści mogli decydować jak maja pracować. Oni maja grać w plannin pokera, robić taski i codziennie spowiadać się na daily.

0

Ty jesteś wyznawcą, wierzysz w to, że samo wprowadzenie scruma magicznie naprawia wszystkie problemy z wytwarzaniem oprogramowania i w ogóle uważasz, że takie rzeczy jak projektowanie API, code review czy sygnalizowanie problemów są efektem istnienia scruma. Tymczasem nie, to są zupełnie niezależne od scruma kwestie, i ludzie potrafili je robić na długo zanim scrum powstał.

Nie ma złotej metody. Ale jeżeli tłumaczę od roku ludziom w komentarzach, że mają pisać testy, a później te ziomki olewają moje komentarze i chcą zamykać swoje historyjki to idę najpierw do SM i mówię, że historyjka nie jest domknięta bo gość olał moje komentarze. Dlaczego ja mam później się babrać w gównianym kodzie? Napisałem kawał dobrego kodu z testami, a później inny gość robi copy-paste'a, nie napisze testu, nie zrefaktoruje i uważa, że jest git. Nie, nie jest git. Ja po sobie posprzątałem. Podpowiedziałem mu nawet jak zrobić zadanie i gość zaciąga dług, który ja będę musiał spłacać kiedy ja wezmę historyjkę w tym projekcie. Wiadomo, najlepiej jest zmienić pracę, ale lepiej przygotować sobie najpierw nową pracę, a nie składać od razu wypowiedzenie.

4
twoj_stary_pijany napisał(a):

Nie ma złotej metody. Ale jeżeli tłumaczę od roku ludziom w komentarzach, że mają pisać testy, a później te ziomki olewają moje komentarze i chcą zamykać swoje historyjki to idę najpierw do SM i mówię, że historyjka nie jest domknięta bo gość olał moje komentarze.

No dobra, więc Scrum daje tyle, że jest Scrum Master, do którego można ponarzekać na kolegów z zespołu. Jak dla mnie, to równie dobrze może Scruma nie być, a narzekać na kolegów z zespołu można do jakiegoś przełożonego.
Jak sam widzisz - Scrum sam z siebie niczego nie daje, jeżeli ludzie nie pracują uczciwie. Z tego powodu nie działał też socjalizm. :)

0

Im dłużej o tym czytam tym mniej wiem. Scrum je programski okvir procesa, koji se koristi za upravljanje kompleksnim razvojem. Scrum nije metoda ili tehnika razvoja sooftware-a
Wszystko co trzeba zrobić wpierw ląduje w Backlogu. Później tworzone są sprinty, najczęściej 2 tygodnie. Delegowanie zadan, dodanie priorytetow, ogolnie Jira mocno. Problemy sa opisywane na "stand-upach". Zarządza tym wszystkim SM. Cyklicznosc procesu pozwala na wypracowanie lepszych schematow dzialan. Stand-upy pomagaja w komunikacji w zespole. Tyle?

3

Pierwsze- co to jest 2SP? Drugie: to, że nie domknęli w 2 tygodnie (a co to ma do rzeczy i jak się ma do SP) to nie znaczy, że źle szacowali. Szacowali może dobrze - ot nie trafili w realizacji. Na tym polega szacowanie, że można nie trafić. W Scrumie zresztą to już zupełnie co innego - bo po prostu oznacza to tylko tyle, że mieliście inne velocity.. i świat się nie wali (chyba, że to patoscrum). — @jarekr000000

Przede wszystkim my co jakiś czas robimy przeskalowanie historyjek. Niektóre robią się łatwiejsze, inne są nieznane. Część historyjek ciężko porównać bo są zupełnie inne. Mamy kubełki z punktacjami: 1SP - najprostsza możliwa historyjka jaką mieliśmy, 2SP, 3SP, 5SP, 8SP, większe niż 8SP to już są zbyt duże historyjki i rozbijamy je na mniejsze. Przy porównywaniu opieramy się na kryteriach CUE - Complexity, Uncertainty, Effort. To nie jest tak, że można się ot tak pomylić z historyjką 8SP na 2SP. Jeżeli nie dotykałeś jeszcze pewnej części systemu to Uncertainty rośnie więc powinieneś dać wyższą liczbę. Ja dotykałem tę część systemu i mówiłem, że to jest na 8SP, podałem swoją argumentację podczas Planning Poker. Goście, którzy nie dotykali tego mówili, że to jest bułeczka z masełkiem i, że to jest 2SP i przekonali SM do takiej oceny. Ja nie będę przeciągał takiego spotkania. Jeżeli gość chciał się skaleczyć to miał do tego pełne prawo jako wolny człowiek.

@twoj_stary_pijany: Doczytaj co to jest szacunek. Przepraszam, jeśli zabrzmiało złośliwie. Większość programistów i managerów nie ma pojęcia co to jest szacunek - mi zajęło 10 lat, aż mi ktoś wreszcie ręcznie wytłumaczył. (Przez to nie mam książki do polecenia - choć na pewno czytałem i oglądałem jakieś video - nie mogę sobie przypomnieć dobrego linku). — @jarekr000000

Wiem, że to co tutaj pisze brzmi ekstremalnie i że kapuję na swoich ziomków z zespołu. Użycie słowa patoprogramiści było na wyrost. W pracy staram się nie oceniać nikogo. Szczególnie jeżeli to mogłoby spowodować, że ktoś straci pracę, a o to jest bardzo łatwo w międzynarodowym środowisku. Natomiast, wyleczyłem się zupełnie z podejścia, że nie kapuje się na kolegów i nie patrzę już na to z tej perspektywy. Byłem pierwszą osobą, która sygnalizowała, że architekt ciśnie część zespołu, żeby pracowała po weekendach i to moja zasługa, że goście sobie teraz odpoczywają po weekendach zamiast robić darmowe nadgodziny. Jeżeli chcą sobie poprogramować w weekend to niech piszą swoje własne projekty, a nie psują planowanie wspólnego projektu. W przeszłości kryłem kilku ziomeczków, którzy mi tak dali w kość, że mnie boli dupa aż do teraz.

Więc teraz staram się być transparentny, żeby nie było takiej sytuacji, że szambo wybija i szef przychodzi do mnie i mówi: "wiedziałeś, a nawet się nie zająknąłeś". Jeżeli chcesz ode mnie approve to pisz testy, ale nie potrzebujesz mojego approve, jest jeszcze kilka innych osób w zespole, które mogą Ci dać approve. Natomiast na daily nie omieszkam zapytać, czy jest jakiś problem z dopisaniem testów do tego ficzeru?

Najgorszy ukończony projekt

Dziwi mnie trochę, że tak ciśniesz scrum skoro sam pracowałeś w jakiejś patowersji scruma. Pozwól, że skomentuję kilka rzeczy, które Ci się przytrafiły. Pamiętaj też, że to nie jest codzienność. Są projekty gdzie scrum wygląda znacznie lepiej.

mikro managier (tez z niemiec) - potrafiący 20 minut dopytywac się (publicznie opierdalać po prawdzie) programisty dlaczego zadanie wyestymowane na 2 godziny robił przez 4 godziny (przy 15tu osobach na zebraniu...,),

Kiedy u mnie architekt publicznie upokarzał na spotkaniu PO to go po prostu zgłosiłem, wcześniej powiadomiłem o tym SM i kilka osób w zespole, że będę to robił. W ogóle, estymowanie w godzinach to jest patola, ale patolą jest również zgadzanie się na takie traktowanie. Dodatkowo na pierwszym spotkaniu z architektem kiedy ten zaczął rozdzielać zadania każdej osobie zapytałem wprost przy wszystkich: "czy zaczynamy tutaj micromanagement?". Swoje przygody z tym architektem opisywałem tutaj: Kiedy zespoły zaczynają się kanibalizować

siedzone daily po 1.5 godziny dziennie,

Na daily, każdy powinien powiedzieć swój status w minutę. Jeżeli są tematy do omówienia to zostawiasz na po spotkaniu, albo na osobne spotkanie w mniejszym gronie zainteresowanych.

zresztą typowe estymaty były na 2 - 4 godziny - w sytuacji, gdzie człowiek często przez cały dzień próbował sie dowiedzieć co w ogóle jest do zrobienia, jednokrotne testowanie ręczne gotowego komponentu zajmowało nieraz więcej czasu niż te szacunki na wykonanie,

Ale to wy robicie te estymaty, dlaczego nie estymowaliście tego na np. 4 dni? W ogóle, w jaki sposób wyestymowaliście historyjkę nie wiedząc co jest do zrobienia?

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