1 Wprowadzenie do Scrum

2 Wprowadzenie do Scrum Prezentowane przez

3 Przegrywamy sztafetę Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986. Podejście do rozwoju produktu podobne do biegu sztafetowego ... może powodować konflikty z celami maksymalnej szybkości i elastyczności. Zamiast tego podejście całościowe, "rugby" - w którym zespół stara się osiągać cele jako całość, przekazując piłkę tam i z powrotem - może lepiej służyć współczesnym wymaganiom konkuren-cyjności." would be nice to include a quote from Wicked Problems here

4 Scrum w 100 słowach Scrum to zwinny proces, który pozwala nam skupić się na dostarczaniu najwyższej wartości biznesowej w najkrótszym czasie. Pozwala szybko i wielokrotnie weryfikować działające oprogramowanie (co dwa tygodnie do miesiąca). To biznes ustala priorytety. Zespoły samodzielnie organizują się, aby ustalić najlepsze sposoby na dostarczenie funkcjonalności o najwyższym priorytecie. Co dwa tygodnie do miesiąca każdy może zobaczyć działające oprogramowanie i zdecydować, czy wydać je takie, jakie jest, czy też nadal rozwijać je podczas kolejnego sprintu.

5 Pochodzenie Scrum Jeff Sutherland Ken Schwaber Mike BeedlePoczatkowe scrumy w Easel Corp w 1993 Firma IDX zespoły 500+ osobowe Ken Schwaber Prezes ADM Wraz z Sutherlandem zaprezentował Scrum jako metodykę - OOPSLA 96 Autor 3 książek o Scrumie Mike Beedle Wzorce Scrum na PLOPD4 Ken Schwaber and Mike Cohn Współtworzyli Scrum Alliance w 2002, początkowo z Agile Alliance

6 Scrum jest stosowany przez:Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

7 Scrum jest stosowany w:Oprogramowaniu komercyjnym Rozwoju na własne potrzeby Programach na zamówienie Projektach o ustalonej cenie Aplikacjach finansowych Aplikacjach z certyfikatem ISO 9001 Systemach wbudowanych Systemach z wymaganiami 99,999% uptime 24x7 Joint Strike Fighter Rozwóju gier wideo Systemach krytycznych dla życia Oprogramowaniu do sterowania satelitami Stronach internetowych Tabletach Telefonach komórkowych Aplikacjach dostawców sieciowych (ISV) Rozwoju niektórych z największych istniejących aplikacji

8 Charakterystyka Samoorganizujące się zespołyPostęp prac nad produktem następuje w miesięcznych „sprintach” Wymagania są gromadzone w postaci listy rejestru produktu - “product backlog” Brak narzuconych praktyk inżynierskich Ustalone reguły w celu stworzenia zwinnego środowiska projektowego Jeden z wielu „zwinnych procesów”

9 Manifest Agile Procesy i narzędzia Ludzie i interakcjeponad Obszerną dokumentację Działające oprogramowanie ponad Formalne ustalenia Współpraca z klientem ponad Podążanie za planem Reagowanie na zmiany ponad Źródło: polskie tłumaczenie pl.wikipedia.org

10 Poziom zakłóceń projektuTrudne do uzgodnienia Anarchia Skomplikowane Wymagania Złożone Źródło: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Proste Proste do uzgodnienia Technologia Nieprzewi- dywalna Przewidy- walna

11 Scrum 24 godziny Sprint 2-4 tygodnie Cel Sprint-u Rejestr sprintuPrzyrost funkcjonalności Rejestr sprintu (Sprint Backlog) Return Gift wrap Cancel Rejestr Produktowy (Product Backlog)

12 Rysunek dostępny pod adresem www.mountaingoatsoftware.com/scrumPodsumowanie Rysunek dostępny pod adresem

13 Sprints Postęp projektu w serii „sprintów”Analogiczne do iteracji w Extreme Programming Typowy czas trwania to 2–4 tygodnie Stały czas trwania prowadzi do lepszego rytmu Produkt jest projektowany, programowany i testowany podczas sprintu

14 Rozwój sekwencyjny a nakładający sięWymagania Projekt Kodowanie Test Zamiast robić każdą rzecz po kolei …w scrumie robimy wszystkiego trochę Źródło: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

15 Żadnych zmian podczas sprintuZmiana Długość sprintów powinna uwzględniać to, na jaki czas możemy wstrzymać się od wprowadzania zmian

