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

Witam

Chciałbym zapytać czy ktoś z was ma jakieś doświadczenia w przekonywaniu zespołu że powinien wypracować jasne kryterium ukończenia każdego elementu backloga produktu?

Czeka mnie to w najbliższym czasie z zespołem któremu jest to raczej obojętne i zastanawiam się jak to najlepiej zrealizować by poczuli wartość w posiadaniu takiego kryterium a z drugiej strony by im tego nie narzucać.

Mam kilka pomysłów jak np.

1. Zadawanie pytań typu "Skąd wiecie że skończyliście?"

2. Przeprowadzenie ćwiczenia w którym każdy z zespołu osobno określa co to znaczy dla niego że dany element backlogu produktu jest wykonany. Następnie porównanie wszystkich odpowiedzi i próba pokazania że każdy rozumie to inaczej co prędzej czy później będzie problemem.

3. Poczekanie aż brak takiego kryterium spowoduje problemy - kiedy wyjdzie że element uznany za zrealizowany wcale taki nie jest. Wtedy sugestia dla zespołu by sam zmierzył się z pytaniem PO "Przecież mówiliście że to jest skończone..."

Zastanawiam się czy są jeszcze jakieś inne skuteczne możliwości - ktoś ma jakiś pomysł lub sugestie?

Z góry dzięki za pomoc

Przy okazji - jeśli ktoś jest zainteresowany tym co Ken Schwaber mówi na ten temat to od niedawna (18 października 2010) na YouTube można znaleźć 3 nagrania z konferencji "Succeeding With Scrum" która odbyła się w Montrealu - poniżej link do pierwszego nagrania

http://www.youtube.com/watch?v=VCzIFn8vt_c&p=7884B2A49...

pozdrawiam
MichałMichał Kisza edytował(a) ten post dnia 13.11.10 o godzinie 19:54

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

Cześć,

Zakładam, że chodzi o Definicję DONE.
Twoje pomysły są dobre.
Mam kilka pytań:
- Co na to testerzy w tym zespole? Nie czują się zaniepokojeni?
- Jak wygląda Agile Wall tego zespołu? Jakie etapy są na niej wydzielone?

Ad.2 Każdy z zespołów może mieć inną Definicję DONE pod warunkiem, że jednym z elementów jest integracja z tym co inne elementy dostarczają. Także nie wiem, jaki będzie wynik Twojego ćwiczenia.

Najbardziej zaniepokojoną osoba w tej sytuacji powinien być PO, bo nie wie co odbiera.

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

Witam

Zakładam, że chodzi o Definicję DONE.

Dokładnie

Co do Twoich pytań:

- Co na to testerzy w tym zespole? Nie czują się zaniepokojeni?

Aktualnie w tym zespole jest tylko jeden tester który skupia się na:
1. klikaniu w interfejs i sprawdzaniu czy wszystko jest ok
2. tworzeniem automatycznych testów GUI (ja bym od tego nie zaczynał ale to pomysł kierownictwa. Jak wiadomo szef ma zawsze rację, a jak aplikacja "sama się klika" to fajnie to wygląda dla innych)
3. rozpoczyna powoli przygodę z pisaniem testów akceptacyjnych w FitNesse (przekonaliśmy kierownictwo, że to dobra droga przynajmniej dla części tworzonych rozwiązań)
4. na dodatek jest osobą dopiero zdobywający doświadczenie (również pomysł kierownictwa)

Resztę testów (jednostkowe i częściowo akceptacyjne) wykonują programiści.

Trudno mi więc odpowiedzieć na Twoje pytanie.

- Jak wygląda Agile Wall tego zespołu? Jakie etapy są na niej wydzielone?

Jeśli dobrze zrozumiałem chodzi o stany elementów backloga podczas ich zamiany w działające oprogramowanie - są cztery:

1. Future (praca jest przygotowana, element backlogu spełnia Definition of Ready, wiemy że będziemy to robić)
2. In Progress (zespół aktualnie pracuje nad danym elementem, w tym tester rozpoczyna swoje testy na tym co oddają mu programiści)
3. Done (programiści wykonali funkcjonalność zgodnie z zebraną akceptacją, wykonana praca jest zintegrowana z istniejącą bazą kodu)
4. Accepted (tester dopina testy, całość gotowa jest do wdrożenia jak tylko klient dokona akceptacji)

Problemy są związane z krokiem trzecim - obecnie podstawą do uznania elementu za wykonany jest zebrana akceptacja (czasami niestety niepełna) oraz "wyczucie" programisty, który "dokańcza" dany element backloga (przez wyczucie rozumiem np. decyzję danego programisty czy pisać testy, czy trzymać się standardów, czy refaktoryzować etc.) Nie specjalnie czuję, aby komuś chciało się to zmienić.

Ad.2 Każdy z zespołów może mieć inną Definicję DONE pod warunkiem, że jednym z elementów jest integracja z tym co inne elementy dostarczają. Także nie wiem, jaki będzie wynik Twojego ćwiczenia.

Zgadza się - natomiast ćwiczenie ma pokazać, że są różnice w rozumieniu co to znaczy, że coś jest skończone. Mój pomysł polega na tym by zespół zrozumiał, że to problem i wspólnie spróbował podjąć kroki by temu zapobiegać

Najbardziej zaniepokojoną osoba w tej sytuacji powinien być PO, bo nie wie co odbiera.

Zdecydowanie tak - właśnie z PO mam rozmawiać w poniedziałek o sytuacji w tym zespole, którego też jestem częścią :)

pozdrawiam
MichałMichał Kisza edytował(a) ten post dnia 14.11.10 o godzinie 00:22

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

