Kryterium Gotowości
Widoczną tendencją w społeczności praktyków i trenerów Scruma jest rosnące docenienie roli Product Ownera. Efektem tego są propozycje praktyk i rozwiązań, które mają usprawnić pracę Product Ownerów. Jedną z nich przedstawiam poniżej.
Po dobrym wdrożeniu Scruma (i innych praktyk agile) w zespołach często występuje efekt „odkurzacza” na backlogu. Polega on na tym, że wraz ze wzrostem efektywności zespołu „czyści” on backlog z zadań powodując, że Product Owner nie nadąża z dobrym definiowaniem odpowiedniej liczby nowych zadań. Kończy się to najczęściej tworzeniem przez Product Ownera zadań naprędce podczas spotkania Planowania Sprintu po to tylko, by zespół miał co robić – by jakoś wypełnić sprint. Oczywiście, takie wymyślone na poczekaniu zadania mają małe szanse być naprawdę wartościowe.
Aby temu zapobiec praktycy Scruma tacy jak Jeff Sutherland czy Serge Beaumont proponują usprawnienie zarządzania backlogiem przez wprowadzenie do Scruma nowej, dodatkowej definicji jakościowej.
Jak wiadomo w każdym projekcie prowadzonym w Scrumie ustala się kryterium ukończenia (ang. definition of done). Określa ono kiedy realizowane zadanie można uznać za wykonane. Jeśli zadanie kryterium tego na końcu sprintu nie spełnia, to niezależnie od tego jak zaawansowane były prace na nim spada ono z powrotem na backlog – nie jest dostarczone.
Najczęściej kryterium ukończenia wyrażone jest mniej więcej tak: „Historyjka użytkownika zaimplementowana, pokryta testami jednostkowymi, zatwierdzona w teście akceptacyjnym, skonsolidowana z resztą projektu, nadająca się do wydania na serwer produkcyjny.”
Innowacja polega na wprowadzeniu analogicznego kryterium na początku sprintu – kryterium gotowości (ang. definition of ready), które określa jakie cechy ma posiadać zadanie aby mogło być wzięte przez zespół „do sprintu” podczas Planowania Sprintu. Zadania nie spełniające tego kryterium nie są brane pod uwagę – nie będą przy planowaniu sprintu rozpatrywane.
Kryterium takie może wyglądać na przykład tak: „Zadanie w pełni zrozumiałe dla zespołu, oszacowane przez zespół, z przygotowanym wstępnym projektem sposobu realizacji, bez otwartych pytań do product ownera”.
Rolę obu kryteriów można porównać do swego rodzaju filtrów. Kryterium ukończenia „odsiewa” nieukończone zadania – określa się je po to, by ustalić pożądaną jakość produktu końcowego. Kryterium gotowości „odsiewa” zadania źle lub niejasno zdefiniowane – określa się je po to, by zespół pracował nad wartościowymi i zrozumiałymi dla niego zadaniami.
Konsekwencją wprowadzenia kryterium gotowości jest pojawienie się różnych stanów (statusów) zadań na backlogu projektu. W najprostszym przypadku będą to przynajmniej dwa stany: zadania „nowe” i „gotowe”. Zadania świeżo wprowadzone na backlog są „nowe”, zadania spełniające kryterium gotowości – „gotowe”. Product Owner stara się doprowadzić zadania do stanu „gotowe”, a więc do tego by spełniały one kryterium gotowości.
Zakłada się, że Product Ownerowi pomaga w tym także i zespół. Dobrą okazją do tego jest oszacowywanie zadań. Niewątpliwie zadania oszacowywać powinien zespół, zarazem, powinno się to odbywać nie tylko podczas spotkań Sprint Planning. W praktyce Scruma zaleca się, aby zespół (wraz z Product Ownerem) poświęcał przynajmniej 5% czasu w sprincie na tak zwaną pielęgnację baclogu. Czas ten można spożytować na dyskusję z Product Ownerem nad najważniejszymi jego zdaniem zadaniami „nowymi” tak, by stały się one dla zespołu na tyle jasne i zrozumiałe, by mógł dokonać ich dobrego oszacowania i uznać je za „gotowe”.
W najprostszym wydaniu proces przechodzenia od zadań „nowych” do „gotowych” wygląda zatem następująco:
- Product Owner umieszcza nowe zadanie na backlogu (w części dla zadań „nowych”).
- Product Owner sortuje zadania “nowe“.
- Zespół oszacowuje pewną liczbę zadań nowych (znajdujących się na szczycie backlogu w części dla zadań „nowych”).
- Jeśli są pytania, wątpliwości – następuje dyskusja z Product Ownerem. Czasem potrzebuje on zwrócić się do interesariuszy by wyjaśnić pewne kwestie, czasem zadanie trzeba rozbić na mniejsze lub zmienić na bardziej zrozumiałe, precyzyjniej określone.
- Zespół oszacowuje zadanie, jest ono oznaczanie jako „gotowe” i przenoszone do właściwego backlogu.
Oczywiście, można sobie wyobrazić więcej kroków prowadzących od „nowe” do „gotowe” zależnie od potrzeb danej organizacji czy projektu. Przykładowo, może istnieć publiczny backlog (tzw. lodówka – ang. „cooler”), gdzie każdy w organizacji może zgłaszać pomysły. Z „lodówki” Product Owner wybiera zadania i przenosi do backlogu dla zadań „nowych”, skąd po wyjaśnieniu i oszacowaniu trafiają na backlog „gotowe”.
W każdym przypadku zaleca się, aby status „gotowe” miało przynajmniej tyle zadań, by przy średniej prędkości (ang. velocity) zespołu wystarczyło ich na około 2 sprinty pracy. Dzięki temu nawet kiedy wystąpi jakieś spowolnienie w „dostawach” nowych zadań zespół będzie w stanie przepracować kolejny sprint robiąc coś sensownego i wartościowego.
Warto zauważyć, że o ile kryterium ukończenia w dużym stopniu wynika z konkretnych uwarunkowań projektu (np. inne będzie dla zespołu pracującego nad aplikacją desktopową, inne dla pracującego nad aplikacjami webowymi) i powinno być określane przy dużym udziale Product Ownera (jeśli nie wprost przez niego), tak kryterium gotowości bardziej zależy od wymagań konkretnego zespołu i powinno być przez ów zespół określane. Ponadto, o ile kryterium ukończenia może się zmieniać w czasie (np. z chwilą przejścia od fazy budowy wewnętrznego prototypu do fazy, w której wyniki pracy trafiają na serwer produkcyjny), o tyle kryterium gotowości jest stabilne.
Ze swojej praktyki mogę dodać, że istotnie często zdarza się, że bałagan wprowadzany przez Product Ownera utrudnia osiągnięcie płynnego przepływu zadań przez zespół, a przez to osiągnięcie przezeń pełnej możliwej wydajności. Zgodnie z założeniami Scruma w każdej chwili można drastycznie zmienić kierunek prac, jednak kiedy zespół jest w kolejnym sprincie zaskakiwany zadaniami, których się nie spodziewał powoduje to spowolnienie jego pracy. Innymi słowy, zmiany kierunku – choć możliwe – kosztują. Dlatego w praktyce jest lepiej jeśli już w czasie bieżącego sprintu zespół wie jakie mniej-więcej zadania czekają go w następnym. Dużo lepsze efekty osiągnie się zatem, jeśli w czasie bieżącego sprintu zespół przeznaczy 5% czasu na wspólne z Product Ownerem oszacowanie i przygotowanie zadań na następne 1-2 sprinty.
Podsumowując, wprowadzenie kryterium gotowości ma na celu poprawę współpracy pomiędzy Product Ownerem (a więc za jego pośrednictwem także i innymi interesariuszami) a zespołem doprowadzając do utworzenia płynnego przepływu zadań (ang. flow) do zespołu. Ponieważ przy takiej organizacji pracy zespół z góry wie jakie zadania czekają go w następnym sprincie praca ma szansę przebiegać płynnie, a co za tym idzie jeszcze bardziej wydajnie. Dlatego właśnie warto poważnie rozważyć wprowadzenie tej praktyki.
Andrzej K. Brandt
Code Sprinters
Scrum Guide po polsku
Zakończyły się prace nad polskim opracowaniem tekstu “Scrum Guide” autorstwa Kena Schwabera i Jeffa Sutherlanda. “Przewodnik po metodyce Scrum”, bo tak nazwany został dokument, dostępny jest pośród innych tłumaczeń na stronie http://www.scrum.org/scrumguides/. Mamy nadzieję, że przyczyni się on do rozpowszechnienia podstawowej wiedzy o Scrumie.
Ostateczny kształt programu certyfikacji
Kwestia wprowadzenia egzaminów na certyfikat Certified Scrum Master była przedmiotem gorących debat w społeczności Scruma, w tym także oczywiście w Scrum Alliance, o których pisaliśmy już wcześniej. Ostatecznie przeważyły argumenty za podniesieniem poprzeczki dla chcących posiadać ten certyfikat i egzamin od 1 października 2009 wprowadzono. Egzamin zdaje się przez Internet odpowiadając na pytania testowe.
Przez pewien czas (na razie mowa jest o końcu roku 2009) wszyscy przystępujący do tego egzaminu będą go zaliczać. Oficjalnie ma to służyć kalibaracji egzaminu. Polega ona na uzyskaniu dużej próby odpowiedzi na kilka zestawów pytań testowych, która pozwolić ustalić odpowiedni poziom poprawnych odpowiedzi, który będzie następnie wymagany aby egzamin zdać. Ponadto będzie można wyeliminować pytania, które nie są dostatecznie jasne i powodują zbyt duży rozrzut odpowiedzi. W tym czasie powstaną także tłumaczenia egzaminu na języki inne niż angielski. Niestety, wśród tych języków nie będzie na razie języka polskiego.
Obecnie zatem sposób uzyskiwania certyfikatu jest następujący:
- osoby kończące z powodzeniem certyfikowane szkolenie CSM są przez trenera zgłaszane do Scrum Alliance,
- otrzymują na e-mail link umożliwiający stworzenie profilu na Scrum Alliance,
- na stronie profilu znajduje się link umożliwiający rozpoczęcie egzaminu,
- egzamin to test wielokrotnego wyboru złożony z 60 pytań, na ukończenie go jest 60 minut (1 minuta na pytanie),
- pytania obejmują takie zagadnienia jak założenia Scruma, spotkania Scrumowe, role oraz narzędzia Scrumowe (np. listy, wykresy) – zakres materiału odpowiada zawartości Scrum Guide (dostępny za darmo na stronach Scrum Alliance),
- po ukończeniu egzaminu na stronie Scrum Alliance można – jak do tej pory – pobrać certyfikat,
- egzamin i certyfikacja są wliczone w cene szkolenia – nie pobiera się dodatkowych opłat.
Certyfikat jest ważny przez dwa lata. Po tym czasie konieczne będzie zdanie egzaminu ponownie oraz wniesienie opłaty (obecnie w wysokosci $150). Obecnie certyfikowani Scrum Masterzy (CSM) będą również musieli zdać opisany egzamin aby utrzymać swój certyfikat. Proces ten dla certyfikowanych przed 1 października 2009 rozpocznie się od kwietnia 2010 poczynając oczywiście od osób posiadających ten certyfikat przez dwa lub więcej lat. Każdy zostanie indywidualnie powiadomiony e-mailem od Scrum Alliance o konieczności zdania egzaminu re-certyfikacyjnego (dlatego m.in. warto upewnić się, że w profilu na stronach Scrum Alliance podany jest aktualny, działający adres e-mail).
Jak już pisaliśmy powyżej obecnie nie planuje się wprowadzenia egzaminów dla CSPO. Wyższe stopnie certyfikacji – CSP i CSC – także będą przyznawane na tych samych zasadach, co obecnie.
Zamieszanie z egzaminem i co z niego wynikło
Około 12 września na stronach Scrum Alliance pojawiło się zawiadomienie, że wprowadzenie egzaminu dla CSM-ów – o którym pisalismy w sierpniu – zostanie odłożone na bliżej nie określoną przyszłość w roku 2010. Uzasadniono to koniecznością przygotowania egzaminu w językach innych niż angielski.
Informacja ta nie zdążyła się jeszcze dobrze rozejść w środowisku zainteresowanych Scrumem (gdzie wywołała zrozumiałe wzburzenie) kiedy zniknęła ze stron Scrum Alliance. Przez jakiś czas nie było wiadomo jakie w końcu jest oficjalne stanowisko a przedstawiciele SA nie udzielali wyjaśnień.
Ostatecznie 21 września pojawił się kolejny plik PDF z informacją o tym, że egzamin zostanie jednak wprowadzony. W ślad za tą wiadomością na stronach Scrum Alliance pojawił się news dodatkowo objaśniający w szczegółach jak wprowadzenie egzaminu będzie wyglądać. Najważniejszą cechą wprowadzanego egzaminu będzie to, że… wszyscy przystępujący do niego będą go automatycznie zdawać!
Następnego dnia ukazała sie informacja, że z dniem 15 września Ken Schwaber złożył rezygnację z kierowania Scrum Alliance jako President and Chair of the Board of Directors of the Scrum Alliance. Rezygnację złożył również Jim Cundiff, dyrektor zarządzający Scrum Alliance. Przewodnictwo Scrum Alliance objął po Kenie Schwaberze Tom Mellor.
Egzamin
Tak więc egzamin zostanie wprowadzony od dnia 1 października 2009, jak uprzednio planowano. Przystąpienie do egzaminu będzie wymagało ukończenia szkolenia CSM (a więc prowadzonego przez certyfikowanego trenera – CST) i jednocześnie trener nadal będzie mógł zadecydować o niedopuszczeniu uczestnika szkolenia do egzaminu (np. z powodu nie pojawieniu się na istotnej części szkolenia).
Podstawą egzaminu będzie krótki dokument Ken Schwabera – Scrum Guide (a nie, jak poprzednio planowano, ogólnie cały zestaw książek o Scrumie). Egzamin będzie występował w 3 wersjach, każda po 60 pytań z ogólnej puli 90 pytań. Przez nieokreślony czas każdy przystępujący będzie “zaliczał” test, a wyniki będą użyte do wybrania ostatecznego zestawu 60 pytań, które będą potem stosowane już w “prawdziwym” egzaminie kiedy zostanie on wprowadzony.
Co więcej, ponieważ egzamin jest wyłącznie po angielsku trenerzy będą zaznaczać wprowadzając uczestników szkolenia czy dana osoba jest w stanie czytać tekst po angielsku. Osoby, które nie znają angielskiego będą otrzymywać certyfikat CSM na dotychczasowych zasadach, a więc nie będą brać udziału w egzaminie. Jak można się spodziewać docelowo będzie dostępny egzamin w różnych językach – przynajmniej tych, którymi mówią aktualnie certyfikowani trenerzy.
Komentarz
Cała sprawa jest dość dziwna. Jak się wydaje rezygnacja Kena Schwabera jest wynikiem właśnie zamieszania wokół egzaminu, a nie ma związku z jego stanem zdrowia po wypadku motocyklowym, któremu uległ w lecie (o czym zresztą w oficjalnym komunikacie nie ma mowy). Co do Jima Cundiffa nie mam najmniejszych wątpliwości co do powodów rezygnacji – ewidentnie poszło o egzamin.
Ale pomijając już kwestię spraw personalnych w Scrum Alliance efekt końcowy nie może cieszyć. Wprowadzenie egzaminu przekładano już dwa razy – i tym razem ponownie de facto nie został on wprowadzony. Zatem zamiast podniesienia poprzeczki dla certyfikatu CSM – i tym samym usunięcia najpoważniejszego zarzutu wobec niego – wprowadzono egzamin tak naprawdę go nie wprowadzając. Uzasadnienie tego brakiem możliwości zdawania egzaminu przez osoby nie czytające tekstu angielskiego z perspektywy polskiej wygląda raczej na wykręt niż na rzeczywisty powód. No i powstaje oczywiste pytanie dlaczego – dajmy na to – Niemiec czy Szwed może mieć szkolenie i egzamin w swoim języku a – powiedzmy – Polak czy Czech nie. Te pytania trzeba będzie Scrum Alliance niewątpliwie zadać.
Tak czy siak pozostaje mieć nadzieję, że Scrum Alliance wprowadzi w końcu egzamin na serio i ureguluje raz na zawsze kwestię języków, o czym oczywiście nie omieszkamy poinformować.
Zmiany w programie certyfikacji
Jednym z zarzutów wobec programu certyfikacji Scrum Alliance była zbytnia łatwość w uzyskiwaniu podstawowych certyfikatów (Certified Scrum Master i Certified Scrum Product Owner) w stosunku do pozostałych poziomów certyfikacji. O ile bowiem w przypadku CSP by nie wspomnieć już o CSC i CST konieczne było udowdnienie w pewien sposób wiedzy i doświadczenia w projektach Scrumowych, o tyle certyfikaty CSM i CSPO dostawali praktycznie wszyscy, którzy wzięli udział w szkoleniu.
Wbrew pozorom udział w szkoleniu nigdy nie był jedynym warunkiem uzyskania certyfikatu. Według obecnych reguł o przyznaniu lub nie certyfikatu uczestnikowi szkolenia decydował trener na podstawie aktywności uczestnika. Ale oczywiście w praktyce b. rzadko zdarzało się, by trener odmówił przyznania certyfikatu (osobiście znam tylko jeden taki przypadek).
Aby podnieść jakość certyfikatu i upewnić się, że uczestnicy szkoleń istotnie mają dobre pojęcie o Scrumie nim dostaną zobowiązujący tytuł CSM Scrum Alliance planuje wprowadzić egzamin. Przygotowania do tego trwają już od dość dawna – w zeszłym roku na Scrum Gathering w Sztokholmie pokazano wersję “beta” egzaminu i zbierano opinie na jego temat. Egzamin miał być wprowadzony od początku roku, z różnych jednak względów termin ten kilkakrotnie przekładano. Ostatecznie egzaminy dla CSM i CSPO wchodzą od 1 października 2009.
Od tego dnia uczestnictwo w certyfikowanym (prowadzonym przez CST) szkoleniu choć nadal wymagane nie będzie już wystarczające dla uzyskania certyfikatu. Konieczne będzie zdanie egzaminu, który będzie miał postać komputerowego testu wielokrotnego wyboru. Bliższe informacje na temat sposobu przeprowadzania tego testu – np. czy będzie on dostępny on-line czy w centrach egzaminacyjnych – zostaną podane wkrótce i oczywiście o nich poinformujemy.
Kolejną nowością będzie konieczność odnawiania certyfikatów poprzez egzamin. I tak wszyscy, którzy uzyskali certyfikat przed kwietniem 2009 będą musieli do kwietnia 2011 zaliczyć egzamin certyfikacyjny. Wszyscy, którzy uzyskali certyfikat między 1 kwietnia a 30 września 2009 będą musieli zdać egzamin w ciągu dwóch lat od daty szkolenia. Dla szkoleń po tej dacie uczestnicy będą mieli 19 dni od daty szkolenia na przystąpienie do egzaminu. Po pierwszym zdaniu egzaminu wszyskie certyfikaty będą musiały być odnawiane co dwa lata przez ponowną egzaminację.
Wspomniane zmiany powodują wysokie zainteresowanie szkoleniami organizowanymi w wrześniu jako ostatnimi, na których certyfikaty będzie można uzyskać na dotychczasowych zasadach. Chcących się przeszkolić przed opisanymi zmianami zachęcamy do zapoznania się z ofertą firm organizujących szkolenia na terenie Polski (lista na stronach Scrum Alliance).
(źródło)
Po drugim spotkaniu i przed następnymi
Drugie spotkanie odbyło się, jak zapowiadano, 16 grudnia w Krakowie. Miało jak zapowiadano charakter dyskusyjny i było ciekawą wymianą poglądów, która potrwała do późnego wieczora. Dyskutowaliśmy zażarcie na temat długości sprintów i tego czy liczyć je w dniach roboczych czy kalendarzowych – tak prosty, wydawałoby się, temat spowodował zaskakująco długą dyskusję, przy okazji której wyszły różne inne tematy – jak np. motywowanie “olewaczy” czy kwestia elastyczności momentu release.
Chociaż frekwencja była dużo mniejsza (czyżbyście woleli przyjść na wykład niż podyskutować z innymi Scrumowcami?) to na nasze spotkanie przybył kolega aż ze Szczecina. Jak widać zainteresowanie Scrumem w Polsce rośnie – co może tylko cieszyć, bo napewno nie zaskakuje.
Natomiast po Nowym Roku musieliśmy wszyscy dojść trochę do siebie. Dziś odbędzie się mikro-spotkanie zainteresowanych udziałem w sterowaniu dalszym rozwojem Polskiej Grupy Scrum, na którym ustalimy m.in. daty i tematy najbliższych spotkań w Krakowie. Niedługo także odbędzie się pierwsze spotkanie w innym mieście.
Polecamy!
Kalendarz
« stycznia 
marca » luty 2012 P W Ś C P S N 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
