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

Wczoraj miałem koniec Sprintu w pracy (piątek). Mój manager w środę zważywszy, że jeszcze połowa zadań nie została zrealizowana zaczął wywierać lekką presją na nas i między innymi na mnie.

Często jest tak, że nie udaje się zrealizować wszystkiego w Sprincie z różnych przyczyn. Np. mi w tym Sprincie wyszło dwie rzeczy niespodziewanie, przez wykonywanie moich zadań przedłużyło się, że nie mogłem wziąć kolejnych. Mimo wszystko czułem presję, że nie dokończę czy coś. W dwa dni podczas Sprintu zdarzyło mi się machnąć pracę od 8 rano do 20 z bez rozliczania nadgodzin.

Manager używa także takich słów, wczoraj ich użył "we are not delivering what we are promised" - co wzbudza po części we mnie poczucie winy. Często też pod koniec Sprintu używa tabeli w Jirze do pokazania ile Story Pointów zrealizowaliśmy jako wskaźnik naszego "Velocity". Widać jego zafixowanie na metrykach i traktowaniu wszystkiego w Sprincie jako promesy.

Z drugiej strony mam już na tyle lat, że marzy mi się normalna praca w której spokojnie bym pracował, nie byłoby tylko że "od Sprintu do Sprintu". Nie chcę czuć tej presji Sprintowej. Nie myśleć po pracy czy dowiozę wszystko czy nie.....

Z kolei pracuję jako Java Developer i jak widzę to 90% firm pracowników Java robi w Sprintach.

Traktowanie Sprintów w Scrumie jako narzędzie do wywierania presji na programistach zdarza mi się już w 3 firmie w przeciągu 7 lat. Ostatnio przez długofalowy stres doszły problemy ze snem. Znajomy doradza mi pójście w Clouda/Maintenence, jeszcze inny pójście w admina.

Chciałbym zmienić pracę ale boję się, że trafię znowu na to samo.

Moje pytanie brzmi? Jak znaleźć normalną firmę, gdzie mógłbym w spokoju robić swoje 8h i nie byłoby tego dociskania i "ciągłego poczucia niedoboru" . Jak uniknąć tych firm? Jakie stanowiska pracy gdzie mógłbym się zahaczyć na parę lat w przód. Do tej pory moje 7 lat pracy to ciągłe szarpanki z życiem. Przepraszam za ten post, ale potrzebowałem się wyżalić bo mam już dość.

No ale nawet jak by nie było sprintów, to byłyby jakieś deadliny. Ja pracowałam raz bez sprintów, i był deadline, i Januszowe teksty typu "mam nadzieje że możemy na Ciebie liczyć", "daj z siebie 200%", "to bardzo ważne" itd. itp., a o nadgodzinach nie chcieli słyszeć.

Presja czasu zawsze jest w pracy software developera, chyba że jest dobry i robi zadania szybciej i się nie przyznaje do tego. (albo robi overemployment jeszcze do tego). Poczucie winy to inna kwestia zupełnie, od tego można po prostu się odciąć i być niezależnym od tego, czy Twój szef jest kut**em czy normalnym człowiekiem.

To zacznij wywierać presję żeby obniżyć scope sprintów bo aktualnie jest za duzy bo nie dostarczacie
Możesz też nalegać żeby dobrze ustalić priorytety bo sprinty są źle planowane

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.

Jeśli Ci to nie przeszkadza, to moja rada jest - po prostu rób swoje, estymuj swoje taski po swojemu, informuj PO o tym jaki jest progres (np w komentarzach), dowoź wszystko swoim rytmem, i nie przejmuj się tymi sprintami - bo one najpewniej są sprintami tylko z nazwy - jakimś sposobem managerów na zwiększenie produktywności.

Jeśli Ci to jednak przeszkadza, i chciałbyś pracować w prawdziwym scrumie, to masz dwa wyjścia: albo odejść z firmy, i już na poziomie rekrutacji pytać o to w jaki sposób praktykują pracwonicy scrum; albo spróbować zagadać do aktualnego przełożonego, z taką obserwacją, powiedzieć mu to co napisałeś tutaj, możliwe że podesłać materiały do Scrum Book'a lub innych materiałów o metodologiach, i próbować wynieść swój team na prostą.