Michał Kisza:
Co do Twoich pytań:

- Co na to testerzy w tym zespole? Nie czują się zaniepokojeni?

Aktualnie w tym zespole jest tylko jeden tester który skupia się na:
1. klikaniu w interfejs i sprawdzaniu czy wszystko jest ok
2. tworzeniem automatycznych testów GUI (ja bym od tego nie zaczynał ale to pomysł kierownictwa. Jak wiadomo szef ma zawsze rację, a jak aplikacja "sama się klika" to fajnie to wygląda dla innych)

Automatyzacja i Continuous Integration są obowiązkowe w agile. Aczkolwiek w sytuacji gdzie te testy ma pisać niedoświadczony tester, który na dodatek jest jedynym testerem z zespole wartość dodana jego pracy będzie mała. Przecież się nie sklonuje.

3. rozpoczyna powoli przygodę z pisaniem testów akceptacyjnych w FitNesse (przekonaliśmy kierownictwo, że to dobra droga przynajmniej dla części tworzonych rozwiązań)
4. na dodatek jest osobą dopiero zdobywający doświadczenie (również pomysł kierownictwa)

Jeden niedoświadczony tester ze stosem zadań przypada na ilu programistów?

Resztę testów (jednostkowe i częściowo akceptacyjne) wykonują programiści.

Jednostkowe jak najbardziej są ich domeną, ale akceptacyjne? To dosyć niebezpieczne. Deweloperzy "wiedzą" jak działa aplikacja, więc zrobią happy path testing. Taka natura ludzka.

Włączanie niedoświadczonych ludzi w pojedynkę do zespołów Scrum jest kiepskim pomysłem. Oni mają mieć wszystkie umiejętności pozwalające na dostarczenie potencially shipable increment, a nie się uczyć ich w trakcie.

Trudno mi więc odpowiedzieć na Twoje pytanie.

Niedoświadczony tester może nie wiedzieć, ze ta sytuacja powinna go zaniepokoić.

- Jak wygląda Agile Wall tego zespołu? Jakie etapy są na niej wydzielone?

Jeśli dobrze zrozumiałem chodzi o stany elementów backloga podczas ich zamiany w działające oprogramowanie - są cztery:

1. Future (praca jest przygotowana, element backlogu spełnia Definition of Ready, wiemy że będziemy to robić)
2. In Progress (zespół aktualnie pracuje nad danym elementem, w tym tester rozpoczyna swoje testy na tym co oddają mu programiści)
3. Done (programiści wykonali funkcjonalność zgodnie z zebraną akceptacją, wykonana praca jest zintegrowana z istniejącą bazą kodu)
4. Accepted (tester dopina testy, całość gotowa jest do wdrożenia jak tylko klient dokona akceptacji)

Chyba pierwszy raz widzę konfigurację, gdzie DONE nie jest ostatnim krokiem. Osiągniecie definicji DONE jest celem każdego taska i PBI. Poza tym jak można "dopinać testy" po osiągnięciu stanu DONE? Przecież to jest nielogiczne. Założę się, że są sytuacje gdzie PBI są w Done, tester nie ma czasu i programiści odklikają ten etap do Accepted, bo "jak ostatnio patrzyłem to działało, więc jest ok".

Proponuję zamienić kolumny miejscami i jeżeli nie zostały wykonane testy akceptacyjne, PBI i taski zostają w Testing albo Acceptance. To zwróci uwagę na testy.

Ken na video podlinkowanym przez Ciebie wyraźnie mówi: DONE = No work left to be done

Problemy są związane z krokiem trzecim - obecnie podstawą do uznania elementu za wykonany jest zebrana akceptacja (czasami niestety niepełna) oraz "wyczucie" programisty, który "dokańcza" dany element backloga (przez wyczucie rozumiem np. decyzję danego programisty czy pisać testy, czy trzymać się standardów, czy refaktoryzować etc.) Nie specjalnie czuję, aby komuś chciało się to zmienić.

Rozwiń proszę: "zebrana akceptacja" i "decyzję danego programisty czy pisać testy, czy trzymać się standardów, czy refaktoryzować etc.".

Zgadza się - natomiast ćwiczenie ma pokazać, że są różnice w rozumieniu co to znaczy, że coś jest skończone. Mój pomysł polega na tym by zespół zrozumiał, że to problem i wspólnie spróbował podjąć kroki by temu zapobiegać

Nie przekonasz tego zespołu, żeby mieli dobrą definicję DONE, bo inne Zespoły mają.

Zdecydowanie tak - właśnie z PO mam rozmawiać w poniedziałek o sytuacji w tym zespole, którego też jestem częścią :)

Naucz PO zwracać uwage na Acceptance Criteria i pytać "Jak to zostało przetestowane?".

BTW Dzięki za video.Krystian K. edytował(a) ten post dnia 14.11.10 o godzinie 11:59

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

http://www.youtube.com/watch?v=-MZdKaqY6wU&NR=1

Od 09:07 jest poruszony ten temat.Krystian K. edytował(a) ten post dnia 14.11.10 o godzinie 12:57

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

Myślę, że trochę odchodzimy od tego o co pytałem - o własne doświadczenia z przekonywaniem zespołów, które bez entuzjazmu podchodzą do pewnych spraw (tutaj do kryterium ukończenia), o propozycję które mógłbym rozwinąć i wypróbować - szukam czegoś o czym nie pomyślałem :)

Zdaję sobie sprawę, że znajomość sposobu pracy zespołu o którym mówię oraz sytuacji w której się znajduje byłaby pomocna, natomiast nie jestem w stanie opisać wszystkiego w tym wątku w sensowny sposób :)

