Ken Schwaber deklaruje, że jego celem jest wyciągnięcie wniosków z ośmiu lat funkcjonowania programu Certified Scrum Master, przede wszystkim w kierunku podniesienia wymagań niezbędnych do uzyskania certyfikatu. Ken chce to osiągnąć przede wszystkim przez wprowadzenie od razu egzaminów oraz zapewnienie spójności szkoleń poprzez rygorystyczną selekcję trenerów i scisłe przestrzeganie jednolitej zawartości materiałów szkoleniowych.

Robi więc wrażenie, że Ken usiłuje zrobić to, czego nie zrobił kiedy jeszcze kierował Scrum Alliance. Jak pisaliśmy wcześniej, odszedł w wyniku konfliktu wokół egzaminów na CSM, obecnie egzamin jest ale nie do końca, bo wszyscy go zdają. Ciekawe jak nowy program certyfikacji wpłynie na dalsze stosowanie Scrum-a i jego akceptację jako dobrej metody prowadzenia projektów informatycznych.

Oczywiście, będziemy informować o dalszych wydarzeniach ze świata Scruma, który wyraźnie dzieli się obecnie na dwa ośrodki.

Poniżej tłumaczenie na język polski informacji o wprowadzeniu programu Professional Scrum Master rozesłanej przez Scrum.org:

W ciągu ostatnich pięciu lat pracowałem jako coach i konsultant z wieloma organizacjami, które wdrożyły Scrum. Scrum Masterzy, których spotykałem mieli często bardzo różne pojęcie na temat tego czym Scrum jest lub nie jest, że nie wspomnę o tym jak Scrum używać. Przykładowo, podaje się, że 84% zespołów pracujących “agileowo” pracuje w Scrumie, jednak mniej niż 50% z tych użytkowników Scruma korzysta z iteracyji i praktyk inkrementalnego rozwoju oprogramowania.

Zdziwił mnie ten dysonans, bo Scrum jest niezwykle prostą metodą i byłem przekonany, że ciężko jest ją mylnie interpretować. Po bliższym zbadaniu sprawy odkryłem, że nawet certyfikowani przez Scrum Alliance Scrum Masterzy (CSM) różnili się pomiędzy sobą w rozumieniu Scruma. Problem ten wynika z następujacych przyczyn:

1. Trenerzy, nawet certyfikowani trenerzy Scrum Alliance (CST), używają bardzo różnych materiałów szkoleniowych opartych często o ich własną interpretację Scruma.
2. Trenerzy nie są regularnie kontrolowani i egzaminowani co do spójności i dokładności tego, czego nauczają.
3. Trenerzy nie muszą przechodzić żadnych egzaminów.
4. Brak jest egzaminów czy sprawdzianów, które zapewniłyby, że jedynie osoby posiadające odpowiednią wiedzę będą mogły być “certyfikowane”.

Odnowiony program szkolenia Scrum Masterów nazywa się Professional Scrum Master. Program ten został bardzo starannie przygotowany tak, aby:

1. Dostarczyć ujednolicone szkolenia wysokiej jakości poprzez licencjonowanych trenerów, którzy będą używać jednolitych materiałów szkoleniowych i których wiedza oraz umiejętnośc trenerskie będą kontrolowane w chwili wydawania licencji i regularnie sprawdzane dla jej utrzymania.
2. Odbywać regularne spotkania ze wszystkimi trenerami tak, by zapewnić spójność wszelkich uaktualnień materiałów szkoleniowych.
3. Dostarczać sprawdzianów i certyfikatów dla Scrum Masterów, które rzeczywiście potwierdzają kompetencje.
4. Zapewnić kolejne, rosnące poziomy szkolenia, sprawdzianów i certyfikacji.
5. Stale monitorować jakość trenerów poprzez ewaluacje szkoleń, wyniki egzaminacyjne ich uczestników oraz regularne przeglądy stosowanych materiałów szkoleniowych i szkoleń.

W programie Professional Scrum Master istnieją zatem trzy poziomy, każdy będący osobnym podprogramem obejmującym sprawdziany, certyfikacje i osiągnięcia. Dla każdego z poziomów istnieje określona baza wiedzy, dwa wyższe poziomy posiadają odpowiednie, unikalne programy szkoleniowe.

Te trzy poziomy to:

