Scrum nie działa

1

Nawet ciekawa dyskusja. Pokazuje jak nieznaczącym i mylącym jest słowo "inżynieria" w inżynierii oprogramowania :)
Większość wpisów traktuje chyba raczej o błędach (?) w implementacji.

@LukeJL: "Taka idea: może ten cały "biznes" należałoby wypieprzyć na zbity ryj i ograniczyć jego rolę jedynie do roli inwestora?" No właśnie, który zespół to naprawdę rozumie? :)

2

Nawet ciekawa dyskusja. Pokazuje jak nieznaczącym i mylącym jest słowo "inżynieria" w inżynierii oprogramowania :)

Owszem, lepsze słowo byłoby "psychologia", ponieważ głównym czynnikiem decydującym są ludzie i jak się zachowują, ich emocje, reakcje w sytuacjach stresowych, inteligencja, zdolności i słabości itp. Ew. można by jeszcze mówić o socjologii programowania czy o antropologii programowania. W każdym razie więcej to ma wspólnego z naukami społecznymi szeroko pojętymi niż z inżynierią. Nawet z religioznawstwem ma to więcej wspólnego (w przypadku Scrum szczególnie) niż z inżynierią.

5

No i chyba o tę psychologię chodzi w Agile (nie piszę o scrumie) bo agile nie mówi jak programować tylko jak pracować nad projektem.

Tytuł wątku: "scrum nie działa".

Tak jakby napisać "Boga nie ma". No i zaraz pisanina. Ja Boga widziałem, a ja nie widziałem, ja się zawiodłem bo dałem na tacę a samochód mi ukradli, a mi się nie podoba co ksiądz powiedział, a ja się modlę codziennie i jestem szczęśliwy, a ja się nie modlę i też jestem szczęśliwy. I wszystko prawdziwe, i wszystko nieprawdziwe.

No ale przynajmniej jest co poczytać :)

1
trojanus napisał(a):
  • rozmycie odpowiedzialności, bo ani PO ani SM nie biorą odpowiedzialności, zespół często gęsto też nie bierze odpowiedzialności - odpowiedzialności ni ma, więc produkt wygląda tak jak wygląda,

A w czym Tobie akurat przeszkadza brak odpowiedzialności? Już Ty się nie bój, jak coś pójdzie nie tak, odpowiedzialni zawsze się znajdą.

  • Retro - kto to wymyślił? dla mnie to jest strata czasu, chcesz mieć realny feedback - idź do lekarza, masażystki, mechanika, kominiarza - ale nie zawracaj głowy innym "abo mi to się nie podobało, bo jak coś zrobiłem i to działało, ale przestało i mnie hejtujo" - tak, są to problemy Pierwszego Świata,

Jeśli retro jest niepotrzebne to znaczy, że agile działa, a ono samo trwałoby 10 min. Retro to oznaka demokracji, znak, że ktoś liczy się z Twoją, programisty, opinią, zamiast odgórnie narzucać ci swoje. Sam nie widziałem większego sensu retro do momentu, gdy trafiłem do zespołu, w którym go nie było, a działał system autorytarny i ludzie łazili niezadowoleni. I mimo, że nie byłem SM, zaproponowałem by je wprowadzić i sam podjąłem się jego prowadzenia. Retro służy również temu, by nie powielać w kółko tych samych błędów.

  • rozbicie planowania na planning i review, jak dla mnie to to samo, w projektowaniu trochę czasu spędziłem i tylko jedno jest pewne: to że Słoneczko wstaje i zachodzi, reszta to jest planowanie,

To samo? Co planujecie na review?

4
GutekSan napisał(a):

Retro służy również temu, by nie powielać w kółko tych samych błędów.

Tak właściwie, to do tego służy inteligencja.

0

Retro to akurat jeden z niewielu plusów Scruma.

Robisz sprint, a potem zastanawiasz się co poszło źle, i jak to usprawnić.