O ile zgadzam się, że pseudoscrum, w którym sprinty są tak naprawdę sposobem na tworzenie nowych deadline'ów co dwa tygodnie, jest patologiczna, to jednak muszę zapytać - czy ty jesteś w zakładzie pracy, czy w obozie pracy? Ludzie, jesteście dorośli, jak coś wam nie pasuje, to spróbujcie usztywnić ten kręgosłup z żelatyny i powiedzieć "nie zgadzam się na takie traktowanie", zamiast podwijać ogon i potem narzekać na forumkach.

Dziękuję wszystkim za odpowiedź

Cześć,

na początku napisałeś "W dwa dni podczas Sprintu zdarzyło mi się machnąć pracę od 8 rano do 20 z bez rozliczania nadgodzin".
Czy jesteś w stanie wyjaśnić po co to robisz? Jeśli na przykład robienie zadań jest dla Ciebie ciekawe i dzięki temu się uczysz to rozumiem.
Przy czym z doświadczenia kilku lat w korporacji wiem, że rzadko ktoś ma tego typu zajawkę, że lubi siedzieć w robocie po nocach dla samej wiedzy.

Popatrz na to z perspektywy Twojego kierownika. Jedna opcja to zdaje on sobie sprawę, że robisz po godzinach i tego nie zgłaszasz, ale dla niego to jest dobre, ponieważ odpowiada za dowożenie tych tematów i Cię wykorzystuje. W tym wypadku na koniec roku on zgarnie premię, a Ty będziesz miał tylko depresje i wypalenie.
Druga opcja to nie ma on świadomości co jest częste w większych firmach, bo ciężko monitorować każdego i dlatego dokłada więcej roboty na każdy sprint.
Może gdyby o tym wiedział inaczej planowałby zadania lub zatrudnił dodatkową osobę. Jeśli pracujesz już jakiś czas to przecież sam najlepiej wiesz ile co zajmuje czasu.

Jeśli strach przed wyrzuceniem z pracy za brak dowożenia tego w nierealnych terminach tak na Ciebie wpływa to znak, że coś jest nie tak.

Wyobraź sobie, że te dodatkowe godziny, które poświeciłeś mogłeś przeznaczyć na obejrzenie filmu, granie, czytanie książek, naukę programowania lub robienie projektów za które mógłbyś otrzymać dodatkowe wynagrodzenie. W przypadku jeśli masz rodzinę lub osobę bliską mogłeś z nią spędzić czas. Nie wiem w jakim jesteś wieku, ale ja dopiero po czasie jak bliscy zaczęli odchodzić z tego świata zacząłem żałować, że tyle czasu siedzę przed tym "pudłem".

Ja zawsze nie dowoże i mam to gdzieś. Lubię robić sobie jednego taska np półtora miesiąca a w swojej karierze programisty spotkałem tylko kilka pojedynczych przypadków, że sprint był w pełni dokończony. To ma Ci powodować wyrzuty sumienia i na tej podstawie wywierać presję, abyś pracował jaknajszybciej.
Firm bez scruma w Polsce nie będących srartupami raczej nie ma a jakiś deadline zawsze będzie. Dlatego polecam zawsze robić swoim tempem. Jeżeli czegoś nie zrobisz, to task był "niedoestymowany" a nie, że Ty robisz za wolno.
Chociaż i tak myślę, że najgorsze jest daily gdzie trzeba się spowiadać ze wszystkiego i wstawać o określonej godzinie.

Już to kiedyś pisałem (pewnie nawet parę razy) ale napiszę jeszcze raz.
Kto estymuje taski? Jeśli ten kto będzie je robił to nie widzę problemu poza niedoszacowaniem (pomijam przypadki, gdzie coś się wydawało być na 1d a skończyło się na 5d ale w takim przypadku po pierwszym dniu albo nawet wcześniej należy iść do TLa i pogadać z nim co dalej - czy obijamy inne taski czy przekładamy ten na następny sprint z innym szacunkiem). Jeśli taski szacuje SM (a dodatkowo nie pyta programistów ile im to zajmie) to niech on je robi skoro tak dobrze jest rozeznany w kodzie i wie ile co zajmie.
Ty możesz mieć pretensję do siebie, że czegoś nie dowiozłeś, tylko w przypadku, kiedy powiedziałeś, że coś zajmie x (ale prawdziwe x a nie takie, że powiedziałeś x ale SM powiedział że za długo to się zgodziłeś na x/2) a zajęło 2*x bo sam niedoszacowałeś. Ale jeśli ktoś narzuca ile masz czasu na dane zadanie to trzeba powiedzieć NIE i albo nie robić albo zgłaszać nadgodziny. Nie ma robienia za free bo po roku, dwóch będziesz miał tak serdecznie dość, że trafisz do psychologa.