• Beginner – Scrum (level I): poziom początkujący, wiedza na temat Scrum-a oceniania w egzaminie testowym złożonym z niemal stu pytań. By uzyskać certyfikację na tym poziomie konieczne jest precyzyjne zrozumienie elementów Scrum – zasad, ról, okien czasowych (ang. time-boxes) i artefaktów (backlog itp.). Niezbędna wiedza zawarta jest w dokumencie “Scrum Guide”, który znajduje się na Scrum.org, i który jest pielęgnowany przeze mnie i Jeffa Sutherlanda. Szkolenia na tym poziomie mogą być prowadzone przez dowolnych trenerów, co obejmuje także dotychczas oferowane przez Scrum Alliance kursy. Można także nauczyć się samemu ze wspomnianego dokumentu i książek.Test sprawdzający wiedzę na tym poziomie jest dostępny na Scrum.org (patrz tutaj).
• Intermediate – How to Use Scrum (level II): poziom praktyka, oceniana wiedza dotyczy użycia Scruma w różnych sytuacjach pojawiających się przy rozwijaniu oprogramowania, na przykład zagadnienia związane z ewolucyjnie powstającą architekturą IT wynikającą z zastosowania różnorodnych produktów i systemów. Sprawdzanie wiedzy obejmuje trudne pytania testowe, studia przypadku i eseje na temat rozwoju oprogramowania. Pytania są sformalizowane w postaci sprawdzianiu i certyfikacji Professional Scrum Master II. Chcący uzyskać ten certyfikat będą musieli wykazać się praktyczną wiedzą na temat wdrażania i stosowania Scruma w złożonych projektach rozwoju oprogramowania.Opracowałem materiały do szkolenia Professional Scrum Master II (znanego również jako Scrum In Depth), będą one udostępniane licencjonowanym trenerom, którzy będą stale oceniani w sposób opisany wcześnej.Szkolenia i certyfikacja w programie Professional Scrum Master II będą dostępne od 1 marca 2010 r. Więcej informacji na Scrum.org.
• Advanced  – Using Scrum to Optimize Value (level III): poziom zaawansowany, oceniana wiedza dotyczy umiejętności maksymalizacji korzyści jakie płyną dla organizacji z zastosowania Scruma. Obejmuje to takie zaawansowane tematy jak na przykład: zarządzanie zmianą, struktury organizacyjne, zarządzanie produktem, zwrot z inwestycji (ROI) i sumaryczny koszt (TCO). Sprawdzanie wiedzy obejmuje trudne pytanie testowe, studia przypadku dotyczące skalowania i optymalizacji kosztów z pomocą Scruma oraz pisemne eseje o podobnej tematyce.Szkolenia i certyfikacja w programie Professional Scrum Master III zostaną udostępnione jesienią 2010. Odpowiednia informacja zostanie opublikowana na Scrum.org.

Professional Scrum Master (PSM) jest innowacyjnym programem szkolenia i oceny wiedzy dla osób odpowiedzialnych za wdrażanie  i używanie Scruma w projektach i całych organizacjach – a więc dla kadry zarządzającej wysokiego i średniego szczebla, Scrum Masterów, architektów czy liderów zespołów developerskich. Program PSM pochodzi bezpośrednio od twórców metodyki Scrum i jest odstępny jedynie poprzez Scrum.org.

Stworzyliśmy ten program po to, by poprawiać naszą profesję, tak aby jakość naszych produktów była lepsza, by nasi klienci bardziej nas doceniali i byśmy mogli cieszyć się z naszej pracy. Szczerze wierzymy, że ten program większy korzyści jakie dobre korzystanie ze Scruma przyniesie całym organizacjom i poszczególnym ludziom.

Więcej informacji na temat programu Professional Scrum Master, w tym egzamin na poziom I oraz lista szkoleń w różnych częściach świata, na Scrum.org.

Ken Schwaber

Większość materiałów o Scrumie (i Agile w ogóle) jest dostępna w języku angielskim. Dla niektórych nie jest to przeszkodą, ale bywa że jest inaczej. Właśnie w związku z tym postanowiłem przetłumaczyć Scrum Checklist na polską “Listę Kontrolną Scrum”, która dostępna jest tutaj.

Poniższy tekst jest tłumaczeniem artykułu umieszczonego na stronie: http://www.crisp.se/scrum/checklist i pozwala zrozumieć czym ta lista jest i jak jej używać.

Co to jest?

“Lista Kontrolna Scrum” jest prostym narzędziem pozwalającym wystartować ze Scrumem lub sprawdzić na etap implementacji Scruma.

To nie są zasady. To są wytyczne. Zespół liczący 2 osoby może zdecydować się nie robić codziennego Scruma (Daily Scrum), ponieważ programują w parze przez cały dzień i nie potrzebują osobnego spotkania na synchronizację. To jest w porządku. Świadomie ominęli praktykę Scruma, ale zapewnili że cel przyświecający tej praktyce został osiągnięty w inny sposób. I to się liczy!

