W jakich zawodach/specjalizacjach IT nie podlega się pod Scrum'a?

Hej, w jakich zawodach specjalizacjach IT nie podlega się w pracy pod Scrum'a? Jestem na etapie w życiu gdzie czuję się wypalony przez tą metodologię i szukam pracy, gdzie mógłbym pracować swoim tempem.

To zależy raczej nie od specjalizacji, tylko od firmy, i projektu, i nawet teamu wewnątrz projektu. W jednych miejscach używa się scruma, w innych nie - różnie można trafić.

może ktoś ma zawód, że pracował np. 5 lat i nigdy nie miał scruma

Ogólnie to nie jest raczej kwestia zawodu, co (jak napisał @Azarien powyżej) danej firmy albo nawet samego projektu.

Ale jeśli mamy już generalizować to ja bym powiedział, że najbardziej scrumowe są zadania związane typowo z tworzeniem czegoś, robieniem na zamówienie klienta itp. Tam masz ciągłą ewolucję wymagań, dopasowywanie się do oczekiwań klienta, otrzymywanie feedbacku itp. W związku z tym - przeciwieństwem jest praca wdrożeniowca, analityka danych, kogoś od baz danych, administratora czy devopsa. Tam masz raczej względnie krótkie strzały, do tego w miarę powtarzalne - więc masz duże szanse, że posiadając doświadczenie, będziesz w stanie to sensownie i realistycznie wycenić, a co za tym idzie, nie będzie potrzeby stosowania metodyk zwinnych.

kevin_sam_w_domu napisał(a):

Hej, w jakich zawodach specjalizacjach IT nie podlega się w pracy pod Scrum'a? Jestem na etapie w życiu gdzie czuję się wypalony przez tą metodologię i szukam pracy, gdzie mógłbym pracować swoim tempem.

Nie bardzo rozumiem co ma sacrum do pracy we własnym tempie? Jak nie będzie scruma to będzie np waterfall i wyceny zrobione przez projektanta/analityka. Proponuje założyć własną frimę - świat nie dopasuje się do ciebie. Musisz se go wykreować jak chcesz coś zmienić.
Typowo nie-scrumowe są działy utrzymania gdzie reagujesz na zaistniałe zdarzenia w czasie rzeczywistym. Ale to raczej nie jest praca "w swoim" tempie.

@UglyMan:

UglyMan napisał(a):

kevin_sam_w_domu napisał(a):

Hej, w jakich zawodach specjalizacjach IT nie podlega się w pracy pod Scrum'a? Jestem na etapie w życiu gdzie czuję się wypalony przez tą metodologię i szukam pracy, gdzie mógłbym pracować swoim tempem.

*Nie bardzo rozumiem co ma sacrum do pracy we własnym tempie? *

Wystarczy, że podczas Scrum Pokera parę osób da wycenę niższą niż Ty i zaczniesz się zastanawiać co jest z Tobą nie tak, w sensie czemu dałeś za małą wycenę? Czy faktycznie potrzebujesz mniej czasu? A może masz gorsze umiejętności?

Security to nadal pojedynczy gość siedzący w piwnicy. Architekci też pod scruma nie podlegają. Najlepiej to zostań team-leadem będziesz wtedy tylko przyglądał się jak stresują się inni :P

kevin_sam_w_domu napisał(a):

@UglyMan:

UglyMan napisał(a):

kevin_sam_w_domu napisał(a):

Hej, w jakich zawodach specjalizacjach IT nie podlega się w pracy pod Scrum'a? Jestem na etapie w życiu gdzie czuję się wypalony przez tą metodologię i szukam pracy, gdzie mógłbym pracować swoim tempem.

Nie bardzo rozumiem co ma sacrum do pracy we własnym tempie?

Wystarczy, że podczas Scrum Pokera parę osób da wycenę niższą niż Ty i zaczniesz się zastanawiać co jest z Tobą nie tak, w sensie czemu dałeś za małą wycenę? Czy faktycznie potrzebujesz mniej czasu? A może masz gorsze umiejętności?