Z kwestii które poruszyłeś widzę, że rozumiem to tak samo jak Ty. Nie wspomniałem tylko, że zespół, który będę chciał przekonać nie pracuje w pełni zgodnie ze SCRUM-em. Raczej jest to pewien zwinny proces, pośredni etap przed przejściem na SCRUM-a (co jak wszyscy wiemy nie jest takie proste).

Od razu wyjaśniam - nie chodzi o robienie SCRUMBut tylko o to, że organizacja która mocno tkwiła w waterfall-u nie może przeskoczyć od razu w tworzenie oprogramowanie zgodnie ze SCRUMem (nawyki-również myślowe, istniejąca baza kodu, etc.).
SCRUM Guide dopuszcza taką możliwość - wiemy dlaczego to robimy, wiemy co trzeba poprawić/zmienić, robimy ale to trwa. Najważniejsze kryterium jest spełnione - dostarczamy działające oprogramowanie po każdej iteracji, tylko czasem coś wypływa przy wdrożeniu (ktoś nie pomyślał, że dana rzecz też jest częścią DONE w odniesieniu do danego elementu backloga).

Co do Twojej odpowiedzi to mam kilka krótkich uwag:

Krystian K.:
Aczkolwiek w sytuacji gdzie te testy ma pisać niedoświadczony tester, który na dodatek jest jedynym testerem z zespole wartość dodana jego pracy będzie mała. Przecież się nie sklonuje.
...
Jeden niedoświadczony tester ze stosem zadań przypada na ilu programistów?
...
Jednostkowe jak najbardziej są ich domeną, ale akceptacyjne? To dosyć niebezpieczne. Deweloperzy "wiedzą" jak działa aplikacja, więc zrobią happy path testing. Taka natura ludzka.

Włączanie niedoświadczonych ludzi w pojedynkę do zespołów Scrum jest kiepskim pomysłem. Oni mają mieć wszystkie umiejętności pozwalające na dostarczenie potencially shipable increment, a nie się uczyć ich w trakcie.

>

Niedoświadczony tester może nie wiedzieć, ze ta sytuacja powinna go zaniepokoić.

True, True - natomiast pamiętajmy, że nie zawsze mamy wszystko co chcemy. Organizacja ma taką a nie inną politykę, szef ma takie a nie inne zdanie mimo argumentacji, więc jedyne co możemy... to zrobić najlepszy użytek z tego co mamy by dostarczyć klientowi najlepszy możliwy produkt w najkrótszym możliwym czasie - to jest w moim zrozumieniu self-organizing.

Zgodzę się, że jest pewne niebezpieczeństwo jeśli programiści wykonują testy (poza jednostkowymi). Natomiast czasami nawet muszą.
Patrząc od strony oczekiwanego rezultatu danego sprintu, role w zespole się zmieniają - zespół ma dostarczyć działający inkrement.
Od razu wyjaśniam - nie jestem naiwny - programista nie będzie tak dobry jak tester, natomiast nie oznacza to, że nie jest w stanie wykonywać takiej pracy jeśli rzeczywiście jest taka potrzeba.

Z ciekawych rzeczy... polecam "Google TechTalks - Agile Testing" na YouTube jeśli ktoś nie widział

http://www.youtube.com/watch?v=bqrOnIECCSg

Krystian K.:
Chyba pierwszy raz widzę konfigurację, gdzie DONE nie jest ostatnim krokiem. Osiągniecie definicji DONE jest celem każdego taska i PBI. Poza tym jak można "dopinać testy" po osiągnięciu stanu DONE? Przecież to jest nielogiczne. Założę się, że są sytuacje gdzie PBI są w Done, tester nie ma czasu i programiści odklikają ten etap do Accepted, bo "jak ostatnio patrzyłem to działało, więc jest ok".

Proponuję zamienić kolumny miejscami i jeżeli nie zostały wykonane testy akceptacyjne, PBI i taski zostają w Testing albo Acceptance. To zwróci uwagę na testy.

Nie widzę tutaj niezgodności - raczej pewne niezrozumienie.
DONE = NO WORK REMAINING - jasne. W odniesienie do tego co napisałem na DONE składają się te wszystkie 4 kroki - po prostu narzędzie którego używamy ma takie stany elementów i to Cię zmyliło.

Krystian K.:
Rozwiń proszę: "zebrana akceptacja" i "decyzję danego programisty czy pisać testy, czy trzymać się standardów, czy refaktoryzować etc.".

Przez "zebrana akceptacja" rozumiem zebrane wspólnie z klientem testy akceptacyjne. Mówiąc w odniesieniu do opowieści użytkownika (User Stories) to co wpisujesz na odwrocie i jest dla Ciebie wskazówką, kiedy wykonana funkcjonalność to jest to czego potrzebuje klient.

Przez "decyzję danego programisty..." rozumiem sytuację, kiedy firma nie ma (jeszcze) polityki dotyczącej tego czy pisać testy czy nie, stosować dane praktyki i wzorce czy nie, przestrzegać danych konwencji nazewniczych czy nie, etc. Decyzja pozostawiona jest programistom lub konkretnym zespołom, natomiast nie ma przymusu - wiemy, że to słabo działa i próbujemy to z niektórymi kolegami zmienić. W tym temacie idziemy w dobrą stronę, natomiast teraz jest jak jest.

Dzięki Krystian za poświęcony czas
pozdrawiam
Michał

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