Pytanie tylko, czy omówienie jakiejś rzeczy na retro faktycznie powoduje potem zmianę czegokolwiek, jakąkolwiek korektę kursu, czy jest to czcze gadanie. Spotkałem się już z takimi sytuacjami, że na retro były omawiane pewne rzeczy, wszyscy sobie pogadali, że tak nie powinno być, że coś trza zmienić, ale na gadaniu się skończyło, ew. na jakimś symbolicznej zmianie (zawsze mnie rozwala to, że niektórzy myślą, że wystarczy założyć jakieś "issue" w aplikacji, albo przykleić karteczkę na tablicy korkowej "w tym sprincie zmieniamy X", a rzeczy się magicznie zmienią, przez sam fakt deklaracji, że w tym sprincie zmieniamy to i to).

Wadą Scruma wydaje się być przegadanie i skupianie się na wszystkich tych symbolicznych gestach, czyli właśnie coś pomiędzy religią a magią.

3
LukeJL napisał(a):

Robisz sprint, a potem zastanawiasz się co poszło źle, i jak to usprawnić.

Ja wolę zastanawiać się przedtem oraz w trakcie. I gdy widzę, że coś robię źle, to przestaję. A gdy wydaje mi się, że wszyscy coś źle robimy jako zespół, to nie czekam na jakiś specjalny moment tylko idę i rozmawiam o tym od razu. Po co czekać?

1
somekind napisał(a):
GutekSan napisał(a):

Retro służy również temu, by nie powielać w kółko tych samych błędów.

Tak właściwie, to do tego służy inteligencja.

Tak, ale na innym etapie.
Inteligencja służy do tego, by właściwie przetwarzać dane. A retro służy do tego by te dane uzyskać. Bez spojrzenia wstecz samą inteligencją nic nie wskórasz.

A tak w ogóle to zapominacie o jednym: Inteligencja jest cechą rzadką i nie do końca przewidywalną, dlatego mądry biznes polega na tym by potrzebę inteligencji zastąpić procesami.

5

somekind
Ja wolę zastanawiać się przedtem oraz w trakcie. I gdy widzę, że coś robię źle, to przestaję.

No właśnie w Scrum tak się nie da, bo Scrum zakłada, że są sprinty i jak się robi nawet coś błędnego, to trzeba dalej robić źle i nie można przestać dopóki nie skończy się dany sprint. To służy temu, żeby była dyscyplina w zespole.

Bo jakby każdy mógł robić, co chce i kiedy chce, to nie byłby to już Scrum. Może co najwyżej na miano agile czy lean mogłoby to zasłużyć, ale Scrum to jednak musi mieć ceremoniał, dyscyplinę, określony porządek, hierarchię, bo tak przecież ktoś wymyślił i takie są reguły Scruma.

to nie czekam na jakiś specjalny moment tylko idę i rozmawiam o tym od razu. Po co czekać?

Nikt nie robi Scruma po to, żeby było szybciej. Jak powiesz od razu i rozwiążesz problem z miejsca, to za szybko projekt pójdzie i velocity skoczy do góry, a to też jest niedobre, bo programiści wg Scruma nie powinni pracować za szybko, bo velocity powinno być na stałym poziomie, bo tak ktoś wymyślił.

Inne wytłumaczenie słyszałem, że po to się spowalnia pracę i pakuje ją w sztywne sprinty, żeby chronić programistów przed "wrzutkami" ze strony biznesu. W sensie, że jeśli nie byłoby sprintów, to biznes mógłby programistów zawalać pracą ile wlezie, a sprinty chronią o tyle, że jeśli coś zostało zaplanowane na dany sprint, to programiści mogą poświęcić czas na to, co zaplanowali na początku sprintu i nie będą mieć "niespodzianek" typu "dzisiaj musisz zrobić dodatkowe 5 rzeczy na dwudziestą drugą, bo klient z Antarktydy chce demo".

Może wic Scrum to taki kompromis między tym, czego wymaga korporacyjna kultura (czyli np. porządek, hierarchia, ceremoniał, dyscyplina, ale także np. rozmaite buzzwordy czy podnosząca ego tytulatura), a tym, żeby programistów jakoś chronić i zachować jakieś pozory agile w kulturze korporacyjnej?

0
GutekSan napisał(a):

Tak, ale na innym etapie.
Inteligencja służy do tego, by właściwie przetwarzać dane. A retro służy do tego by te dane uzyskać. Bez spojrzenia wstecz samą inteligencją nic nie wskórasz.