@abracadabr: z jakiej niby racji on ma być odpowiedzialny jeśli to on szacował? Sama nazwa przeczy jakiejkolwiek odpowiedzialności. Albo zmienić system albo nauczyć się mieć wywalone na śmieszne sprinty i tyle

Koniec sprintu/deadline to nie wyrok, spokojnie. Ja w tym sprincie dowiozlem wszystko bez nadgodzin w poprzednim połowę i też bez nadgodzin, da się? Da. Polecam nie dać sobie wejść na głowę. Po tekstach typu daj z siebie 200%, albo zależy nam bardzo... To ja stawiam sprawę krótko, że robię tyle ile mogę zrobić i nic więcej, żadnych nadgodzin siedzieć nie zamierzam. Jeśli sprawa się powtarza to szukam nowej pracy.

a ja w tym sprincie dowiozę 0%. I to nawet nie dlatego że miałem jeden duży task którego nie skończyłem. Od pierwszego dnia sprintu sypały się błędy, criticale i blokery jak szalone XD

Bezsens scruma gdy ma się produkt na produkcji

Być może lepiej by było, gdyby w zespole był jeden programista, który by czuwał nad stanem projektu, naprawiał błędy, badał criticale i usuwał blokery.
Wtedy reszta programistów mogłaby zajmować się swoją robotą.

Z drugiej strony jest też podejście zgoła odwrotne, używane w metodyce lean, gdzie błąd na produkcji celowo zatrzymuje pracę całego zespołu - https://kanbanize.com/blog/stop-the-line/
Tylko że później niczego nie można przewidzieć, jeśli jest coś zaplanowane, a potem sypią się błędy i wszyscy usuwają błędy zamiast w spokoju dodawać ficzery.

E, ale w Scrumie nie ma czegoś takiego, że ktoś jest winien. Winny jest cały zespół, bo cały zespół szacuje :3

Jeszcze jedna sprawa o której nikt nie wspomniał. Większość z tu piszących (w szczególności ci, którzy piszą "nie dało się no trudno") to wyrobnicy (nie ma się co spinać - ja też) - dostajesz zadania do zrobienia i masz je zrobić, z mniejszym (zerowym) lub większym wpływem na projekt. Nie interesuje nas klient, czy jest kasa na wypłatę, generalnie naszym zmartwieniem są taski, które mamy do zrobienia a które my lub ktoś inny w jakiś sposób wycenił. Jeśli taski wyceniamy sami (albo całym teamem) to powinno to być dla nas wiążące, jeśli wycenił je ktoś inny to jeśli się nie zgadzamy z wyceną to trzeba o tym GŁOŚNO powiedzieć.
Teraz przechodząc do sedna - jeśli mamy taska na x dni i dnia x-1 już wiemy, że się nie wyrobimy to trzeba powiedzieć o tym przełożonemu. Nasz TL i/lub SM ma nad sobą kogoś, kto albo jest decyzyjny albo ma nad sobą kogoś decyzyjnego albo kogoś kto ma nad sobą kogoś decyzyjnego itd. Zmierzam do tego, że to jednak na kodzie, który my dostarczymy zarabia nasz pracodawca/zleceniodawca. Taski zazwyczaj mają różną ważność - jeden może być zrobiony teraz ale jak będzie zrobiony za pół roku to się nic nie stanie, inny może być krytyczny bo jak go nie będzie w tym miesiącu to duży klient odejdzie. Zazwyczaj my nie mamy takiej wiedzy więc nie powinniśmy sami ustalać priorytetów - od tego też są ludzie. Więc jeśli coś się opóźnia to trzeba zadecydować czy task ciągniemy dalej czy jest on nieważny i go przekładamy bo są ważniejsze rzeczy. Ale żeby to działało to trzeba się KOMUNIKOWAĆ. Jeśli nic nie mówisz tylko robisz darmowe nadgodziny to możesz mieć żal tylko do siebie.

