SCRUMjak ugryźć i nie połamać sobie zębów - doświadczalnie

Michał Koniewiczmarzec 2016

Cele do osiągnięcia• Jakie są główne założenia SCRUM?• Jakie są praktyczne zagadnienia do uwzględnienia w

SCRUM?• Jak działa SCRUM w praktyce?• A kiedy nie działa i jak uniknąć typowych problemów?

Agenda• Teoria Teoretyczna - szybkie wprowadzenie do

SCRUM• Teoria Praktyczna – podbudowa doświadczalna• Zderzamy Teorie i Praktykę - czyli jak robimy

SCRUMem• Aspekty - Udany (i nieudany) SCRUM• Podsumowanie

O mnie

• Firma: Profi-Data• Od 15 lat zawodowo w IT• Od 13 lat zarządzanie projektami IT• Duże, średnie, małe projekty IT, pełny zakres• PRINCE2 Practitioner (CN# P2R/870526)• Zapalony fan Agile i szczecińskiego PMI• Kontakt www.linkedin.com/in/michalkoniewicz

Szybkie wprowadzenie do SCRUM

Teoria Teoretyczna

czyli szybkie wprowadzenie do SCRUM

Szybkie wprowadzenie do SCRUM• Historia powstania SCRUM• Problemy metod „klasycznych” / Waterfall• Ken Schwaber & Jeff Sutherland• The SCRUM Guide (PL)

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-PL.pdf• (zachęcam do przeczytania – tylko 18 stron wraz z tytułowa i spisem treści)

Szybkie wprowadzenie do SCRUMGłówne założenia SCRUM•Lekki•Łatwy do zrozumienia•Bardzo trudny do opanowania (ale mam nadzieję, że prezentacja trochę pomoże )

MK: A na dodatek SCRUM jest darmowy Źródło: The SCRUM Guide (PL) http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-PL.pdf

Szybkie wprowadzenie do SCRUM

SCRUM jest metodyką wytwórczą!a nie zarządczą, czy „jakąś inną” do przekładania

papierów z biurka na biurko. W każdej iteracji ma być konkretny Przyrost naszego

„Produktu”

Szybkie wprowadzenie do SCRUMGłówne założenia SCRUM•SPRINTy o stałej długości trwania•Każdy SPRINT ma dostarczać ukończony przyrost Produktu. •Stałość zakresu SPRINTU•Przejrzystość•Inspekcja•Adaptacja•Timeboxing!

Szybkie wprowadzenie do SCRUMRole w SCRUM – z kogo składa się Zespół SCRUMowy?•Product Owner (PO) – odpowiedzialność, wizja, rządzi BackLogiem. Tylko 1 osoba! •Zespół (Deweloperski) – zwany dalej Zespołem•Scrum Master (SM) – coach, dba aby SCRUM był rozumiany i stosowany

Szybkie wprowadzenie do SCRUMRole – Zespół (Deweloperski)•Odpowiada za przekształcanie BackLogu w Przyrost Produktu•Odpowiedzialność zespołowa•Samoorganizujący się•Równość – brak hierarchii•Min. 3, Maks. 9 osób•Interdyscyplinarny – komplet kompetencji niezbędny do wytworzenia przyrostu Produktu•„Zespół złożony z profesjonalistów”

Szybkie wprowadzenie do SCRUMSprint•SPRINT = „Projekt” (trwający maksymalnie miesiąc)•Sztywny okres czasu, zazwyczaj 1 do maks. 4 tygodni – Timeboxing!!!•Dostarcza ukończony Przyrost Produktu

Szybkie wprowadzenie do SCRUMArtefakty SCRUM - BackLogi •„Worki” na rzeczy, które są do zrobienia•Product Backlog•Sprint Backlog•Backlog Item, Historyjki Użytkownika (User Stories)•Zadania (Tasks)

Szybkie wprowadzenie do SCRUMDefinition of Done (DoD)•Kryterium Ukończenia, do oceny czy nasz Produkt / przyrost Produktu / element BackLogu jest „Done”•Gotowość „do użycia”•Wszyscy muszą rozumieć•Pomaga Zespołowi zaplanować prace•Współdzielone przez Zespoły pracujące na jednym Produktem•DoD nie jest sztywne – dojrzewa w czasie aby jakość naszego Produktu była jeszcze lepsza!

Szybkie wprowadzenie do SCRUM„Wydarzenia SCRUM (Events)”•Planowanie Sprintu (Sprint Planning)•Sprint•Codzienny SCRIM (Daily)•Przegląd Sprintu (Sprint Review)•Retrospektywa Sprintu (Sprint Retrospective)

Teoria Praktyczna

Teoria Praktyczna

aby lepiej zrozumieć SCRUM

Teoria Praktyczna• Problemy z klasycznymi metodami wytwarzania

(rozwiązań informatycznych)• „Analiza klasyczna” – silosowy wertykal • Wady klasycznego Waterfall’a• Oporność i odporność Waterfall na wprowadzanie

zmian• Brak namacalności Produktu do ostatnich etapów, to

jak mam stwierdzić czy to jest to co chcę?

Teoria Praktyczna

Źródło: https://www.scrumalliance.org/community/articles/2012/january/a-sprint-is-not-a-mini-waterfall

Waterfall vs SCRUM

Teoria PraktycznaJak działa SCRUM?

Źródło: http://deanhume.com/home/blogpost/the--ideal--sprint-length/90

Teoria PraktycznaAby robić, trzeba wiedzieć co …Trzeba zmienić sposób myślenia - Minimum Viable Product

Źródło: Henrik Kniberg http://blog.crisp.se/author/henrikkniberg

Teoria PraktycznaAby robić, trzeba wiedzieć co•Historyjki Użytkownika (US)•Historyjki mają reprezentować konkretne potrzeby „Klienta”•W dobre Historyjki trzeba ZaINVESTować•Ale cały czas mają być lekkie i przyjemne

Teoria PraktycznaHistoryjki (US) – jak definiować?•Horyzontalne podejście•Przekrojowe•Sposób definiowania•Cały czas pilnujemy aby były dobrą INVESTycją•User Stories – reprezentują potrzeby klienta

MK: Historyjki powinny cały czas odzwierciedlać potrzebę/-y Klienta

Teoria PraktycznaHistoryjki – zaINVESTujmyI – Independent (niezależne)N – Negotiable (negocjowalne)V – Valuable (dostarczają konkretną korzyść)E - Estimable (estymowalne)S – Small (wystarczająco małe do zaplanowania)T – Testable (testowalne)

Źródło: https://en.wikipedia.org/wiki/INVEST_(mnemonic)

Teoria PraktycznaHistoryjki – jak zdefiniować?

Jako <rola> chcę <potrzeba, funkcja>, aby <cel, uzasadnienie>

Jako Administrator chcę mieć możliwość zablokowania konta użytkownika, aby osoby nieuprawnione nie mogły korzystać z Systemu

Teoria PraktycznaHistoryjki – Kryteria Akceptacji•Historyjki *powinny* mieć Kryteria Akceptacji•Kryteria Akceptacji doprecyzowują jak Historyjki mają być zrobione•Nie mylić Kryteriów Akceptacji z Definition of Done •Kryteria Akceptacji to mega Pomoc dla „Testerów”•Najlepiej gdy definiowane (negocjowane) przez PO i ZespółPrzykład: Blokowanie kont z listy i dla pojedynczego rekordu użytkownika, tylko dla aktywnych. Potwierdzenie blokowania np. dialogiem.

Teoria PraktycznaHistoryjki – i co jeszcze?•Dobrze zapisana Historyjka Użytkownika:

Tytuł + Opis + Kryteria Akceptacji•Historyjki mogą mieć dodatkowe „specyfikacje” (opisy, screeny, etc.), ale należy pamiętać, że sama Historyjka to nie 50 stron dokumentacji!•KISS (Keep It Simple Stupid)

Teoria PraktycznaHistoryjki – szacowanie•„Understand that the accuracy of an estimate is more important than the precision of the estimate”„Celność” oszacowania vs Precyzja•Techniki szacowania Złożoności•Szacowanie przez porównanie•Często używane miarki•SCRUM Poker

Teoria PraktycznaHistoryjki – szacowanie - problem wzorca

Źródło: http://slideplayer.pl/slide/60560/ POMIAR I MIARA. I Liceum Ogólnokształcące im. Marii Skłodowskiej-Curie w Pile ID grupy: - 97/70_MF_G1 Kompetencja

Teoria PraktycznaHistoryjki - A po co w ogóle szacować?Czy szacowanie historyjek w Story Pointach służy do:a)przedstawieniu przez PO zarządowi lub klientowi informacji, że produkt będą mieli na 15 czerwca?b)dokładnemu wyliczeniu ile roboczogodzin lub roboczodni poświęci zespół na realizację?c)wyzwoleniu dyskusji w zespole odnośnie realizowalności historyjki?d)przydzieleniu historyjki do osoby, która "wyceniła" historyjkę najniżej?e)uzgodnieniu z PO podejścia do realizacji albo dekompozycji historyjki?f)uzyskaniu pięknych wykresików Sprint Burndown, Product/Release Burndown?