To całe "patrzenie wstecz" zawiera się w definicji samej inteligencji, czyli zdolności postrzegania, analizowania i wykorzystywania zdobytej wiedzy w celu adaptacji do zmian. Człowiek inteligentny, gdy widzi, że jego działania nie odnoszą pożądanych skutków, zmienia te działania. To jest to, co odróżnia inteligentnych od głupców - bo tylko głupcy robią ciągle to samo oczekując innych efektów.
Rozumowanie zaś jest podstawową cechą naszego gatunku. Też z definicji... a właściwie z nazwy.

dlatego mądry biznes polega na tym by potrzebę inteligencji zastąpić procesami.

Tu się nie sposób nie zgodzić, im większa i bardziej zbiurokratyzowana firma, tym więcej ameb w niej pracuje.

2

Czyli podsumowując: jak scrum nie działa, to znaczy, że pewnie źle jest implementowany (praktycznie 90% tłumaczeń jego nieefektywności, w tym też na forach zagranicznych). A jak działa, to często jego zasługa (no bo pracujemy w scrumie!), innych rzeczy już nie...

Codzienne daily? Dla jednych bezsens, dla innych jeden z niewielu plusów. Retro? To samo, dla jednego jeden z niewielu plusów, dla innego kompletny bezsens. I tak każdy jeden element tej "filozofii". Jakby tu wyodrębnić, co dla jednych jest plusem, a co minusem, to wyjdą takie miszmasz zbiory, z których nic nie wynika. To wszystko moim zdaniem świadczy o wątpliwej skuteczności tej filozofii, która jest aplikowana do wielu teamów, do różnych ludzi bez uwzględniania czegokolwiek dodatkowego.

3

Scrum nie jestest panaceum na wszytkie problemy projektowe. Jak jest robiony z głową to działa. Tylko, że to o niczym nie świadczy, bo to samo można powiedzieć o innych podejściach lekkich czy ciężkich.

Mam wrażenie, że scrum jest hejtowany, bo stał się wszechobecny, nieomylny, do tego "obrośnięty tłuszczem" (nadmiar narzędzi, szkoleń, cerytyfikowanych eksperów, itd.), a nawet zaczął zaprzeczać ideologii agila (przypomnę - "Individuals and interactions over processes and tools", "Responding to change over following a plan").

Osobiście mnie śmieszy ten hejt. To jak dyskusja nad wyższością świąt Bożego Narodzenia nad Wielkanocą.

0

Zapamiętajcie tylko jedno: SCRUM nie rozwiązuje żadnych problemów w Zespole ale bezlitośnie je ujawnia i obnaża.

6

Raczej mam wrażenie, że przykrywa.

Działanie w sprintach i otoczka pseudo-edżajlowa ukrywa fakt, że wszystko i tak jest jednym wielkim waterfallem.

Dużo fajnie brzmiących buzzwordów (scrum, sprints, stand ups, velocity, product owner, scrum master(!) ) ukrywa fakt, że jest to zwykły micromanagement.

itp. itd.

0
trojanus napisał(a):

Też mam kilka uwag do Scruma, co prawda jako dev a nie jako PO, SM czy Bóg raczy wiedzieć kto tam jeszcze jest z jakimś "foxxy" określeniem w nazwie pełnionej funkcji - już samo to wprowadza zamieszanie.
Uważam, że Scrum się nie nadaje do projektowania/prowadzenia projektów. Wiem za to do czego się nadaje: do robienia reklamy dla dużych klientów, na zasadzie: "bo my to pracujemy w Scrumie, jesteśmy Agile i w ogóle to jesteśmy tacy fajni".

Do projektów lepszy XP, ale do produktów się nadaje.
Jakie są dobre założenia Scruma:

  • wykorzystuje Sprinty, choć 3-4 tygodnie Sprintu to jakieś nieporozumienie, po takim okresie czasu zapomniałbym o czym jest projekt. Sprint powinien jak dla mnie trwać tydzień.
  • to tyle, więcej nie ma :P