Jeżeli już stosujesz Scrum może warto żeby zespół przeszedł wspólnie przez tą listę na retrospekcji? Oczywiście, traktując ją jako narzędzie do dyskusji, nie do oceniania.

Jak korzystać z listy kontrolnej?

• Robert: “Przyniosłem użyteczną listę kontrolną na tą retrospekcję. Jest coś na tej liście czego nie robimy?”

• Monika: “Hmmm, zobaczmy. Wygląda na to że na pewno nie mamy ‘Kryterium ukończenia’ i nie mierzymy prędkości”

• Robert: “‘Kryterium ukończenia’ jest wymienione jako ‘Podstawa Scruma’ więc wydaje się być całkiem ważne! Prędkość jest pod ‘Rekomendowane ale nie zawsze potrzebne’, więc poczekajmy z tym i zacznijmy z rzeczami podstawowymi”

• Monika: “Popatrz, nie spełniamy także ‘Dostarczanie działającego, przetestowanego oprogramowania co 4 tygodnie lub szybciej’. To jest wymienione jako ‘Kwintesencja’. Brzmi sensownie, bo marketing zawsze na to narzeka!”

• Robert: “Może koncepcja ‘Kryterium ukończenia’ może nam pomóc w braniu mniejszych porcji do sprintu i umożliwi częstsze robienie wydań?”

• Monika: “Dobry pomysł, spróbujmy!”

Jak NIE używać listy kontrolnej?

• Wielki szef: “Ok zespole, zobaczmy jak zgodny ze standardem jest Wasz Scrum. Wypełnijcie proszę listę kontrolną”

• Robert: “Szefie, cieszę się że mogę Ci powiedzieć że robimy wszystko. W zasadzie wszystko poza Burndown chart””

• Wielki szef: “Niedobry, niedobry zespół! Z listy wynika że powinniście robić te…burny…czy coś! Ja je chcę!”

• Monika: “Ale my robimy 2-tygodniowe sprinty i prawie zawsze dostarczamy to, do czego się zobowiązaliśmy, a klienci są zadowoleni. Na tym etapie Sprint burndown chart nie wniesie żadnej wartości.”

• Wielki szef: “Z listy wynika że powinniście to robić, więc nie pozwólcie żebym znowu Was przyłapał na oszukiwaniu, albo wezwę Policję ds Scruma!”

Czy to oficjalna lista kontrolna?

Nie. Lista została zrobiona przez Henrik Kniberga i wyraża jego osobiste i subiektywne opinie na temat tego co tak naprawdę jest ważne w Scrumie. Poświęcił kilka lat pomagając firmom zacząć pracę ze Scrumem, spotkał setki innych praktyków, trenerów i coachów; i przekonał się że stosowanie list kontrolnych jest pomocne, jeżeli odpowiednio się z nich korzysta.

Co ze starą wersją?

Stara lista kontrolna (w postaci mindmapy) jest ciągle dostępna. Jednak jest już w obiegu dosyć długo, a nowa jest wg Henrika dużo lepsza.

Gdzie mogę podzielić się swoją opinią?

Jeżeli chciałbyś podzielić się opinią na temat listy kontrolnej lub zaproponować jej usprawnienie napisz emaila na henrik.kniberg(AT)crisp.se (po angielsku). Jeżeli masz uwagi do polskiego tłumaczenia napisz na b.kobylecki(AT)gmail.com lub po prostu napisz komentarz poniżej.

Dlatego interesującą opcją jest darmowy test wiedzy o Scrumie, który na swojej stronie scrum.org udostępnia Ken Schwaber. Test składa się z 80 pytań, w większości jednokrotnego wyboru, na które należy odpowiedzieć w ciągu 80 minut. Jego cenną cechą jest to iż od razu jesteśmy informowani, z uzasadnienem, jeśli wybierzemy błędną odpowiedź – można zatem nie tylko sprawdzić, ale i poprawić swoją wiedzę.

Osoby, które zdadzą test z wynikiem co najmniej 75% dobrych odpowiedzi są wymieniane na specjalnej liście, która jest dostępna w formacie PDF na tej samej stronie.

Ken choć nie kieruje już Scrum Alliance nadal pracuje nad rozwojem Scruma i jego nauczania, w ramach czego przygotował nową generację szkoleń Certified Scrum Master II. Jak się wydaje testy, które przygotowuje mają służyć sprawdzaniu wiedzy uczestników tych szkoleń.

Aby rozpocząć test należy udać się na jego stronę i wcisnąć duży, zielony guzik. Do rozpoczęcia testu niezbędne jest hasło – “assessment2″ – podane zresztą na tej samej stronie.