(można wybrać więcej niż jedną odpowiedź )

Teoria PraktycznaHistoryjki – Szacowanie - dlaczego nie należy szacować w rbh/rbd/md.?•Szacowanie Złożoności •Złożoność to nie to samo co Pracochłonność•Oderwanie się od księgowo-kadrowo-rozliczeniowej rutyny•Szacowanie to nie jest deklaracja Zespołu na rzeczywistą pracochłonność !!!

Teoria PraktycznaZespół SCRUM - Kim robić?•Obsada wszystkich „ról”•Nie łączyć ról PO i SM•W zespole ma być komplet Kompetencji•Zespół profesjonalistów•„Zasoby” zaalokowane w 100% do „naszego” SCRUMa!•Jedna lokalizacja - MK: „Zdalny” SCRUM sprawdza się „średnio”

Teoria PraktycznaSCRUM Tablica - przykład

Źródło: http://programmers.stackexchange.com/questions/21436/managing-production-issues-during-a-scrum-sprint

Teoria PraktycznaBackLog (BL)•Ciągłe zarządzanie BL (a nie na ostatnią chwilę)•Agregacja, podział, usuwanie BackLog Items/Historyjek•BackLog Item a User Stories•Product Backlog, Sprint Backlog•„Historyjki techniczne”