Jak bym tak podchodził do tematu to juz bym chyba dawno ze sobą skończył, bo bym nie wytrzymał napięcia psychicznego. Ja np uważam się za słabego programistę, ale mam ile cechy, które pozwalają mi się unosić na powierzchni szamba. Najlepsze metodyka, jaką o jakiej czytałem na tym forum (@abrakadaber o tym pisał) to JJNNB . Nie ma się co przejmować, dopóki kasa na koncie.

Koledzy trochę robicie z igły widły. Dajecie niższe wyceny niż inni członkowie zespołu i już chcecie robotę zmieniać, bo to jest jakiś wielki stres? Obawiam się, ze problem nie leży w pracodawcy tylko hm… w samoocenie?

@UglyMan:

Typowo nie-scrumowe są działy utrzymania gdzie reagujesz na zaistniałe zdarzenia w czasie rzeczywistym. Ale to raczej nie jest praca "w swoim" tempie.

Tylko to jest jeszcze gorsze, bo wtedy leci SLA i masz np. 48H na usunięcie awarii, a żeby usunąć trzeba namierzyć. Tak więc praca na utrzymaniu może być jednak o wiele bardziej stresująca.

@kevin_sam_w_domu

Jestem na etapie w życiu gdzie czuję się wypalony przez tą metodologię i szukam pracy, gdzie mógłbym pracować swoim tempem.

Scrum w jednek firmie != Scrum w innej firmie. Wiadomo że we wszelkich ołtosorsingach robisz soft dla klienta i tam raczej będzie ciśnięcie aby terminy się zgadzały.

Najbezpieczniej to chyba do jakiejś firmy produktowej dołączyć. Tam na 99% też będzie scrum, ale sądzę, że jednak spokojniej.

.andy napisał(a):

@UglyMan:

Typowo nie-scrumowe są działy utrzymania gdzie reagujesz na zaistniałe zdarzenia w czasie rzeczywistym. Ale to raczej nie jest praca "w swoim" tempie.

Tylko to jest jeszcze gorsze, bo wtedy leci SLA i masz np. 48H na usunięcie awarii, a żeby usunąć trzeba namierzyć. Tak więc praca na utrzymaniu może być jednak o wiele bardziej stresująca.

Wiem jak to wygląda. Kilka lat spędziłem na utrzymaniu gdzie kary za przekroczenie jednego dnia przekraczały moją miesięczną pensję. Mieliśmy szkolenia jak sobie radzić ze stresem i to, że klient bluzga ci do telefonu, to nie bluzga na ciebie tylko na firmę :)

@UglyMan:

Najlepiej jest, jak odbieraniem telefonów zajmuje się I linia wsparcia a nie programiści. Potem to jeszcze przechodzi przez II linię i dopiero wpada do programistów/baz danych/grafików itp.

Osobiście też znam pracę na utrzymaniu i może to być bardziej stresujące, szczególnie jak bug jest duży i kluczowy do działania, wtedy liczy się czas i może to być demotywujące...

Moim zdaniem nie problemem jest metodyka pracy a otoczenie, pełniona funkcja i odpowiedzialność z nią związana. Jeżeli ktoś liczy na dużo monet co miesiąc, to trzeba się liczyć, że będzie to czymś okupione. Jak ktoś chce mieć 20k co miesiąc do łapki, to raczej logiczne jest że będzie musiał sobie radzić z dużą presją.
Im większa kasa, tym często większa odpowiedzialność.

Co do scruma powiem tak: są 3 pewne rzeczy w życiu:

1. Śmierć
2. Podatki
3. Nie wyrobienie się w sprincie.

Ja sie do tego po prostu przyzwyczaiłem.

kevin_sam_w_domu napisał(a):

Hej, w jakich zawodach specjalizacjach IT nie podlega się w pracy pod Scrum'a? Jestem na etapie w życiu gdzie czuję się wypalony przez tą metodologię i szukam pracy, gdzie mógłbym pracować swoim tempem.

