Temat: Jak przekonać zespół do posiadania jasnego kryterium...

Michał Kisza:

Sporo "książkowych definicji" którymi mnie i czytających zarzuciłeś są rezultatem do którego się dąży. Są też czymś co większość osób na tym forum dobrze zna i rozumie.

Niczego z książki nie było. Jak definicje mogą być rezultatem? Nie znam poglądów i wiedzy większości osób z forum.

Myślę, że cel tego forum to wymiana pomysłów i doświadczeń z zakresu SCRUMa, nie tylko po wdrożeniu, ale również przed i w trakcie tego procesu. Myślę, że to o co pytałem zrozumiał dokładnie np. Paweł Schmidt czy Mateusz Witański, podając swoje pomysły (za które dzięki).

Aha, czyli jak z mojego doświadczenia wynika, że standardowe praktyki działają to nie powinienem o tym mówić, bo to jest "książkowa definicja". Ciekawe podejście, ale nie skorzystam :)

W trakcie wdrażania Scruma w projektach widziałem dużo hacków i obejść i ich skutki. Veni, vidi, vici. Można szybciej postać w miejscu, a można też zrobić parę kroków w tym czasie. Można pozwolić zespołowi pobłądzić i potracić trochę czasu, ale można też skorzystać z doświadczania i władzy ScrumMastea i zawrócić owieczki :)

Sorry, że drążyłem i próbowałem pomóc znajdując przyczynę a nie lecząc objawy.

Mówisz o jednej z możliwych dróg wdrożenia SCRUMa która pewnie zadziała w wielu sytuacjach, ale to jest tylko jeden ze sposobów wdrożenia (terapia szokowa - wszystko od razu). Są też inne sposoby (to mógłby być ciekawy wątek BTW).

Mówienie o jednym nie wyklucza istnienia wielu.

Myślę, że zgodzisz się ze mną, że celem ostatecznym jest to, by SCRUM był wdrożony bez żadnych "but".

Jasne, że się zgadzam się. Trzeba też pamiętać, że to nie oznacza zniknięcia problemów.
Ciekawy wpis o adaptacji Scrum miał ostatnio Mike Cohn: http://architects.dzone.com/articles/agile-adoption-go...

Temat: Jak przekonać zespół do posiadania jasnego kryterium...

Krystian K.:

Michał Kisza:

Sporo "książkowych definicji" którymi mnie i czytających zarzuciłeś są rezultatem do którego się dąży. Są też czymś co większość osób na tym forum dobrze zna i rozumie.

Niczego z książki nie było. Jak definicje mogą być rezultatem? Nie znam poglądów i wiedzy większości osób z forum.

Na SCRUM Guide można patrzeć jak na definicję tego czym SCRUM jest. Rezultatem jest mieć działający w ten sposób zespół - bez żadnych "but". Mamy definicję i mamy rezultat.

Krystian K.:

Myślę, że cel tego forum to wymiana pomysłów i doświadczeń z zakresu SCRUMa, nie tylko po wdrożeniu, ale również przed i w trakcie tego procesu. Myślę, że to o co pytałem zrozumiał dokładnie np. Paweł Schmidt czy Mateusz Witański, podając swoje pomysły (za które dzięki).

Aha, czyli jak z mojego doświadczenia wynika, że standardowe praktyki działają to nie powinienem o tym mówić, bo to jest "książkowa definicja". Ciekawe podejście, ale nie skorzystam :)

Nikt nie twierdzi, że nie działają i nikt nie twierdzi, że nie masz czegoś mówić lub pisać. W moim zrozumieniu, sugerujesz, że "da się wskoczyć" w SCRUMa od razu - tak naprawdę... to zależy.

Krystian K.:
W trakcie wdrażania Scruma w projektach widziałem dużo hacków i obejść i ich skutki. Veni, vidi, vici. Można szybciej postać w miejscu, a można też zrobić parę kroków w tym czasie. Można pozwolić zespołowi pobłądzić i potracić trochę czasu, ale można też skorzystać z doświadczania i władzy ScrumMastea i zawrócić owieczki :)