<OT>Przyznawać się ilu z tych krzyczących "jeśli nie zrobię wszystkich tasków pracując 8h to trudno", jeśli zrobi wszystkie taski przed końcem sprintu pracując po 8h "chwali" się tym przełożonemu a ilu ma "dodatkowy free time"?</OT>

Też jestem takiej sytuacji. Ja pomysł na siebie mam taki, że pracuję zdalnie i jak coś mi nie pasuje (typu robi się micromanagement, nudne taski w najbliższych miesiącach się szykują, czy ktoś da 20% więcej niż mam teraz), to się od razu ulatniam. Żadnych wyrzutów sumienia (uczciwie pracuję, ale raczej wolę kodem komunikować co robię, niż pięknie improwizować, grać słowami na daily), w końcu biznes jest biznes. Poza tym w naszym fachu im więcej zmian, tym szansa na bardziej różnorodny stack, tym samym lepsze skile.

Podczas rekrutacji już zaznaczam swój entuzjastyczny stosunek do SCRUM i to zwykle eliminuje mi ileś firm, ale jak już trafiam, to tam gdzie Scruma nie ma i mało kto ma ochotę to wdrożyć.

Warto pamiętać, że to co miałeś to taka typowa patologia, która ze SCRUMem nie ma wiele wspólnego - poza nazewnictwem.
Prawdziwy scrum jest o wiele gorszy:
co prawda nie ma takiego prostackiego upokarzania programistów na deadlinach, za to frustracja jaką wywołuje marnowanie czasu na planowanie, estymowanie, retro, refinmenty, stany d**y powoduje, że perspektywa machania ciężkim wiosłem, podczas gdy ktoś wali Cię batem po gołych plecach nie wydaje się taka zła.

oliver_ napisał(a):

Manager używa także takich słów, wczoraj ich użył "we are not delivering what we are promised" - co wzbudza po części we mnie poczucie winy.
Często też pod koniec Sprintu używa tabeli w Jirze do pokazania ile Story Pointów zrealizowaliśmy jako wskaźnik naszego "Velocity". Widać jego zafixowanie na metrykach i traktowaniu wszystkiego w Sprincie jako promesy.

No nie, obiecywać, że się dostarczy można jedynie te zadania, które dobrze rozumiemy, albo w ogóle są w trakcie i już je kończymy. A i tak lepiej obiecywać w perspektywie 2-3 sprintów niż jednego.
velocity nie powinno się pokazywać pod koniec sprintu, powinno być wejściem do planowania następnego sprintu, bo na tej podstawie można oszacować ile realistycznie zadań jest sens wziąć, aby dowieźć sprint. Jeśli planowanie odbywa się w oderwaniu od efektów poprzednich sprintów, to jest to czysta głupota.

Z kolei pracuję jako Java Developer i jak widzę to 90% firm pracowników Java robi w Sprintach.

No to raczej nieuniknione, że sprinty są. Tylko w samym fakcie podzielenia roku na krótsze okresy nie ma nic złego.
Też mam scruma, i jakoś nie zastanawiam po pracy, czy dowiozę, czy nie. Dowiezienie jest zazwyczaj efektem w miarę uczciwej pracy.

Moje pytanie brzmi? Jak znaleźć normalną firmę, gdzie mógłbym w spokoju robić swoje 8h i nie byłoby tego dociskania i "ciągłego poczucia niedoboru" . Jak uniknąć tych firm? Jakie stanowiska pracy gdzie mógłbym się zahaczyć na parę lat w przód. Do tej pory moje 7 lat pracy to ciągłe szarpanki z życiem. Przepraszam za ten post, ale potrzebowałem się wyżalić bo mam już dość.

Pytaj na rozmowie kwalifikacyjnej, jak u nich wygląda planowanie, co robią z velocity, czy obiecują dowiezienie wszystkich zadań w sprincie, i jakie są konsekwencje niedowiezienia.

Czitels napisał(a):

Ja zawsze nie dowoże i mam to gdzieś. Lubię robić sobie jednego taska np półtora miesiąca a w swojej karierze programisty spotkałem tylko kilka pojedynczych przypadków, że sprint był w pełni dokończony.

Skoro planujecie sprinty tak, żeby ich nie dowieźć, to nic dziwnego, że większości nie dowozicie. Osobiście nie rozumiem takiego podejścia, no ale skoro tak lubicie...
U mnie z kolei przez prawie 3 lata pracy nie dowieźliśmy może ze 4 sprintów.

