SCRUM zawsze i wszędzie zbawieniem będzie?

5

Witam.

Czy zdarzyło się Wam pracować jako programiści pod sztandarem scruma?
Mam tu na myśli pełen zespół (3-9 devów) wraz z dedykowanymi rolami Scrum Mastera oraz Product Ownera.

Osobiście nie jestem przekonany do całości "procesu".
Agile'owcy mówią, że "nie czuję" scruma, całość brzmi dość sekciarsko
Po zapoznaniu się z teorią i praktykowaniu przez pewien czas nie potrafię także powiedzieć na co spalane jest 16h dziennie (2 osoby po 8h) czasu pracy osób procesowych.
Ogarnięcie ticketów, mail/komunikacja z klientem + ewentualne zebranie fizycznie nie zajmują więcej niż 3-4h.
Zajęcia takie jak coachowanie zespołu, wspieranie samoorganizacji i usuwanie przeszkód w zespole to dość hm... eteryczne pojęcia.

Jakie są Wasze wrażenia/zdanie na ten temat?
Chodzi mi tu głównie o Wasze opinie na temat przydatności wspomnianych dedykowanych ról SM&PO.
Jak wielki mają one sens przy bądź co bądź niewielkim zespole (czy narzut organizacyjny nie jest zbyt duży)?

5

SCRUM podobnie jak prawie wszystko działa tylko przy pewnych zadaniach/przypadkach, ale jak z prawie każdą metodologią/technologią można do niego poejść sekciarsko i używać wszędzie, nawet tam gdzie to zupełnie nie ma sensu.

Jeżeli zespół jest rozproszony geograficznie i trzeba coś ustalić to mitingi mają sens, ale jeżeli zespół siedzi razem i jedyną osobą w innym miejscu jest pm, to już się można poważnie nad tym sensem zastanawiać.
Jeżeli nawet pm jest w tej samej lokalizacji to mitingi są marnowaniem czasu.
Mitingi też powinny być o czymś, a nie tępe odbębnienie szablonu, że wczoraj robiłem to, dzisiaj to, a jutro tamto(od tego jest jira), i jeżeli tego się nie przestrzega to SM można rozwinąć jako sado maso a nie scrum master.
Rotacyjna rola sm(na początek) ma ten sens, że człowiek zaczyna rozumieć, że to jest jednak dodatkowy wysiłek i mniej ludzi wtedy hejci stałego sma.

Usuwanie przeszkód faktycznie działa o ile osoba za to odpowiedzialna się na to stanowisko nadaje i ma realne możliwoći/władzę.

Mnie śmieszy burnout, a w zasadzie nie sam wykres, ale częste podejście do tematu.
Czętro traktuje się to tylko jako fapword, albo jako coś co będzie magicznie skracać projekty.
Tzn na planingach dociska się zadania kolanem, żeby jak najwięcej weszło, później 1/3 zostaje na kolejny, ale dalej szacuje się optymistycznie.
Efektem takiego działania jest kompletna bezużyteczność burnoutu w danym projekcie.

Podsumowując
Jak się scruma używa z rozsądkiem a nie traktuje jako magię lub coś z czego wybieramy kawałki optymistyczne a resztę olewamy to ma to sens, ale z moich obserwacji przeważnie stosuje się pseudoscrum nie rozumiejąc co po co jest i wychodzi to jak malowanie ścian młotkiem.

0