Sorry, że drążyłem i próbowałem pomóc znajdując przyczynę a nie lecząc objawy.

W mojej ocenie SCRUM master ma władzę nad procesem SCRUMa (w rozumieniu - wie najlepiej co to jest SCRUM), ale zespół który realizuje ten proces, składa się z ludzi, którzy jeśli nie są do czegoś przekonani to nie będą robić tego czy tamtego a już na pewno nie w najlepszy możliwy sposób. Czasem kontrolowane błądzenie może przynieść więcej pożytku niż narzucanie czegoś z góry.

Klasa SCRUM Mastera objawia się w tym, że potrafi tak działać, że zespół sam dojdzie do pewnych wniosków i będzie chciał pracować w sposób w jaki chce tego SCRUM Master. Nie zawsze jest to najlepszy wybór, ale jak napisałem - TO ZALEŻY.

Co do pracy SCRUM Mastera - ciekawy materiał można znaleźć w lokalizacji (jeśli ktoś nie widział)

"10 tips that ScrumMasters should know, (but probably don't!)" - talk by Nigel Baker, Scrum coach and trainer, delivered at "Agile Tuning" community conference in Cracow, Poland.

http://vimeo.com/10481187

Wracając do tego tego co napisałeś... sposób wdrożenia o którym piszesz jest dobrym pomysłem w sytuacji, kiedy masz do dyspozycji zespół, który chce tak pracować od początku i rozumie po co się tak pracuje (zalety).

Krystian K.:
Ciekawy wpis o adaptacji Scrum miał ostatnio Mike Cohn: http://architects.dzone.com/articles/agile-adoption-go...

Dzięki za link

pozdrawiam
MichałMichał Kisza edytował(a) ten post dnia 17.11.10 o godzinie 20:29

Temat: Jak przekonać zespół do posiadania jasnego kryterium...

Niedawno spotkałem się z jeszcze jedną propozycją rozwiązania - posiadanie w Backlogu zadań związanych z kredytem technicznym i dwa podejścia do tego typu zadań - spędzanie dodatkowych sprintów na pokrycie systemu testami i refoktoryzacją lub przy okazji najdrobniejszej zmiany porządkowanie kodu w danym obszarze.
Może to też naprowadzi na rozwiązanie.

Temat: Jak przekonać zespół do posiadania jasnego kryterium...

Mateusz Witański:
Niedawno spotkałem się z jeszcze jedną propozycją rozwiązania - posiadanie w Backlogu zadań związanych z kredytem technicznym

Tworzenie kredytu technicznego/technical debt nie powinno być pochodną nie osiągania definicji DONE. Technical debt może być tworzony przez taski typu: zainstaluj nową wersję bazy albo nowy driver.

i dwa podejścia do tego typu zadań - spędzanie dodatkowych sprintów na pokrycie systemu testami i refaktoryzacją

takie Sprinty nie mają wartości dla klienta, więc nie są sprintami, tylko miniwaterfallem. To czego nie lubimy zrobimy później. Niezwykle trudno jest przekonać PO do wciągnięcia jednej Story z technical debt a co dopiero całe Sprinty.

lub przy okazji najdrobniejszej zmiany porządkowanie kodu w danym obszarze.
Może to też naprowadzi na rozwiązanie.

A kto ma sprawdzać, czy przypadkiem nie jesteś w obszarze technical debt? I tu już jest jeden problem.
Drugim problemem jest to, że w momencie, kiedy do User Story dołożysz taski z technical debt, którego przecież nie brano pod uwagę, bo nie jest w acceptance criteria oryginalnej Story, estymata Ci urośnie i w oczach PO będzie to co najmniej dziwne.Krystian K. edytował(a) ten post dnia 26.11.10 o godzinie 11:38

Temat: Jak przekonać zespół do posiadania jasnego kryterium...

Problem, jaki opisał Michał jest taki, że zespół tworzy kredyt techniczny i padło pytanie, jak sobie z tym poradzić.
Czy tworzenie takiego kredytu jest dobre i kto ma go diagnozować to chyba inna dyskusja. W tym wątku padło pytanie, jak sobie z tym, co już występuje, poradzić.