Traktowanie sprintów jako dwutygodniowych deadline'ów - jak uniknąć tych firm.

@somekind: wprowadzanie zmian w systemie, który przejęliśmy od innego dostawcy, dodatkowo najlepiej jak po stronie biznesu też jest zmiana na świeżaka (bonusowe punkty, za takiego co zupełnie nie ogarnia) lubię porównywać do wrzucenia granatu do szamba:

• duża doza zaskoczenia
• wszyscy g8wnem umazani
• sprzątanie zajmuje dużo więcej niż ktokolwiek mógłby się spodziewać

Co do oryginalnego tematu - ja mam wrażenie, że czasami tu wszyscy są w jakiejś wirtualnej rzeczywistości. Praca nie jest rozłożona równomiernie - raz trzeba przycisnąć więcej, innym razem są luzy. To czy ktoś używa scruma, czy czegokolwiek innego do pędzenia "niewolników" szybciej to jest osobna para kaloszy, którą ciężko rozpracować nie znając całego kontekstu i pół litra też by się przydało.

Co do bugów - zawsze były, zawsze są, zawsze będą! Więc do uja wafla - ktoś kto zarządza procesem wytwórczym softu przy produkcie, który cały czas ewoluuje MUSI mieć zaplanowany sposób obsłużenia tego i nie może być tak, że domyślnie zawsze wpada to w nadgodziny, bo to znaczy, że zarządzanie na takim projekcie nie istnieje. Jak pisałem wcześniej - są wyjątki, ale pewne rzeczy można antycypować.

Kolejna sprawa, to poruszany tu wcześniej wątek zapewnienia jakości - jak maniana totalna wychodzi na prod, to znaczy że nie istnieją procesy QA. Klient się nie obrazi od razu, ale jak PM/Account nie zarządzi wkur*em klienta prawidłowo, to wiedz, że jest granica wytrzymałości każdej klienckiej d**y i w końcu poszuka kogoś innego - niezależnie od tego, czy problem daje się rozwiązać, czy teren jest tak zabagniony, że osuszanie potrwa długo. Jeśli bagno jest duże, to znowu rola PMa / Accounta, żeby to wyjaśnić i odpowiednio sprzedać, żeby dostać czas na naprawę.

Na moich projektach jak się okazywało, że z jakimś elementem mamy często problem, to odsyłałem człowieka, który siedział aż gruntownie naprawił / przebudował / zmigrował dane, żeby co chwila nie wybuchało mi w rękach. Przez miesiąc załóżmy byłem na zero, jeśli chodzi o zarobek na utrzymaniu, ale w dłuższej perspektywie opłacało się z wielu przyczyn:

• poprawa wizerunku
• bardziej przewidywalny proces dostarczania nowych ficzerów (brak losowych wrzutek z proda)
• i last but not least klient nie wyzywał mnie od debili - spokój wart każdych pieniędzy

Zastanawia mnie ta pewność, że można pewne rzeczy estymować. No bo przecież każdego dnia jak się budzę rano to z góry wiem, że przez tydzień nie będę miał żadnego buga na produkcji albo czy może przez tydzień nie będę robił nic innego, a tylko fixy robił :P

@ToTomki: to się nazywa po prostu doświadczenie ;) czy można estymować, że ktoś będzie miał wypadek i w związku z tym warto kupić ubezpieczenie?

Dzięki doświadczeniu można estymować bugi na produkcji?

W jednym projekcie upierali się, żeby estymować bugi. PO z scrum majstrem strasznie naciskali. Po dwóch pierwszych doszło do nich, że taka estymacja nie ma sensu, bo nic nie estymuje :D

jarekr000000 napisał(a):

Primo to kojarze, że to Ty narzekałeś na planowanie i że nie możesz brać tasków z następnego sprintu. A dla mnie problem to nie to czy przy sprincie da się naprawiać bugi i dowozić - ale "po co". W sensie - po co tracić czas na planowanie czegoś co ma na tyle dużą wariancję, że nie ma sensu na tym polegać. Traci się tylko czas na planowanie i ew. nonsenowne wyciąganie wniosków (np. z velocity).

@jarekr000000: odpowiadam na komentarz, bo wyciągasz brudy z mojej przeszłości, a w komentarzu się nie zmieszczę. :)