16 Ramy Scrum Role Rytuały Artefakty Właściciel produktuMistrz (ScrumMaster) Zespół Role Planowanie sprintu Przegląd sprintu Retrospektywa Codzienny scrum Rytuały Rejestr produktowy Rejestr sprintu Wykres wypalania Artefakty

17 Scrum framework Role Rytuały Artefakty Właściciel produktuMistrz (ScrumMaster) Zespół Role Planowanie sprintu Przegląd sprintu Retrospektywa Codzienny scrum Rytuały Artefakty Rejestr produktowy Rejestr sprintu Wykres wypalania

18 Właściciel produktu (Product owner)Definiuje funkcjonalności produktu Decyduje o dacie wydania i zawartości Jest odpowiedzialny za dochodowość/ zwrot z inwestycji (ROI) dla produktu Priorytetyzuje funkcjonalności według ich wartości rynkowej. Dostosowuje priorytety w iteracjach Akceptuje wykonanie pracy

19 Mistrz - The ScrumMasterReprezentuje management w projekcie Odpowiada za wdrażanie praktyk i wartości Scrum Usuwa przeszkody Czuwa nad produktywnością zespołu Ułatwia współpracę pomiędzy funkcjami Chroni zespół przed zewnętrznymi ingerencjami

20 Zespół - The team Zwykle 5-9 osób WielofunkcyjnyProgramisci, testerzy, projektanci user experience itd. Członkowie pracują na cały etat Mogą być wyjątki (np. administrator baz danych)

21 Zespół - The team Samoorganizujacy sięIdealnie bez tytułów lecz wyjątkowo są one dopuszczalne Skład zespołu może się zmieniać tylko pomiędzy sprintami

22 Scrum - ramy Role Rytuały Artefakty Właściciel produktuMistrz (ScrumMaster) Zespół Role Planowanie sprintu Przegląd sprintu Retrospektywa Codzienny scrum Rytuały Rejestr produktowy Rejestr sprintu Wykres wypalania Artefakty

23 Cel sprintu Rejestr sprintu Spotkanie planistyczneWydajność zespołu Ustalenie priorytetów Analiza i szacowanie rejestru produktu Wybranie celu sprintu Cel sprintu Rejestr produktowy Warunki biznesowe Planowanie sprintu Plan osiągnięcia celu sprintu Przygotowanie rejestru sprintu (zadań) z rejestru produktu (opowieści użytkownika/ funkcjonalności) Estymacja rejestru produktu (h) Właściwy produkt Rejestr sprintu Techno-logia

24 Planowanie sprintu Zespół wybiera pozycje z rejestru produktu, do których wykonania może się zobowiązać Zostaje utworzony rejestr sprintu Zadania zostają zidentyfikowane i każde z nich zostaje estymowane (1-16 godzin) Planowanie wykonuje cały zespół a nie ScrumMaster Uwzględniony jest projekt całościowy Jako osoba wybierająca się na wakacje chciałbym zobaczyć zdjęcia hoteli. Warstwa funkcjonalna (8h) Interfejs użytkownika (4h) Testy jednostkowe (4h) Wykonanie klasy foo (6h) Testy wydajnościowe (4h)

25 Codzienny scrum Parametry Nie służy do rozwiazywania problemówCodziennie 15-minut Na stojaco Nie służy do rozwiazywania problemów Zapraszamy cały świat Mówić mogą tylko członkowie zespołu, ScrumMaster i właściciel produktu Pomaga w unikaniu dodatkowych spotkań

26 Każdy odpowiada na 3 pytaniaCo robiłeś wczoraj? 1 Co będziesz robić dzisiaj? 2 Czy coś utrudnia pracę? 3 Odpowiedzi nie są raportem dla ScrumMastera Są deklaracją przed innymi członkami zespołu

27 Przegląd sprintu Zespół prezentuje co osiągnął w sprincieZazwyczaj ma postać demo nowych funkcji lub architektury Nieformalny Zasada: 2 godziny przygotowań Brak slajdów Uczestniczy cały zespół Zapraszamy cały świat

28 Retrospektywa Okresowo, weryfikacja, co działa, a co nieZwykle minut Po każdym sprincie Uczestniczy cały zespół ScrumMaster Właściciel produktu Zespół Mogą być klienci oraz inni uczestnicy

29 Start / Stop / KontynuacjaCały zespół przedstawia i omawia co chciałby: Zacząć robić Przestać robić To tylko jeden ze sposobów przeprowadzenia retrospektywy sprintu Kontynuować

30 Scrum framework Roles Rytuały Artefakty Właściciel produktuMistrz (Scrum Master) Zespół Roles Planowanie sprintu Przegląd sprintu Retrospektywa Codzienny scrum Rytuały Rejestr produktowy Rejestr sprintu Wykres wypalania Artefakty

