Wprowadzenie do Scrum

1. Wprowadzeniedo Scrum <twoje imię nazwisko> <data>

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

3. 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." Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review,January 1986. Przegrywamy sztafetę

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 • Poczatkowe scrumyw 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. Ludzieiinterakcje Reagowanienazmiany Działające oprogramowanie Współpraca z klientem Podążanie za planem Obszerną dokumentację Formalneustalenia Procesy i narzędzia ponad ponad ponad ponad Manifest Agile Źródło: www.agilemanifesto.org, 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. 24 godziny Cel Sprint-u Gift wrap Return Cancel Rejestr sprintu (Sprint Backlog) Sprint 2-4 tygodnie Przyrost funkcjonalności Scrum Rejestr Produktowy (ProductBacklog)

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

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 • Długość sprintów powinna uwzględniać to, na jaki czas możemy wstrzymać się od wprowadzania zmian Zmiana

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

17. Rytuały Role • Planowanie sprintu • Przegląd sprintu • Retrospektywa • Codzienny scrum • Właściciel produktu • Mistrz (ScrumMaster) • Zespół Scrum framework 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. Role Artefakty Rytuały • Właściciel produktu • Mistrz (ScrumMaster) • Zespół • Rejestr produktowy • Rejestr sprintu • Wykres wypalania • Planowanie sprintu • Przegląd sprintu • Retrospektywa • Codzienny scrum Scrum - ramy

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

24. Warstwa funkcjonalna (8h) Interfejs użytkownika (4h) Testy jednostkowe (4h) Wykonanie klasy foo (6h) Testy wydajnościowe (4h) 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.

25. Codzienny scrum • Parametry • 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. 1 2 3 Co robiłeś wczoraj? Co będziesz robić dzisiaj? Czy coś utrudnia pracę? Każdy odpowiada na 3 pytania • Odpowiedzinie 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 godzinyprzygotowań • Brak slajdów • Uczestniczy cały zespół • Zapraszamy cały świat

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

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

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

31. 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

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

37. Wykres wypalania sprintu Godziny

38. 4 8 12 7 10 11 8 16 16 Zadanie Pon. Wt. Śr. Czw. Pt. Interfejs użytkownika 8 Środkowa warstwa 16 8 Test środkowej warstwa 12 Napisanie pomocy online 50 40 30 Godziny 20 10 0 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 • www.controlchaos.com • scrumdevelopment@yahoogroups.com

43. Literatura o Scrum • Agile and Iterative Development: A Manager’s Guide by Craig Larman • Agile Estimating and Planning by Mike Cohn • Agile Project Managementwith 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: • 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 adresemhttp://creativecommons.org/licenses/by/3.0/

46. Kontakt Autor prezentacji: Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110 (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 http://pl.linkedin.com/in/piotrosinski