Narzekałem na wielogodzinne planowanie kilka dni z rzędu, to fakt. Zdarzała mi się taka dezorganizacja projektu kilka razy w życiu, głównie w SH. Np. siedział cały zespół (SM, architekt, 8 developerów, 4 QA) i planował taski. Gdy programiści mówili, co będą robić, to testerzy się nudzili. Gdy testerzy mówili co i jak będą testować, to programiści zasypiali. Zadania programistyczne były rozpisywane właściwie task per linijka kodu. Cała ta planistyczna orgia zajmowała 2-3 dni, a efektem było to, że większość tych misternie zaplanowanych zadanek nie miała sensu, a dowiezienie 25% planu było sukcesem. A na koniec sprintu było generalnie obrzucanie się winą - testerzy winili programistów (bo za późno dostali ficzery do testów, i nie mieli szans przetestować), a programiści obwiniali inne zespoły (bo nie dostarczyli zależności).
W sumie jakby brać ze sobą sztachety na retro, to by było jak na tradycyjnym weselu. Jak ktoś lubi takie klimaty, to spoko, tylko dla mnie to tak jakby bez sensu. Nikt decyzyjny nigdy nie odważył się powiedzieć, żeby zmienić ten proces - a jak ja zacząłem marudzić, że jak g**no nie działa, to nie ma prawa zadziałać, to zostałem wezwany na dywanik, i miałem nawet robioną ewaluację przez HR. :D (Wyszło, że jestem wredny i naużywam sarkazmu.)

Obecnie nie jest to moim problemem - planowanie sprintu to mniej niż godzina - warunkiem jest wcześniejsze solidne omówienie zadań, co zajmuje ze może z godzinę, maksymalnie dwie tygodniowo. Wszystko na spotkaniach bez biznesu - programiści sami z siebie nie będą przecież siedzieli na spotkaniu dłużej niż godzinę. A zadania i tak trzeba omówić, niezależnie od metodyki, no chyba, że zakładamy, że nie musimy wiedzieć, co robimy. Tylko to też moim zdaniem bez sensu.
No i tak, niby mam 3 dni raz na 10 tygodni w kalendarzu przeznaczone na planowanie, ale 80% tego czasu spędzam na robieniu jakichś poców czy refaktoryzacji. Mam to szczęście pracować w firmie, w której nie powtarza się w nieskończoność nieskutecznych działań w nadziei, że przyniosą inny efekt. Jak się okazało, że breakout roomy w Zoomie nie działają, to Zoom wyleciał z firmy całkowicie - i nikt nie narzuca już zespołom jakich narzędzi użyją do zaplanowania roboty. Jak się okazało, że na co drugim demie większość zespołów nie ma co pokazać, to po prostu demo jest raz na 2 sprinty. Itp., itd.

No i tamto był scrum, i to jest scrum. Tamten chyba był bardziej prawdziwy, bo każdy zespół miał swojego mistrza młyna, a w firmie były zatrudnione ze cztery zwinne kanapy. Ale mnie nazwa metodyki nie obchodzi tak bardzo, dla mnie liczy się, że spotkań jest mało, a te, które są mają dla mnie sens, bo dotyczą programowania.

jarekr000000 napisał(a):

Zwykle to akurat biznes jest źródłem tego problemu, więc nie bardzo wiem, w czym mógłby pomóc.

No ja po prostu informuję biznes, że wymaga czegoś niemożliwego, i tego nie dostanie. Znam takich, co to do końca biznesowi mówią, że wszystko idzie zgodnie z planem, no ale nie wiem po co - finalnie biznes i tak się zorientuje, że nie dostali tego, co chcieli.

KamilAdam napisał(a):

Ja też nie. W zespole mamy jednego backendowca, jednego frontendowca, jednego bazodanowca, jednego PM i półtora testera. SM jest funkcją/rolą testera.

Jak trafia się bug wydajnościowy z produkcji, to jak myślisz do kogo trafia :D

No ok, ten konglomerat ciężko nazwać zespołem. Czemu zatem dziwić się, że metodyka pracy zespołowej w tym przypadku nie działa?

BTW i najważniejsze. Dalej nie wiem ile procent sprintu mam przeznaczyć na bugi :P

Jak już pisałem, to Ty najwyraźniej 100%.
Swoją drogą, współczuję.

ToTomki napisał(a):

Zastanawia mnie ta pewność, że można pewne rzeczy estymować. No bo przecież każdego dnia jak się budzę rano to z góry wiem, że przez tydzień nie będę miał żadnego buga na produkcji albo czy może przez tydzień nie będę robił nic innego, a tylko fixy robił :P