Nie wiem, czy to pomoże, ale...
W jednym z ostatnich moich projektów jeden ze składników wynagrodzenia programistów zależał od dostarczonej i zaakceptowanej przez klienta funkcjonalności. Ponieważ mieliśmy zarówno klientów wewnętrznych jak i zewnętrznych, to:
- w przypadku tych pierwszych była brana pod uwagę ustalona wartość funkcjonalna oprogramowania w pewnych umownych jednostkach
- w przypadku klientów zewnętrznych wystawiona FV za wykonane prace

W tym układzie wszystkim stronom zależało na jasnym, jednoznacznym określeniu kryteriów akceptacji dla poszczególnych funkcjonalności.

Jest to niestety metoda kija i marchewki, jednak dopóki zespół sam nie dojrzeje do stosowania pewnych mechanizmów, nie wykształci w sobie czegoś, co ja nazywam świadomością biznnesową, powinna być skuteczna.

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

Tutaj jest ciekawa definicja:
http://www.brepettis.com/blog/2009/3/3/the-cult-of-don...

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

Michał Kisza:
Myślę, że trochę odchodzimy od tego o co pytałem - o własne doświadczenia z przekonywaniem zespołów, które bez entuzjazmu podchodzą do pewnych spraw (tutaj do kryterium ukończenia), o propozycję które mógłbym rozwinąć i wypróbować - szukam czegoś o czym nie pomyślałem :)

Zdaję sobie sprawę, że znajomość sposobu pracy zespołu o którym mówię oraz sytuacji w której się znajduje byłaby pomocna, natomiast nie jestem w stanie opisać wszystkiego w tym wątku w sensowny sposób :)

Z kwestii które poruszyłeś widzę, że rozumiem to tak samo jak Ty. Nie wspomniałem tylko, że zespół, który będę chciał przekonać nie pracuje w pełni zgodnie ze SCRUM-em. Raczej jest to pewien zwinny proces, pośredni etap przed przejściem na SCRUM-a (co jak wszyscy wiemy nie jest takie proste).

Od razu wyjaśniam - nie chodzi o robienie SCRUMBut tylko o to, że organizacja która mocno tkwiła w waterfall-u nie może przeskoczyć od razu w tworzenie oprogramowanie zgodnie ze SCRUMem (nawyki-również myślowe, istniejąca baza kodu, etc.).
SCRUM Guide dopuszcza taką możliwość - wiemy dlaczego to robimy, wiemy co trzeba poprawić/zmienić, robimy ale to trwa. Najważniejsze kryterium jest spełnione - dostarczamy działające oprogramowanie po każdej iteracji, tylko czasem coś wypływa przy wdrożeniu (ktoś nie pomyślał, że dana rzecz też jest częścią DONE w odniesieniu do danego elementu backloga).

Działające może tak, ale gotowe do wdrożenia to już nie.
Tja :) We have Scrum but sometimes we have issues with release because we don't have good Acceptance Criteria and definition of DONE.

Pasuje do wzorca?

True, True - natomiast pamiętajmy, że nie zawsze mamy wszystko co chcemy.

Piękna wymówka. Można też spróbować "nie żyjemy w idelanym świecie". Przecież nie musicie nic kupować, inwestować w sprzęt czy oprogramowanie. Wystarczy zmienić nastawienie, zrobić workshop, znaleźć przyczyny i je usunąć. Inspect and addapt.

Organizacja ma taką a nie inną politykę, szef ma takie a nie inne zdanie mimo argumentacji, więc jedyne co możemy... to zrobić najlepszy użytek z tego co mamy by dostarczyć klientowi najlepszy możliwy produkt w najkrótszym możliwym czasie - to jest w moim zrozumieniu self-organizing.

No to jak organizacja nie chce się zmienić i nie ma wsparcia ze strony kierownictwa, to tak jak ken mówił, jest to jak zaproszenie teściowej do mieszkania z młodym małżeństwem.

Wszystko Wam powytyka i jeżeli nie zmienicie organizacji, to nie ma sensu się męczyć.

Zgodzę się, że jest pewne niebezpieczeństwo jeśli programiści wykonują testy (poza jednostkowymi). Natomiast czasami nawet muszą.

Jest coś co powoduje tą sytuację i to coś jest prawdziwym problemem. Nie ma przyczyny - problem znika.

Patrząc od strony oczekiwanego rezultatu danego sprintu, role w zespole się zmieniają - zespół ma dostarczyć działający inkrement.

Nie tylko działający, ale też przetestowany i zintegrowany, gotowy do wdrożenia. Potentially Deliverable increment to nie jest Potentially Working increment.

Od razu wyjaśniam - nie jestem naiwny - programista nie będzie tak dobry jak tester, natomiast nie oznacza to, że nie jest w stanie wykonywać takiej pracy jeśli rzeczywiście jest taka potrzeba.

Tester pewnie tez może programować, tylko takich propozycji nikt o dziwo nie składa. :)

Nie widzę tutaj niezgodności - raczej pewne niezrozumienie.
DONE = NO WORK REMAINING - jasne. W odniesienie do tego co napisałem na DONE składają się te wszystkie 4 kroki - po prostu narzędzie którego używamy ma takie stany elementów i to Cię zmyliło.

Oj nie. Zmylił mnie Twój opis:

Accepted (tester dopina testy, całość gotowa jest do wdrożenia jak tylko klient dokona akceptacji)

Jak "tester dopina testy", jak coś jest DONE? "dopinanie testów" to jest work remaining, więc po tym jeszcze potrzebujecie DONE DONE ;)

Przez "zebrana akceptacja" rozumiem zebrane wspólnie z klientem testy akceptacyjne. Mówiąc w odniesieniu do opowieści użytkownika (User Stories) to co wpisujesz na odwrocie i jest dla Ciebie wskazówką, kiedy wykonana funkcjonalność to jest to czego potrzebuje klient.