Teoria PraktycznaDefinition of Done (DoD)•Ogólne (Uniwersalne) reguły „ukończenia”•Dobrze mieć przygotowane przed pierwszym Sprintem•Warto unikać „szczególaryzmu”•Jak najbardziej zmieniać i dostosowywać DoD (ale z głową )•DoD vs Kryteria Akceptacji

Teoria PraktycznaNarzędzia, techniki (IT), agile development•Wszystkie zwinne: TDD, XP, Pair Programming•Wczesny commit do VCS, codzienny commit i build•Continuous Integration•Testy jednostkowe, automatyzacja testówPo co?Aby mieć wczesny „feedback”, a nie dopiero na koniec Sprintu.Automatyzacja zamiast „ręcznego dziobania”, aby była lekkość i zwinność

Aspekt - Udany SCRUMTimeboxing (SM)

Długość Sprintu →Wydarzenie ↓

1 w. 2 w. 3 w. 4 w.

Planning 2h 4h 6h max. 8h

Daily max. 15 min max. 15 min max. 15 min max. 15 min

Review 1h 2h 3h 4h

Retrospective 0,75h 1,5h 2,25h 3h

Teoria Praktyczna

MK: W SCRUMie nic oprócz timeboxów nie jest „na sztywno”

(bo przecież miała być elastyczność, lekkość i zwinność )

