Jak wygląda u was scrum ?

1. kto prowadzi spotkania scrumowe ?
2. ile godzin scrumu macie co tydzień - mniej więcej i jakie spotkania scrumowe macie

Cel pytania to zrozumienie czy są szanse na znośny scrum.

U mnie:

1. Obecnie wszystkie spotkania łącznie z retrospektywą, planowaniem i refinmentami prowadzą developerzy, każdy ma dyżur na sprint, nie wydaje mi się to zbyt normalne ale może to częste również w innych firmach ?

1 tydzień
—————-
2h planowanie
Daily - 30 do 40 minut x 5 = 2,5 - 3h
3 h refinment

2 tydzień
——————
3h refinemnet
2,5h retrospektywa
Daily - 30-40 minut = 2,5 - 3h
30 minut demo
30 minut planowanie demo

Dodatkowo przynajmniej 1h dodatkowych spotkań nie scrumowych ale cyklicznych na sprint

Wychodzi łącznie 16,5 -17,5 h na sprint, czy to dużo ?

Brzmi jak coś co całkowicie nie ma sensu.

Ja nie mam scuma. Dobrze mi się pracuje. Ale korpo naciska na „predictability” - nie wiem jak długo się będziemy bronić.

każdy ma dyżur na sprint

To akurat bardzo dobra praktyka. Jeżeli programiście nie zakomunikujesz że praca zespołowa to także jest jego praca, to on zamknie się w swoim klepaniu kodu.

Daily - 30 do 40 minut

Coś tu jest nie tak. No chyba, że masz zespół 20 osobowy, ale wtedy tym bardziej to jakaś patologia.

W poprzedniej pracy wychodziło:
1.5h + 2h + 1h w poniedziałek (demo/retro/retro wspólne)
1h + 2h w wtorek (pre planing/ planing)
1h w poniedziałek drugi (retro wspólne)
1h w piątek przygotowanie do demo
30 min daily codziennie z wyłączeniem 2 pierwszych dni sprintu.
Razem 13.5h + spotkania okolicznościowe + wydłużenia tych spotkań jak trzeba było.

W nowej pracy nie jesteśmy agile więc jest święty anielski spokój.

ArchitektSpaghetti napisał(a):

Ja nie mam scuma. Dobrze mi się pracuje. Ale korpo naciska na „predictability” - nie wiem jak długo się będziemy bronić.

• Pogadaj z biznesem.
• Ustal po co chcą predictibility.
• Znajdź potrzebę za tym - może mają za dużo ryzyka, może się spalili na estimate'ach, dojedz do sedna co im przeszkadza, może za słabe delivery
• zaproponuj jak można naprawić ten problem w normalny sposób, bez tego "predictibility"

IMO wliczanie czasu daily do tygodniowego czasu spotkań nie ma za bardzo sensu, bo i tak nawet jak nie ma Scruma, to daily/standup zazwyczaj jest.

U mnie jest zazwyczaj standup 30 min dziennie + planning 1h co tydzień.

1. Codzienna spowiedź gdzie mówimy co robimy dzisiaj i zamierzamy robić jutro, zakończona aktem żalu za to, że dlaczego tak wolno. Tzw. Daily
2. Refinement 2x w tygodniu
3. Sprint Retro 1x na 2 tygodnie
4. Planowanie 1x na tygodnie

1. Daily 30 min
2. Refinement około 2h w tygodniu
3. Resztę spotkań scrumowych agregujemy do jednego dnia. Co dwa tygodnie mamy taki "Scrum Day". Wtedy od 10 do 14 jesteśmy na Review, Retro, Planowanie.

Prowadzący Scrum Daya jest rotacyjny - na szczęście nie mamy Scrum Mastera. Sami sobie wypracowaliśmy sposób pracy, który nam wszystkim odpowiada.
Generalnie podoba mi się ta koncepcja jednego dnia bardziej intensywnego jeśli chodzi o spotkania, żeby potem przez 2 tygodnie skupiać się tylko na refinementach.

