Lista kontrolna dla Scrum Mastera
Dobry Scrum Master może zajmować się dwoma lub trzema zespołami jednocześnie. Jeśli zadowalasz się ograniczeniem swojej roli do organizowania spotkań, pilnowania limitów czasowych i rozwiązywania problemów zespołu, rola Scrum Mastera może funkcjonować w niepełnym wymiarze czasu. Zespół z pewnością i tak przekroczy oczekiwania, jakie istniały w Twojej organizacji przed Scrumem, i z największym prawdopodobieństwem nie dojdzie też do większych katastrof.
Jeśli jednak potrafisz wyobrazić sobie, że zespół czerpie radość z tworzenia rzeczy, których wcześniej nikt nie uważał za możliwe, powinieneś też mieć wolę bycia wspaniałym Scrum Masterem.
Wspaniały Scrum Master może zajmować się tylko jednym zespołem na raz.
Szczególnie na początku polecamy więc zmotywowanego i zaangażowanego Scrum Mastera dla około siedmioosobowego zespołu.
Jeśli nie masz jeszcze pełnego przeglądu całej pracy do wykonania, spróbuj dowiedzieć się więcej o Product Ownerze, zespole, metodach wytwarzania stosowanych przez zespół i całej organizacji. Nawet jeśli nie ma gotowego przepisu, wymieniłem tutaj kilka rzeczy, na które Scrum Master powinien zwrócić uwagę:
Lista kontrolna Scrum Mastera dla Product Ownera
Możesz zwiększyć efektywność Product Ownera, pomagając mu zadbać o Product Backlog i plan wydań. (Pamiętaj jednak, że tylko Product Owner powinien priorytetyzować Backlog.)
Czy priorytetyzacja Product Backlogu odpowiada najaktualniejszym przemyśleniom i wizji Product Ownera?
Czy wszystkie wymagania i życzenia wszystkich interesariuszy zostały uwzględnione w Backlogu? Pamiętaj, że Backlog może się stale zmieniać.
Czy Product Backlog ma odpowiednie rozmiary, którymi można wygodnie zarządzać? Aby utrzymać liczbę pozycji na poziomie łatwym do opanowania, szczegółowe pozycje powinny znajdować się na górze Backlogu, a bardziej ogólne tematy raczej na końcu. Zbytnie zagłębianie się w szczegóły przy więcej niż tylko najbardziej priorytetowych pozycjach jest kontraproduktywne, ponieważ wymagania będą się stale zmieniać wraz z rozwojem produktu i ciągłą komunikacją z klientami/interesariuszami.
Czy są wymagania (szczególnie te na górze Backlogu), które można by lepiej napisać jako niezależne, negocjowalne, wartościowe, szacowalne, małe i testowalne User Stories (kryteria INVEST)?
Czy wyjaśniłeś Product Ownerowi kwestię długu technicznego i jak go unikać? Pomocne może być dodanie zautomatyzowanych testów i refaktoryzacji do Definition of Done każdej pozycji Backlogu.
Czy Backlog jako źródło informacji jest dobrze widoczny dla wszystkich interesariuszy?
Czy masz automatyczne narzędzie do zarządzania Backlogiem? A jeśli tak, czy faktycznie Ci to pomaga? Takie narzędzia niosą bowiem ryzyko, że trudno znaleźć poszukiwane informacje, jeśli Scrum Master aktywnie ich nie komunikuje.
Czy możesz pomóc komunikować informacje, drukując je i rozdając wszystkim zainteresowanym?
Czy możesz pomóc komunikować te informacje, tworząc duże, dobrze widoczne schematy i diagramy?
Czy pomogłeś Product Ownerowi podzielić pozycje Backlogu na odpowiednie wydania? (Np. na bieżące prace (Front Burner), nadchodzące prace (Back Burner) i rzeczy, które zostały wprawdzie dodane do Backlogu, ale jeszcze nie przygotowane (Fridge).)
Czy wszyscy interesariusze (w tym zespół) wiedzą, czy plan wydań – mierzony obecną prędkością (np. Story Points na Sprint) – nadal odpowiada rzeczywistości?
Czy Product Owner zaktualizował plan wydań po ostatnim Sprint Review? Tylko nieliczni Product Ownerzy dostarczający produkty wystarczająco przetestowane na czas aktualizują plan wydań w każdym Sprincie. Często przesuwają część prac na przyszłe wydania, gdy pojawiają się ważniejsze zadania. Spróbuj zastosować wykresy Burndown Produktu/Wydania według Mike'a Cohna, które możesz prezentować wszystkim zainteresowanym po potwierdzeniu na Sprint Review, że pozycje są „done". Na ich podstawie można wcześnie rozpoznać zmiany w zakresie lub harmonogramie.
Lista kontrolna Scrum Mastera dla zespołu
1.) Czy członkowie zespołu przez większość czasu są w stanie „flow"? Niektóre cechy tego stanu to: jasne cele (oczekiwania i zasady są rozpoznawalne; cele są osiągalne i odpowiadają umiejętnościom poszczególnych osób); koncentracja i skupienie (skupienie na określonym punkcie); zmniejszona niepewność (działanie i świadomość zlewają się); zanika poczucie czasu (subiektywne odczuwanie czasu się zmienia); bezpośrednia i natychmiastowa informacja zwrotna (sukcesy i niepowodzenia w trakcie działania są dobrze rozpoznawalne, więc zachowanie można w razie potrzeby dostosować); zrównoważona proporcja umiejętności do wyzwania (nie jest ani za trudne, ani za łatwe); poczucie osobistej kontroli nad sytuacją/działaniem (działanie jest z natury wartościowym, a przez to effortless zadaniem).
1.) Czy członkowie zespołu wydają się dobrze ze sobą współżyć? Czy robią coś razem? Czy wspólnie z kolegami świętują ich sukcesy?
2.) Czy członkowie zespołu dbają o to, by każdy przestrzegał wysokich standardów? Czy zachęcają się nawzajem do doskonalenia?
3.) Czy są problemy lub możliwości, o których zespół nie mówi, bo nie czuje się wystarczająco komfortowo? Możesz skonsultować się z profesjonalistą, który pomoże Ci uczynić trudne rozmowy łatwiejszymi. (Lub przeczytaj więcej na ten temat w książce Crucial Conversations: Tools for Talking When Stakes are High)
4.) Czy wypróbowałeś już różne formaty i miejsca na Sprint Review? Kilka pomysłów znajdziesz w książce Agile Retrospectives: Making Good Teams Great Esther Derby i Diany Larsen.
5.) Czy zespół dotrzymał kryteriów akceptacji? Może podczas Sprintu warto jeszcze raz przejrzeć kryteria akceptacji pozycji Product Backlogu na ten Sprint.
6.) Czy Sprint Backlog faktycznie odzwierciedla to, nad czym zespół aktualnie pracuje? Przerwy i rozproszenia, które nie przyczyniają się do osiągnięcia celu Sprintu, są przeszkodami.
7.) Czy szacunki zadań i tablica zadań są na bieżąco aktualizowane?
8.) Czy artefakty do samozarządzania zespołu (tablica zadań, wykres Sprint Burndown itd.) są dobrze widoczne dla całego zespołu, praktyczne i użyteczne?
9.) Czy te artefakty są odpowiednio chronione przed mikrozarządzaniem?
10.) Czy członkowie zespołu dobrowolnie zgłaszają się do określonych zadań?
11.) Czy do Backlogu dodano pozycje dotyczące spłaty długu technicznego (aby naprawić problemy szkodzące prędkości) lub przynajmniej omówiono je z Product Ownerem?
12.) Czy członkowie zespołu zostawiają swoje tytuły zawodowe poza pokojem zespołowym?
13.) Czy cały zespół czuje się odpowiedzialny za testy, dokumentację dla użytkowników itd.?
Lista kontrolna dla rozwoju produktu
1.) Czy Twój system w środowisku deweloperskim ma przycisk „push-to-test", tak aby każdy (w tym samym lub innym zespole) mógł łatwo sprawdzić, czy coś zepsuł? Zazwyczaj osiąga się to za pomocą frameworka xUnit (JUnit, NUnit itp.).
2.) Czy masz odpowiednią proporcję między zautomatyzowanymi end-to-end testami systemowymi (testami funkcjonalnymi) a zautomatyzowanymi testami jednostkowymi?
3.) Czy zespół pisze zarówno „testy funkcjonalne", jak i testy jednostkowe w języku systemu, który rozwija (zamiast własnościowych języków skryptowych lub narzędzi Capture & Playback, z którymi tylko mała część zespołu potrafi pracować)? To jest możliwe!
4.) Czy Twój zespół odkrył już niezwykle użyteczną szarą strefę między testami systemowymi a testami jednostkowymi?
5.) Czy serwer Continuous Integration automatycznie alarmuje w ciągu godziny (lub kilku minut), gdy tylko ktoś spowodował błąd regresji?
6.) Czy wszystkie testy są zgromadzone w wynikach serwera Continuous Integration?
7.) Czy członkowie zespołu odkryli już zalety ewolucyjnego projektowania (Continuous Design) i „bezlitosnej refaktoryzacji" jako alternatywy dla Big Design Upfront (BDUF)? Refaktoryzacja ma jasną definicję: zmiana wewnętrznej struktury systemu bez zmiany zachowania widocznego z zewnątrz. Przy redundantnym kodzie, złożonej logice, złej konwencji nazewnictwa, nadmiernym sprzężeniu między obiektami itp. refaktoryzacja powinna być przeprowadzana wielokrotnie w ciągu godziny. Zautomatyzowane pokrycie testami świetnie nadaje się jako siatka bezpieczeństwa do refaktoryzacji. Luki w pokryciu testami i odkładana refaktoryzacja to choroby, które nazywamy długiem technicznym.
8.) Czy Twoja Definition of Done dla każdej funkcjonalnej pozycji Product Backlogu obejmuje w pełni zautomatyzowane pokrycie testami oraz refaktoryzację? Jest mało prawdopodobne, że w każdym Sprincie uda Ci się wyprodukować potencjalnie wydawalne oprogramowanie bez nauczenia się metod eXtreme Programmingu (jak opisano np. u Kenta Becka, Rona Jeffriesa itp.).
9.) Czy członkowie zespołu pracują głównie w parach (Pair Programming)? Pair Programming może dramatycznie poprawić utrzymywalność kodu i zmniejszyć liczbę błędów. Może jednak stawiać przed dużymi wyzwaniami i czasem wydaje się trwać dłużej (gdy przedkładamy ilość nad jakość). Zamiast zmuszać do tego członków zespołu, sam dawaj przykład i proponuj pracę parami w określone dni tygodnia. Niektórzy członkowie zespołu wkrótce zaczną preferować ten sposób pracy.
Lista kontrolna Scrum Mastera dla rozwoju organizacji
1.) Czy istnieje wystarczająca koordynacja między poszczególnymi zespołami? Scrum of Scrums jest jedynym sposobem, by to osiągnąć. Dodatkowo możesz wysyłać przedstawicieli swojego zespołu na Daily Standup innych zespołów.
2.) Czy koordynacja w zespole jest faktycznie – jak zalecane – prowadzona przez tych, którzy codziennie wykonują prace?
3.) Czy różni Scrum Masterzy spotykają się, by pracować nad listą organizacyjnych przeszkód?
4.) Czy przeszkody są przekazywane kierownictwu ds. rozwoju, gdy jest to stosowne? Czy można zmierzyć ich koszt w kategoriach pieniężnych lub w postaci utraconego czasu wprowadzenia produktu na rynek, utraconej jakości lub utraconych możliwości dla klienta?
5.) Czy Twoja organizacja należy do nielicznych, w których możliwości kariery są zgodne ze zbiorowymi celami zespołów? Tak nie jest, gdy istnieją bodźce skłaniające do programowania lub prac architektonicznych kosztem testów, automatyzacji testów lub dokumentacji dla użytkowników.
6.) Czy pomagasz tworzyć organizację uczącą się?
7.) Czy Twoja organizacja jest znana w prasie branżowej lub w innych niezależnych źródłach jako atrakcyjne miejsce pracy lub lider rynku?
Strach jest Twoim przyjacielem
Kiedy zdasz sobie sprawę, ile możesz zdziałać, możliwe, że poczujesz strach. Ale to tylko znak, że jesteś na właściwej drodze.
Tekst pochodzi z bloga Scrum Alliance i został przez nas przetłumaczony na język polski.