To powinno być zrobione przed albo w trakcie Palnning Meeting. Inaczej wyjdą później rzeczy, których się nikt nie spodziewa. Może nawet te problemy przy wdrożeniu, o których wspomniałeś.

Przez "decyzję danego programisty..." rozumiem sytuację, kiedy firma nie ma (jeszcze) polityki dotyczącej tego czy pisać testy czy nie, stosować dane praktyki i wzorce czy nie, przestrzegać danych konwencji nazewniczych czy nie, etc. Decyzja pozostawiona jest programistom lub konkretnym zespołom, natomiast nie ma przymusu - wiemy, że to słabo działa i próbujemy to z niektórymi kolegami zmienić. W tym temacie idziemy w dobrą stronę, natomiast teraz jest jak jest.

Czyli firma nie jest gotowa na zmianę, ale chce mieć naklejkę Agile. To tak nie działa i zdecydowanie na należy takiej praktyki popierać czy też usprawiedliwiać.

I nie dziw się, że nie dostałeś odpowiedzi na pierwotnie postawione pytanie, bo to co napisałeś w pierwszym poście okazuje się jednym ze skutków a nie główną przyczyną. Stary Opel Kadet z naklejką turbo czy Deluxe nadal jedzie tak samo.

Ostatniej zimy wpadłem samochodem w poślizg na śniegu. Na nastepny dzien pojechałem do dealera i zarządząłem natychmiastowego przeglądu układu DSTC (antypoślizgowy), bo przecież nie zadziałał i to na pewno jego wina. Mechanicy powiedzieli, że najpierw sprawdzą inne rzeczy. Stwierdzili, że na początek, to możebym zmienił opony z tłu, bo sa prawie łyse. Zmieniliśmy opony, pojechaliśmy na jazdę próbną na parking pokryty lodem i śniegiem. I wiesz co? DSTC działało jak trzeba i nie zarzucało mi tyłu. Jakbym upierał się przy przeglądzie układu, to pewnie by wyszło, że jest ok, a ja bym znowu wpadł w poślizg.Krystian K. edytował(a) ten post dnia 15.11.10 o godzinie 15:58

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

Paweł S.:
Nie wiem, czy to pomoże, ale...
W jednym z ostatnich moich projektów jeden ze składników wynagrodzenia programistów zależał od dostarczonej i zaakceptowanej przez klienta funkcjonalności. Ponieważ mieliśmy zarówno klientów wewnętrznych jak i zewnętrznych, to:
- w przypadku tych pierwszych była brana pod uwagę ustalona wartość funkcjonalna oprogramowania w pewnych umownych jednostkach
- w przypadku klientów zewnętrznych wystawiona FV za wykonane prace

W tym układzie wszystkim stronom zależało na jasnym, jednoznacznym określeniu kryteriów akceptacji dla poszczególnych funkcjonalności.

Jest to niestety metoda kija i marchewki, jednak dopóki zespół sam nie dojrzeje do stosowania pewnych mechanizmów, nie wykształci w sobie czegoś, co ja nazywam świadomością biznnesową, powinna być skuteczna.

Można zamiast kar finansowych zrobić coś łatwiejszego do zaimplementowania. Wynik Sprintu może zostać odrzucony przez PO i velocity za ten Sprint jest 0. Wyrzucamy kod i piszemy go od nowa.
To powinno być równie bolesne dla Teamu i nie wymaga decyzji na poziomie HR itd.

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

Krystian K.:

Wynik Sprintu może zostać odrzucony przez PO i velocity za ten Sprint jest 0. Wyrzucamy kod i piszemy go od nowa.

Z tego co zrozumiałem z początku wątku, to PO także nie przedstawił żadnych DoD, więc de facto musi wierzyć programistom na słowo, że wszystko działa.
Ja widzę tutaj bardziej problem PO, który daje zadania bez DoD, a nie samego zespołu. Jak PO ma odebrać kod, skoro nie określił, czego oczekuje.

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

Krystian K.:

Paweł S.:
Nie wiem, czy to pomoże, ale...
W jednym z ostatnich moich projektów jeden ze składników wynagrodzenia programistów zależał od dostarczonej i zaakceptowanej przez klienta funkcjonalności. Ponieważ mieliśmy zarówno klientów wewnętrznych jak i zewnętrznych, to:
- w przypadku tych pierwszych była brana pod uwagę ustalona wartość funkcjonalna oprogramowania w pewnych umownych jednostkach
- w przypadku klientów zewnętrznych wystawiona FV za wykonane prace

W tym układzie wszystkim stronom zależało na jasnym, jednoznacznym określeniu kryteriów akceptacji dla poszczególnych funkcjonalności.

Jest to niestety metoda kija i marchewki, jednak dopóki zespół sam nie dojrzeje do stosowania pewnych mechanizmów, nie wykształci w sobie czegoś, co ja nazywam świadomością biznnesową, powinna być skuteczna.

Można zamiast kar finansowych zrobić coś łatwiejszego do zaimplementowania. Wynik Sprintu może zostać odrzucony przez PO i velocity za ten Sprint jest 0. Wyrzucamy kod i piszemy go od nowa.
To powinno być równie bolesne dla Teamu i nie wymaga decyzji na poziomie HR itd.

A tam od razu kar. Premia (a o tym czynniku pensji tu mówimy) jest nagrodą :-)

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

Krystian - generalnie czuję się trochę "zjechany" tym co napisałeś ;-). Wszystko byłoby fajnie tylko nie zapominajmy, że nikt nie ma monopolu na wiedzę.