Jakie są złe założenia Scruma:

  • podział ról na Scrum mastera, PO i resztę czyt. zespoły,
  • rozmycie odpowiedzialności, bo ani PO ani SM nie biorą odpowiedzialności, zespół często gęsto też nie bierze odpowiedzialności - odpowiedzialności ni ma, więc produkt wygląda tak jak wygląda,
  • Retro - kto to wymyślił? dla mnie to jest strata czasu, chcesz mieć realny feedback - idź do lekarza, masażystki, mechanika, kominiarza - ale nie zawracaj głowy innym "abo mi to się nie podobało, bo jak coś zrobiłem i to działało, ale przestało i mnie hejtujo" - tak, są to problemy Pierwszego Świata,
  • rozbicie planowania na planning i review, jak dla mnie to to samo, w projektowaniu trochę czasu spędziłem i tylko jedno jest pewne: to że Słoneczko wstaje i zachodzi, reszta to jest planowanie,
  • wycenianie zadania vel. Scrum Poker - z większym absurdem się nie spotkałem w życiu. Albo coś trzeba zrobić, albo nie - i tyle. Dobrze, że te wyceny nie są robione przy pomocy kostki k20, choć można tak zrobić przecież "te punkty nie mają żadnego znaczenia".

To tak z grubsza biorąc.

0

wykorzystuje Sprinty, choć 3-4 tygodnie Sprintu to jakieś nieporozumienie,
po takim okresie czasu zapomniałbym o czym jest projekt. Sprint powinien jak dla mnie trwać tydzień.

Pracowałem w sprincie tygodniowym i dalej było to nie porozumienie. Szczególnie biorąc pod uwagę fakt istnienia weekendu i to, że sprint zaczynał się w środku tygodnia. Trochę dla mnie patologią jest zostawiać w piątek rozgrzebane zadanie, a potem siadać do niego w poniedziałek.

Jak dla mnie "sprint", jeśli w ogóle miałby istnieć, to powinien się zamykać w piątek. W zasadzie może lepszym podejściem byłoby zrobić dwa sprinty tygodniowo: regularna praca: poniedziałek, wtorek, środa i koniec sprintu. A potem dodatkowy mini sprint czwartkowo-piątkowy. Wiadomo, że pod koniec tygodnia się jest bardziej zmęczonym, więc podczas tego mini-sprintu można by się zajmować czymś mniejszym, mniej wymagającym. Np. jakiś prosty refaktor, czy fiksowanie jakiegoś drobnego buga. Ew. robienie poprawek do tego, co się dowiozło w środę.

Tylko przy częstych sprintach, nie powinno być długich spotkań. Może dlatego te sprinty często są za długie, bo ludzie się boją, że jak będą sprinty np. 2 razy w tygodniu, to będą "zmuszeni" zrobić dodatkowe 4 godziny spotkań, bo przecież jest cargo cult planowania, robienia retrospekcji itp.

rozmycie odpowiedzialności, bo ani PO ani SM nie biorą odpowiedzialności, zespół często gęsto
też nie bierze odpowiedzialności - odpowiedzialności ni ma, więc produkt wygląda tak jak wygląda,

Dokładnie. Nikt za nic nie odpowiada, ale każdy jest specem od wszystkiego (i np. backendowcy się wpieprzają do frontendu i robią tam sajgonki, spaghetti i parę innych rzeczy. No bo przecież Scrum i "self-organized teams", czyli w rezultacie taka wielka samowolka i chaos, gdzie każdemu się wydaje, że jest full stackiem)

wycenianie zadania vel. Scrum Poker - z większym absurdem się nie spotkałem w życiu.
Albo coś trzeba zrobić, albo nie - i tyle. Dobrze, że te wyceny nie są robione przy pomocy kostki k20, choć można tak zrobić

Wg mnie lepiej by było, gdyby były losowane, ponieważ nie traciłoby się ani czasu na estymacje, ani energii na kłócenie się z kimś, czy coś ma mieć przydzielone 3 czy 5 punktów.

2
LukeJL napisał(a):

Pracowałem w sprincie tygodniowym i dalej było to nie porozumienie. Szczególnie biorąc pod uwagę fakt istnienia weekendu i to, że sprint zaczynał się w środku tygodnia.

To akurat słuszne podejście, największym bezsensem jest zaczynanie czegoś w poniedziałek a kończenie w piątek, czyli dni, w które najczęściej bierze się urlopy.

