GoldenLine
Zaloguj się
Michał Kotarba

Michał Kotarba Główny Analityk,
nazwa.pl

Temat: Monitoring i kontrola w SCRUM

Co w SCRUM jest w miarę efektywne jeżeli chodzi o:

1. Monitorowanie postępu prac w SCRUM
2. Kontrolę efektywności zespołu

?

Z jednej strony jest burndownchart czy velocity, ale nie daje pełnego obrazu. BC zależy od zakresu prac jaki weźmie na klatę zespół i w żaden sposób nie pokazuje jak się to ma do faktycznych możliwości zespołu, a velocity pozwala jedynie zorientować się co do możliwości zespołu ze sprintu na sprint (patrz identyczny problem co z BC). Według tego można ewentualnie sprawdzać sam postęp prac.

Jest może coś bardziej efektywnego, reprezentatywnego? Korzystacie z jakichś konkretnych wskaźników/narzędzi?
Link do wypowiedziLink
Jarosław Cichoń

Jarosław Cichoń Software
Developement
Manager, Misys

Temat: Monitoring i kontrola w SCRUM

Jesli zespol w danym sprincie dostarczyl okreslona ilosc roboty - czy nie jest to wskaznik biezacej efektywnosci zespolu ? (Ew mozna uzyc sredniej z velocity? )

Jesli zespol co sprint robi porzadna retrospekcje , ktora ma w zalozeniach podniesc wydajnosc zespolu - czy mozna zakladac ze potencjalna efektywosc zespolu jest w jakis sposob ograniczona? :)

Wreszcie - wiedzac ze scrum jest 'empirycznym' procesem - czy warto starac sie prognozowac, czy przewidywac potencjalna wydajnosc zespolu? :)

Pozdr,
Jarek
Link do wypowiedziLink
Michał Kotarba

Michał Kotarba Główny Analityk,
nazwa.pl

Temat: Monitoring i kontrola w SCRUM

Oczywiście, że warto. :)

W SCRUM zespoły są autonomiczne, które same określają jaką ilością pracy mogą zająć się w danym sprincie, ile zdołają zrobić. Wiadomo, że ludzie są ludźmi i moga teoretycznie wziąć o wiele mniej niż byliby w stanie zrobić. Wiadomo, że celuję teraz w skrajności, ale dla managmentu jest istotne jak szybko zespoły mogą produkować i czy koszty ponoszone na zespół są kosztami adekwatnymi do możliwych efektów.

Velocity nic tutaj nie pomoże. Zespół szacujący w story pointach może szacować historyjki w odniesieniu do najmniejszego zadania w danym backlogu. Zatem velocity daje nam obraz wydajności zespołu dla danego projektu. Tutaj też oczywiście można sprytnie przysterować tym wskaźnikiem.
Link do wypowiedziLink
Maciej Tafliński

Maciej Tafliński PSPO, Scrum Master

Temat: Monitoring i kontrola w SCRUM

SCRUM powinien opierać się na zaufaniu i przejrzystości. Jeśli istnieją jakieś podejrzenia, że zespół świadomie zaniża swoją velocity, należałoby to jawnie wyświetlić na retrospekcji.
Dla mnie osobiście o wiele gorsza jest nierówna velocity niż niska velocity :) Jeśli nie wiem ile story points zespół zrobi, to nie daje mi to możliwości planowania. Natomiast jeśli jest niskie velocity, to po prostu może nie uda się zrobić najmniej wartościowych elementów w backlogu.

Jeśli są podejrzenia o sterowanie wskaźnikami, to jest temat dla SM i na retrospekcję.
Link do wypowiedziLink
Michał Kotarba

Michał Kotarba Główny Analityk,
nazwa.pl

Temat: Monitoring i kontrola w SCRUM

Czyli rozumiem, że nie ma się zbytnio czym przejmować i obwarowywać się dodatkowymi wskaźnikami. Tak jak napisałem wcześniej, sterowanie przez zespół velocity to skrajność, ale teoretycznie możliwy przypadek.

Dzięki za odpowiedź. W takim wypadku temat chyba dla mnie zamknięty.
Link do wypowiedziLink
Jarosław Cichoń

Jarosław Cichoń Software
Developement
Manager, Misys

Temat: Monitoring i kontrola w SCRUM