Teoria PraktycznaJeszcze warto zapamiętać:•PO – reprezentuje „wartość dla biznesu”, dba aby Backlog / priorytety prac odzwierciedlały korzyść / wartość dla biznesu.•Konsensus zakresu Backlogu Sprintu pomiędzy PO i Zespołem jest zawsze możliwy (ale czasem trzeba ponegocjować )

Zderzenie Teorii z PRAKTYKĄSCRUM doświadczalnie

z doświadczeń praktycznych

Zderzenie Teorii z PRAKTYKĄPlanowanie Sprintu (PO)•Uporządkowany BackLog przed Planningiem to jest „must have”!•Daj Zespołowi czas „przed” na zapoznanie się z BL•Przygotuj zarys Definition of Done•Zrób Sprint Planning Meeting

Zderzenie Teorii z PRAKTYKĄPlanowanie Sprintu – Sprint Planning Meeting•Prezentacja Historyjek przez PO•Rzutnik, tablica, karteczki, bardzo się przydają•Burza mózgów, pomysły na „ugryzienie”•Dekompozycja na Zadania•Szacowanie Zadań przez Zespół•Zatwierdzenie BackLogu (Sprintu) do realizacji w Sprincie

Zderzenie Teorii z PRAKTYKĄDefinition of Done (DoD)•„Could we ship it?”•Nie checklisty!•Nie drobiazgowo!•Dobrze gdy wskazuje kluczowe Produkty lub kluczowe działania•Zespół pomaga uzupełnić DoD•Pamiętajmy, że DoD nie jest „niezmienne” i ustalone raz na zawsze!

Zderzenie Teorii z PRAKTYKĄPlanowanie Sprintu•Nie „statyczne” zrzucenie BackLogu na Zespół•Historyjki vs Zadania•Szacowanie Historyjek •Dynamicznie i elastycznie - dekompozycja, agregacja, usuwanie Historyjek•Bez dużego nakładu – zasada Łatwo dodać, zmodyfikować, usunąć, poprawić. •Timeboxing! (SM)

Zderzenie Teorii z PRAKTYKĄPlanowanie Sprintu•2 Przebiegi zamiast „książkowej” 1 iteracji•Pytania, wątpliwości – omawianie•Wstępna koncepcja podziału prac•Druga iteracja•Docelowa koncepcja podziału prac / dekompozycja na Zadania•Timeboxing!!!

Zderzenie Teorii z PRAKTYKĄPlanowanie Sprintu – Zadania•Definiowanie Zadań (Kryteria i DoD są pomocne) – to Zespół ustala optymalne podejście!•Wszystkie „role” powinny mieć Zadania w Sprincie•Szacowanie pracochłonności zadań•Nie wszystkie Zadania muszą być zdefiniowane! (kryterium 60% zdefiniowanych Zadań jest ok)•Ilość zadań a pojemność zespołu•Kryterium 75% FTE (np. 6 z 8 rbh)

Zderzenie Teorii z PRAKTYKĄPlanowanie Sprintu•To Zespół ustala ile i jakich Historyjek (lub Backlog Item) „bierze na klatꔕPO nie może naciskać Zespołu•Zatwierdzony Sprint Backlog jest kontraktem między PO i Zespołem•Określony zostaje Cel Sprintu•Prac. Zadań < pojemność Zespołu (kryterium 75% FTE)•Zamrożony Backlog Sprintu

Zderzenie Teorii z PRAKTYKĄKryterium 75%Pytanie: Czemu mam „płacić” za „nieproduktywne” 2 rbh w ciągu 1 rbd?Odpowiedź: Po to abyś nie musiał płacić:•Za terminy, bo tylko „jeden ktoś” widział o co chodzi•Za terminy, bo ktoś coś pominął, niedoszacował•Za koszty szkoleń dedykowanych / transferu wiedzy•Za koszty jakości•Za odejścia pracowników, którym nie zapewnia się czasu na rozwój / samodoskonalenie

Ludzie nie są z gumy!

Zderzenie Teorii z PRAKTYKĄZaplanowaliśmy Sprint, no to lecimy!

