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

Wprowadzenie do Scrum Prezentowane przez <ty> <data>

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

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.

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

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

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

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”

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: www.agilemanifesto.org, polskie tłumaczenie pl.wikipedia.org

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

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)

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

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

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.

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

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

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

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

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

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)

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

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

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

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)

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ń

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

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

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

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ć

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

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

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

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

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

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

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

Wykres wypalania sprintu Godziny

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

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

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

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

Co dalej www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com

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

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

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 http://creativecommons.org/licenses/by/3.0/

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