KamilAdam napisał(a):

a ja w tym sprincie dowiozę 0%. I to nawet nie dlatego że miałem jeden duży task którego nie skończyłem. Od pierwszego dnia sprintu sypały się błędy, criticale i blokery jak szalone XD

Bezsens scruma gdy ma się produkt na produkcji

Ale co ma scrum do produktu na produkcji? o.O
Bezsensem jest nieumiejętność tworzenia tasków oraz wydzielenia przestrzeni na naprawę bugów. To jest niezależne od scruma, po prostu nie umiecie planować swojej pracy. No, ale zawsze łatwiej zwalić na zewnętrznego wroga niż pomyśleć, co jest faktyczną przyczyną.

LukeJL napisał(a):

Być może lepiej by było, gdyby w zespole był jeden programista, który by czuwał nad stanem projektu, naprawiał błędy, badał criticale i usuwał blokery.
Wtedy reszta programistów mogłaby zajmować się swoją robotą.

Też można, tylko to by musiała być rotacyjna rola, bo raczej nikt tego nie zniesie na dłuższą metę.
No i pytanie - co, jeśli nie ma bugów?

ToTomki napisał(a):

E, ale w Scrumie nie ma czegoś takiego, że ktoś jest winien. Winny jest cały zespół, bo cały zespół szacuje :3

Polecam normalne firmy, tam czy ze scrumem, czy bez, to to w ogóle nikt nie jest winny.

abrakadaber napisał(a):

Taski zazwyczaj mają różną ważność - jeden może być zrobiony teraz ale jak będzie zrobiony za pół roku to się nic nie stanie, inny może być krytyczny bo jak go nie będzie w tym miesiącu to duży klient odejdzie. Zazwyczaj my nie mamy takiej wiedzy więc nie powinniśmy sami ustalać priorytetów - od tego też są ludzie. Więc jeśli coś się opóźnia to trzeba zadecydować czy task ciągniemy dalej czy jest on nieważny i go przekładamy bo są ważniejsze rzeczy. Ale żeby to działało to trzeba się KOMUNIKOWAĆ. Jeśli nic nie mówisz tylko robisz darmowe nadgodziny to możesz mieć żal tylko do siebie.

Do ustalenia priorytetu zadań służy planowanie sprintu.

<OT>Przyznawać się ilu z tych krzyczących "jeśli nie zrobię wszystkich tasków pracując 8h to trudno", jeśli zrobi wszystkie taski przed końcem sprintu pracując po 8h "chwali" się tym przełożonemu a ilu ma "dodatkowy free time"?</OT>

Nikomu się nie chwalę, po prostu biorę jakiś tech debt z backlogu, albo story z następnego sprintu.

somekind napisał(a):

Ale co ma scrum do produktu na produkcji? o.O
Bezsensem jest nieumiejętność tworzenia tasków oraz wydzielenia przestrzeni na naprawę bugów. To jest niezależne od scruma, po prostu nie umiecie planować swojej pracy. No, ale zawsze łatwiej zwalić na zewnętrznego wroga niż pomyśleć, co jest faktyczną przyczyną.

A wy planujecie bugi na produkcji? Rozumiem, że na przed każdym bugiem na produkcji planujecie na to kilka dni w sprincie - bo nie ogarniam jak inaczej dowozicie...
W normalnej produkcji czasem nie ma bugów tygodniami, czasem są takie tygodnie, że wszyscy siedzą nad bugami i nie robi się nic poza tym. SCRUM do tego w ogóle nie pasuje. a w szczególności planowanie.
To znaczy oczywiście można sobie wyznaczyć np. 50% sprintu na naprawę bugów itp. I może to nawet często działać, ale jest to po prostu idiotyczna strata czasu na planowanie czegoś, czego nie ma sensu planować (sprintu - jeśli mamy produkcję).

Scrum == Micromaanagament + bat na programistów. Scenariusz w znacznej większości korpo :P

somekind napisał(a):

Ale co ma scrum do produktu na produkcji? o.O
Bezsensem jest nieumiejętność tworzenia tasków oraz wydzielenia przestrzeni na naprawę bugów. To jest niezależne od scruma, po prostu nie umiecie planować swojej pracy. No, ale zawsze łatwiej zwalić na zewnętrznego wroga niż pomyśleć, co jest faktyczną przyczyną.