Powodzenia!

Jak się wydaje wynika to z jednego podstawowego problemu, który trudno określić inaczej niż “kultura bylejakości”. Jest to połączenie niemożności osiągnięcia zakładanego poziomu jakości tworzonego systemu z akceptacją tego stanu rzeczy przez otoczenie obu zespołów. Ta akceptacja jest pełna rezygnacji, by nie powiedzieć fatalizmu, zwłaszcza ze strony kluczowych odbiorców systemu (oba zespoły budują systemy wewnętrzne) – ale jest. Efektem jest funkcjonowanie całkiem poważnie nastawienia, które najlepiej oddał jeden ze Scrum Masterów mówiąc do zespołu “wydajmy to na produkcję  – juzerzy nam to przetestują”. Najbardziej niebywałe jest tu to, że nikt nie zaprostestował.

Przy takim podejściu katastrofa (w postaci spektakularnego padu krytycznego dla firmy systemu) tylko czeka aby się wydarzyć, a praca obu zespołów jest pasmem “marszów śmierci”, następujących po nich okresów letargu i stałego gaszenia pożarów.

Nie wchodząc zbytnio w szczegóły warto pochylić się nad tymi przypadkami, bo mają one – niestety – nie tylko szanse stać się przykładem, że Agile ogólnie a Scrum szczególnie “nie działa”, ale wydają się być dość typowe.

Jak mi się wydaje najistotniejszym wnioskiem jaki z nich wypływa jest taki, abyśmy zawsze pamiętali to, co wbijane jest do głów na każdym (porządnym) szkoleniu scrumowym – Scrum nie rozwiązuje sam ze siebie żadnych problemów, Scrum jedynie czyni je widocznymi. Scrum to nie panaceum, nie uczyni cudów.

Nie da się zatem przy pomocy Scruma i Agile przerobić grupy studentów bez solidnych podstaw informatycznych na sprawny zespół programistów. Zanim zacznie się stosować praktyki XP i pracować w krótkich sprintach w Scrumie trzeba na początek umieć dobrze obiektowo modelować i programować, trzeba umieć pisać czytelny kod (np. mieć nawyk stosowania sensownych nazw obiektów, metod i zmiennych czy pisania sensownych komentarzy), mieć pojęcie o wzorcach projektowych, umieć je stosować i tak dalej. Trzeba wreszcie posiadać wiedzę o stosowanej technologii, a więc o języku w którym się pisze i jego właściwościach, właściwościach stosowanych kompilatorów czy interpreterów i innych związanych z danym językiem narzędzi.

Trzeba też umieć korzystać z frameworków i bibliotek – a więc przede wszystkim mieć świadomość ich istnienia, a także wad i zalet by móc odpowiednio dobrać je do swojego projektu. Trzeba wreszcie umieć właściwie wykorzystać środowisko pracy, takie jak systemy kontroli wersji, błędów, automatycznych buildów itp. No i oczywiście cały szeroki świat testów – nie dość, że trzeba mieć nawyk ich pisania oraz wykonywania – trzeba także mieć umiejętności i narzędzia. To właśnie braki tej podstawowej wiedzy i związanych z nią praktyk decydują o wspomnianej wyżej niemożności jaka trapi oba zespoły.

Oczywiście, wszystkiego można się nauczyć – ale trzeba mieć od kogo. Jeśli w zespole wszyscy są mniej-więcej równie początkujący jego rozwój jest znacznie utrudniony jeśli nie niemożliwy. Zdecydowanie lepiej jest, jeśli w zespole przynajmniej część stanowią doświadczeni programiści i testerzy, którzy mogą pomóc “świeżym” kolegom w rozwoju. W przeciwnym razie praktyki takie jak przeglądy kodu czy programowanie w parach niewiele dają – przeciwnie, petryfikują wręcz niski poziom i jako “bezsensowne” są szybko zarzucane.

Równie toksyczna i prowadząca do utrwalania się dysfunkcji zespołu – który miast miejscem rozwoju staje się miejscem walki z problemami dawno już rozwiązanymi gdzie indziej – jest akceptacja marnych wyników przez odbiorców i kierownictwo.

I tu dotykamy innego problemu – otóż niezwykle często myli się u nas samoorganizację i inne cechy Scruma z brakiem zarządzania. Tymczasem samoorganizacja dokonuje się wokół celów, które to cele ktoś z zewnątrz musi postawić i wymagać ich osiągania. Jakość jest jednym z takich celów – jakość nie jest jakimś regulowalnym parametrem (niczym na linii produkcyjnej), przeciwnie – pewien ustalony poziom jakości tego co jest budowane (będący potem podstawą kryterium ukończenia) jest jednym z celów służących samoorganizacji zespołu.