@wielki Samiec
Dzięki za ciekawą odpowiedź :)
Z Twojej wypowiedzi wnioskuję, że pakowanie "by default" 2 stale dedykowanych nietechnicznych osób (żadnych rotacyjnych ról, określanych przez agile'owców jako patologia ;-) ) mija się z celem? Czy też może źle Cię rozumiałem?

Gdyby ktoś był w stanie, najlepiej z praktyki, uzasadnić taką "książkową" sytuację to bardzo chętnie doczytam.

BTW Biorę pod uwagę, że agile'owcy przy starcie projektu mają ciut więcej roboty,
jednak z mojej perspektywy kiedy projekt "okrzepnie" po paru miesiącach zwyczajnie nie widzę możliwości aby produktywnie wykorzystywali codziennie 2 x 8h na organizację.

1

"Diabeł siedzi w tym" że Scrum to metodyka wytwórcza i potrzebuje metodyki zarządczej. Jeśli Scrum jest stosowany w dobrym miejscu i utrzymany jako grupa procesów sensownie, działa. Scrum nie postawi i nie wypracuje dobrego celu projektu oraz nie będzie zajmował się budżetem. Także ryzyka obejmie (z definicji) wyłącznie techniczne.

Co do małej ilości pracy SM i PO, uwierz mi że jeśli są kompetentni (tj. PO ma wiedzę analityczną a SM ma umiejętności coachingowe) to działa to wyśmienicie i mają dużo pracy. Inną sprawą jest także to że SM może być nim w kilku grupach zespołach (i tak jest bardzo często).

Co do "czucia Scruma", brzmi sekciarsko i rzeczywiście jest nieprecyzyjne. Po prostu trzeba wiedzieć jak to działa i jak każda z aktywności w Scrum'ie dostarcza wartość (oraz jaką).

Poza tym, metodyka jak każda inna. Są luki których nie obsłuży i nawet się nie stara :-)

0

Scrum / Agile to jeden malutki fragmencik dotyczący prowadzenia projektów, który często klienci i biznes mają w d**ie. Nie rozwiązuje wszystkich problemów i nie wszędzie się nadaje. Sztandarowy przykład to dział utrzymania, scrum tam to tragedia.

5

Scrum, tak jak i Agile to buzzwordy, które mają głównie znaczenie marketingowe - jesteśmy nowocześni, fajni, wydajni, bo mamy scruma.
Generalnie, idea może słuszna, ale ponieważ zajmują się nią głównie osoby, które tego nie rozumieją, oraz korporacje, w których wszystko musi być zbiurokratyzowane, to w praktyce zamiast zwinności są czasochłonne procesy i dokumenty do wypełnienia.
Ponadto, każdy inteligentny człowiek, jest zwinny z natury, nie potrzebuje do tego żadnych szkoleń, książek, ani odgórnie narzuconych procesów.

Do oglądania: https://vimeo.com/110554082
Do poczytania: https://medium.com/swlh/agile-is-the-new-waterfall-f7baef5d026d#.35u63lhdy

1

Czyli najlepsza metodyka to rozsądek. Tak samo jak najlepszy antyvirus, najlepszy środek antykoncepcyjny itd..

0
hyde napisał(a):

Czyli najlepsza metodyka to rozsądek. Tak samo jak najlepszy antyvirus, najlepszy środek antykoncepcyjny itd..

Troszkę odbiegliśmy od tematu.
Przypominając: Dwoje dedykowanych nietechnicznych osób (PO + SM) wrzucanych "by default" do zespołu.
Czy/kiedy ma to sens? Dlaczego się to sprawdza?
Jak nie wpaść w korpopułapkę tego, że będą bo "przecież muszą być bo adżajl" ;-)

0

Ja pracowałem z SM który był PM i działało to sprawnie, chociaż trochę za duż była wiara z metodologię u niego.
W sumie to nie wiem czy działało sprawnie przez scruma którego był fanem, czy po prostu przez to, że człowiek nadawał się na to stanowisko jak mało kto, a co więcej był bardzo nastawiony na faktyczne rozwiązywanie problemów, a nie gadanie o nich czy "poganianie murzynów".

Jeżeli miałaby to być zupełnie osobna osoba lub nawet 2., to ja tego nie widzę, bo cały czas mieli by miting z PMami.

0

to co mi się podoba w Scrumie/Agile/etc.

  • refleksja nad tym co robimy i jak to robimy, jak można usprawnić
    czyli retrospekcje, improvementy itp.
    To jest dobre, bo można się doskonalić z każdym sprintem (przynajmniej w teorii)

  • spike solutions -- http://www.extremeprogramming.org/rules/spike.html
    to jest dobre, że jak coś jest trudnego, to można wyznaczyć taska specjalnie na prototypowanie/research zanim się to zrobi na poważnie.

  • definition of ready
    to jest dobre przy definiowaniu tasków zależnych od działań innych osób, np. żeby zrobić X, muszę mieć dostarczony przez designera projekt graficzny albo muszę mieć dostarczone API od backendowca itp. To pomaga w organizacji teamu, bo bez tego trzeba zgadywać i robić mocki, które potem trzeba przerabiać itp. a to zajmuje czas...