Metodologia to zawsze pewien sposób patrzenia na rzeczywistość tak jak prawa Newtona jak i szczególna teoria względności opisują tą samą rzeczywistość choć w inny sposób.
Problem jaki widzę ze scrumem to fakt, że opisuje rzeczywistość w sposób strasznie słaby. W większości przypadków scrum działa, bo ludzie myślą logicznie i mają metodologię gdzieś. Jak pojawi się krytyczny błąd to zazwyczaj naprawia się go od razu, w scrumie blokuje cię iteracja. Jak pojawi się zmiana wymagań to robi się replanning, w scrumie czekasz na koniec iteracji. Jak osoba krytyczna np. jedyny tester w zespole to robi się replannig, w scrumie to w sumie nie wiadomo co powinno się robić, chyba czekać do kolejnej iteracji.

jarekr000000 napisał(a):

A wy planujecie bugi na produkcji? Rozumiem, że na przed każdym bugiem na produkcji planujecie na to kilka dni w sprincie - bo nie ogarniam jak inaczej dowozicie...

Oczywiście, że nie planujemy bugów na produkcji. Planowanie czy estymowania bugów jest wymysł jakichś chorych managerów - ale oni takie cuda wymyślają niezależnie od scruma. :)

Po prostu nie planujemy zadań na każdą godzinę sprintu, dzięki czemu mamy wydzielony czas na naprawę bugów, jeśli się pojawią.

W normalnej produkcji czasem nie ma bugów tygodniami, czasem są takie tygodnie, że wszyscy siedzą nad bugami i nie robi się nic poza tym. SCRUM do tego w ogóle nie pasuje. a w szczególności planowanie.

Dla mnie to jakiś WTF. Jest kilka warstw testów automatycznych, jest code review, ktoś jeszcze potem testuje e2e, klienci też testują po swojej stronie. Skąd nagle tyle bugów na produkcji?
To chyba w startupie jakimś, bo w produkcji zarabiającej pieniądze, to firma by się zwinęła po takim sprincie. Po prostu nie byłoby już klientów.

To znaczy oczywiście można sobie wyznaczyć np. 50% sprintu na naprawę bugów itp. I może to nawet często działać, ale jest to po prostu idiotyczna strata czasu na planowanie czegoś, czego nie ma sensu planować (sprintu - jeśli mamy produkcję).

No u nas to jest jakieś może 10% zaplanowane na bugi, w praktyce nigdy nie wykorzystywane. Produkcję mamy, sprinty zaplanowane też mamy, i jakoś tak wychodzi, że dowozimy. Niespecjalnie nawet cokolwiek robię w tym kierunku.
Nie twierdzę bynajmniej, że scrum to jedyna słuszna droga do organizacji pracy, ale po prostu się da mieć scruma, mieć sprinty i nie mieć stresu.

slsy napisał(a):

Metodologia to zawsze pewien sposób patrzenia na rzeczywistość tak jak prawa Newtona jak i szczególna teoria względności opisują tą samą rzeczywistość choć w inny sposób.

Metodologia to akurat nauka o metodach badań. :P

Problem jaki widzę ze scrumem to fakt, że opisuje rzeczywistość w sposób strasznie słaby. W większości przypadków scrum działa, bo ludzie myślą logicznie i mają metodologię gdzieś. Jak pojawi się krytyczny błąd to zazwyczaj naprawia się go od razu, w scrumie blokuje cię iteracja. Jak pojawi się zmiana wymagań to robi się replanning, w scrumie czekasz na koniec iteracji. Jak osoba krytyczna np. jedyny tester w zespole to robi się replannig, w scrumie to w sumie nie wiadomo co powinno się robić, chyba czekać do kolejnej iteracji.

Taka idea scruma, żeby nie było zmian wymagań, bo jak codziennie do pracy przychodzi inny manager i je zmienia o 180 stopni względem poprzedniego, to jest to strasznie irytujące (i stresujące też - mnie przynajmniej bardzo swego czasu stresowało). Wywarcie presji na biznesie na dostarczenie ustalonych wymagań przed rozpoczęciem pracy jest moim zdaniem bardzo zdrowe i sensowne (i oczywiście nie wymaga scruma).
Scrum sam w sobie też nie broni naprawiania bugów w sprincie. Oprócz głupców, którzy każdą godzinę sprintu planują na taski, więc bugi trzeba chyba robić w nadgodzinach. (Albo po prostu mieć zakaz robienia bugów.) Tylko to akurat znowu nie jest winą scruma.