Ale samoorganizacja wymaga nie tylko celów – wymaga również presji. Samoorganizacja nie nastąpi jeśli zobowiązanie zespołu do wykonania tego co wziął “do sprintu” nie jest traktowane poważnie. A poważne traktowanie oznacza nie tylko świętowanie osiągnięcia celu sprintu podczas przeglądu (sprint review) – oznacza także poważne traktowanie porażek. Wymaga to od zarządzających takimi zespołami subtelności, stanowczości  ale przede wszystkim konsekwencji – zespół musi dobrze rozumieć, że zawiódł; musi zdawać sobie sprawę z tego, że nie jest dobrze (no bo jeśli jest dobrze – to po co coś poprawiać?).

I tu dochodzimy do najistotniejszego – dobra firma czy dział tworzący oprogramowanie to taki, gdzie sprawy takie są dla wszystkich oczywiste. A więc jest dla każdego jasne, że fuszerka to fuszerka i trzeba się jej wstydzić (niezależnie od tego czy na wierzchu działa czy nie), że system krytyczny dla firmy ma działać zawsze a wszelkie zaburzenia tego stanu rzeczy są porażką dla zespołów i plamą na ich profesjonaliźmie. To jest właśnie kultura jakości, w której metody agile kwitną i pomagają. Bez niej – w kulturze bylejakości, a więc akceptacji marności rezultatów i mierności wysiłków – Scrum, Agile – czy w ogóle inne metodyki działające na innym poziomie abstrakcji nie przyniosą oczekiwanych efektów.

Dlatego zanim będziemy próbować wdrażać gdzieś Scruma upewnijmy się, że środowisko w ogóle się do tego nadaje – że sypiemy ziarno na żyzną glebę kultury jakości, a nie na uklepany nawykiem ugór bylejakości. I jeśli to konieczne lepiej zacząć pracę od postaw, od budowania kultury jakości, nawet jeśliby to była przysłowiowa “orka na ugorze”.

Andrzej K. Brandt
Code Sprinters

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:

1. Product Owner umieszcza nowe zadanie na backlogu (w części dla zadań „nowych”).
2. Product Owner sortuje zadania “nowe“.
   
3. Zespół oszacowuje pewną liczbę zadań nowych (znajdujących się na szczycie backlogu w części dla zadań „nowych”).
   
4. 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.
   
5. 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

Tematem będzie tym razem używanie historyjek użytkownika (user stories) do opisywania zadań na backlogu oraz pielęgnacja backlogu i planowanie długofalowe. Jak zwykle rozpoczniemy od krótkiego wystąpienia, po którym zapraszamy do dyskusji.

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.

Poniżej linki do niektórych materiałów, które były omawiane w trakcie spotkania.

• prezentacja Serge Beaumont o narzędziach dla Product Ownerów (blog Serge’a),
• prezentacja Stefana Roocka i Markusa Andrezaka o wdrożeniu agile w mobile.de,
• prezentacja Harveya Wheatona o tym jak praktykuje się Scrum i agile w jego firmie produkującej gry konsolowe Supermassive Games.

Do zobaczenia za miesiąc!

W spotkaniu tym powracamy do formatu “mini wykład, potem dyskusja”, tym razem zamiast wykładu Andrzej Brandt i Tomek Włodarek opowiedzą o nowościach i ciekawostkach z konferencji Scrum Gathering w Monachium. Najciekawsze wystąpienia i dyskusje na konferencji wiązały się z rozwojem roli Product Ownera w Scrumie. Okazuje się, że po usprawnieniu pracy zespołu często to Product Ownerzy nie dają sobie rady z dostarczaniem odpowiednio szybko historyjek na backlog, w związku z czym pojawiają się interesujące propozycje usprawnienia ich pracy. Drugi ciekawy wątek to przykłady wdrożenia Scrum i innych metodyk agile w różnych firmach i organizacjach. Takie opowieści o tym jak to się działo w rzeczywistych organizacjach zawierają wiele ciekawych wskazówek pochodzących z praktyki.

Zatem, tym razem na rozpoczęcie dyskusji zostaną poruszone następujące tematy:

• usprawnienia pracy product ownera – dalszy rozwój roli Product Ownera,
• wdrożenie Scrum w portalu mobile.de – ciekawy przypadek wdrożenia Scruma, zwłaszcza w środowisku z podejściem lean.

Dyskusja jak zwykle nie ograniczona w zakresie.

Serdecznie zapraszamy!