FlyingSpirit napisał(a):

U mnie:

1. Obecnie wszystkie spotkania łącznie z retrospektywą, planowaniem i refinmentami prowadzą developerzy, każdy ma dyżur na sprint, nie wydaje mi się to zbyt normalne ale może to częste również w innych firmach ?

to nietypowe, ale IMO te sensowny pomysł

Wychodzi łącznie 16,5 -17,5 h na sprint, czy to dużo ?

to mało. nie po to wprowadza się scrum, żeby programiści tracili czas na kodowanie. powinni rozwijaż soft skille, komunikować się i budować zespół.

u mnie na szczęście nie mam scruma.
spotkania:
2-2.5 godz tygodniowo
i jedna godzina nieobowiązkowej prezentacji, którą można posłuchać ale nie trzeba (o firmie, jakimś projekcie, kawałku kodu, wyjebce na produkcji itp).

W jednej firmie miałem prawdziwy scrum - programista miał 18 godzin tygodniowo na spotkania (średno, wzięte z bazy lotus notes).
Formalnie nie wszystkie te spotkania były związane ze scrum, tym niemniej 4 godzinne planowania, 4 godzinne pre planowanie (!!), całodniowe retro itp dokłądały do pieca.
Choć stan d**y trwał zwykle do 30 minut.

To jest w ogóle smutne, że taka ogromna rzesza wykształconych ludzi jest w stanie wpaść w taką pułapkę. Nie ma dowodów/danych które mówią, że wprowadzenie scruma (czyli tych wszystkich ceremonii jak planning, daily, etc.) zwiększają produktywność

o, nowy wątek do narzekania na Scruma.
No to znajomy mi ostatnio opowiadał iż zamiast nudnego retro mają teraz Super Mario Retro po czym coś zaczął opowiadać iż kartki do wypełneinia są ukryte w planszy Super Mario.
Po Spotkaniu nie wytrzymał i powiedział iż nie jest nativem angielskiego i nie jest w stanie jednocześnie "grać" i pisac kartek, a w ogóle to jak do tej pory wiedział jakie są typy kartek do wypełnienia to mógł to sobie przygotowac wcześniej.
Szybko dostał odpowiedź z USA od jednego z tamtych devów iż on jest nativem angielskiego i też nie rozumie co się dzieje XD

To chyba było ostatnie spotkanie Super Mario Retro

Scrum byłby spoko, gdyby tylko pozbyć się planningów, daily, scrum masterów, coach'ów i płatnych certyfikatów.

Riddle napisał(a):

Scrum byłby spoko, gdyby tylko pozbyć się planningów, daily, scrum masterów, coach'ów i płatnych certyfikatów.

I tak szacowanie (z ang. estimation) jest z tego najgorsze. A potem i tak ktoś się zawsze czepia czemu źle szacowałeś

Riddle napisał(a):

Scrum byłby spoko, gdyby tylko pozbyć się planningów, daily, scrum masterów, coach'ów i płatnych certyfikatów.

Tak naprawdę jeszcze sprinty są kijowe. Ale wywalenie sprintów to dalszy priorytet.

i "tasków" wymyślanych przez nietechnicznych marketoisdów

W ogóle to praca powinna zostać odwołana.

Miang napisał(a):

i "tasków" wymyślanych przez nietechnicznych marketoisdów

Tak, zgadzam sie.

Powinny być sprecyzowane targety albo potrzeby użytkownika - programiści powinni starać się je dostarczyć. Specyfikowanie tasków to prawie że mikromanagement, który nie pozwala pracownikom być kreatywnym. Odbębniają tylko task po linii najmniejszego oporu żeby móc odhaczyć task jako zrobiony.

jarekr000000 napisał(a):

Tak naprawdę jeszcze sprinty są kijowe. Ale wywalenie sprintów to dalszy priorytet.