Na minus:

  • estymacje, story points, velocity etc. -- metody estymowania złożoności tasków i mierzenia szybkości teamu wg mnie są nierealistyczne i niemiarodajne.

Na plus / minus

+/- Kanban. Niby fajne, proste, ale jak dla mnie to nie odwzierciedla dobrze workflowu programisty. Wiele tasków jest ze sobą powiązanych, czasem chciałoby się równolegle robić 3 taski naraz, ale nie można bo w sprincie jest jeden task do zrobienia. Więc się robi jeden task, którego i tak nie można dobrze zrobić bez ruszenia innych itd.

Chociaż mam wrażenie, że to nie wina Kanbana, tylko organizacji tasków i workflowu. Tak czy inaczej bywało, że workflow oparty na Kanbanie mnie ograniczał i spowalniał.

0
Złoty Mleczarz napisał(a):

Przypominając: Dwoje dedykowanych nietechnicznych osób (PO + SM) wrzucanych "by default" do zespołu.

"dwie wyznaczone nietechniczne osoby"
Przepraszam, że się czepiam, ale już drugi raz wytłuszczasz słowo, które stosujesz kompletnie niezgodnie z jego znaczeniem, i to strasznie kłuje w oczy.

Jak nie wpaść w korpopułapkę tego, że będą bo "przecież muszą być bo adżajl" ;-)

To może należy zacząć od tego, że w Scrumie nie ma kogoś takiego jak PM, więc wrzucanie kogoś takiego do zespołu świadczy o niezrozumieniu tematu i próbie używania tej metodyki na siłę. No, ale przecież każdy Janusz wie, że kierownik musi być, kontrola najwyższą formą zaufania i takie tam, więc PMa trzeba do zespołu wcisnąć, nawet jeśli będzie jedynym jego członkiem.

0

Część rzeczy scruma to ptologia, częste spotkania albo wszyscy developerzy obecni na review.

U mnie robia to team leaderzy, którzy nie umieją programować.

0

Według mnie każda tego typu metodologia powinna być zmieszana ze zdrowym rozsądkiem i wtedy warto poczytać ksiązki np. Pana Goldratta i zainteresować się teorią ograniczeń.
Ale to w zasadzie dla zarządzających a nie developerów.

0

Mnie tez interesuje czym zajmuje sie SM w zespole scrumowym jesli jest to tylko dedykowana osoba do tego, bo nie ma na pewno tyle pracy do wykonania przez 8 godzin dziennie co deweloperzy.

0

I dlatego SM jest zatrudniany na niepełny etat lub na godziny i/lub pracuje w kilku zespołach pełniąc w nich funkcje SM'a. Jest właścicielem procesu Scrum'a w sensie zarządczym ale już o tym sam Scrum nie mówi :-)
Współpracuje także z PO i innymi (zależne od struktury organizacji) aby procesy Scrum'a toczyły się bez przeszkód a historyjki/przypadki użycia/wymagania były "dowożone" do końca sprintu. Powinna być 1 taka osoba bo jak każdy z developerów miałby np. załatwiać sobie licencje na kompilatory/narzędzia/sprzęt/stanowisko, obsługiwać wrzutki projektowe, to byłby spory bałagan i sam pracownik odrywany byłby od swojej pracy.
Często (niestety) także trzeba wpływać na PO by nie pływał "w poezji" na spotkaniach tylko był przygotowany merytorycznie...
Jak zawsze.... są zespoły gdzie trzeba kopać po (Y) wszystko i wszystkich a są i takie gdzie praca polega na tym by nie przeszkadzać i czasem pomóc :-) Każda organizacja ma inną dojrzałość procesową i inny balans proces/projekt.
Ale po co tu opisywać samą metodykę? Dobrze jest opisana w literaturze. Ma kilka dobrych narzędzi, zasad i wykładni które trzeba dostosować do organizacji a nie robić rewolucję i destabilizować produkcję. Chodzi o to żeby każdy robił to co umie lub lubi lub za co mu płacą w sposób najbardziej wydajny...
Na każdą metodykę jak się spojrzy z perspektywy, jest ukonstytuowaniem zdrowego doprecyzowanego przez jasno wyrażone reguły znane wszystkim zainteresowanym. Z moich doświadczeń wynika że "biznes" (słowo wytrych) uczy się aspektów technologii ale także i zespół uczy się innego spojrzenia na swoją pracę. Przez to że każdy widzi to inaczej, szybciej identyfikowane są luki. Z syndromu "oni" nic dobrego nie wynika.