Nie chodzi o estymowanie bugów - bo to nie ma sensu, tylko o zrobienie sobie buforu na naprawę bugów. Bugów przekraczających bufor się nie naprawia (chyba, że biznes stwierdzi inaczej), a jeśli bufor zostanie, to przeznacza się go na inne rzeczy.

A u nas sprinty fajnie się sprawdzają. Bierzemy realne cele i najważniejsze to dowieźć zadania celowe. Często jakieś 2 lub 3. Reszta fajnie by było jakby weszła ale nikt nie ciśnie jak to się nie wydarzy. Wiadomo, że są rzeczy nieprzewidziane czy chociażby wsparcie produkcji. To jakaś patologia, że wszystko ma wejść bo to miecz obusieczny. Potem są zespoły, w których ktoś po tygodniu swoje zadania kończy i zamiast zabrać kolejne z backlogu to przez tydzień siedzi i nic nie robi bo "nie zdąży zamknąć w tym sprincie" więc nie ma co brać.

No ale to może dlatego, że pracuję w firmie produktowej nad naszym produktem a nie w jakimś outsourcingu gdzie PM ciśnie bo sprzedane zostało tyle to tyle ma być dowiezione.

Jak uniknąć? Bardzo prosto, zamiast aplikować na pozycję oczko wyżej to aplikujesz na pozycję oczko niżej. Wtedy nikt nie ma za dużo oczekiwań i możesz zabłysnąć i może nawet częściej wychodzić z menedżerem na piwo.

Co prawda kasy będzie trochę mniej ale wolny czas możesz poświęcić na networking co z pewnością zwróci się z większą przebitką w przyszłości.

musisz zejść z monety, jak weźmiesz 50-70% tego co obecnie to nikt Cię nie będzie dociskał
mówisz podczas rekrutacji że szukasz spokojniej pracy, bez zapierdolu po godzinach i Twoja stawka temu odpowiada, potem mówisz o tym ustaleniu za każdym razem jak ktoś Cię próbuje dociskać

należy też pamiętać że scrum jest inaczej sprzedawany biznesowi, a inaczej zasobom ludzkim, cały system opiera się na tym przecież żeby zasoby ludzkie miały nadzieje że będzie lepiej.
wiadomo są jacyś upupieni ludzie którzy nigdy w macdonalds/kfc nie byli, ale większość ludzi tam była, i pierwszy raz się zdziwiła jak na bilbordzie był inny burger niż dostali po zakupie, to im się lampka już zaświeciła.
nie bez powodu spint się nazywa sprintem, a nie run (bieg), march (marsz), walk(chód). Spróbujcie raz po razie przebiec pare sprintów, a zrobić kilka marszów to zrozumiecie czego się oczekuje od zasobów ludzkich w scrumie :-)
jak się sprzedaje biznesowi scrum:
daily meeting to takie spotkanie statusowe, jak w fabryce że przed zmianą mówi się jaki jest target i ile się z tego zrobiło, ludzie robiący na magazynie też mają daily meeting
w backlogu są tylko feature by bugi itd trzeba było robić w nadgodzinach i nie uwzględnia się nieplanowanych rzeczy, spotkań, daily, refactoru, architektury, optymalizacji, ci/cd, urlopy
używa się punktów zamiast godzin, jeżeli chcesz mieć coś dobrze zaplanowane to umieszczasz to w kalendarzu i blokujesz dla danego zadania czas wtedy widzisz ile możesz zrobić w danym czasie, ile idzie na spotkania itd, dzięki punktom i przy dobrym scrum masterze zasoby ludzkie biorą więcej tasków niż powinny, taka sama zasada jak używanie żetonów w kasynie
wycenia się user story by mieć optymistyczną estymacje, a jak ktoś powie że zrobi, to będzie pracował w darmowych nadgodzinach by dowieźć, są oczywiście tacy którzy tego nie robią ale od tego jest scrum master, hire slow fire quick
review jest po to by wymuszać częste deadliney, i kapitalizować na tym że ktoś się zobowiązuje do wykonania sprintu, po prostu jest to wymuszenie crunchu co 2 tygodnie, a nie tylko przed releasem
retrospekcje są po to by zasoby ludzkie mogły się wygadać i wyrzucić z siebie problemy i żeby czuły się wysłuchane, ewentualnie od czasu do czasu w nagrodę coś dla nich zrobić małego i taniego
w scrumie jest takie coś że można ciągle zmieniać, jest to po to żeby nie trzeba było tracić czasu na dobre zdefiniowanie projektu/wireframe/mvp i przerzucić koszt tego na zespół scrumowy
ignoruje się zalecenia idealistów agile, że sprint się powinno anulować gdy np. product owner nie odp na pytania zespołu lub wyszły jakieś niespodziewane rzeczy
punktów używa się jako KPI/productivity metrics, robi się burndown chart itd by widzieć przodowników pracy
w pewnym momencie konwertuje się scrum na waterfall estymując cały backlog i dzieląc na sprinty, biorąc pod uwagę aktualne velocity i nie biorąc pod uwagę że będzie coraz więcej bugów oraz będą zmiany i modyfikacje, ale wyznaczając deadline całego projektu
częścią tej konwersji jest migracja by zasoby ludzkie zgodziły się na plan kilku sprintów do przodu tzw roadmapa
też ważna kwestią jest gamyfikacja czyli tablica scrumowa, że nikt nie chce przenieść najmniejszej liczby kartek / punktów w sprincie: youtube.com/watch?v=cPs2dz-DjGQ
różne rytuały i nowomowa jest po to by zasoby ludzkie nie zorientowały się że robią na plantacji, taka gamyfikacja wyścigu szczurów, do tego właśnie jest scrum master: youtube.com/watch?v=rg7EF90Aaw8
wiadomo są zasoby ludzkie które bronią scruma, po prostu jest więcej ludzi którzy lubią soft-BSDM niż się wydaje, tak przy okazji BSDM biczuje nowe światło na role scum MASTER'a, i kto tu jest slave'em :-) taki paradoks że teraz brancha nie można mieć już mastera, ale scrum może mieć mastera, widać jakie są priorytety