somekind napisał(a):

KamilAdam napisał(a):

a ja w tym sprincie dowiozę 0%. I to nawet nie dlatego że miałem jeden duży task którego nie skończyłem. Od pierwszego dnia sprintu sypały się błędy, criticale i blokery jak szalone XD

Bezsens scruma gdy ma się produkt na produkcji

Ale co ma scrum do produktu na produkcji? o.O
Bezsensem jest nieumiejętność tworzenia tasków oraz wydzielenia przestrzeni na naprawę bugów. To jest niezależne od scruma, po prostu nie umiecie planować swojej pracy. No, ale zawsze łatwiej zwalić na zewnętrznego wroga niż pomyśleć, co jest faktyczną przyczyną.

Ile tej przestrzeni mam wydzielić na bugi? 30%? 50%? Bo w tym sprincie brakło mi 100% przestrzeni żeby naprawić wszystkie bugi które się zmówiły i na raz pojawiły jednocześnie. Teraz właśnie większość bugów przechodzi na kolejny sprint. Wiec jak już sie umówiły to teraz będzie lepiej. Oczywiście w story pointach to dalej będzie tragedia bo bugów sie nie estymuje więc w tym sprincie mam wykonac coś ok 1SP a reszta to bugi

somekind napisał(a):

Dla mnie to jakiś WTF. Jest kilka warstw testów automatycznych, jest code review, ktoś jeszcze potem testuje e2e, klienci też testują po swojej stronie. Skąd nagle tyle bugów na produkcji?
To chyba w startupie jakimś, bo w produkcji zarabiającej pieniądze, to firma by się zwinęła po takim sprincie. Po prostu nie byłoby już klientów.

A to jest jakaś liczba bugów po której klienci się zawijają 5, 10? 100? Bo nie wiedziałem. Co gorsza klienci ewidentnie też nie.

KamilAdam napisał(a):

Ile tej przestrzeni mam wydzielić na bugi? 30%? 50%? Bo w tym sprincie brakło mi 100% przestrzeni żeby naprawić wszystkie bugi które się zmówiły i na raz pojawiły jednocześnie. Teraz właśnie większość bugów przechodzi na kolejny sprint. Wiec jak już sie umówiły to teraz będzie lepiej. Oczywiście w story pointach to dalej będzie tragedia bo bugów sie nie estymuje więc w tym sprincie mam wykonac coś ok 1SP a reszta to bugi

No ja serio uważam, że scrum to najmniejszy problem jeśli 100% czasu pracy zajmuje naprawianie bugów.
To jest jakaś patodeveloperka. :D

jarekr000000 napisał(a):

A to jest jakaś liczba bugów po której klienci się zawijają 5, 10? 100? Bo nie wiedziałem. Co gorsza klienci ewidentnie też nie.

Nie wiem, ale jak przez 2 tygodnie wszystko leży, i klienci nie są w stanie używać softu, przez co tracą dochody, to jak długo mogą takie coś tolerować? Obawiam się, że raczej krócej niż dłużej.

somekind napisał(a):

KamilAdam napisał(a):

Ile tej przestrzeni mam wydzielić na bugi? 30%? 50%? Bo w tym sprincie brakło mi 100% przestrzeni żeby naprawić wszystkie bugi które się zmówiły i na raz pojawiły jednocześnie. Teraz właśnie większość bugów przechodzi na kolejny sprint. Wiec jak już sie umówiły to teraz będzie lepiej. Oczywiście w story pointach to dalej będzie tragedia bo bugów sie nie estymuje więc w tym sprincie mam wykonac coś ok 1SP a reszta to bugi

No ja serio uważam, że scrum to najmniejszy problem jeśli 100% czasu pracy zajmuje naprawianie bugów.
To jest jakaś patodeveloperka. :D

Naprawdę nigdy nie dostałeś buga którego rozwiązywałeś przez 2tygodnie? Albo dwóch bugów po tydzień? Jakieś poj'bane issue performansowe którego nie da się odtworzyć gdzie gubią się losowe dane? Ktoś używa aplikacji którą robicie czy piszecie do szuflady?