Jak dla mnie "sprint", jeśli w ogóle miałby istnieć, to powinien się zamykać w piątek. W zasadzie może lepszym podejściem byłoby zrobić dwa sprinty tygodniowo: regularna praca: poniedziałek, wtorek, środa i koniec sprintu. A potem dodatkowy mini sprint czwartkowo-piątkowy.

To by się mogło sprawdzić chyba tylko we frontendowych greenfieldach. W starszych systemach albo na backendzie niektórych pojedynczych tasków nie da się sensownie zamknąć w tydzień, a co dopiero dwa dni. A niektóre refaktoryzacje potrafią potrwać i miesiąc.

1

@LukeJL:

wincyj sprintów aby tylko chodzić na spotkania :D

Tylko przy częstych sprintach, nie powinno być długich spotkań. Może dlatego te sprinty często są za długie, bo ludzie się boją, że jak będą sprinty np. 2 razy w tygodniu, to będą "zmuszeni" zrobić dodatkowe 4 godziny spotkań, bo przecież jest cargo cult planowania, robienia retrospekcji itp.

:)

0

To akurat słuszne podejście, największym bezsensem jest zaczynanie czegoś w poniedziałek
a kończenie w piątek, czyli dni, w które najczęściej bierze się urlopy.

W sumie coś w tym jest, nie pomyślałem o tym.

To by się mogło sprawdzić chyba tylko we frontendowych greenfieldach. W starszych systemach
albo na backendzie niektórych pojedynczych tasków nie da się sensownie zamknąć w tydzień, a co dopiero dwa dni.
A niektóre refaktoryzacje potrafią potrwać i miesiąc.

To argument za tym, że w ogóle idea dzielenia pracy na z góry ustalone fragmenty czasu ("sprinty") jest nietrafiona. Pozbawia możliwości bycia elastycznym.

we frontendowych greenfieldach

We frontendowych greenfieldach też się trafia, że jeden task zajmuje tydzień czy dwa tygodnie. Tylko, że jak dla mnie to wynika często z tego, że taski są często źle podzielone. Bo od strony biznesowej coś może wyglądać na 1 rzecz, a od strony techniczniej już tak prosto nie ma i to co się biznesowi wykluło jako jeden ficzer, to w rezultacie jest ileś mniejszych oddzielnych rzeczy do zrobienia.

(trochę wyjaskrawiając to np. zrobienie klona Google mogłoby być opisane jako "jak użytkownik chciałbym mieć możliwość wyszukania czegoś w internecie przez wpisanie hasła w małym okienku", a zrobienie klona Facebooka jako "jako użytkownik chciałbym mieć możliwość kontaktu ze znajomymi przez stronę www")

Bywało, że pracowałem niby nad "jednym taskiem", ale było do niego dołączone ileś subtasków (gdzie jeden subtask się robiło np. z 3 dni).

Tylko, że mimo wszystko dla biznesu był to "1 task", więc ciągle biznes miał pretensję, że "czemu to jeszcze nie gotowe, jak to tylko 1 task".

1
LukeJL napisał(a):

To by się mogło sprawdzić chyba tylko we frontendowych greenfieldach. W starszych systemach
albo na backendzie niektórych pojedynczych tasków nie da się sensownie zamknąć w tydzień, a co dopiero dwa dni.
A niektóre refaktoryzacje potrafią potrwać i miesiąc.

To argument za tym, że w ogóle idea dzielenia pracy na z góry ustalone fragmenty czasu ("sprinty") jest nietrafiona. Pozbawia możliwości bycia elastycznym.

I dobrze, bo nie można być zbyt elastycznym. Programistom czasem trzeba określić ramy czasowe, żeby nie dłubali nad jedną rzeczą w nieskończoność. Jeśli coś jest wystarczająco dobre - do wora, i robimy następne.

5

I dobrze, bo nie można być zbyt elastycznym. Programistom czasem trzeba określić ramy czasowe, żeby nie dłubali nad jedną rzeczą w nieskończoność. Jeśli coś jest wystarczająco dobre - do wora, i robimy następne.