To prawda, jesli zespół zaczyna manipulować wskaźnikami SM powinien zareagować od razu lub najpóźniej na retrospekcji. Ale przy okzaji wyszły ciekawe wnioski.
Dlaczego warto przewidywać potencjalna maksymalna celcius zespołu ?
(ano po to zeby sprawdzić czy zespół nie zaniża wydajności - brak zaufania? )
Skad założenie ze zespół bedzie miał tendencje do brania mniej ?
Początkujące zespoły maja tendencje do brania wiecej roboty.
Po pierwszej spektakularnego porażce zespół potrafi wziąć mniej,
ale dlatego zeby dostarczyć całość a nie dlatego zeby wziąć kasę
I sie nie zmeczyc. A nawet wtedy zespoły potrafią dobrać sobie robotę
z backlogu. Może to jest szokujące, ale zespoły nie pracują dla pieniędzy :)
Link do wypowiedziLink
Wiktor Żołnowski

Wiktor Żołnowski Co-founder at
Pragmatic Coders

Temat: Monitoring i kontrola w SCRUM

Przede wszystkim należy podkreślić, że jeśli już chcemy mierzyć w jakiś sposób efektywność zespołu w Scrum to powinniśmy brać pod uwagę cały zespół a nie tylko developerów - PO jest częścią zespołu i od jego pracy również (a w wielu przypadkach głównie) zależą wyniki zespołu.

Jeśli o wskaźniki chodzi to wszelkiego rodzaju wykresy powszechnie stosowane, jak sprint burndown czy burnup, albo project burndown chart zazwyczaj są wystarczające by monitorować postępy prac zespołu.
Oczywiście potrzebne jest pełne zrozumienie tego co dane wykresy oznaczają i co można z nich wyczytać.

Co do manipulowania przy wskaźnikach - z praktyki wynika, że jeśli burndown chart wygląda idealnie to możemy go wyrzucić do kosza.

Velocity można ustalać na różne sposoby (podobnie jak szacować estymaty) - można to np. robić relatywnie - ustalić, że najmniejszy item na backlogu ma 2 a wszytko inne to relatywna wielokrotność, albo zacząć od drugiej strony - zaplanować sprint czy dwa bez estymatów i ustalić, że nasza prędkość to np 30SP, po czym podzielić te punkty pomiędzy itemami w sprintach. W następnej iteracji estymować już relatywnie ale z trochę większą dokładnością - mamy wiecej empirycznej wiedzy na temat tego ile to jest X SP.

Warto się zastanowić co monitorować? Dobrym pomysłem (jak dotąd chyba najlepszym z jakim się spotkałem w praktyce) jest monitorowanie ilości wytwarzanego Bussines Value - każdy item (historyjka na backlogu) oprócz estymaty ma jeszcze określoną w jakichś względnych, abstrakcyjnych punktach BV. W ten sposób możemy maksymalizować zyski i monitorować straty. Oczywiści to jak nadawać historyjką określoną wartość to już inny temat i raczej bardzo zależny od kontekstu. Nie zapominajmy też o długu technologicznym i jego spłacie, która też wnosi BV.

Zgadzam się z przedmówcą - Scrum jest oparty na zaufaniu i przejrzystości. Jeśli nie ma w organizacji kultury wspierającej zaufanie to będzie to poważna przeszkodą w trakcie wdrożenia. No ale od czego są Scrum Masterzy jeśli nie od usuwania przeszkód :).Wiktor Żołnowski edytował(a) ten post dnia 05.03.12 o godzinie 15:33
Link do wypowiedziLink
Paweł Zienkiewicz

Paweł Zienkiewicz Szczecin.
Outsourcing.

Temat: Monitoring i kontrola w SCRUM

Monitorowanie i próba zwiększania efektywności "zarządzeniami" z góry, czyli tzw pressing powoduje, że developerzy automatycznie i liniowo obniżają jakość produktu, który tworzą.

Jeśli jest podejrzenie, że velocity jest zaniżane, to są metody na to, żeby starać się lepiej określać złożność poszczególnych Backlog itemów. Są to np. planning poker. Osoby, które mają skrajne wartości (np długie czasy realizacji) zgodnie z regułami planning pokera muszą wyjaśnić, dlaczego tak pesymistycznie podchodzą do zadania.

PO powinien mieć przynajmniej szczątkową wiedzę na temat złożoności niektórych problemów, ale czasem jego "blondynkowość" (przepraszam za szczyptę szowinizmu) i zadawanie głupich pytań na Sprint Planning Meeting pozwala znaleźć lepsze rozwiązania do realizacji zadań z backlogu.
Link do wypowiedziLink
Michał Kotarba

Michał Kotarba Główny Analityk,
nazwa.pl

Temat: Monitoring i kontrola w SCRUM

Dzięki za uwagi. Każdy punkt widzenia jest dla mnie ważny i cenny. Na dzień dzisiejszy zebrałem kilka ciekawych uwag i widzę, że niewiele jest do zmiany/usprawnienia. Proces wymaga naniesienia tylko drobnych korekt.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Dlaczego scrum działa




Wyślij zaproszenie do
Anuluj