Scrum to połączenie dziwnych polityk i partyzantki. Wymuszonej powagi i improwizacji. Korpostylu i januszerki.

Dziwne polityki/wymuszona powaga to wiadomo, cały Scrum polega na tym, że wymyśla się jakieś procedury i wierzy w ich powagę. Tylko, że jak nie będzie Scruma to zawsze mogą być jakieś inne dziwne polityki firmowe (nawet może gorsze, bo Scrum przynajmniej to kodyfikuje jakoś).

Partyzantka natomiast bierze się z próby wprowadzenia Scruma w realnym projekcie. Realni ludzie wprowadzają Scruma do realnych projektów, więc to nigdy nie będzie książkowy Scrum, tylko bardzo nagięty. Tylko, że partyzantkę będzie się robiło nawet bez Scruma. Zawsze się trochę improwizuje.

Czyli od Scrumu nie uciekniesz. Wszystko jest Scrumem. Nawet walka rządu z pandemią to też taki Scrum - bo masz jednocześnie ceremonie typu obostrzenia, tarcze antykryzysowe, lockdowny, maseczki, czyli Scrum w teorii, a z jednej strony masz wielki burdel i nieudolność, czyli Scrum w praktyce.

Pod Scrum Mastera się nie podlega. Z nim się walczy
BTW jak na rekrutacji powiesz że gardzisz SM to odpadnie ci 90% firm i zostanie te 10% których szukasz

@LukeJL:

Scrum to połączenie dziwnych polityk i partyzantki. Wymuszonej powagi i improwizacji. Korpostylu i januszerki.

Nie zgadzam się.

Dziwne polityki/wymuszona powaga to wiadomo, cały Scrum polega na tym, że wymyśla się jakieś procedury i wierzy w ich powagę. Tylko, że jak nie będzie Scruma to zawsze mogą być jakieś inne dziwne polityki firmowe (nawet może gorsze, bo Scrum przynajmniej to kodyfikuje jakoś).

Wymuszona powaga? Nie wiem jak to u Ciebie wygląda, ale u mnie nie ma żadnej wymuszonej powagi. Fakt, że jak się na daily omawia zadania to nie ma offtopiku ale no to chyba chodzi o to nie? Lecimy, szybkom dajemy status itd.

Partyzantka natomiast bierze się z próby wprowadzenia Scruma w realnym projekcie. Realni ludzie wprowadzają Scruma do realnych projektów, więc to nigdy nie będzie książkowy Scrum, tylko bardzo nagięty. Tylko, że partyzantkę będzie się robiło nawet bez Scruma. Zawsze się trochę improwizuje.

No nie zgadzam się. Partyzantka jeżeli już się pojawia, to bierze się z patologii w firmie. Jeżeli ktoś wprowadza tę metodologię byle jak, jak najtaniej aby było, to potem nic nie będzie działało poprawnie i nie ma to związku ze scrumem ale patologią w danej organizacji.

Pod Scrum Mastera się nie podlega. Z nim się walczy
BTW jak na rekrutacji powiesz że gardzisz SM to odpadnie ci 90% firm i zostanie te 10% których szukasz

No ja na swojego nie narzekam. Moim zdaniem generalizujesz. Może wpadasz na takich a nie innych ludzi w firmach i stąd takie zdanie?

Pracowałem gdzie scrum to był tylko z nazwy, ale i mam styczność gdzie faktycznie to jest scrum. Wiadomo ideału nie będzie ale liczy się dążenie do polepszania tego co się ma.

.andy napisał(a):

@LukeJL:

Scrum to połączenie dziwnych polityk i partyzantki. Wymuszonej powagi i improwizacji. Korpostylu i januszerki.

Nie zgadzam się.

Jakoś bardzo nie będę Scruma bronił, ale jakiś Scrum musiał bardzo @LukeJL skrzywdzić, że ma takie złe zdanie o nim.

