Dwa słowa o mnie Dwa słowa o Scrumie Kilka przykładów Co można robić, a czego unikać Prosta SCRUM-GAME Adam Smyk Warsztaty - Metodyka SCRUM - Lipiec 2013 Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa/Gdańsk/Bytom Open Source Education Center - Warszawa/Wrocław HOLON Gdynia Licea ogólnokształcące im.s.żeromskiego i im. E.Bułhaka 75% edukacja programistyczna i 25% uczestnictwo w projektach 1
AGILE, SCRUM 1. osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania, 2. działające oprogramowanie jest dostarczane okresowo (raczej tygodniowo niż miesięcznie), 3. podstawową miarą postępu jest działające oprogramowanie, 4. późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania, 5. bliska, dzienna współpraca pomiędzy biznesem a deweloperem, 6. bezpośredni kontakt, jako najlepsza forma komunikacji w zespole i poza nim, 7. ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt (design), 8. prostota, 9. samo-zarządzalność zespołów, 10. regularna adaptacja do zmieniających się wymagań. Planowanie na życzenie Skala projektu określa wiarygodność jego założeń Zmiana planu jest bardzo kosztowna Szybko zmieniające się technologie Duża złożoność i kompleksowość Zdefiniowane i powtarzalne procesy Zespół nie lubi systematycznego działanie Słaba współpraca między członkami zespołu Brak integracji Zespół nie ma nic do gadania, bo ma kierownika Przygotowanie i utrzymanie projektu jest bardzo kosztowne Chaos w kontroli projektu Duża ilość zbędnej dokumentacji Skomplikowane metodyki 2
iteracyjna i inkrementalna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile. Wykorzystywana głównie w projektach informatycznych Przy odrobinie pracy własnej można ją zastosować w szkole, w dowolnym miejscu Role Mistrz młyna (Scrum master) Właściciel produktu (Product owner) Zespół (Team) Zespół pracuje w przedziałach czasowych zwanych sprintami Po każdym takim sprincie, użytkownik dostaje działający produkt Ważne są wymagania czasowe Na początku tworzona jest lista wymagań w formie historyjek Każda historyjka opisuje pewną cechę produktu Właściciel produktu wyznacza priorytety wymagań 3
Formułowany jest rejestr wymagań. Wybiera się zadania o najwyższym priorytecie Zadania są wybierane przez zespół dobrowolnie Rejestr zadań nazywa się sprint backlog Przystąpienie zespołu do pracy Właściciel produktu nie ingeruje w pracę Scrum meeting Codzienne spotkanie około 15 minut Co zrobiłem od ostatniego spotkania? Co będę robił teraz? Jakie mogę mieć problemy, czego się boję, kto może mi pomóc? Uczestniczy cały zespół projektowy Sprint review prezentacja osiągnięć przez wszystkich uczestników Opinie twórców Burn-down-chart 4
Dostarczaniu kolejnych, coraz bardziej dopracowanych wersji produktu Włączaniu się przyszłych użytkowników w proces wytwórczy Samoorganizacji całego zespołu projektowego Zwiększenie produktywności Uciekamy od utartych schematów Pobudzamy od utartych schematów Produkt wynikowy jest zbieżny z wymogami klienta Zdecydowanie wspiera kulturę pracy zespołowej, a także zaangażowanie pracowników i ich zadowolenie z pracy Od 5 do 9 osób za mało -> nie zespół za dużo -> trudno się dogadać Interdyscyplinarność Jedna osoba jeden zespół Czas trwania sprintu ustalony i niezmienny (2 4 tygodnie) Użytkownik musi widzieć i czuć zmianę po sprincie Stand-up meeting Timeboxing I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it. Oszacowanie skali trudności problemu Szacują wszyscy, ale indywidualnie Nie sugerujemy się innymi każdy ma własne zdanie 5
Symulacja Scrum przy użyciu LEGO Autor: Alexey Krivitsky Chcemy rozpocząć grę z otwartym backlogiem jako zaproszenie do współpracy między klientem a zespołem. Backlog może zostać wcześniej przygotowany przez trenerów, ale nie powinien być zamknięty i precyzyjnie określać zrób to, a później zrób tamto. Chcemy przedstawić i nauczyć kompletnie nowego rodzaju współpracy międzyklientami a zespołami. Powinniśmy uczyć rozwoju produktu, a nie mikro-zarządzania na poziomie poszczególnych zadań. Zatem backlog czy instrukcje (do samej gry, przyp. tłum.) nie powinny składać się z listy zadań, ale raczej powinny stanowić wizję produktu - szersze spojrzenie na to co ma zbudować zespół. Gra powinna dać się skalować tak aby pasowała do szkoleń dla więcej niż 20 osób. To oczywiście oznaczać będzie podział grupy na mniejsze zespoły. Może to być jednak szansa na przećwiczenie umiejętności współpracy między zespołami. Podział na wiele zespołów powinien być robiony rozważnie, ponieważ bez konkretnych wskazówek naturalnym jest, że zaczną one rywalizować ze sobą (zamiast współpracować - przyp. tłum.) Wszystkie metryki, o których zbieranie proszą trenerzy, powinny stanowić oczywistą pomoc dla zespołu, ponieważ gra powinna nauczyć uczestników kształtowania własnego procesu. Gra powinna być tak zaprojektowana, aby zespół mógł zagrać w nią wielokrotnie. Każda nowa sesja gry powinna dostarczać materiału do kolejnych ulepszeń procesu jaki symuluje zespół. 6
Czas gry: 100-120 minut 100 minut - jeśli używana jest technika szybkiej estymacji zespołowej 120 minut - jeśli używamy gry planning poker lub innej podobnej Rozmiar grupy: 4-25 osób Idealnie 2-3 zespoły po 4-6 osób (co daje 8-18 osób) Można rozszerzyć o Scrum Master ów Zestawy LEGO: pudełko LEGO na zespół 4-6 osobowy Używam zestaw podstawowy o numerze #61772 Potrzeba czterech takich zestawów na 20 osób Rekwizyty: standardowy pakiet szkoleniowy Karteczki samoprzylepne, papier do flipchartów, markery Karty do planning pokera (mogą być zrobione ręcznie) Wyposażenie sali: stół dla każdego zespołu 4-6 osobowego Dodatkowa przestrzeń (stół lub miejsce na podłodze) dla finalnego produktu jest bardzo pomocna Rolę właściciela produktu pełni prowadzący. Ta gra może być prowadzona bez specjalnie wyznaczonych Scrum Masterów, chociaż: zespoły, mogą wybrać swoich Scrum Masterów. Dodatkowi trenerzy mogą stać się Scrum Masterami. Członkowie zespołu Uczestnicy szkolenia zostają członkami zespołów. Testerzy Opcjonalnie testy akceptacyjne Członkami zespołów mogą być też testerzy. Ich głównym zadaniem będzie pomoc w dokumentowaniu ustaleń na temat wymagań i przeprowadzenie testów akceptacyjnych. Nie dopuszczaj obserwatorów przyjemnością jest sama gra Ta gra sprawia tyle przyjemności, że bierni obserwatorzy będą tracić więcej niż faktycznie wynosić z gry (to moja opinia). Jeśli jednak macie inne doświadczenia w tej kwestii, chętnie o tym usłyszę. Zachowania Z obserwacji wynika, że konkretne zachowania, jakie ludzie prezentują podczas gier, są odzwierciedleniem ich nawyków z miejsca pracy. W sytuacji stresowej ludzie maja tendencję do ujawniania swoich naturalnych zachowań. Ta gra jest celowo zaprojektowana tak, aby była stresująca na tyle, żeby uwidocznić zachowania, które mogłyby źle wpłynąć na adopcję praktyk Agile. Celem trenera, jest wskazanie takich zachowań grupie i obrócenie ich w naukę oraz pokazanie zagrożeń, na które należy mieć oko. Style komunikacji Zwróć uwagę na managerów, dyktatorów, donośne głosy i podobne postawy. Mogą one stanowić bogaty materiał do podsumowań oraz osobistego coachingu. Załamujący się proces Zwracaj uwagę na elementy procesu, w których zespoły popełniają błędy. Na przykład podczas dyskusji w trakcie zbierania wymagań zespoły mogą nie zadawać dostatecznej liczby pytań wyjaśniających wątpliwości. Prawdopodobnie zespoły będą miały podobne problemy w trakcie prawdziwych projektów. Zwrócenie uwagi na takie błędy podczas podsumowań jest jednym ze sposobów poradzenia sobie z nimi. Przygotowanie Formowanie zespołów obowiązkowo 5 minut Definiowanie procesu Formowanie wizji Budowanie backlogu Szacowanie Gra Planowanie sprintu Wykonanie (Sprint) Ocena efektów sprintu Zakończenie Podsumowanie 7
Zajmie 5 minut. Nie ma powodów, aby wykluczać tę część z gry - to dodatkowa okazja do nauki. Starając się zademonstrować samoorganizację w akcji, proszę zwykle uczestników do zorganizowania się w grupach 4-6 osobowych i przygotowanie sobie miejsca do pracy. Jest to dobre zajęcie na rozgrzewkę, ponieważ może wymagać przestawiania i uporządkowania stołów. Zajmie 10 minut. Minęło do tej pory 5 minut gry. Jako trener odgrywający rolę właściciela produktu powinienem w tym momencie przekazać następujące informacje: 1. Wszystkie zespoły będą budowały jeden wspólny produkt - nie konkurujemy ze sobą, tylko pracujemy dla tego samego dostawcy. 2. Produktem jest MIASTO z konkretnymi cechami. 3. Głównym budulcem są klocki LEGO, ale można użyć innych materiałów jako dodatków. 4. Ja podejmuję główne decyzje na temat produktu - to jest moje miasto. 5. Będę zaangażowany w proces budowy poprzez odpowiadanie na pytania i zapewnianie komentarzy na temat powstałego produktu. Celem jest dbanie o to, aby zespoły ćwiczyły Scrum przez tworzenie produktu przy pomocy klocków LEGO. Trudność kryje się za pytaniem w jaki sposób połączyć rolę właściciela produktu (nie mającego wpływu na proces) i trenera (zainteresowanego tym, aby wszystko odbyło się zgodnie ze Scrum)? Jest kilka sposobów, jakie wypróbowałem: 1. Zmiana wcieleń - wyjaśnij zasady Scrum zespołom - Jawnie ogłaszam czy aktualnie gram rolę właściciela produktu czy trenera tak, aby uczestnicy nie mieli wątpliwości. 2. Granie roli początkującego właściciela produktu - pozwól zespołowi sprzedać Ci Scrum. Zazwyczaj gram właściciela produktu, który nie wie zbyt dużo na temat Agile czy Scrum i po przedstawieniu mojej wizji miasta proszę zespół, aby pomógł zaprojektować proces, który najlepiej będzie tu pasował. Zajmie 15 minut. Minęło do tej pory 15 minut gry. Kiedy nakreśliłeś już wizję i uzgodniłem proces, czas na przedstawienie cech miasta. Zwykle robię to pokazując zespołom zestaw przygotowanych wcześniej na kartkach user stories przyczepionych do arkusza flipchart. Najczęściej zawierają one następujące elementy: budynek jednopiętrowy (kilka takich, po jednym na kartkę), budynek dwupiętrowy (kilka), sklep, szkoła, kościół, szpital, przedszkole, przystanek autobusowy, skrzyżowanie, park, rzeka, most. Część elementów może być naszkicowana na flipcharcie Opowiadam o swoich wyobrażeniach tego miasta Zajmie 20 minut. Minęło do tej pory 30 minut gry. Jakimś sposobem szacowanie stanowi najtrudniejszą część tego etapu. Mogę tutaj: 1. Zrezygnować z szacowania (jak radzą guru Agile). 2. Zrobić to szybko i prosto. 3. Poświęcić trochę czasu na poćwiczenie planning pokera. Najszybsza technika Swimlane sizing 8
Minęło do tej pory 50 minut gry i nic nie zostało zbudowane Ograniczamy planowanie do 3 minut Zajmie 7 minut. Preferujemy sprinty 7-minutowe, ponieważ to wystarczająco dużo czasu aby kilka osób zbudowało kilka elementów bez nadmiernego dopracowywania ich. Aby upewnić się, że uczestnicy są wystarczająco zestresowani, pokazujemy na notebooku lub przez projektor, w widocznym miejscu, duży zegar z upływającym czasem: Zajmie 5 minut. Kiedy czas się kończy upewniam się, że uczestnicy faktycznie przestali budować i zaczynam dopytywać się gdzie jest moje miasto? Z obserwacji wynika, że dopiero po drugim sprincie zespoły zaczynają na bieżąco dostarczać budynki z ukończonych user stories na miejsce prezentacji (arkusz z flipcharta). W większości przypadków po pierwszym sprincie nikt tak faktycznie nie miał jeszcze pomysłu na to, jak dokonać prezentacji efektów pracy. Jako właściciel produktu nagle zdaję sobie sprawę, że: Lubię symetrię Wszystko w tym samym kolorze, faktycznie znaczyło jednolite kolory budynków, ale każdy z nich w innym kolorze. Budynki są zbyt małe, zbyt duże lub zbyt różnorodne. Okna na poszczególnych piętrach nie są w jednej linii. I wiele innych Nie dokończone elementy zostają cofnięte do backloga Możemy zmienić szacowanie Jeżeli user stories zostały przyjęte aktualizujemy wykres burn-down, ogłaszając że cały produkt ma być wydany po trzeci sprincie i że będzie ciężko Czas również na retrospekcję sprintu, czyli co możemy zrobić lepiej w kolejnym sprincie 9
Bez tracenia zbyt dużej ilości czasu na dyskutowanie porażek pierwszego sprintu, który zwykle jest katastrofą, przechodzimy do planowania kolejnego. Nauczyłem się, że potrzeba średnio trzech sprintów, aby zbudować 80% backlogu z zachowaniem oczekiwanej jakości. 1. Sprint #1 a. Planowanie 3 minuty b. Wykonanie (Sprint) 7 minut c. Ocena 5 minut 2. Sprint #2 d. Planowanie 3 minuty e. Wykonanie (Sprint) 7 minut f. Ocena 5 minut 3. Sprint #3 g. Planowanie 3 minuty h. Wykonanie (Sprint) 7 minut i. Ocena 5 minut Razem: 45 minut W związku z tym, że przygotowania zajęły nam ok. 1 godzinę (od określenia wizji do oszacowanego backlogu), sprinty zajęły 45 minut, 15 minut zajmie podsumowanie, więc cała gra trwa 120 minut. Prawdopodobnie dobrym pomysłem jest zrobienie krótkiej przerwy po ocenieniu ostatniego sprintu i przed przejściem do podsumowania, aby uspokoić emocje i krótko odpocząć (Czy mówiłem, że gra zaprojektowana jest, aby być wyczerpującą? Nie tylko dla zespołów...) Po zebraniu się z powrotem w kole, rozpoczynamy dyskusję pokierowaną wokół następujących pytań otwartych: Co uczestnicy zaobserwowali? Jakie to uczucie być w zespole Scrum? Jak poszły krótkie iteracje? Jak dokładne okazały się oszacowania (zakładając, że mamy przed sobą wykres burndown) Co zrobilibyśmy inaczej od samego początku, jeśli mielibyśmy jeszcze jedną okazję, aby rozegrać tę grę? Jakie było zadanie właściciela produktu? Jakie to uczucie, gdy po pierwszym sprincie prawie wszystko wymaga przeróbek? Co robili Scrum Masterzy? Jak zmieni się wasza strategia, jeśli będziecie wiedzieć, że właściciel produktu nie jest dostępny podczas sprintów? Jak poszła komunikacja pomiędzy zespołami? Czy pojawiły się jakieś zależności? Jak zostały rozwiązane? Czego się nauczyli uczestnicy? Można w dowolny sposób uwzględniać losowe elementy takie jak: zmiany rozmiaru zespołu oraz stopnia skomplikowania zadań. Po prostu, po planowaniu sprintu, ale tuż przed rozpoczęciem budowy, zespół rzuca kostką i albo zwiększa oszacowania user stories, albo Niektórzy z członków zespołu zostają wysłani na chorobowe na czas sprintu, podczas gdy zespół będzie musiał wykonać zaplanowaną już pracę. Celem takiej gry jest pokazanie, że współpraca w zespole jest kluczowa dla zrównoważenia zadań wykonywanych w trakcie sprintu, ponieważ coś może pójść inaczej niż to było planowane. Oczywiście Właściciel Produktu również może wprowadzić własne modyfikacje i z tym się nie dyskutuje 10
Utworzyć podobną mapę Internetu Aby uniknąć nieskończonego stopnia abstrakcji rozwiązania, wstępnie zmieniłem temat: Napisać program, który wizualizuje trasę pakietu i zaznacza jej przebieg na mapie. Po kilku reorganizacjach temat przybrał postać: Wizualizacja trasy pakietów generowanych przy ściąganiu stron www i cacheowanie wyników w bazie danych Czas przygotowania do zadania: Około 4-5 miesięcy zależy od zespołu Zespół nie wie, że jest przygotowywany do tego właśnie zdania, ja wiem Określenie silnych i słabych punktów poszczególnych członków zespołu Przygotowanie narzędzi pomocniczych, bibliotek do realizacji tego zadania: narzędzia te mają ułatwić rozwiązanie, ale w żaden sposób nie mogą go w całości rozwiązywać narzędzia mogą mieć błędy (zamierzone lub nie) Użyte technologie i narzędzia: Google maps tracert i ping MS Access i JDBC to wstępnie, a później migracja do MySQLa Dwa języki programowania JAVA i C++, w efekcie została tylko JAVA Planowane było również wykorzystanie basha ale Linux okazał się zbyt mało znany Wyrażenia regularne i serwis http://www.adres-ip.pl/geolokalizacja.html NFS, SVN Serwer HTTPPROXY produkcja własna ssh Timeboxing: 5 Sprintów + 1 dodatkowy Planowanie sprintu (około 15 minut) Sprinty 5 dniowe (czytaj 5 godzinne) Podsumowanie sprintu (około 30 minut do 15 minut) Daily scrum (około 5 minut) Aha, nie pracowaliśmy w domu, tzn. ja pracowałem, a zespół mam nadzieję, że nie, miał zakaz pracy w domu 11
Kto był kim 2 zespoły 7 osobowe Scrum master ja Klient - ja Właściciele produktu uczeń i uczennica o wyjątkowo humanistycznych predyspozycjach Dużo prostsza: Aplikacja spammująca Technologie: hmailserver przekazywanie poczty open rely Java klient spammera MySql baza adresów i tekstów Spammer a SCRUM 1 zespół 8 osób 3 sprinty po 5 godzin każdy 1 osoba w zespole zajmowała się testowaniem 1 osoba zajmowała się tworzeniem dokumentacji 1 osoba wytwarzała sensowne teksty spammerskie Aplikacja: Counter-Speeder Mamy daną aplikację, jak szybko dana aplikacja zostanie policzona dzisiaj, a jak szybko 10 lat temu. Technologie: Serwis http://www.top500.org z niego czerpiemy dane Java XML MySql Wyrażenia regularne SVN FreeMaker Top500 a SCRUM 1 zespół 8-9 osób 3 sprinty po 5 godzin każdy 1 osoba zajmowała się tworzeniem dokumentacji 1 osoba zajmowała się szacowanie złożoności, szukaniem benchmarków 1 osoba zrobiła prezentację wyników działania aplikacji Aplikacja: Remote compiler Aplikacja: Remote executor W przeglądarce wpisujemy kod, który kompiluje się i uruchamia na zdalnej maszynie. Po wykonaniu wyniki są zwracane i wyświetlane na stronie Technologie: Java SVN FreeMaker 12
http://scrum-game.pl/ http://www.lego4scrum.com/ http://pl.wikipedia.org/wiki/scrum http://en.wikipedia.org/wiki/scrum_(software_development) http://top500.org/ http://pl.wikipedia.org/wiki/internet http://www.slideshare.net/arekbee/scrum-8071975 13