Właśnie ze sprintami jest taki problem, że one, wdrożone tak jak są opisane w XP mają sens. Tylko że większość zespołów wprowadza je tak jak opisuje scrum, i one wtedy tracą cały sens. Pojęcie "sprint" stało się synoniem "14 dni". I co - nazwiesz sobie swoje dwa tygodnie sprintem... i co dalej? Co to zmienia? Co daje? Oprócz nic. Więc jak ktoś ma sprinty takie jak w XP to super. Ale jak to są scrumowe sprinty, to lepiej je wywalić całkiem.

W 90% przypadków, zwinne zarządzanie jest tak zwinne jak kij od miotły, czyli wcale. Ot buzzword.

Riddle napisał(a):

Miang napisał(a):

i "tasków" wymyślanych przez nietechnicznych marketoisdów

Tak, zgadzam sie.

Powinny być sprecyzowane targety albo potrzeby użytkownika - programiści powinni starać się je dostarczyć. Specyfikowanie tasków to prawie że mikromanagement, który nie pozwala pracownikom być kreatywnym. Odbębniają tylko task po linii najmniejszego oporu żeby móc odhaczyć task jako zrobiony.

powinna być osoba albo ścisłe grono osób pełniących rolę architektów, przekładających te potrzeby na prace konieczne do wykonania w projekcie . Jak nie ma nikogo ze spojrzeniem z góry to na projekt to juniorzy 3 razy zrobią to samo w 3 modułach przez skopiowanie istniejącego kodu z innego modułu ( z błędami przy kopiowaniu), w międzyczasie jeden z nich wymyśli inny sposób i ten kod też zostanie powielony w kilku modułach, inni na pałę powrzucają magiczne numerki do kodu bo tak szybciej....
i jeszcze nietechniczny menago ZABRANIA spisania se kawałka dokumentacji na wewnętrzne potrzeby odnośnie tego modułu bo to niezgodne z procedurami i jego formatem dokumentacji, a przecież ma być agile więc oczywiście pzestrzega zasady Individuals and interactions over processes and tools

Miang napisał(a):

powinna być osoba ale ścisłe grono osób pełniących rolę architektów, przekładających te potrzeby na prace konieczne do wykonania w projekcie .

Tak. I to "ścisłe grono osób przekładających te potrzeby na prace konieczne do wykonania w projekcie" to powinien być zespół programistów.

Praca programisty jest kreatywną pracą - musisz pozwolić zespołom podejmować swoje decyzje i projektować rozwiązania. Jak będziesz traktować zespół programistów jako "klepczy" którzy mają tylko przepisać taski z jiry na kod to wyjdzie Ci okropny software z błędami i okropna produktywność.

Gdybyś miał "jedną osobę która jest architektem" która przekłada potrzeby na prace, to równie dobrze ona mogłaby cały kod napisać. Dlatego że żeby sprecyzować prace techniczne z dostateczną ilością szczegółów żeby to miało sens, to musiałby po prostu napisać ten software :D Programowanie to nie jest jak produkcja samochodów czy budynków - że jedna osoba "projektuje", a potem programiści "budują" coś.

Miang napisał(a):

Jak nie ma nikogo ze spojrzeniem z góry to na projekt to juniorzy 3 razy zrobią to samo w 3 modułach przez skopiowanie istniejącego kodu z innego modułu ( z błędami przy kopiowaniu), w międzyczasie jeden z nich wymyśli inny sposób i ten kod też zostanie powielony w kilku modułach, inni na pałę powrzucają magiczne numerki do kodu bo tak szybciej....

Jeśli tylko potrzeby klienta/użytkowników zostaną spełnione, to nie widzę problemu. Zespoły powinny sobie same wypracować styl pracy - nie powinny go mieć narzuconego z góry.

Riddle napisał(a):

Miang napisał(a):