Łatwo wytykać innym ich niedociągnięcia tu i tam, szczególnie nie znając danej firmy ani powodów takich a nie innych decyzji - co?

Trochę ten wątek poszedł nie w tym kierunku w którym powinien.

Krystian K.:
Działające może tak, ale gotowe do wdrożenia to już nie.
Tja :) We have Scrum but sometimes we have issues with release because we don't have good Acceptance Criteria and definition of DONE.

Pasuje do wzorca?

Nie - pasowałoby do wzorca gdybyśmy z definicji zmieniali SCRUMa w coś z czym nam jest łatwo i wygodnie, a potem nazwali to SCRUMem. Tak tylko po to by się pochwalić, że mamy "SCRUMa" i jesteśmy przez to "zajebiści" w tym co robimy. Myślenie na poziomie folderu reklamowego nie ma miejsca w tym przypadku.

Krystian K.:
Piękna wymówka. Można też spróbować "nie żyjemy w idelanym świecie". Przecież nie musicie nic kupować, inwestować w sprzęt czy oprogramowanie. Wystarczy zmienić nastawienie, zrobić workshop, znaleźć przyczyny i je usunąć. Inspect and addapt.

Wiesz, jak już odwołujemy się do autorytetów - sam Ken Schwaber powiedział, że niektórym organizacjom zmiany zajmują nawet 2 lata i są bolesne.
Z Twojej wypowiedzi wynika, że zmiany dzieją się w sposób natychmiastowy. Jeśli w organizacji w której pracujesz zmiany o których piszesz dokonały się w... minutę, może dwie to pogratulować miejsca pracy - tylko jakoś nie pasuje do porównania, którego używa Ken w odniesieniu do nauki SCRUMa (jest jak nauka gry w szachy)

Krystian K.:

Organizacja ma taką a nie inną politykę, szef ma takie a nie inne zdanie mimo argumentacji, więc jedyne co możemy... to zrobić najlepszy użytek z tego co mamy by dostarczyć klientowi najlepszy możliwy produkt w najkrótszym możliwym czasie - to jest w moim zrozumieniu self-organizing.

No to jak organizacja nie chce się zmienić i nie ma wsparcia ze strony kierownictwa, to tak jak ken mówił, jest to jak zaproszenie teściowej do mieszkania z młodym małżeństwem.

>

Wszystko Wam powytyka i jeżeli nie zmienicie organizacji, to nie ma sensu się męczyć.

Skąd wnioskujesz że nie chce?. Łatwo powiedzieć - trudniej zrobić, szczególnie jeśli chodzi o nawyki. Organizacja się zmienia, ale to jest proces, również w zakresie przekonywania kierownictwa. Nie zawsze najlepszym rozwiązaniem jest zabrać "swoje zabawki" i pójść do pracy gdzieś indziej bo jest "pod górkę".

Krystian K.:

Zgodzę się, że jest pewne niebezpieczeństwo jeśli programiści wykonują testy (poza jednostkowymi). Natomiast czasami nawet muszą.

Jest coś co powoduje tą sytuację i to coś jest prawdziwym problemem. Nie ma przyczyny - problem znika.

Patrząc od strony oczekiwanego rezultatu danego sprintu, role w zespole się zmieniają - zespół ma dostarczyć działający inkrement.

Nie tylko działający, ale też przetestowany i zintegrowany, gotowy do wdrożenia. Potentially Deliverable increment to nie jest Potentially Working increment.

Kolejne Twoje założenie, że nie rozumiemy różnicy. Wiesz mogę wymienić jeszcze z 10-15 rzeczy, które powinny być zrobione w ramach Definition of Done dla funkcjonalności którą realizujemy. Chce się powiedzieć - powiedz mi coś czego nie wiem.

Od razu wyjaśniam - nie jestem naiwny - programista nie będzie tak dobry jak tester, natomiast nie oznacza to, że nie jest w stanie wykonywać takiej pracy jeśli rzeczywiście jest taka potrzeba.

Tester pewnie tez może programować, tylko takich propozycji nikt o dziwo nie składa. :)

Jasne - tester siedzi w osobnym budynku, ogrodzony drutem kolczastym, etc. Tak było w waterfallu - w Agile mówi się wiele o interdyscyplinarności zespołów i pracy zespołowej, w SCRUMie nie jest inaczej. Nikt nie mówi o zastępowaniu programistów we wszystkich obszarach i odwrotnie. Mówię tylko, że czasami w pewnych obszarach jest to możliwe - tyle. O szczegóły możemy się spierać w innym wątku :)

Krystian K.:
Jak "tester dopina testy", jak coś jest DONE? "dopinanie testów" to jest work remaining, więc po tym jeszcze potrzebujecie DONE DONE ;)

Nadal myślę, że nie zrozumiałeś i czepiasz się słów, a ja nie chcę zanudzać innych szczegółowym opisem tego, jak to dokładnie wygląda.

Krystian K.:

Przez "zebrana akceptacja" rozumiem zebrane wspólnie z klientem testy akceptacyjne. Mówiąc w odniesieniu do opowieści użytkownika (User Stories) to co wpisujesz na odwrocie i jest dla Ciebie wskazówką, kiedy wykonana funkcjonalność to jest to czego potrzebuje klient.

To powinno być zrobione przed albo w trakcie Palnning Meeting. Inaczej wyjdą później rzeczy, których się nikt nie spodziewa. Może nawet te problemy przy wdrożeniu, o których wspomniałeś.

Zgadam się:
- powinno być zebrane wcześniej, co nie oznacza że w trakcie realizacji nie wychodzą nowe rzeczy.
- problemy wychodzą i bardzo dobrze. Jest to pewną nauczką dla zespołu, który który widzi że pewne rozwiązania są dla nich dobre (np. jasne kryterium ukończenia).