2

Nie zawsze i nie wszedzie. Srednio sie sprawdza przy kobylastych systemach gdzie jest nakladka na Waterfalla. Ale tez duzo zalezy od tego co przez to rozumiemy i jak ten scrum wyglada. Tak jak obecnie wspolpracujemy bezposrednio z klientem nie majac ciezkiego procesu to daje bardzo duzo:

  • Nie ma micromanagementu - po to sa standupy (no dobra czasem wpadnie jakis alarm z produkcji ale to sila wyzsza, wtedy "all hands on deck")
  • Scrum ma jeden rewelacyjny mechanizm: ustalamy co robimy w sprincie i nie powinnismy tego zmieniac, jesli klient chce cos dorzucic jest zasada, ze ustala sie wspolnie z zespolem czy da sie dorzucic tak po prostu czy wyrzucamy cos innego.
  • Przy rozproszonym zespole jednak jest to jakis szkielet komunikacji (ma znaczenie zwlaszcza jak sie zespol tworzy)
  • Jesli klient jest sensowny to mozna wrzucac zadania techniczne/usprawnienia ktore inaczej robilibysmy w tzw. miedzyczasie.
  • Jesli zespol jest juz doswiadczony i zgrany - znamy swoja predkosc przy naszym sposobie estymowania, wiec mniej wiecej wiadomo ile mozna zaplanowac w sprincie.
  • Cos co nie dla kazdego bedzie plusem (dla mnie jest) szybko widac jak ktos symuluje prace.
  • Demo: zespoly dostarczaja kompletne funkcjonalnosci, jesli kilka zespolow musi wspolpracowac, mozna pojsc na demo innego zespolu i zobaczyc co robia. Bylo to zwlaszcza nieocenione jak pracowalem w testach integracyjnych.
  • Retrospektywy (tylko jesli sa na nich podnoszone konkretne akcje z przypisaniem do osoby i rozwiazaniem tego).

Teraz tak (to jest moja opinia, nie koniecznie zgodna ze Scrum guide, a wlasciwie bedaca Agilowa herezja:) ):

  • Scrum master - jest potrzebny na poczatku by ustalic reguly, zeby sie to wszystko "zaczelo krecic", pozniej wystarczy jak z doskoku przyjdzie na spotkanie zobaczyc czy wszystko jest ok, czy odpowie czasem na pytania.
  • Product/System Owner - bardzo wazna rola, osoba ktora jest na styku miedzy klientem a zespolem, musi rozumiec zadania od strony biznesowej, dobrze jesli choc troche orientuje sie w sprawach technicznych (ale to juz nie musi byc na poziomie szczegolow). Ona uklada backlog i ustala priorytety. Moim zdaniem w momencie gdy zespol jest zgrany i doswiadczony i jest to faktycznie konkretna osoba (nie moze byc czlowiek z przypadku, bo bedzie kaplica) bardzo dobrze laczy sie z rola Scrum Mastera.

Tak naprawde nie chodzi o to by miec proces dla procesu, tylko by byc w stanie dostarczyc konkretna wartosc w konkretnym czasie.

Bonus: W srodowiskach AgileFallowych - ScrumMaster bardzo przydaje sie jako bullshit separator, czyli gdy tylko moze odbija wrzutki z zewnatrz, stara sie odciazyc zespol od zbednych spotkan, broni przed micromanegementem, beirze na siebie sprawy organizacyjne etc.

0

firma w której pracuje tylko i wyłacznie na Scrum

  • tej metody to to że dzieki niej osoby zaangażowane w projekt wiedzą co sie w nim dzieje ( co jest wazne jesli mamy rozproszony zespół 7 osobowy z 2ch miast)
  • na pewno koszty (w sensie nie kazdy klient che za to płacić że sobie 7 osób pogada 0,5 dziennie ) bo to extra 3,5 godziny na dzień
  • szybsza reakcja na problemy i blockery reszty zespołu