powinna być osoba ale ścisłe grono osób pełniących rolę architektów, przekładających te potrzeby na prace konieczne do wykonania w projekcie .

Tak. I to "ścisłe grono osób przekładających te potrzeby na prace konieczne do wykonania w projekcie" to powinien być zespół programistów.

doświadczonych programistów

Praca programisty jest kreatywną pracą - musisz pozwolić zespołom podejmować swoje decyzje i projektować rozwiązania. Jak będziesz traktować zespół programistów jako "klepczy" którzy mają tylko przepisać taski z jiry na kod to wyjdzie Ci okropny software z błędami i okropna produktywność.

Gdybyś miał "jedną osobę która jest architektem" która przekłada potrzeby na prace, to równie dobrze ona mogłaby cały kod napisać. Dlatego że żeby sprecyzować prace techniczne z dostateczną ilością szczegółów żeby to miało sens, to musiałby po prostu napisać ten software :D Programowanie to nie jest jak produkcja samochodów czy budynków - że jedna osoba "projektuje", a potem programiści "budują" coś.

Miang napisał(a):

Jak nie ma nikogo ze spojrzeniem z góry to na projekt to juniorzy 3 razy zrobią to samo w 3 modułach przez skopiowanie istniejącego kodu z innego modułu ( z błędami przy kopiowaniu), w międzyczasie jeden z nich wymyśli inny sposób i ten kod też zostanie powielony w kilku modułach, inni na pałę powrzucają magiczne numerki do kodu bo tak szybciej....

Jeśli tylko potrzeby klienta/użytkowników zostaną spełnione, to nie widzę problemu. Zespoły powinny sobie same wypracować styl pracy - nie powinny go mieć narzuconego z góry.

taaa "zespół" juniorów po bootkampie se wypracuje, po kilku miesiącach poodchodzi kawałkami ale bajzel zostanie
entuzjasta "zespołu" jako agilowego bytu: zdziwiony Pikachu

Riddle napisał(a):

To jest w ogóle smutne, że taka ogromna rzesza wykształconych ludzi jest w stanie wpaść w taką pułapkę. Nie ma dowodów/danych które mówią, że wprowadzenie scruma (czyli tych wszystkich ceremonii jak planning, daily, etc.) zwiększają produktywność

Bo ona ma zwiększysz mikrozarządzanie a nie produktywność. Wszyscy jesteśmy w tej samej pułapc. Nic nie możemy z tym zrobić ALE drodzy panowie i panie jak płacą to w sumie co nas to interesuje? Mniejszy wysiłek dla nas bo w czasie tych pierdół można sobie przeglądnąć pocztę, poszukać artykułów, filmików czy przepisów na obiad.

Miang napisał(a):

Riddle napisał(a):

Miang napisał(a):

powinna być osoba ale ścisłe grono osób pełniących rolę architektów, przekładających te potrzeby na prace konieczne do wykonania w projekcie .

Tak. I to "ścisłe grono osób przekładających te potrzeby na prace konieczne do wykonania w projekcie" to powinien być zespół programistów.

doświadczonych programistów

No nie. Wszystkich w zespole.

Miang napisał(a):

taaa "zespół" juniorów po bootkampie se wypracuje, po kilku miesiącach poodchodzi kawałkami ale bajzel zostanie
entuzjasta "zespołu" jako agilowego bytu: zdziwiony Pikachu

Jeśli zatrudniasz zespół juniorów po bootkampie, to dostajesz to za co płacisz.

Poza tym, jak masz taki zespół, to nie ważne jak ustruturyzujesz pracę, to i tak wynik będzie marny. Nie ma metodyki w którą możesz włożyć niekompetentnych ludzi, żeby wyszedł z tego dobry software. Po prostu się nie da.

a skąd się bierze kompetentnych?

Miang napisał(a):

a skąd się bierze kompetentnych?

Dwa sposoby.