I tak się właśnie rodzi jakoś.
Jest wystarczająco dobre, bo trzeba coś pokazać na demo..., bo jak nie to nam spadnie velocity i przyjdzie ktoś z kierownictwa i będzie truł.

1

Ja trochę pospamuje linkiem do posta, który namisałem odnośnie scruma -> https://developer20.com/why-do-many-people-say-that-scrum-is-a-bullshit/

wg mnie, żeby scruma robić dobrze, to trzeba go zakumać. Mi to zajęło około roku. Czasami najbardziej agilowym podejściem jest... zrezygnowanie z scruma w ogóle. Jak np developerzy uważają standup za stratę czasu i tylko przeszkadzajkę to można to rozwiazać na wiele sposobów:

  • zmienić godzinę standupu
  • zmienić jego formę, tak aby trwał np 3 minuty na zespół
  • zrobić daily scrumy (bo tak to się oryginalnie nazywa) na wiadomości na slacku
  • całkowicie zrezygnować ze standupów

Nie zapominajmy po co one były wprowadzone: żeby być na bieżąco co się dzieje w projekcie i by w miarę często mówić o problemach by móc ewentualnie je szybciej rozwiązać.

Planowania nie są czymś co musi podać Ci dokładne wartości. Jest po to, aby MNIEJ WIĘCEJ wiedzieć ile zespół jest w stanie zrobić. Jeśli zadanie na 3 punkty trwało więcej niż inne zadanie oszacowane na 8 punktów, to znaczy, że albo te pierwsze było niedoszacowane (czegoś nie wiedzieliśmy/nie przewidzieliśmy) albo drugie zadanie było przeszacowane.

Spodobało mi się ostatnio zformułowanie: W Scrumie chodzi o to, aby nie być ch**jem :D
Jak coś nie działa, to trzeba się dowiedzieć dlaczego nie działa i spróbować to naprawić. Jak się nie da, albo jest to niepotrzebne, to można z tego zrezygnować. Wliczając w to scruma.

3

Wszystko zależy od ludzi - jak trafi się ogarnięty zespół to nawet scrum mu nie przeszkodzi za bardzo (2018, jarekr000000), a nawet momentami pomoże. Jak trafi się na obiboków których największym problemem jest "co ja powiem na standupie" + scrum master któremu staje na widok gładkiego burn down charta w Jira, to zaczyna się kolorowanie trawy na zielono, a najbardziej elastyczna w całym tym Agile'u zaczyna być definition of done - np. "wystarczy wypchnąć kod do repo".

2
jarekr000000 napisał(a):

I dobrze, bo nie można być zbyt elastycznym. Programistom czasem trzeba określić ramy czasowe, żeby nie dłubali nad jedną rzeczą w nieskończoność. Jeśli coś jest wystarczająco dobre - do wora, i robimy następne.

I tak się właśnie rodzi jakoś.
Jest wystarczająco dobre, bo trzeba coś pokazać na demo..., bo jak nie to nam spadnie velocity i przyjdzie ktoś z kierownictwa i będzie truł.

Jarku, ale wiesz co ma najniższą jakość?
Coś czego w ogóle nie ma.

Kluczem jest tu słowo wystarczająco, które oznacza, że coś spełnia ustalone standardy jakości. A te standardy też zostały określone w procesie planowania przy tworzeniu Definition of Done dla danego User Story. I tak rozumiem określenie wystarczający, a nie jako posiadający pozory bycia skończonym. Tymczasem przedłużanie pracy w celu maksymalizowania jakości prowadzi do tego, że albo dostajemy doskonały produkt, którego nikt już nie potrzebuje, albo w ogóle nie dostajemy nic, bo niczego nie udało się skończyć.

Programiści czasem zapominają, że nie są artystami, i nie tworzą dzieła sztuki, tylko produkt biznesowy.

3
GutekSan napisał(a):

Tymczasem przedłużanie pracy w celu maksymalizowania jakości prowadzi do tego, że albo dostajemy doskonały produkt, którego nikt już nie potrzebuje, albo w ogóle nie dostajemy nic, bo niczego nie udało się skończyć.

No i na tym właśnie polega Scrum w praktyce. Na przedłużaniu pracy poprzez stosowanie meetingów i micromanagementu, a w efekcie nie kończeniu niczego.