Riddle napisał(a):

Pytanie tak na prawdę się sprowadza do tego, czy chcesz pracować w prawdziwym scrumie, czy nie. Mówiąc "prawdziwy scrum" mam na myśli ten opisany w scrum book, mniejwięcej zgodny z agile manifesto. Bo ogólnie, sprawa ma się tak, że wbrew pozorom Scruma praktykuje się w niewielu firmach. Wszystkie firmy na rynku IT (wszystkie, bez wyjątku) powiedzą Ci że mają scruma (będą robili dzienne spotkania, i nazywali rzeczy sprintami, retrami, etc.) ale w sporej części firm to jest tylko scrum jednak z nazwy.

@loza_prowizoryczna: , @Jaslanin Skąd wy wzięliście pomysł, że jak się jest "oczko niżej" / "za 70%" to nie będą was cisnąć? Jak się sprzedajecie poniżej umiejętności, to na 100% będziecie zapieprzać powyżej.

Jaslanin napisał(a):

nie bez powodu spint się nazywa sprintem, a nie run (bieg), march (marsz), walk(chód). Spróbujcie raz po razie przebiec pare sprintów, a zrobić kilka marszów to zrozumiecie czego się oczekuje od zasobów ludzkich w scrumie :-)

Jedyny marsz jaki znam w IT, to marsz ku klęsce. Ale czy tak dużo lepszy od tego patologicznego scruma, to nie wiem. :)

daily meeting to takie spotkanie statusowe, jak w fabryce że przed zmianą mówi się jaki jest target i ile się z tego zrobiło, ludzie robiący na magazynie też mają daily meeting

Ale to, że coś jest w fabryce i na magazynie, oznacza, że to jest złe i nie powinno być w IT?
Toalety i drugie śniadania też trzeba zlikwidować, bo w fabrykach mają?
Rozwiń argument.

w backlogu są tylko feature by bugi itd trzeba było robić w nadgodzinach

No to jakaś bzdura totalna, ale bez związku ze scrumem per se. :)

i nie uwzględnia się nieplanowanych rzeczy, spotkań, daily, refactoru, architektury, optymalizacji, ci/cd, urlopy

Zaginanie czasoprzestrzeni to kolejna cecha nieumiejętności organizacji pracy bez względu na metodykę.

używa się punktów zamiast godzin

No niby tak, z drugiej strony, co można zauważyć na forum, to wszyscy, którzy narzekają na niewyrabianie się z pracą piszą jednocześnie o zadaniach zaplanowanych w jednostkach czasu, a nie w punktach. Dziwna korelacja, czyż nie?

piotrpo napisał(a)

@loza_prowizoryczna: , @Jaslanin Skąd wy wzięliście pomysł, że jak się jest "oczko niżej" / "za 70%" to nie będą was cisnąć? Jak się sprzedajecie poniżej umiejętności, to na 100% będziecie zapieprzać powyżej.