• Albo zatrudniasz już kompetentnych.
• Albo pozwalasz niekompetentnym uczyć się w pracy, by stali się kompetentni np. stosując knowedge sharing, albo pozwalając im znajdować techniczne implementacje wymagań userów. Przy czym knowledge sharing to oczywiście nie jest żadna prezentacja w powerpoincie, tylko np. praca razem. Sporo firm aktywnie nie pozwala pracownikom się uczyć - np. nie dając im odpowiedzialności albo stosując micromanagement; przez co Ci pracownicy już pernamentnie pozostaną niekompetetni.

Riddle napisał(a):

Miang napisał(a):

a skąd się bierze kompetentnych?

Dwa sposoby.

• Albo zatrudniasz już kompetentnych.
• Albo pozwalasz niekompetentnym uczyć się w pracy, by stali się kompetentni np. stosując knowedge sharing, albo pozwalając im znajdować techniczne implementacje wymagań userów. Przy czym knowledge sharing to oczywiście nie jest żadna prezentacja w powerpoincie, tylko np. praca razem. Sporo firm aktywnie nie pozwala pracownikom się uczyć - np. nie dając im odpowiedzialności albo stosując micromanagement; przez co Ci pracownicy już pernamentnie pozostaną niekompetetni.

czyli kompetentny ma na pełny etat uczyć juniora. jak ten kompetentny nie zwieje z firmy to będzie cud. no i Nie ma metodyki w którą możesz włożyć niekompetentnych ludzi, żeby wyszedł z tego dobry software. czyli z tej nauki nie będzie nic wartościowego. firma płaci dwóm osobom pensje i nic z tego nie ma?

Miang napisał(a):

czyli kompetentny ma na pełny etat uczyć juniora. jak ten kompetentny nie zwieje z firmy to będzie cud. no i Nie ma metodyki w którą możesz włożyć niekompetentnych ludzi, żeby wyszedł z tego dobry software. czyli z tej nauki nie będzie nic wartościowego. firma płaci dwóm osobom pensje i nic z tego nie ma?

Mógłbyś raz przestać pisać pierwszą rzeczy która Ci przyjdzie na język? Nigdzie nie napisałem o uczeniu na pełen etat i o tym że nic z tego nie ma.

Jeśli firma ma (powiedzmy) seniora i juniora, to większość firm robi coś takiego że senior robi swoje, a junior swoje. Jednocześnie junior nie dostaje swoich odpowiedzialności, nie może projektować softu tylko daje bardzo techniczne tech-taski, przez co nie może się uczyć i na zawsze pozostanie juniorem w tej firmie.

To co można zrobić, to to, że do części rzeczy (np 10,20,30%) tego co robi senior włączyć juniora. Może mogliby zrobić jedno zadanie razem które tego samego dnia pójdzie na proda? Może mogliby razem zdebugować jakiś bug, albo może mogliby razem zrefaktorować jakąś klasę lub napisać test. Feature'y i zadania będą wypełniane tak jak powinny. Stosowałem takie podejście wiele razy i ono działa w porządku. Jeśli taka praca tak potrwa rok, dwa, to junior będzie stopniowo podnosił swoje kompetencje, aż w pewnym momencie będzie mu można zaufać z dowiezieniem całkowicie nowego feature'a samemu.

A co do "zwiewania z firmy" to problemem jest - czemu ludzie chcą zwiać z Twojej firmy? Może dlatego że jest słaba, nie pozwala ludziom się uczyć, przez co ludzie są nie zadowoleni, nie mogą być kreatywni, nie mogą być zadowoleni ze swojej pracy? Może dlatego że nie pozwala im się developować software'u wysokiej jakości tylko daje im tech-taski które bardziej przypominają przepisywanie z tablicy niż rozwój oprogramowania. Taki pomysł tylko.

Riddle napisał(a):

Miang napisał(a):