I dalej nie odpowiedziałeś mi ile procent czasu powinienem przeznaczać na bugi żeby było dobrze

somekind napisał(a):

No ja serio uważam, że scrum to najmniejszy problem jeśli 100% czasu pracy zajmuje naprawianie bugów.

Wystarczy odziedziczyć po kimś kod. Tak czy owak mamy kolejną klasę projektów do której scrum nie pasuje.

KamilAdam napisał(a):

Naprawdę nigdy nie dostałeś buga którego rozwiązywałeś przez 2tygodnie? Albo dwóch bugów po tydzień? Jakieś poj'bane issue performansowe którego nie da się odtworzyć gdzie gubią się losowe dane?

Miałem nie raz, i nie widzę problemu, bo:

1. Nie jestem jedynym pracownikiem zespołu, jeśli ja naprawiam buga, to historyjki dalej są robione przez resztę.
2. Jeśli bug nie jest krytyczny (czyli nie leży produkcja), to nie trzeba, go robić natychmiast. Naprawia się go w wolnej chwili, w czasie nieprzekraczającym sprintowego worka na bugi.
3. Jeśli po wstępnej analizie widać, że to jest grubsza sprawa, i nie da się to zrobić w czasie założonym na bugi w sprincie, ale już zdiagnozuje się przyczynę, to robi się z tego np. dług techniczny, a potem planuje jak każde normalne zadanie w kolejnym sprincie.
4. Gdybyśmy jakimś cudem zostali zawaleni tysiącem pilnych bugów, to jeśli biznes tak zdecyduje, to poświecimy cały sprint (albo 2, albo 8) na ich naprawianie.
   Aczkolwiek dla mnie to jest sytuacja niepojęta, aby mieć tyle bugów. Takie rzeczy może się zdarzały, gdy jeszcze pracowałem w młodych, ambitnych zespołach, w plantacjach spaghetti zwanych "liderami branży", z architektami, którzy równocześnie pisali prace magisterskie idąc normalnym tokiem studiów. :P Ale w firmach produktowych, które znam nie ma na to szans - jakość produktu jest zbyt ważna, bo to jest źródło dochodu. Jeśli dbamy o jakość, to bugi się zdarzają, a nie stanowią główną część pracy.

Bugi zdarzają się niezależnie od metodyki i trzeba sobie jakoś ogarnąć pracę z nimi - no chyba, że kochasz je naprawiać przez 100% czasu pracy.
Klucz to ogólnie komunikacja i rozsądek, a nie wymyślanie sobie sztucznych ograniczeń i narzekanie na nie.

Ktoś używa aplikacji którą robicie czy piszecie do szuflady?

Nie no, nikt nie używa. 1,5 miliarda obrotu rocznego są generowane przez bugi na produkcji. :D :D :D

I dalej nie odpowiedziałeś mi ile procent czasu powinienem przeznaczać na bugi żeby było dobrze

Na to nie ma jakiegoś ogólnego wzoru, wartość trzeba dobrać na podstawie historii konkretnych projektów. Skoro u Ciebie 100% czasu zajmują bugi, to chyba tyle po prostu powinieneś brać. Co powinno dać trochę do myślenia po pierwsze biznesowi, po drugie programistom.

slsy napisał(a):

Wystarczy odziedziczyć po kimś kod. Tak czy owak mamy kolejną klasę projektów do której scrum nie pasuje.

No jeśli mamy pracować nad projektem, którego zupełnie nie znamy, nie ma dokumentacji, i nie ma przekazania wiedzy, to trzeba o tym poinformować biznes i niech rozwiąże problem.

somekind napisał(a):

No jeśli mamy pracować nad projektem, którego zupełnie nie znamy, nie ma dokumentacji, i nie ma przekazania wiedzy, to trzeba o tym poinformować biznes i niech rozwiąże problem.

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

somekind napisał(a):

KamilAdam napisał(a):

Naprawdę nigdy nie dostałeś buga którego rozwiązywałeś przez 2tygodnie? Albo dwóch bugów po tydzień? Jakieś poj'bane issue performansowe którego nie da się odtworzyć gdzie gubią się losowe dane?

Miałem nie raz, i nie widzę problemu, bo:

1. Nie jestem jedynym pracownikiem zespołu, jeśli ja naprawiam buga, to historyjki dalej są robione przez resztę.

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

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