0

Programiści czasem zapominają, że nie są artystami, i nie tworzą dzieła sztuki,

No może rzeczywiście nie jest to dziełu sztuki, ale nadal jest to praca wysoce twórcza, wymagająca pomysłu i myślenia. Może rzeczywiście porównywanie z "klasyczną" sztuką jest (trochę) chybione, ale już chyba każdy znajdzie dużo podobieństw z nowoczesnymi nurtami, jak chociażby konceptualizmem.

3
GutekSan napisał(a):

Kluczem jest tu słowo wystarczająco, które oznacza, że coś spełnia ustalone standardy jakości. A te standardy też zostały określone w procesie planowania przy tworzeniu Definition of Done dla danego User Story. I tak rozumiem określenie wystarczający, a nie jako posiadający pozory bycia skończonym. Tymczasem przedłużanie pracy w celu maksymalizowania jakości prowadzi do tego, że albo dostajemy doskonały produkt, którego nikt już nie potrzebuje, albo w ogóle nie dostajemy nic, bo niczego nie udało się skończyć.

Programiści czasem zapominają, że nie są artystami, i nie tworzą dzieła sztuki, tylko produkt biznesowy.

Co do zasady się z Tobą zgadzam, bo często też walczę z nieuzasadnionymi biznesowo próbami rozdmuchania funkcjonalności. Zrobimy framework do robienia takich projektów i potem se już tylko będziemy konfigurować w XMLu to nadal korpo-standard.

Ale zupełnie ortogonalnym problemem jest Scrum, który wprowadza ceremonie i czasem głupie, zupełnie niczym nie uzasadnione terminy. Pół biedy jak te cykle dotyczą jednego zespołu. Ale miałem przyjemność pracować w zupełnie zescrumowanej firmie.

Na co dzień widziałem dylematy - jak nie wypchniemy na czwartek ficzera i nie pokażemy na demo, to nie będziemy mogli wypchnąc na środowisko integracyjne, to security nie zmieni reguł na firewallach, to drugi team nie będzie mógł zacząć prac nad swoim kawałkiem itd. A jeszcze niektóre teamy mają cykle tygodniowe, niektóre dwu, niektóre miesiąc, a jedyny spec od security, który może pomóc przy problemach jest dostępny co drugi tydzień.
Na koniec zupełnie absurdalnie wychodzi, że oddanie kawałka o jeden dzień później powoduje finalne opóźnienie na produkcji o miesiąc. Co np. dla nowoczesnej firmy założonej w XIX wieku jest nie do zaakceptowania.

Więc trafiam (i to norma) do takich zespołów gdzie na ścianach wielkie rozpasane DOD (i ciągle rosnące), a w praktyce mamy dopychanie kolanem i oficjalne prośba o robienie niezbyt skrupulatnych review, bo będzie problem.

Najgorsze, że jak się zespół do czegoś takiego przyzwyczai to niestety jest ciężko to wyplenić (kulturowo).

1

generalnie to pracowal ktos w scrumie ktory jako tako funkcjonowal? ja duzo doswiadczenia nie mam ale 2gi rok w scrum i mam wrazenie ze praca scrumie to ogranizowanie spotkan i debatowanie nad tym jak pracuje sie w scrumie

2
filemonczyk napisał(a):

generalnie to pracowal ktos w scrumie ktory jako tako funkcjonowal?

Ogólnie to w tej firmie, o której często piszę udało się w pewnym momencie prowadzić SCRUMa prawie by the book i nawet dużo patologii, takich jak pisałem udało się wyeliminować. I to był też moment, w którym zaczęliśmy tego SCRUma powoli olewać - najważniejsze to wyeliminowanie całego śmiecia - straty czasu na planowanie, retro (jaki nonsens), i daily stan dupy.

Zrobiliśmy spotkania opcjonalne w większości (daily też). Z nazwy to tam został SCRUM, żeby nikt się nie czepiał. Rozwalanie dużo czasu zajęło, ale SCRUM ma wbudowane opcje ułatwiające destrukcję (na szczęście).

Np.: na każdym retro powtarzałem, że uważam, że retro jest stratą czasu.... - miałem nadzieję, że w końcu się ten postulat uda przepchnąć (rok ponad zajęło, ale się udało).