Krystian K.:
Czyli firma nie jest gotowa na zmianę, ale chce mieć naklejkę Agile. To tak nie działa i zdecydowanie na należy takiej praktyki popierać czy też usprawiedliwiać.

I nie dziw się, że nie dostałeś odpowiedzi na pierwotnie postawione pytanie, bo to co napisałeś w pierwszym poście okazuje się jednym ze skutków a nie główną przyczyną. Stary Opel Kadet z naklejką turbo czy Deluxe nadal jedzie tak samo.

W świecie, który opisujesz wszyscy zainteresowani zgadzają się ze wszystkim co niesie ze sobą podejście zwinne od razu, bez przekonywania i potrzeby podawania przykładów. W rzeczywistości tak nie jest. Świadczy o tym dla przykładu liczba organizacji, które mają problem z wdrożeniem SCRUMa.

Ostatniej zimy wpadłem samochodem w poślizg na śniegu. Na nastepny dzien pojechałem do dealera i zarządząłem natychmiastowego przeglądu układu DSTC (antypoślizgowy), bo przecież nie zadziałał i to na pewno jego wina. Mechanicy powiedzieli, że najpierw sprawdzą inne rzeczy. Stwierdzili, że na początek, to możebym zmienił opony z tłu, bo sa prawie łyse. Zmieniliśmy opony, pojechaliśmy na jazdę próbną na parking pokryty lodem i śniegiem. I wiesz co? DSTC działało jak trzeba i nie zarzucało mi tyłu. Jakbym upierał się przy przeglądzie układu, to pewnie by wyszło, że jest ok, a ja bym znowu wpadł w poślizg.

Powiem tylko jedno - cieszę się, że nie skończyło się wypadkiem. Jestem przekonany, że tej zimy będzie mniej poślizgów z Twoim udziałem ;-).

Co do pytania od którego wątek się zaczął, to spotkanie z zespołem odbyło się dzisiaj, zobaczyli problem i chcą go rozwiązać - powstanie jawne kryterium ukończenia.

Dzięki za wskazówki
pozdrawiam
MichałMichał Kisza edytował(a) ten post dnia 15.11.10 o godzinie 20:13

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

Mateusz Witański:
Z tego co zrozumiałem z początku wątku, to PO także nie przedstawił żadnych DoD, więc de facto musi wierzyć programistom na słowo, że wszystko działa.
Ja widzę tutaj bardziej problem PO, który daje zadania bez DoD, a nie samego zespołu. Jak PO ma odebrać kod, skoro nie określił, czego oczekuje.

Może nie do końca jasno się wyraziłem.

PO określa czego oczekuje - poprzez testy akceptacyjne, spotkania na których dyskutujemy o tym czego dokładnie potrzebuje w budowanej funkcjonalności. Ostatecznie, PO otrzymuje efekt prac zespołu (pod koniec iteracji), który jest sprawdzany przez przedstawicieli docelowych użytkowników. Jeśli wszystko według nich jest ok, to decyzją PO, kolejny inkrement jest wdrażany (jeśli stanowi wystarczającą wartość biznesową). Myślę, że to jest wystarczające by wiedzieć czego dokładnie potrzebuje klient i mu to zapewnić.

Z drugiej strony, pamiętajmy o tym, że jest kilka rzeczy na których PO niekoniecznie musi się znać, a które powinny wejść w skład kryterium ukończenia (np. związane z budową kodu - jakość, standardy, pokrycie kodu testami czy też konwencje nazewnicze. Oczywiście wszystko zależy od specyfiki projektu) W tym przypadku PO ufa, że ma ludzi którzy znają się na swoje profesji i dopilnują, że to co zrobią będzie zgodne ze sztuką.

Problem polegał na tym, że istniała pewna niezgodność w zrozumieniu tych rzeczy przez developerów, co powodowało pewne problemy związane raczej z wnętrzem systemu. Stąd pomysł by wnioski czy coś jest zrobione czy nie opierać nie na samej akceptacji tylko na kryterium ukończenia, które oprócz akceptacji będzie zawierać pewne dodatkowe, istotne elementy.

Wracając do początku wątku - poszukiwałem pomysłów, jak skutecznie uświadomić zespołowi, że chce takiego kryterium :)

Pozdrawiam
MichałMichał Kisza edytował(a) ten post dnia 15.11.10 o godzinie 20:45

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

Niedawno miałem przypadek, gdzie nowy programista musiał "wgryźć" się w kod pisany przez zespół prawie 10 lat. Miał z tym problemy głównie z powodów, o których piszesz.
Moim zdaniem najlepiej byłoby zrobić jedną z trzech rzeczy:
1. testy danego fragmentu kodu przekazać innemu programiście
2. dać do napisania dokumentację do fragmentu kodu pisanego przez innego członka zespołu
3. w kolejnych iteracjach starać się tak przydzielać zadania, żeby każdy musiał korzystać z wcześniej napisanego kodu innego członka zespołu
Wydaje się, że wtedy zespół wewnątrz dojdzie do porozumienia, jaki kod pozostawić po sobie - szczególnie gdy brak zaangażowania w budowę kodu będzie odczuwalny dla wszystkich.
Pozdrawiam

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