2

Ja od roku pracuje w zespole scrumowym. Najpierw SM był to nasz kierownik. Potem SM był rolą przechodnią, a potem ja zostałem SM, bo najbardziej mi to leżało i najlepiej spełniałem tą funkcję.

Generalnie to scrum to nie tylko zmiana metodyki, ale całego myślenia. Jest to pozornie niewygodne dla programistów i dobre dla "firmy" ale z perspektywy czasu sądzę, że developer jest "szczęśliwszy" w scrumie ( prawdziwym ).

Scrum jako podstawę przyjmuje szczerość i to, że wiem ile mogę zrobić. To jest najważniejsze, bo jak zespół pracuje i może zrobić 200 SP na sprint to po wprowadzeniu scruma zrobi dokładnie też te 200 SP i nie więcej. Zmienia się to, natomiast, że wyceny są realne, bo wycenia zespół, po dokładnym omówieniu tematu i wtedy wiadomo ile zajmie i co można wrzucić na sprint.

W klasycznym zespole często nie wiadomo kiedy temat będzie done ( brak definicji ). Robi się mechanizm, pokazuje się "projektantowi", po czym okazuje się, że to trzeba jeszcze poprawić, a to zmienić etc. Programista się irytuje oraz czuje się zagubiony i zdemotywowany ( jak musi zaorać to co zrobił i zrobić inaczej ). Jednocześnie zawsze może zwalić, opóźnienie, że były zmiany i z natury człowiek to wykorzystuje i faktycznie spowalnia. To się programistą podoba i bronią się, przed scrumem bo tam dokładnie wiadomo ile temat powinien zająć i nie można zwalić, że się tydzien siedzi nad jednym taskiem - no chyba, że coś nieprzewidzianego wyjdzie ale to na dayly wychwytuje i się roztrzaskuje taki temat całym zespołem. Po czasie okazuje się, że jednak programiści mieszczą się w wycenach SP ( współczynnik SP się zmienia dla zespołu co sprint, a nie pogania się programistów, żeby szybciej robili, tu chodzi o pokazanie prawdziwego stanu ), po tym okazuje się, że czerpią satysfakcje z sukcesów i się przekonują.

Oczywiście wszystko co robimy jest w kontrakcie i tak współpracujemy z resztą firmy ( jestem członkiem zespołu RnD, jest nas 6 osób, gdzie cała firma to ok 90. Naszym PO jest prezes bo on wie co powinno sie robić, co rozwijać a co łatać, z punktu widzenia klientów i rezultatów.

Jak zespół przechodzi na scruma to robota czasami rusza bo w końcu nie mogą się opierdalać/ ściemniać. To wymaga zgody i pokoju członków, bo jak zespół się buntuje przeciwko scrumowi to to nie wyjdzie.

Dlatego, że mamy kontrakt to go przestrzegamy bo sami go wymyśliliśmy i nie zostało to nam narzucone ( w przeciwienstwie do klasycznego działu ).

Przed przejściem na scruma nie wiedziałem czy dobrze pracuje - czy idziemy w dobrym kierunku - sprinty robią poczucie, że spełniam dobrze zadanie bo schodzą tematy z tablicy. Na wszystko jest czas bo w końcu wiemy ile tego czasu mamy ( a z pustego i Salomon nie naleje ). Nie wychodzę z pracy z poczuciem presji i winy, że coś idzie gorzej czy źle. W końcu skończyły się (nieprzymusowe) nadgodziny, gdzie zostawałem, żeby coś nadgonić z własnej woli - teraz 8h i wychodze z pracy i mam czyste sumienie, tak jak reszta teamu, a wszystko planowo idzie.

0

DoD to nie jest wynalazek scrumowy. Pracowałem w zespołach, które scrumowe nie były, a DoD każdy znał i stosował. Podobnie ma się sprawa z brakiem nadgodzin.

Szacowanie czasochłonności zadań to w ogóle trudny temat i scrum go nie rozwiązuje. story pointy, marchewki, zaangażowanie zespołu - a i tak wahania w produktywności między sprintami potrafią być w praktyce kilkukrotne.

Opieprzanie - ja z tym nigdy nie miałem problemu w scrumowych zespołach. Zazwyczaj faktycznie pracowałem 2h dziennie, i to nawet nie do końca ze złej woli, tylko dlatego, że bezużyteczne spotkania, szkolenia, oczekiwanie na review codu, albo inne scrumowe procesy nie pozwalały mi pracować. No, a jak coś mi nie pozwala pracować, to odechciewa mi się też pracować, wtedy gdy mogę, proste.

0

Widzę, że dyskusja ładnie się toczy :)