To co można zrobić, to to, że do części rzeczy (np 10,20,30%) tego co robi senior włączyć juniora. Może mogliby zrobić jedno zadanie razem które tego samego dnia pójdzie na proda? Może mogliby razem zdebugować jakiś bug, albo może mogliby razem zrefaktorować jakąś klasę lub napisać test. Feature'y i zadania będą wypełniane tak jak powinny. Stosowałem takie podejście wiele razy i ono działa w porządku. Jeśli taka praca tak potrwa rok, dwa, to junior będzie stopniowo podnosił swoje kompetencje, aż w pewnym momencie będzie mu można zaufać z dowiezieniem całkowicie nowego feature'a samemu.

ale przecież wyżej piszesz że to zespół decyduje a nie senior

Miang napisał(a):

ale przecież wyżej piszesz że to zespół decyduje a nie senior

Nie. Doczytaj uważnie moje posty. Ja napisałem że "zespół decyduje, a nie manager/szef/klient" - zespół.

Czyli klient/szef/manager przychodzi z requirementem "chcemy żeby userzy mogli share'ować swoje ustawienia" a cały zespół decyduje jak to najlepiej wykonać. Wtedy seniorzy i juniorzy razem pracują nad tym jak dowieźć taki feature, przy czym juniorzy biorą udział w całym procesie dostarczania feature'a i się uczą - piszą testy, rozmawiają z klientem, robią mvc, dodają implementację, wrzucają na środowisko testowe, a potem uczestniczą w release'ie. To jest zdrowe podejście.

Jak szef przychodzi i mówi do juniora: "na tym ekranie dodaj taki przycisk, tutaj wyślij taki request, a tutaj dodaj taki obrazek"; to tym samym wyłącza go z procesu developowania, a to znaczy że taki junior nigdy się nic nie nauczy, i na zawsze pozostanie niekompetentny. Jeśli sprowadza się juniora do "klepacza kodu", i nie pozwala mu się testować i wdrażać rozwiązań ani doprecyzować wymagań z klientem/użytkownikiem, to na zawsze pozostanie bez potrzebnych umiejętności. Na zawsze nie będzie miał skillsów, więc nie będzie można mu ufać, więc nie będzie można mu powierzyć odpowiedzialności, więc nie zespół nigdy nie wytworzy sobie zdrowego procesu, więc taki zespół będzie ciągle niewydajny. To jest patola.

PS: @Miang Popracuj nad umiejętnością czytania ze zrozumieniem, bo mam wrażenie że umyka Ci połowa rzeczy które piszę i potem wkładasz mi słowa w usta których nie napisałem.

FlyingSpirit napisał(a):

1. kto prowadzi spotkania scrumowe ?
2. ile godzin scrumu macie co tydzień - mniej więcej i jakie spotkania scrumowe macie

• Daily 3-15 minut, zazwyczaj koło 10. Nikt go nie prowadzi, bo co tam prowadzić?
• Retro - 1 spotkanie w praktyce raz na miesiąc, trwa z pół godziny. Jak nie mamy o czym rozmawiać, to nie rozmawiamy. Jak próbujemy wymyślić jak zmusić inne zespoły do wzięcia się do roboty, to schodzi się godzina. Prowadzi SM.
• Demo - może z raz na 5 sprintów się jakieś trafi. Bierzemy w tym udział, gdy jest coś, co da się pokazać. Zajmuje to wówczas maks 15 minut. Spotkanie prowadzone przez biznes, naszą część pokazuje zazwyczaj ten, kto najwięcej nad danym ficzerem pracowął.
• Refinementy - są wtedy, gdy są potrzebne, średnio pewnie wyjdzie jedno jednogodzinne spotkanie na tydzień. Prowadzi ten, kto pisał solution design do danego ficzera (czyli w 70% przypadków team leader), w przypadku długu technicznego prowadzą ci, którzy go zgłaszali.

Sorry za powrót do tematu wątku.