Mateusz Witański:
Moim zdaniem najlepiej byłoby zrobić jedną z trzech rzeczy:
1. testy danego fragmentu kodu przekazać innemu programiście
2. dać do napisania dokumentację do fragmentu kodu pisanego przez innego członka zespołu
3. w kolejnych iteracjach starać się tak przydzielać zadania, żeby każdy musiał korzystać z wcześniej napisanego kodu innego członka zespołu
Wydaje się, że wtedy zespół wewnątrz dojdzie do porozumienia, jaki kod pozostawić po sobie - szczególnie gdy brak zaangażowania w budowę kodu będzie odczuwalny dla wszystkich.
Pozdrawiam

W dowolnym smaczku Agile nie ma czegoś takiego jak własność kodu. Każdy jest właścicielem całego kodu.
Programiści dogadują się co do stylu i wprowadza się automatyczne narzędzie do weryfikacji tego stylu np. checkstyle dla Java. Błędy w stylu muszą być poprawione tak jak inne.
Do tego Pair Programming.

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

Michał Kisza:
Krystian - generalnie czuję się trochę "zjechany" tym co napisałeś ;-). Wszystko byłoby fajnie tylko nie zapominajmy, że nikt nie ma monopolu na wiedzę.

Łatwo wytykać innym ich niedociągnięcia tu i tam, szczególnie nie znając danej firmy ani powodów takich a nie innych decyzji - co?

Trochę ten wątek poszedł nie w tym kierunku w którym powinien.

Po co bierzesz to osobiście? Piszemy o Tobie czy o firmie i sytuacji? Nie rób prywatnej krucjaty z tego wątku. Odpisałeś emocjonalnie, przekręcając moje odpowiedzi.

Odpisuje tylko na to co Ty piszesz. Oczywiście, że całej sytuacji nie znam. Myślę, że z tego wątku skorzysta dużo więcej osób niż tylko Ty i każda "relacja z pola walki" jest cenna.

Co do pytania od którego wątek się zaczął, to spotkanie z zespołem odbyło się dzisiaj, zobaczyli problem i chcą go rozwiązać - powstanie jawne kryterium ukończenia.

I bardzo dobrze. Gratuluje! :) Napisz czy zadziałało i jak wygląda ta definicja.

Co do tych zmian, które mają trwać latami. To odnosi się to do zmian po wdrożeniu frameworka takim jakim jest a nie o procesie wdrażania. Zmiany zawsze zachodzą i procesy wokół Scrum będą się zmieniały. To normalne. Praktycznie z każdego Sprint Retrospective będą jakieś zmiany do wdrożenia.

Co do mojej firmy, to nie wdrożyliśmy Scruma w całej firmie. Mamy z tego co wiem tylko jeden team. Reszta stwierdziła, że to za trudne i nie działa.

W świecie, o którym pisze, czyli rzeczywistym konflikty i rożne poglądy są naturalne i nie są niczym złym. Wystarczy je zaakceptować i znaleźć sposoby ich rozwiązywania.

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

Krystian K.:

W dowolnym smaczku Agile nie ma czegoś takiego jak własność kodu. Każdy jest właścicielem całego kodu.

Co ta uwaga wnosi do dyskusji?

Programiści dogadują się co do stylu i wprowadza się automatyczne narzędzie do weryfikacji tego stylu np. checkstyle dla Java. Błędy w stylu muszą być poprawione tak jak inne.
Do tego Pair Programming.

Chyba to właśnie nie zadziałało, więc trzeba znaleźć rozwiązanie, a nie rzucać hasła z jakiegoś podręcznika. W teorii wszystko wygląda fantastycznie.

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

Mateusz Witański:

Krystian K.:

W dowolnym smaczku Agile nie ma czegoś takiego jak własność kodu. Każdy jest właścicielem całego kodu.

Co ta uwaga wnosi do dyskusji?

Nie wiem, o co pytasz, wuięc wyjaśnię całość. "Smaczek Agile" = Lean Software Development, Kanban, XP, Scrum i wszystkie inne metody i framaworki w kategorii Agile.

Chyba to właśnie nie zadziałało, więc trzeba znaleźć rozwiązanie, a nie rzucać hasła z jakiegoś podręcznika. W teorii wszystko wygląda fantastycznie.

Nie zadziałało, czy tej praktyki zabrakło?

Wydzielając zadania na podstawie poprzedniego właściciela kodu jest sprzeczne z zasadą, że każdy w Teamie może wziąć dowolne zadanie. Pisanie testów i dokumentacji przez innego programistę wchodzi w konflikt z Test Driven Development.

Metody Agile są empiryczne, a nie teoretyczne. Pewnie, że można wynaleźć koło raz jeszcze, tylko po co marnować czas?Krystian K. edytował(a) ten post dnia 16.11.10 o godzinie 15:09

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

Krystian K.:
Po co bierzesz to osobiście? Piszemy o Tobie czy o firmie i sytuacji? Nie rób prywatnej krucjaty z tego wątku. Odpisałeś emocjonalnie, przekręcając moje odpowiedzi.

Co do przekręcania... to zrozumiałem Twoją wypowiedź tak jak odpisałem. Myślę, że to zadziałało w obie strony :)

Co do emocji i prywatnej krucjaty... to Twoje zdanie (każdy czytający może wyrobić sobie własne).

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.

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).

Krystian K.:
Co do tych zmian, które mają trwać latami. To odnosi się to do zmian po wdrożeniu frameworka takim jakim jest a nie o procesie wdrażania. Zmiany zawsze zachodzą i procesy wokół Scrum będą się zmieniały. To normalne. Praktycznie z każdego Sprint Retrospective będą jakieś zmiany do wdrożenia.

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).

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

Czy aby tak się stało istnieje "jedyna słuszna droga"? - wątpie.

Dzięki za dyskusje
pozdrawiam
MichałMichał Kisza edytował(a) ten post dnia 16.11.10 o godzinie 21:09