31 To jest rejestr produktuWymagania Lista wszystkich pożądanych prac w projekcie Idealnie-zapisane w taki sposób, aby każda pozycja przedstawiała wartość dla użytkownika lub klienta Priorytety ustala właściciel produktu Korekta priorytetów na początku każdego sprintu To jest rejestr produktu

32 Przykładowy rejestr produktuPozycja Estymata Gość może wykonać rezerwację. 3 Jako gość chcę mieć możliwość anulowania rezerwacji. 5 Jako gość chcę zmienić datę rezerwacji. Jako pracownik hotelu chcę mieć możliwość uruchomienia raportu RevPAR (revenue-per-available-room) 8 Poprawiona obsługa wyjątków ... 30 50

33 Cel sprintu Krótkie zdanie informujące, na jakiej pracy skupimy się podczas kolejnego sprintu Nauki przyrodnicze Wykonanie podstawowych funkcjonalności do badań DNA Aplikacja bazodanowa Możliwość uruchamiania aplikacji na bazie SQL Server oprócz Oracle Usługi finansowe Wsparcie dla większej liczby finansowych wskaźników technicznych niż ma firma ABC

34 Zarządzanie rejestrem sprintuCzłonkowie zespołu sami wybierają prace, które chcą wykonać Praca nie jest przydzielana odgórnie Praca pozostała do wykonywania jest aktualizowana codziennie

35 Zarządzanie rejestrem sprintuKażdy członek zespołu może dodawać, usuwać lub zmieniać rejestr sprintu Pojawiają się prace do wykonania Jeżeli praca jest niejasna, zdefiniuj pozycję rejestru z większym planowanym czasem, a następnie podziel go na mniejsze fragmenty Aktualizuj rejestr pozostałej pracy w miarę jak coraz więcej jest wiadome

36 Rejestr sprintu Zadanie Pon. Wt. Śr. Czw. Pt. 8 10 16 8 16 12 4 12 16Interfejs użytkownika Dodaj log błędów 8 10 16 8 16 12 4 12 16 8 4 11 8 8 Środkowa warstwa Test środkowej warstwa Napisanie pomocy online Napisanie klasy foo

37 Wykres wypalania sprintuGodziny

38 Zadanie Pon. Wt. Śr. Czw. Pt. Interfejs użytkownika 8 4 12 16 8 10 16 7 11 8 Środkowa warstwa 16 Test środkowej warstwa 8 Napisanie pomocy online 12 50 40 30 Godziny 20 10 Mon Tue Wed Thu Fri

39 Skalowalność Typowy zespół składa się z 7 ± 2 osóbSkalowalność poprzez zespoły zespołów Czynniki podczas skalowania Typ aplikacji Rozmiar zespołu Rozproszenie zespołu Czas trwania projektu Scrum był stosowany w projektach, w których uczestniczyło ponad 500 osób

40 Skalowanie poprzez „Scrum scrumów” (scrum of scrums)

41 „Scrum scrumów scrumów” (scrum of scrums of scrums)

42 Co dalej www.mountaingoatsoftware.com/scrum www.scrumalliance.org

43 Literatura o Scrum Agile and Iterative Development: A Manager’s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen

44 Literatura o Scrum Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber Succeeding with Agile by Mike Cohn User Stories Applied for Agile Software Development by Mike Cohn

45 Copyright Dozwolone jest: Pod następującymi warunkamiKopiowanie, dystrybucja, wyświetlanie i użytkowanie Tworzenie remiksów i adaptacji Pod następującymi warunkami Uznanie Autorstwa. Należy umieścić informację o twórcy w sposób opisany przez twórcę lub właściciela (ale nie w sposób, który sugerowałby uznanie dla Ciebie lub wykorzystania pracy). Nic w tej licencji nie umniejsza ani nie ogranicza praw moralnych twórcy Więcej informacji znajduje się pod adresem

46 Kontakt Autor prezentacji: Mike Cohn [email protected] (720) (office) Dopuszczalne jest usunięcie tego slajdu (lub dowolnego innego) pod warunkiem podania informacji skąd pochodzi ta prezentacja. Należy pozostawić logo i nazwę firmy (np. w lewym dolnym rogu). Możesz też zamiast tego umieścić gdzieś w prezentacji slajd mówiący o źródle, z którego pochodzi prezentacja lub jej fragmenty. Dziękuję Polskie tłumaczenie: Piotr Osiński