Nie do końca rozumiem logikę tego zdania ale logik jest wiele. A co do sprzedaży - wiesz, jest wiele walut w obiegu ale tylko jedna z nich jest (nawet nie krypto) kompletnie deflacyjna. To czas wolny.

Należy przeczytać ze zrozumieniem Scrum Guide, potem tłumaczysz w firmie dlaczego ich waterfall z adżajlowym podejściem nie działa.
Kruszysz beton i praca idzie wspaniale.

Ale teraz wracajmy do rzeczywistości.
Pytasz podczas rekrutacji: Jak u nich wygląda sprint, jak zazwyczaj się kończy, co jeśli task był źle wyestymowany, szukasz red flag.

loza_prowizoryczna napisał(a):

piotrpo napisał(a)

@loza_prowizoryczna: , @Jaslanin Skąd wy wzięliście pomysł, że jak się jest "oczko niżej" / "za 70%" to nie będą was cisnąć? Jak się sprzedajecie poniżej umiejętności, to na 100% będziecie zapieprzać powyżej.

Nie do końca rozumiem logikę tego zdania ale logik jest wiele. A co do sprzedaży - wiesz, jest wiele walut w obiegu ale tylko jedna z nich jest (nawet nie krypto) kompletnie deflacyjna. To czas wolny.

Brak logiki w zdaniu @piotrpo jest pewnie nawiązaniem do braku logiki w twoim zdaniu. To że zatrudnisz się za 70% swojej stawki nie znaczy że nie będą cię cisnąć. Teoretycznie może to zmniejsza szansa. Przykładowa sytuacja - pato janusz ciśnie wszystkich na 130%. Ty oszukujesz że jesteś midem mimo że jesteś seniorem i zatrudniasz się za stawke mina czyli 70% stawki seniora i udajesz 30 procent głupszego niż jesteś. W związku z tym w pierwszym sprincie się wyrabiasz (70% roboty seniora * 130% patoligii daje ok 100% wykonanej pracy w sprincie)
Ty zadowolony. pato janusz zadowolony. Profit?