Jak nie będzie scruma to będzie np waterfall i wyceny zrobione przez projektanta/analityka.

Standardowa propagadna Scrumowa nr.1 - jak nie Scrum to waterfall. Piękne.
(nigdy nie brałem udziału w projekcie waterfall (poza może projektami studenckimi), a pracowałem długo zanim nawet o SCRUMIE usłyszałem.
I nawet wtedy ludzie wiedzieli, żę waterfall to utopia i tak się projektów nie robi.

Z ciekawostek - jak najbardziej można nie mieć estymat. Całkiem dużo zespołów tak pracuje. Ja, w sumie nie mam estymat - mam określenie poziomu komplikacji zadania:

• trywialne (zmiana jednej linijki),
• proste (wiadomo co zrobić i nie widać żadnych ryzyk),
• męczące (trzeba się napracować i jest jakieś ryzyko, że będzie się zaskoczonym),
• nie wiadomo co to nawet jest - (trzeba podzielić lub zrobić rozpoznanie alką (timebox)

@LukeJL:

Przez wymuszoną powagę nie miałem na myśli tego, że ludzie są super poważni (bo mogą być całkiem wyluzowani), tylko raczej że niektórzy poważnie traktują rzeczy takie jak np. planning poker. Cała idea planning pokera to jest absurd i raczej coś jak z dowcipów czy gier po pijaku. A jednak ludzie całkiem na serio myślą, że jak podczas planowania rzucą liczbę od niechcenia, to potem będzie to miało jakieś wielkie znaczenie. I później traktowanie tych estymacji jako wyroczni i liczenie na podstawie tego velocity i patrzenie na wykresy, jakby miało to jakiekolwiek znaczenie.

Wycenę zadania się robi na poziomie zespołu a nie poszczególnej osoby na koniec. Jeżeli ktoś da mniej lub więcej niż inni, to się to wyjaśnia dlaczego tak a nie inaczej. Potem jest decyzja czy np. ocena tej osoby była ze względu na małe doświadczenie, wiedzę czy niezrozumienie tematu. Dopowiada się rzeczy i na koniec powstaje finalna wycena zespołu.

Jak zespoły pracują ze sobą już N sprintów, to jesteś w stanie z mniejszą lub większą dokładnością ocenić ile są w stanie obrać ziemniaków. Wiadomo, ziemniak ziemniakowi nie równy. Zawsze też mogą się pojawić jakieś okoliczności, których ktoś nie przewidział i czas pracy nad zadaniem.

I później traktowanie tych estymacji jako wyroczni i liczenie na podstawie tego velocity i patrzenie na wykresy, jakby miało to jakiekolwiek

Nikt normalny nie traktuje tego jako wyroczni ale też nie jest to wartość z tzw. d**y.

Albo przywiązywanie wielkiej wagi do obecności na codziennych standupów. Rozumiem, że fajnie jest mieć taką możliwość komunikacji z całym zespołem o jednej godzinie raz dziennie, ale jednak wymuszanie tego i opieprzanie za nieobecność na standupach jest śmieszna, bo na większości standupów nic się nie dzieje (albo np. rzeczy, ktore się dzieją dotyczą tylko częsci zespołu). Poza tym jak będzie trzeba, to można zawsze skomunikować się inaczej

Może tak jest u Ciebie. Standup polega na omówieniu zadań z całego zespołu scrumowego, pokazania problemów (to powinno być też sygnalizowane w ciągu dnia) oraz omówienia innych rzeczy.
Wiadomo, że np. komuś może coś wypaść i nie będzie w stanie na nim być i wtedy po prostu informuje zespół - bo pracuje w zespole.

To zależy od menedżmentu firmy, znam firmy

• IT które wziąż nie pracują w scrumie (raczej małe takie których nie stać na edżajl-coucha za 30k)
• IT które pracują w Scrumie
• zupełnie nie IT które może nie pracują w Scrumie (bo nie upadli na głowę żeby zatrudnić edżajl-coucha za 30k) ale w czymś Scrumo-podobnym i nawet Jira używają do sprawdzania czy handlowiec dzwonił i czemu jeszcze nie zadzwonił chociaż ma otwartego task w Jira

Czemu uważasz że wypalenie przez Scrum?

Gamedev raczej takich cudów nie ma.

jarekr000000 napisał(a):

Jak nie będzie scruma to będzie np waterfall i wyceny zrobione przez projektanta/analityka.

Standardowa propagadna Scrumowa nr.1 - jak nie Scrum to waterfall. Piękne.
(nigdy nie brałem udziału w projekcie waterfall (poza może projektami studenckimi), a pracowałem długo zanim nawet o SCRUMIE usłyszałem.
I nawet wtedy ludzie wiedzieli, żę waterfall to utopia i tak się projektów nie robi.

Z ciekawostek - jak najbardziej można nie mieć estymat. Całkiem dużo zespołów tak pracuje. Ja, w sumie nie mam estymat - mam określenie poziomu komplikacji zadania:

• trywialne (zmiana jednej linijki),
• proste (wiadomo co zrobić i nie widać żadnych ryzyk),
• męczące (trzeba się napracować i jest jakieś ryzyko, że będzie się zaskoczonym),
• nie wiadomo co to nawet jest - (trzeba podzielić lub zrobić rozpoznanie alką (timebox)

Czyli metodyka ułańska - weźmy i zróbmy. Do tego potrzeba ogarniętych ludzi. Niestety, ale większość ludzi potrzebuje bata w postaci terminu. Mało jest firm, które nie chcą wiedzieć ile coś będzie kosztowało, zanim to zlecą.

UglyMan napisał(a):

Mało jest firm, które nie chcą wiedzieć ile coś będzie kosztowało, zanim to zlecą.

Oczywiście jest ciągle trochę takich firm, a bardziej projektów. To są projekty fixed price - robienie takiego projektu w SCRUMie to typowa patologia, bo akurat SCRUM się do takich słabo nadaje zupełnie - (na grzyba estymować i commitować się w sprintach, skoro projekt jest już dawno wyceniony i trzeba jechać z planem).

Niestety, ale większość ludzi potrzebuje bata w postaci terminu.

Nie znam większości ludzi, ale jeśli Ciebie zawsze poganiali to nie znaczy, że a) naprawde tego potrzebujesz, b) inni też tego potrzebuą - to raczej tradycja.

Oczywiście terminy deadliny itp. to rzeczywistość - biznes czasem ma daty, do których trzeba się dostosować. To nie znaczy, że każde zadanie trzeba estymować i przejmować się jego czasem wykonania. Dużo projektów, featurów działa na zasadzie stałych wydań - co zrobimy i domkniemy to wchodzi na produkcję. A jak nie domkniemy teraz to pójdzie następnym razem, świat się nie zawali.

Stawiam hipotezę, że tak ponad 90% estymat które ludzie robią nie ma żadnego znaczenia, bo to czy zadanie będzie zrobione w 1 czy 10 dni niewiele zmieni. (Chyba, że manago bawi się w Tetrisa). Ludzie robią sobie sztuczną presję. Sprinty.
Jak ktoś biegnie na długi dystans to nie robi cały czas serii sprintów.

niestety to się rozprzestrzenia nawet poza obszary IT
w obecnej firmie analitycy biznesowi podlegają scrumowi - są teamy złożone z samych analityków. mają daily, planowanie, story pointy i cały ten $hit.
w poprzedniej firmie podobnie miały... rekruterki. Miały też u siebie wielką kanbanową tablicę do śledzenia progresu w rekrutacji (wtf?)

@kevin_sam_w_domu: no ale powiedz, co w tym Scrumie jest dla Ciebie takiego niedobrego? Czy to cecha Scruma?

co w tym Scrumie jest dla Ciebie takiego niedobrego?

Ze Scrumem jest jak z komunizmem - w teorii wygląda bardzo fajnie, ale mega ciężko jest spotkać dobrze to wdrożone (zarówno Scrum, jak i komunizm). Zresztą zobacz na forum, ile ludzie żalów wylewają na to, co się dzieje u nich w firmach. Mam wrażenie, że stosunek opinii negatywnych do pozytywnych to tak 80/20. I nie jest to dowód że sam scrum jest zły, ale że ciężko znaleźć miejsce gdzie to ładnie działa, a często przybiera to formę parodii (albo patologii).

Ja u nas w firmie (mała firma produktowa) namówiłem górę na kanban i sprawdza się o niebo lepiej niż sztuczne sprinty scrumowe. Nadal mamy planowania, jakieś estymaty zadań itp, ale brak sprintów robi robotę. Po prostu jest kolejka zadań i jak kończysz jedno to zaczynasz następne. Jak coś się w zadaniu przedłuża, to nikt nie robi problemu, bo nie ma że releas w poniedziałek.
Teraz też przechodzimy z releasów na coś w typie trunk based - każdy task wychodzi z mastera i jest deployowany od razu na produkcję. Jestem ciekaw jak to się sprawdzi bo jeszcze nigdy tak nie pracowałem, ale fajnie mi to się spina z kanban.

To co mogę doradzić to zmiana pracy na firmę produktową. Po prostu jakość liczy się bardziej niż estymaty i łatwiej wprowadzić sensowne zmiany.

W tej chwili chyba wszystko jedzie jakimś agile'm scrum, kanban - jeden pies. Nawet jak masz fixed price gdzie wiesz co musisz dostarczyć i na kiedy, to przyjdzie jakaś małpa i zacznie robić sprinty i z nich rozliczać. Jedyny wyjątek to wsparcie, ale tam mają inną magię - ITIL, bo ktoś zauważył, że oni nie pracują w projekcie, tylko na strumieniu.

Natomiast nawet w tym scrumie, można trafić całkiem dobrze, gdzie ta metodyka pomaga w pracy, a można trafić na jakiegoś scrumowego krzyżowca i wtedy jedyne co można zrobić, to zwyczajnie go olać, bo po przejściu kursu dla mistrzów, zrobił certyfikat, dostał podwyżkę i poczuł się "władny". Można z nim rozmawiać tak jak z parafianką księdza pedofila - beton. Wtedy robota w projekcie stoi, zaplanowałeś za mało to broń boże zrobić coś jeszcze, bo burndown wyjdzie krzywy, zaplanowałeś za dużo, to pretensje, ze się nie udało, a ty zwyczajnie nie przewidziałeś, że akurat wypada scrumowy wielki tydzień i będzie więcej scrumowych nabożeństw, niż czasu na pracę.

Aktualnie pracuję w projekcie, w którym udało nam się wypchnąć chyba całość szajsu za burtę, zostały rzeczy przydatne, czyli zadania są przyzwoicie opisane i przegadane z zespołem, rozbite na user stories, oszacowane, chyba, że się nie da, to robimy zadania na rozpoznanie tematu, żeby dało się oszacować. Raz na jakiś czas spotykamy się i przegadujemy co można by poprawić, daily trwa 15 minut, chyba, że ktoś potrzebuje zostać i pogłębić dyskusję. Żadnych dyskusji o tym czym jest story point, żadnej dodatkowej presji. Wiadomo co trzeba będzie zrobić, wiadomo co zostało zrobione, wiadomo jakie są kryteria akceptacji. Wszystko kwestią trafienia na odpowiednią osobę.

kevin_sam_w_domu napisał(a):

Hej, w jakich zawodach specjalizacjach IT nie podlega się w pracy pod Scrum'a? Jestem na etapie w życiu gdzie czuję się wypalony przez tą metodologię i szukam pracy, gdzie mógłbym pracować swoim tempem.

No ja też nie lubię się obijać, ale spójrz na to z tej strony, że to przecież oni palą swoje pieniądze.
Zawsze możesz spróbować upchnąć drugiego klienta albo jakieś zlecenia w czasie wolnym.

.andy napisał(a):

Moim zdaniem nie problemem jest metodyka pracy a otoczenie, pełniona funkcja i odpowiedzialność z nią związana. Jeżeli ktoś liczy na dużo monet co miesiąc, to trzeba się liczyć, że będzie to czymś okupione. Jak ktoś chce mieć 20k co miesiąc do łapki, to raczej logiczne jest że będzie musiał sobie radzić z dużą presją.
Im większa kasa, tym często większa odpowiedzialność.

E tam, to od kultury organizacji zależy. Największą presję czułem zarabiając 5k, w projekcie, który był na wczesnym etapie tworzenia. Teraz nie czuję nawet 10% tamtej presji pracując nad softem, który faktycznie działa i ma użytkowników.

scibi_92 napisał(a):

Co do scruma powiem tak: są 3 pewne rzeczy w życiu:

1. Śmierć
2. Podatki
3. Nie wyrobienie się w sprincie.

Ja sie do tego po prostu przyzwyczaiłem.

Hmm... Przez ostatnich 40 sprintów mój zespół nie wyrobił się dwiema historyjkami. Raz, bo ludzie odpowiedzialni za załatwienie integracji z zewnętrznym API dali ciała, drugi raz, bo inny team nie zrobił swojej części zależności (obie te rzeczy to oczywiście patologie, ale nie są winą scruma).

Ale też się kiedyś nie wyrabiałem w sprintach, to było w polskim SH, w którym planowanie sprintu trwało dwa dni, a jego efektem było tyle tasków ile klas mamy napisać, a story pointy były przeliczane wprost na godziny. Estymaty w godzinach nie mają sensu.

jarekr000000 napisał(a):

(nigdy nie brałem udziału w projekcie waterfall (poza może projektami studenckimi), a pracowałem długo zanim nawet o SCRUMIE usłyszałem.
I nawet wtedy ludzie wiedzieli, żę waterfall to utopia i tak się projektów nie robi.

A mi się zdarzyło. Był waterfall, był UML, był sztab analityków odizolowany od programistów, byli architekci w wieku 22-25 lat, były nadgodziny, było wspaniale. ;)

Z ciekawostek - jak najbardziej można nie mieć estymat. Całkiem dużo zespołów tak pracuje. Ja, w sumie nie mam estymat - mam określenie poziomu komplikacji zadania:

• trywialne (zmiana jednej linijki),
• proste (wiadomo co zrobić i nie widać żadnych ryzyk),
• męczące (trzeba się napracować i jest jakieś ryzyko, że będzie się zaskoczonym),
• nie wiadomo co to nawet jest - (trzeba podzielić lub zrobić rozpoznanie alką (timebox)

W sumie do tego sprowadzają się estymaty u mnie, tyle że mają przypisane wartości liczbowe. No i to działa o tyle, że w ramach każdego sprintu dostarczamy tyle SP, ile zakładamy.
Oczywiście bez scruma można byłoby zrobić więcej, bo nie byłoby ograniczeń blokujących ludzi, a poza tym nikt nie jest taki głupi, żeby dostarczać więcej niż obiecał, bo wie czym to grozi. :)
No ale jak klient woli cyferki od efektów, to jego sprawa.

piotrpo napisał(a):

W tej chwili chyba wszystko jedzie jakimś agile'm scrum, kanban - jeden pies.

Ni ma reguły. Pracowałem w dużym korpo, gdzie oficjalnie był scrum a w praktyce każdy był sobie statkiem :P Było to na tyle ciekawe, że nie było jakiś durnych spotkań, daily i innych dupereli. Był jeden wyznaczony termin do kiedy coś ma być zrobione.

Teraz pracuję w innym korpo, gdzie wszyscy żyją scrumem i co raz częściej bywa to przytłaczające. Dosłownie sztuka dla sztuki, ale to temat na inny wątek :P

Podsumowując - Firma i scrum to ruletka.