Jednak z tego co widzę, praktycznie nikt nie jest w stanie uzasadnić sensu istnienia dwóch pełnoetatowych "Agileowców" w zespole.
Z jednej strony wytyczne "książkowe" mówią dość jasno o zespole 3-9 osób (w tym PO i SM),
jednak na dłuższą metę nikt nie widzi możliwości tego aby te osoby faktycznie się nie nudziły.
Oczywiście odrzucając patologie typu "robimy scrumowo bo tak jest u nas w korpo" czy też "jest PO na pełen etat, jednak roboty ma na 3h dziennie" ;-)

1

To nie jest tak, że nie może być 2 etatów dla PO i SM. Ja jestem SM i prezes jest PO, czyli to są nasze dodatkowe funkcje, ale niekoniecznie to musi tak wyglądać. Nasz scrum jest spisany w kontrakcie i jest pewnie troszkę innych niż scrum kogokolwiek innego. Nie ma uniwersalnej metodyki i scrum należy dostosować do firmy ( my kształtowaliśmy scrum przez 6 sprintów po 2 tyg, czyli przez 12 tyg). Być może istnieją realne powody, żeby te dwie funkcje były jako osobne etaty w jakiejś firmie i tylko w niej. Specyfika pracy, branży i struktur uniemożliwia jednoznaczną odpowiedź na to pytanie.

0

Pracowaliśmy w scrumie przez rok i zrezygnowaliśmy z niego.

Wady:

  • trzeba bardzo dokladnie planowac zadania do wykonania w trakcie sprintu
    Mieliśmy 2-tygodniowe sprinty, w trakcie refinementów trzeba było dokładnie przeanalizowac kazde zadania do wykonania i podzielic na mniejsze zadania. Jesli w trakcie sprintu okazalo sie, ze o czyms zapomnielismy i czegos nie uwzglednilismy to mielismy obsuwe w czasie i czasem skutkowalo to niedowiezieniem sprintu. Poza tym jesli w trakcie sprintu wychodzilo, ze chcemy zrobic dane zadanie jednak inaczej to jesli wydluzy to prace to nie bylo mozliwosci zmiany - bo przez to moze nie udac sie dowiezc sprintu i nie byc gotowym do deploya.

  • trzeba szacowac przed sprintem kogo kiedy nie bedzie
    Na podstawie poprzednich sprintow jestesmy w stanie oszacowac ile punktow jestesmy w stanie wziac do biezacego sprintu, jesli w trakcie sprintu ktos sie rozchoruje to jest bardzo prawdopodobne niedowiezenie sprintu

  • wyścig szczurów
    Kazde zadanie jest w SCRUMie wycenione pod względem złożoności, widac wiec w trakcie sprintu kto ile punktow 'spalil', wiec jak ktos w danym sprincie 'spalil' widocznie mniej punktow niz pozostali mial rozmowe o tym dlaczego tak slabo mu poszlo

0

Pozwolę sobie trochę odkopać, bo mnie jedno zastanawia. Kto w takim scrumie zajmuje się (lub powinien) architekturą, żeby było dobrze? Zawsze mi się wydawało, że powinien być osobny człowiek od tego. Z drugiej strony słyszę, że w scrumie wszyscy są równi i każdy robi wszystko, co w moim odczuciu kłóci się z sensownym położeniem tak ważnego fundamentu.

0

Od architektury powinien być architekt, ktoś taki nie musi być członkiem zespołu scrumowego.

A żeby było dobrze, to powinien to być doświadczony profesjonalista.

0

Od razu tam architekt... na kolanie cos porysowac, bedzie dobrze... pozniej bedziemy sie martwic ;)

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