Źródło: https://xpda.com/junkmail/junk166/military/

Zderzenie Teorii z PRAKTYKĄRealizacja Sprintu•Sprint startuje od razu po Planningu•Pobieranie (przypisywanie się do) Zadań•TODO, IN PROGRESS, DONE•Nie przypisywanie się osób do Historyjek!•Codzienne spotkania - Daily Meeting•PO i SM są zawsze dostępni dla Zespołu!•BackLog Sprintu się nie zmienia w trakcie Sprintu!

Zderzenie Teorii z PRAKTYKĄRealizacja Sprintu (Zespół)•Żadnych „mikro waterfall’i” w Zespole•Pracuje cały Zespół (wszystkie „role”) od początku Sprintu nad dowiezieniem zakontraktowanych Historyjek•PO trzyma się z dala od „mikromanagementu”•SM pomaga Zespołowi „dowieźć” zakontraktowane Historyjki

Zderzenie Teorii z PRAKTYKĄRealizacja Sprintu (Zespół) – Daily Meetings•Daily Meeting to podstawa•Stałe miejsce i czas. •Max. 15 minut – Timeboxing!•Na stojąco•PO i SM są opcjonalni (ale SM ma dbać, że Daily się odbywają)•To nie jest „status prac dla: PO*, SM*, Zarządu* (*-niepotrzebne skreślić)”!

Zderzenie Teorii z PRAKTYKĄRealizacja Sprintu (Zespół) – Daily cd.•3 tematy: co robiłem, co będę robił, jakie są problemy•Aktualizacja Zadań na SCRUM Tablicy•Tematy grube, dodatkowe pytania, kwestie do wyjaśnienia, wątpliwości – omawiane osobno (Timeboxing!)

Zderzenie Teorii z PRAKTYKĄRealizacja Sprintu (PO)A co robi Product Owner (PO) w trakcie Sprintu?•Jest cały czas dostępny dla Zespołu, odpowiada na pytania, klaryfikuje tematy.•Pracuje nad BackLogiem Produktu dla kolejnych Sprintów (co nie oznacza, ze robi to sam)•Jest „on-line” z SM

Zderzenie Teorii z PRAKTYKĄRealizacja Sprintu (SM)A co robi Scrum Master w trakcie Sprintu?•Wspiera Zespół•Dba o stosowanie reguł SCRUMa•Usuwa przeszkody (organizacyjne)•Jest na bieżąco z PO

Zderzenie Teorii z PRAKTYKĄRealizacja Sprintu – Minimalizacja „Work in Progress”•Nie rozgrzebywać zbyt dużej liczby historyjek•Optymalnie gdy Zespół koncentruje się na 1-2 Historyjkach „na raz” (zależy mocno od wielkości zespołu, doświadczenia, zakresu prac)•Dowiezienie vs rozgrzebanie

Zderzenie Teorii z PRAKTYKĄFinalizacja Sprintu – Sprint Review

Zderzenie Teorii z PRAKTYKĄFinalizacja Sprintu – Sprint Review•Uczestniczą wszyscy: PO, SM, Zespół •Review to nie są testy, Produkt ma być gotowy!•Formuła – prezentacja przez Zespół co zostało wykonane•PO zatwierdza co jest „Done” w oparciu o DoD•Zespół jest gratyfikowany *tylko* za ukończone („Done”) Historyjki, nie ma „zaliczeń” częściowych, połowicznych, etc.

Zderzenie Teorii z PRAKTYKĄFinalizacja Sprintu – Sprint Review – c.d.•Klasyfikacja „optymistyczna” i „pesymistyczna”•Aktualizacja BackLogu•Omówienie planu dalszych działań•Wynikiem jest Backlog (do kolejnego Sprintu)•Weryfikacja funkcjonalności przez PO przed Review (Timeboxing!)

Zderzenie Teorii z PRAKTYKĄFinalizacja Sprintu – Retrospektywa Sprintu (SM)•Inspekcja i Adaptacja•Co poszło dobrze, co poszło źle, co możemy poprawić?•Nie „obwinianie” się wzajemne•Dbaj o dowartościowany, obdarzony zaufaniem Zespół

