SCRUM zawsze i wszędzie zbawieniem będzie?

Odpowiedz Nowy wątek
2016-02-01 23:48
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)?

Pozostało 580 znaków

2016-02-02 11:26
Wielki Samiec
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.

Pozostało 580 znaków

2016-02-02 12:15
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ę.

Pozostało 580 znaków

2016-02-02 12:45
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 :-)


Każdy problem w informatyce można rozwiązać, dodając kolejny poziom pośredniości,z wyjątkiem problemu zbyt dużej liczby warstw pośredniości — David J. Wheeler

Pozostało 580 znaków

2016-02-02 13:42
Czarny Młot
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.

no tak.. i tam Kanban albo inne metodyki Lean :-) - Mokrowski 2016-02-02 14:48

Pozostało 580 znaków

2016-02-02 21:01
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[...]rfall-f7baef5d026d#.35u63lhdy


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Film - najlepszy. (+ jeden z tych, którzy podpisali: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/) - Endrju 2016-02-02 22:02
Dobry link, ciekawe czy Martin już go za to zjebał. :D - somekind 2016-02-07 01:14

Pozostało 580 znaków

2016-02-02 23:14
1

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

Pozostało 580 znaków

2016-02-02 23:30
Złoty Mleczarz
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" ;-)

Pozostało 580 znaków

2016-02-02 23:45
Pijany Lew
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.

Pozostało 580 znaków

2016-02-03 01:39
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ł.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);

Pozostało 580 znaków

2016-02-03 02:08
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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