<twoje imię nazwisko>

Prezentacja na temat: "<twoje imię nazwisko>"— Zapis prezentacji:

1 <twoje imię nazwisko>
Wprowadzenie do Scrum <twoje imię nazwisko> <data>

2 Wprowadzenie do Scrum Prezentowane przez <ty> <data>

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 Beedle
Poczatkowe 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ły
Postę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 interakcje
ponad 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ń projektu
Trudne 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 sprintu
Przyrost funkcjonalności Rejestr sprintu (Sprint Backlog) Return Gift wrap Cancel Rejestr Produktowy (Product Backlog)

12 Rysunek dostępny pod adresem www.mountaingoatsoftware.com/scrum
Podsumowanie 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 sprintu
Zmiana 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 produktu
Mistrz (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 produktu
Mistrz (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 ScrumMaster
Reprezentuje 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 Wielofunkcyjny
Programisci, 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 produktu
Mistrz (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 planistyczne
Wydajność 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ów
Codziennie 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 pytania
Co 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 sprincie
Zazwyczaj 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 nie
Zwykle minut Po każdym sprincie Uczestniczy cały zespół ScrumMaster Właściciel produktu Zespół Mogą być klienci oraz inni uczestnicy

29 Start / Stop / Kontynuacja
Cał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 produktu
Mistrz (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 produktu
Wymagania 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 produktu
Pozycja 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 sprintu
Czł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 sprintu
Każ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 16
Interfejs 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 sprintu
Godziny

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ób
Skalowalność 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 warunkami
Kopiowanie, 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 mike@mountaingoatsoftware.com
(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