Zderzenie Teorii z PRAKTYKĄ

I możemy starować kolejny Sprint

Aspekty - Udany SCRUMTip of the day

MK: Umiejętność mieszczenia się Zespołu w Timeboxach jest bardzo dobrym wskaźnikiem

sprawności całego Zespołu.

Jeżeli się nie mieścimy, to coś jest do poprawy.

Aspekty - Udany SCRUMDostosowuj SCRUM!•Adaptacyjność – są różne poziomy „startu” dla różnych projektów / różnej specyfiki projektów.•Nie warto „na siłę” zawsze robić „tak samo”. SCRUM musi być zaadaptowany do specyfiki / celu Projektu.

Przykłady: Mały projekt „technologiczny” vs Średni projekt „biznesowy”

Aspekty - Udany SCRUMCo robić aby SCRUM się udawał?•Bramki jakościowe do „wystartowania” kolejnego „zdarzenia” SCRUM•To co nam „wyłazi” poza SCRUM – wypychaj poza SCRUM (i nie przejmować się Organizacją)•Przygotowania, szkolenia – przez pierwszym Sprintem•Szerszy kontekst projektu (SCRUM – metodyka wytwórcza, nie wpychać wszystkiego w SCRUM)

Aspekty – Udany SCRUMAntywzorce•„Sprint 0”•Łączenie ról PO i SM•Za mały Zespół / za duży Zespół•Brak alokacji 100% osób w Zespole •Wystartowanie projektu SCRUM na zasadzie „jakoś to będzie”•Inni szacują, a jeszcze inni realizują

Aspekty – Udany SCRUMAntywzorce•Ponazywanie Wymagań klasycznej specyfikacji „Historyjkami”•Nienegocjowalne historyjki (problem SIWZ)•Przywiązywanie się do metryk SCRUM•SINO (SCRUM in Name Only) – grzeszki robienia „scrum” na pokaz

[Propozycje ?]

Aspekty – Udany SCRUM„Często zadawane pytania” •Słyszałem, że w SCRUMie nie trzeba tworzyć dokumentacji, czy to prawda?•Słyszałem, że w SCRUMie nie trzeba się przemęczać, czy to prawda?•Czy Product Owner lub Scrum Master powinni mieć wiedzę techniczną?

PodsumowanieJeżeli jest tak pięknie to czemu nie wszyscy stosują SCRUM?•Małe i średnie projekty•Problem dużych projektów (SCRUM of SCRUM)•Nie wszystkie projekty się nadają, •Brak zaangażowania Klienta•Brak zaufania•Niezrozumienie korzyści•Opór Klienta w zaakceptowaniu modelu finansowego

PodsumowanieJeżeli jest tak pięknie to czemu nie wszyscy stosują SCRUM?

Moje „top 3” przyczyny:1.Zaufanie, zaufanie, zaufanie2.Brak elastyczności Organizacji/Klienta3.Brak zaangażowania Organizacji/Klienta

PodsumowanieA co wg mnie daje SCRUM? (perspektywa ciężkometodycznego PMa )1.„Wydobycie” najlepszych umiejętności osób w Zespole2.Uniknięcie Mikrozarządzania3.Najskuteczniejsze przejście do Dobrze Wykonanej Pracy (zrobienie software’u „Done”)

Podsumowanie

Podsumowanie

Pytania?

PodsumowanieLinkownia:www.scrumguides.orgscrummethodology.comwww.mountaingoatsoftware.comScrum Practitioners (grupa linkedin)http://www.slideshare.net/PMI_Szczecin/michael-kacprzak-agile-project-management-dowiadczenia-z-okopw-na-wesoo (świetna prezentacja Michaela dot. Agile)

Coś na odreagowanie: http://devopsreactions.tumblr.com

Podsumowanie

Dziękuję za uwagę

Michał Koniewiczmarzec 2016