Oczywiście że nie. janusz orientuje się że się na pewno opierdzielasz bo się wyrobiłeś. W związku z tym kolejnym sprint dostajesz na 160% i też się nie wyrabiasz, ale za to za 70% pensji. Te wszystkie sprinty w firmie są pewnie tak estymowane żeby wzbudzić w ludziach poczucie winy i syndrom oszusta, darmowe nadgodziny. Ale po co ja w ogóle o tym pisze :(

KamilAdam napisał(a):

Te wszystkie sprinty w firmie są pewnie tak estymowane żeby wzbudzić w ludziach poczucie winy i syndrom oszusta, darmowe nadgodziny. Ale po co ja w ogóle o tym pisze :(

No pewnie taka mechanika januszostwa. I to najwyraźniej działa, skoro tak robią. Przerażające, że niby dorośli i często wykształceni ludzie tak się dają wykorzystywać.

No chyba, że...

KamilAdam napisał(a):

Oczywiście że nie. janusz orientuje się że się na pewno opierdzielasz bo się wyrobiłeś. W związku z tym kolejnym sprint dostajesz na 160% i też się nie wyrabiasz, ale za to za 70% pensji. Te wszystkie sprinty w firmie są pewnie tak estymowane żeby wzbudzić w ludziach poczucie winy i syndrom oszusta, darmowe nadgodziny. Ale po co ja w ogóle o tym pisze :(

No widzisz, jednak można znaleźć jakieś punkty styczne na dwóch toczących się okręgach. Założyłeś że dowozisz taska w 100% w 70% zaplanowanego i czasu i Janusz to wie. Gdy tak naprawdę nawet będąc hiper-duper-seniorem zawsze popełnisz jakieś błędy (bo specyfikacja jest do d**y, bo tester dał ciała, bo po prostu za dużo czasu siedziałeś na 4p). Więc już samo to powoduje że masz marne szanse na wyrobienie się w sprincie.

Gdy tak naprawdę wszystko rozbija się o wolny rynek asymetrię informacji. Janusz nie ma magicznej kuli żeby wiedzieć jakie są twoje realne możliwości więc stosuje taktykę salami żeby zmaksymalizować potencjał zasobu ludzkiego. Może to robić tak jak mówisz, może również zainstalować monitoring, może zmusić ludzi do pracy w biurze (legalniejsza opcja monitoringu).

Tyle że dziś mamy możliwość pracy zdalnej, hybrydowej i te możliwości są o wiele mniejsze. Przez to Janusz nie wie czy robiąc sprint uprawiałeś redlining swojej galarety w głowie czy jechałeś cały czas na luzie resztę czasu poświęcając na swoje dobre samopoczucie.

A praca z dobrym samopoczuciem jest dużo zdrowsza bez względu na to czy pracodawcą jest Janusz czy unicorn z owocowymi czwartkami :)

Może estymować z użciem PERT (Program Evaluation and Review Technique)?

@loza_prowizoryczna: @KamilAdam
Pewnie za bardzo zagmatwałem. Przedstawię to inaczej. Jeżeli dajemy się rypać na "poziomie stanowiska" (co można uprościć do kasy...), albo na kasie, to jest też większe prawdopodobieństwo, że będziemy rypani na darmowych nadgodzinach. Powód jest zawsze ten sam "bo można".

Dziękuję wszystkim za odpowiedź i wiadomości prywatne nie zdawałem sobie sprawy że tyle ruchu zrobi ten post. Także dziękuję za wsparcie i dobre slowa. Jestem aktualnie ja etapie szukania nowej pracy a w tej zacząłem robić tzw. "silent quitting". Niech mnie zwalniają.

@Klojtex:

Osobiście uważam, że planowanie w punktach "pracochłonności" to też jakaś bzdura, bo znajomość projektu w zespole nie musi się rozkładać równomiernie. Nie czytałem przy tym SG, więc mogę pomijać założenia, ale z mojej perspektywy, jeśli cele nie zostały osiągnięte, po prostu po winna się pojawić dyskusja pt. "Co poszło nie tak" i na bazie tego powinny zostać podjęte odpowiednie kroki. Ma to sens? Bo ja dotąd z "książkowym scrumem" to się spotkałem tylko raz, reszta to takie "custom kanban" i to podejście (z reguły) działało lepiej.

Teraz będę trochę pisał jak ten gość z mema, którego wkleiłem parę postów wcześniej. SP, to nie jest jednostka pracy,. pracochłonności, złożoności. W sumie to nie jest żadna dająca się zdefiniować jednostka. Ponieważ po dość długim czasie ogarniania o co w tym chodzi, chyba doszedłem do momentu, w którym rozumiem, to się podzielę, bo nie podzieli się tym z wami żaden ScrumMaster po politologii, czy innej kosmetologii.

Właściwie, to wystarczyłoby liczyć ile tasków średnio zespół ogarniał w jednostce czasu. Jeżeli taski będą podobne, to i liczba zamkniętych tasków w okresach, dajmy na to 2 tygodniowych będzie zbliżona. Ale wiadomo, że taski są różne, więc jeżeli do prawidłowo zdefiniowanych tasków, czyli takich, w których wiadomo co ma zostać zrobione poprosi się zespół o podanie czy ten task jest mniejszy, większy czy taki zwykły, nada tym odpowiedziom wartości liczbowe, to uzyska się trochę lepszą stabilność wyników/przewidywalność. Czyli zbieramy zespół, mówimy, że np. 1sp to takie najmniejsze możliwe do wyobrażenia zadanie, 3 to takie "zwykłe" itd, Właściwie nie ma znaczenia od czego się wystartuje, ważne jak się kończy, jak zwykł mawiać pan premier. A kończy się to tak, że ludzie w zespole po jakimś czasie nadal nie wiedzą, czym ten story point jest, ale potrafią wycenić zadania w miarę jednomyślnie w SP. W tym momencie wystarczy już jedynie wyciągać średnią prędkość za ostatni okres(y), i jesteśmy w stanie szacować ile i jakiej roboty zostanie dowiezione.
Żeby to działało, trzeba spełnić kilka warunków:

• kazać się zamknąć ambitnemu team leaderowi, który nadal wszystko by tylko szacował nisko, bo "przecież to łatwe", może dla niego i owszem, ale nie dla reszty zespołu, która nie potrafi przeczytać jego "clear code"

• nie rozliczać zespółu z "commitmentów" i innego g...a, w tym również pozytywnie "o jaki piękny burndown chart wam wyszedł"

• nie urządzać dramatów, że "się czegoś nie dowiozło"

• robić retrospektyw z pytaniem "dlaczego się czegoś nie dowiozło"

• nie rozliczać pracowników z liczby przepalonych story pointów

• trzymać z dala od zespołu, wszystkich, którzy mają jakieś wąty

• odrzucać zadania, które trzeba jeszcze uszczegółowić, albo rozpisać

  Jeżeli się tych warunków (i pewnie wielu innych) nie spełnia, to SP staje się naprawdę nic nie znaczącą jednostką. Jeżeli się ich przestrzega, to jesteśmy w stanie powiedzieć "OK, za c.a. 4 tygodnie będzie zrobione, chyba, ze nie będzie".
  Do tego trzeba trochę kanbana mieć - taski muszą być ułożone pod względem pilności. Jak coś jest ważne/pilne, to powinno być robione przed tym, co jest mniej ważne/pilne - wydawałoby się oczywiste, a jednak nie jest. Trzeba też traktować zespół jak dorosłych, znających się na swojej robocie ludzi, a nie bandę wyrobników kopiących od kołka do wieczora.

tekan napisał(a):

Ale ten obrazek jest cholernie prawdziwy.
Scrum z definicji spowalnia pracę i wymusza na ludziach obijanie się. Jeśli u kogoś w scrumie jest zapieprz i nadgodziny, to znaczy, że źle go wdrożył.

somekind napisał(a):

Ale ten obrazek jest cholernie prawdziwy.
Scrum z definicji spowalnia pracę i wymusza na ludziach obijanie się. Jeśli u kogoś w scrumie jest zapieprz i nadgodziny, to znaczy, że źle go wdrożył.

No nie zgadzam się - story pointy, velocity i inne pierdoły to narzędzia manipulacji, które w oczach menadżerów mają skłonić ludzi do zapieprzu poprzez budowanie poczucia winy itp., ale tak, żeby nie było widać bata.
Fakt, że to miecz obosieczny bo na cyników bez uczuć nie działa - po prostu podwyższamy estymaty (SP, które są w praktyce jednostką czasu tylko zakamuflowaną), olewamy cele sprintu, zwyczajnie nie dowozimy itp. Rygorystycznie przestrzegamy zasad ustalonych w DOD, dzięki czemu mamy spokój i luz.

I nie mamy z tym problemu. Ale inni programiści czasem mają.

@jarekr000000: To jaki system byś polecał najbardziej? Jakoś gdzieś te zadania trzeba przedyskutować, czyli spotkanie i tak musi się odbyć. Jakoś trzeba ocenić czy funkcję dowieziemy na czwartek, czy na środę, ale za dwa lata.
Nie to żebym był fanem scruma, ale jakoś tę taczkę pchać do przodu trzeba.

jarekr000000 napisał(a):

to narzędzia manipulacji, które w oczach menadżerów mają skłonić ludzi do zapieprzu poprzez budowanie poczucia winy itp., ale tak, żeby nie było widać bata.

nigdy nie zapomnę pomysłu pani ekspert z biznesu na retro (tak, biznes wzdzwaniał się na retro i inne daily i planingi)

wdzwaniajmy się z dodatkowo codziennie z programistami i pytajmy ich czemu jeszcze nie zrobili. Już samo to będzie wzbudzać wstyd

jurek1980 napisał(a):

@jarekr000000: To jaki system byś polecał najbardziej? Jakoś gdzieś te zadania trzeba przedyskutować, czyli spotkanie i tak musi się odbyć. Jakoś trzeba ocenić czy funkcję dowieziemy na czwartek, czy na środę, ale za dwa lata.
Nie to żebym był fanem scruma, ale jakoś tę taczkę pchać do przodu trzeba.

1. Dlaczego spotkanie musi się odbyć - maile i komunikatory (async) nie działają?
   (oczywiście czasem warto (efektywniej) coś przegadać - to się robi spotkanie, ale osobiście zdecydowanie wole ad-hoc meeting na temat konkretnego problemu niż regularne spotkania na których sztucznie robi się problemy).
2. No właśnie, to zwykle ważne czy coś będzie za rok dwa czy za tydzień. Natomiast przeważnie(!!!) zupełnie nieważne czy będzie za 3 dni czy za 5. Zawsze jak szacujesz to zadaj sobie pytanie co by się stało, gdyby zadanie trwało 3 razy dłużej i przeważnie odpowiedź jest - nic. Bo dość często zadania trwają 3 razy dłużej niż szacowano i jakoś świat się nie wali.

Jeśli szacowanie jest ważne - bo to budżet projekt czyli fixed - price (dla klienta) to z definicji nie ma tam miejsca na żadny scrum, i najlepiej jak szacowanie to mała grupa doświadczonych programistów i tyle.
Jak mamy umowę ramową i jakiś niby agile to szacowanie zwykle nie ma wielkiego sensu w ogóle - po prostu robimy soft i tyle. A jak już ten soft działa na produkcji i nie zamierzamy go zwinąć to sens szacowania zadań prawie zupełnie upada.

Oczywiście klient raz na jakiś czas chciałby dodać jakiś większy ficzer i zastanawia się czy warto i czy np. zdążymy na końcową wyprzedaż letnią czy inny termin - tu znowu IMO nie ma sensu szacowanie przez zespół - to jest duża grupa tasków, kilka doświadczonych osób musi to rozpisać na pomniejsze punkty i wyszacować zgrubnie. Wrzucanie tego na kark zespołu, gdzie większość i tak ma w dupie to co się wyświetla na ekranie jest bezsensowną stratą czasu.

U mnie w firmie stosuje się czasem (czasem!!!) szacowanie w niektórych projektach - generalnie jako sprawdzenie czy dobrze rozumiemy co jest do zrobienia i mamy 4 wartości:
1 - trywialne - godzina pracy, max dzień,
2 - dzień pracy, może kilka dni, zadanie jasne, ale trzeba troche nakodzić
3 - może tydzień pracy - zadanie ma jakieś ryzyko (mogą być niespodzianki)
5 - za dużo -podzielmy to

nikt nie komentuje i nawet specjalnie nie sprawdza ile faktycznie zeszło na taski, nie ma velocity,
a szacowanie służy w zasadzie w 100% do sprawdzania czy wszyscy programiści mniej więcej podobnie rozumieją co jest do zrobienia.

@jurek1980: Nie wiem jak Jarek, ale ja polecam nie mieć szefa-dzbana. A co do twoich "jakoś trzeba", to:

• Jakoś gdzieś te zadania trzeba przedyskutować, czyli spotkanie i tak musi się odbyć.

Ale może powinno ono się odbyć wtedy jak jest potrzebne, a nie wtedy jak harmonogram sprintu pozwoli?

• Jakoś trzeba ocenić czy funkcję dowieziemy na czwartek, czy na środę, ale za dwa lata.

  Dlaczego trzeba oceniać kiedy coś zostanie dostarczone?

@piotrpo:
Ja wolę jak mam zaplanowane w kalendarzu spotkanie. Widzę to tak, że pewnie w dużej części firm zrobiłby się chaos. Mniej zorganizowane osoby zaczęłyby robić takie spotkania z dnia na dzień, bez uprzedzenia i paradoksalnie mogłoby to zwiększać ich częstotliwość.

Co do szacowania terminu, no to jednak program poza opensource raczej pisany jest w celu zysku dla firmy i jednak trzeba troszkę szacować czy coś może kosztować x czy 10x.

@jarekr000000: dzięki, widzę miks podejść.

jurek1980 napisał(a):

@jarekr000000: To jaki system byś polecał najbardziej? Jakoś gdzieś te zadania trzeba przedyskutować, czyli spotkanie i tak musi się odbyć. Jakoś trzeba ocenić czy funkcję dowieziemy na czwartek, czy na środę, ale za dwa lata.
Nie to żebym był fanem scruma, ale jakoś tę taczkę pchać do przodu trzeba.

Ale czemu Cię interesuje co ile zajmie? Jeżeli ktoś skończy dane zadanie to skończy i weźmie następne. No chyba, że są priorytety i coś musi być zaraz wzięte więc trzeba na szybko inne oszacować czy się zdąży w międzyczasie, ale to inna sprawa.

jurek1980 napisał(a):

@piotrpo:
Ja wolę jak mam zaplanowane w kalendarzu spotkanie. Widzę to tak, że pewnie w dużej części firm zrobiłby się chaos. Mniej zorganizowane osoby zaczęłyby robić takie spotkania z dnia na dzień, bez uprzedzenia i paradoksalnie mogłoby to zwiększać ich częstotliwość.

Testowałem i zdecydowanie wolę spotkania ad-hoc, bez uprzedzenia.. Traci się o wiele mniej czasu. Jak mam zaplanowane spotkanie o jakiejś godzinie to wkurw rośnie mi już 40 minut przed i nie mogę się skupić na napierniczanu, a potem jeszcze przez godzinę po spotkaniu przeżywam jego bezsens. Jak mi się kolega wdzwoni z problemem to przynajmniej jest zaoszczędzone to pierwsze 40 minut wkurwu.