Przy okazji wcale nie złośliwie bo, skoro ciągle narzekamy na to samo (!), to znaczy, że nie udaje nam się problemow rozwiązać i możemy z nimi żyć i po prostu oszczędzić sobie narzekania.
(mam wrażenie, że norma w wiekszości zespołów).

Przestaliśmy sie przejmować velocity. Nauczyliśmy się nie czekać na DEMO ... z demonstrowaniem. Lepiej pokzać coś zanim jest gotowe, puty jeszcze ludzie (potencjalnie użytkownicy) mają szanse coś zmienić.

Ogólnie powstał jakis nowy proces, ale nie wiem czy jest sens opisywać, specyfika firmy jest taka, że dużo zespołów równoległych działało w tym samy kodzie, albo blisko niego i było dużo zależności. Zrobiliśmy sobie spotkania sync z innyi zespołami i tam chodziliśmy (jak ktoś miał potrzebę!).

Np. jedno z takich spotkań/process dokładnie zastąpiło retro - wpisywaliśmy po jednym/dwóch największychy problemach z każdego zespołu (w zespole mieliśmy ścianke bólu gdzie każdy ad hoc mógł wpisać jak go coś wkurzyło) i jak się powtarzały (między zespołami) to szedł task do szefostwa - naprawcie nam firmę. A jak nie to się rozchodziliśmy (5 minut i po spotkaniu).

Planingi się zmieniły tak, że po prostu programista z biznesem siadał (czasem na kilka godzin) przed spotkaniem i szacował z nimi jakies punkty na podstawie swojego doświadczenia. Potem na planowaniu mówił - jest takie zadanie i wg mnie tyle to zajmie bo to i to. Był czas, żeby zgłosić uwagi do tego planowania, czy np, o wszystkich problemach pamiętał, robiło to duża oszczędnośc czasu. No i oczywiście koniec dramy z dyskusjami 3 czy 5. Każda wątpliwość przy niezbyt dużych różnicach to liczba większa i nie tracimy czasu na precyzyjne celowanie z szacunkami ( bo i po co).

Udało mi się nawet ze dwa razy przemycić przy szacowaniu liczbę 4 i 10 jako estymatę (musiałem udawadniać, że takie liczby też istnieją... - ale jest zaskakująco prosty dowód tego).

Wydaje mi się, że jeszcze ważniejsze od wypaczenia SCRUMa było wprowadzenie innych reguł, typu: nikt nie koduje taska sam dłużej niż dwa dni. Czyli jak ktoś przekisi taska 2 dni to dostaje partnera do kodowania i następuje przekazanie taska, ewentualnie robią go dalej 2 osoby. Taki bieda pair programming, ale realizował cel - o każdym większym tasku miały dogłębne pojęcie przynajmniej 2 osoby.

Jeszcze było kilka innych myków, ale wszystko to związane ze specyfiką firmy i zadaniami (wiele zespołów, bardzo skomplikowana domena, rozwłóczona przez 120 serwisów, paranoiczne security itd). Dlatego, wcale nie sprzedawałbym i nie polecał tego procesu gdzieś indziej.

Najważniejsze wyszło nieźle - można było kodować. Prawie cały dzień. Jak przyszedłem do firmy to w zespole było 18 godzin spotkań na człowieka na tydzień.... Mieliśmy żarty o tym, że już w następną środę na przerwie pomiędzy 2 zebraniami uda nam się może odpalić Intlellij. Były całe tygodnie gdzie odpalenie IDE się nie udawało - mega frustracja.

0

Raz miałem scruma zgodnego z książką, który działał dobrze. Mieliśmy cztery osoby w zespole + szef, nasz klient był dostępny i bardzo ładnie nam to szło. Mam jednak wrażenie, że to dzięki temu, że projekt był wewnętrzny, więc nasz klient był bardzo techniczny i jednocześnie nie było twardych terminów. W każdym innym przypadku dyskutowanie zajmowało często więcej czasu, niż samo kodzenie, a przy zadaniach, gdzie zajmowało mniej, estymaty się nie zgadzały z rzeczywistością dość mocno.

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