• Save
Zarządzanie projektami it metodyką scrum
Upcoming SlideShare
Loading in...5
×
 

Zarządzanie projektami it metodyką scrum

on

  • 2,481 views

Prezentacja ze szkolenia dla studentów UMCS.

Prezentacja ze szkolenia dla studentów UMCS.

Statistics

Views

Total Views
2,481
Views on SlideShare
2,477
Embed Views
4

Actions

Likes
1
Downloads
1
Comments
0

2 Embeds 4

http://www.linkedin.com 3
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Zarządzanie projektami it metodyką scrum Zarządzanie projektami it metodyką scrum Presentation Transcript

  • Zarządzanieprojektami IT metodyką SCRUM Cezary Kamioski
  • O mnie • Kieruję 11 osobowym zespołem programistów. • Zapewniam utrzymanie i rozwój 14 różnych aplikacji. • Podnoszę jakośd produktów i efektywnośd ich wytwarzania. • Aktualnie w trakcie Certyfikacji ISTQB Test Manager. • W planach na ten rok certyfikacja Prince 2 Practitioner oraz ITIL Foundation.2013-04-02 cezarykaminski.pl 2
  • Konspekt1. Metodyki prowadzenia projektów IT.2. Role projektowe.3. Proces i podstawowe narzędzia projektowe.4. Dodatkowe narzędzia projektowe.5. Narzędzia wspomagające SCRUM.2013-04-02 cezarykaminski.pl 3 View slide
  • 1. Metodyki prowadzenia projektów IT 2013-04-02 cezarykaminski.pl 4 View slide
  • 1. Metodyki prowadzenia projektów IT Model kaskadowy 2013-04-02 cezarykaminski.pl 5
  • 1. Metodyki prowadzenia projektów IT Model V 2013-04-02 cezarykaminski.pl 6
  • Metodyki prowadzenia projektów IT Metodyki sztywne - wady • Problemy w komunikacji zespołu. • Niejasne wymagania klienta. • Przekraczająca terminy implementacja. • Testowanie zazwyczaj jest pomijane. • Defekty wykrywane są na koocu a ich naprawa jest droga. • Niska elastycznośd. • Warunki biznesowe ulegają zmianie. 2013-04-02 cezarykaminski.pl 7
  • Metodyki prowadzenia projektów IT Manifest Agile - geneza Deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania, została opracowana na spotkaniu jakie miało miejsce w dniach 11-13 lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA. Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania. Początki Scruma sięgają jednak 1995 roku. 2013-04-02 cezarykaminski.pl 8 Źródło grafiki: 10yearsagile.org
  • 1. Metodyki prowadzenia projektów IT Manifest Agile - treśd • Ludzie i interakcje ponad procesy i narzędzia. • Działające oprogramowanie ponad obszerną dokumentację. • Współpraca z klientem ponad formalne ustalenia. • Reagowanie na zmiany ponad podążanie za planem. 2013-04-02 cezarykaminski.pl 9
  • 1. Metodyki prowadzenia projektów IT Czym NIE jest SCRUM? • SCRUM nie jest panaceum na wszystkie problemy projektowe. • SCRUM nie mówi tym jak poprawid jakośd programowania. Nie mówi: • Jak kodowad? • Jak wersjonowad kod? • Jak dokumentowad kod? • SCRUM nie jest modelem ciągłego ulepszania procesów. 2013-04-02 cezarykaminski.pl 10
  • 1. Metodyki prowadzenia projektów IT Czym jest SCRUM? 2013-04-02 cezarykaminski.pl 11 Źródło grafiki: agileforall.com
  • 1. Metodyki prowadzenia projektów IT Czym jest SCRUM? Scrum jest metodą, przy użyciu której ludzie mogą z powodzeniem rozwiązywad złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzad produkty o najwyższej możliwej wartości. Scrum jest: • Lekki, • Łatwy do zrozumienia, • Bardzo trudny do opanowania. 2013-04-02 cezarykaminski.pl 12
  • 1. Metodyki prowadzenia projektów IT Kto używa SCRUM? • Microsoft • SUN • IBM • Yahoo • Google 2013-04-02 cezarykaminski.pl 13
  • 1. Metodyki prowadzenia projektów IT Kiedy warto wdrożyd SCRUM? • Gdy dopuszczalne są zmiany. • Gdy potrzebne są szybkie reakcje na zmiany. • Gdy zespół dysponuje doświadczonymi programistami (testy jednostkowe). • Gdy klient jest skłonny do współpracy i bierze odpowiedzialnośd za produkt. • Gdy jakośd produktu jest ważna. • Gdy etap produkcji może byd jawny dla klienta. 2013-04-02 cezarykaminski.pl 14
  • 2. Role projektowe Rola: Product Owner 2013-04-02 cezarykaminski.pl 15 Źródło grafiki: agileforall.com
  • 2. Role projektowe Product Owner (Właściciel produktu) 2013-04-02 cezarykaminski.pl 16 Źródło grafiki: www.mspy.com
  • 2. Role projektowe Product Owner (Właściciel produktu) Odpowiedzialność • Rozumie ideę projektu. • Odpowiada za wartośd biznesową projektu i zwrot inwestycji (ROI). • Nadaje priorytety wymaganiom. • Jest arbitrem w kwestii rozumienia wymagao. • Decyduje o wydaniach: dacie i zakresie. • Może zmieniad kolejnośd realizacji wymagao. • Może zrezygnowad z rozwoju produktu. 2013-04-02 cezarykaminski.pl 17
  • 2. Role projektowe Product Owner (Właściciel produktu) Pożądane cechy • Patrzy na projekt z szerszej perspektywy niż zespół projektowy. • Posiada kompetencje i umocowanie do podejmowania i egzekwowania swoich decyzji. • Dysponuje czasem aby uczestniczyd w spotkaniach SCRUM-owych. • Jest bezpośrednio związany z produktem. • Jest skłonny do negocjowania wymagao. 2013-04-02 cezarykaminski.pl 18
  • 2. Role projektowe Rola: The Team 2013-04-02 cezarykaminski.pl 19 Źródło grafiki: agileforall.com
  • 2. Role projektowe Rola: The Team 2013-04-02 cezarykaminski.pl 20 Źródło grafiki: www.mozaicworks.com
  • 2. Role projektowe The Team (zespół) Odpowiedzialność • Samoorganizacja pracy. • Priorytetyzowanie zadao w sprincie. • Szacowanie czasochłonności User Stories. • Produkcja kompletnej części produktu w czasie sprintu. • Testy jednostkowe i akceptacyjne. • Identyfikacja ryzyk i blokad oraz informowanie o tym Scrum Mastera. • Uczestniczenie w porannych spotkaniach. 2013-04-02 cezarykaminski.pl 21
  • 2. Role projektowe The Team (zespół) Pożądane cechy • Interdyscyplinarnośd (grafik, tester, deweloper, architekt, adimistrator, itd.). • Umiejętnośd programowania w parach. • Znajomośd TDD. • Znajomośd „code smells” oraz doświadczenie w refactoringu. • Znajomośd Continuous Integration. • Umiejętnośd pracy zespołowej. • Otwartośd na innowacje. 2013-04-02 cezarykaminski.pl 22
  • 2. Role projektowe Rola: Scrum Master 2013-04-02 cezarykaminski.pl 23 Źródło grafiki: agileforall.com
  • 2. Role projektowe Scrum Master (Mistrz młyna) 2013-04-02 cezarykaminski.pl 24 Źródło grafiki:www.fennassociates.com
  • 2. Role projektowe Scrum Master (Mistrz młyna) Odpowiedzialność • Dba o trzymanie się zasad Scruma. • Zapewnia produktywnośd zespołu oraz podnosi jakośd jego pracy. • Umożliwia bliską współpracę zespołu i komunikację. • Usuwa bariery/blokady. • Dba o uczestnictwo członków zespołu w spotkaniach. • Wspiera Product Ownera z zakresie znajomości Scruma. • Służy zespołowi zamiast nim zarządzad. • Chroni zespół przed wpływami zewnętrznymi. 2013-04-02 cezarykaminski.pl 25
  • 2. Role projektowe Scrum Master (Mistrz młyna) Pożądane cechy • Posiada umocowanie do pełnionej roli. • Nie powinien byd przełożonym żadnego z członków zespołu. • Posiada zdolności przywódcze (team leader). • Rozumie wizję Product Ownera. • Rozumie „pojemnośd” zespołu. • Umie rozwiązywad problemy. • Posiada zdolności komunikacyjne. 2013-04-02 cezarykaminski.pl 26
  • Narzędzie: Product Backlog2013-04-02 cezarykaminski.pl 27 Źródło grafiki: agileforall.com
  • 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) Ideowo • Zawiera wymagania istotne z punktu widzenia Product Ownera. • Priorytetyzuje go Product Owner. • Zawiera również bugi i inne zadania, którymi ma się zająd zespół. • Jeżeli nie czegoś w nim nie ma, to zespół się tym nie zajmuje. • Jego wymagania są podstawą do pracy w sprintach. 2013-04-02 cezarykaminski.pl 28
  • 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) Technicznie • Wykonany w postaci tabeli. • Jeden wiersz to jedno wymaganie. • Wymagania opisane są przez: – Identyfikator, – Tytuł, – Treśd, – Szacowaną wartośd , – Numer sprintu, – Status (oczekujący, realizowany, wykonany). • Kolejnośd ma znaczenie – na początku są najważniejsze wymagania. 2013-04-02 cezarykaminski.pl 29
  • 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) 2013-04-02 cezarykaminski.pl 30 Źródło grafiki: www.romanpichler.com
  • 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) 2013-04-02 cezarykaminski.pl 31
  • 3. Proces i podstawowe narzędzia projektowe User Stories 2013-04-02 cezarykaminski.pl 32 Źródło grafiki: www.solutionsiq.com
  • 3. Proces i podstawowe narzędzia projektowe User Stories (Historie użytkownika) • Służą do określenia wymagao uwzględniających różne punkty widzenia (różne role przyszłych użytkowników). • Podmiotem jest zawsze użytkownik koocowy. • Powinny wnosid wartośd biznesową z perspektywy klienta. • Powinny byd proste i zrozumiałe. • Powinny zawierad kryteria akceptacyjne (DOD). • Skomplikowane historie to tzw. EPICS – powinny zostad podzielone na user stories. • Budowa: Jako …….. mogę ….. dzięki temu…. 2013-04-02 cezarykaminski.pl 33
  • 3. Proces i podstawowe narzędzia projektowe User Stories • Historie tworzone wg. zasady INVEST: – Independent (niezależne), – Negotiable (negocjowalne), – Valuable (wartoścowe), – Estimable (mierzalne), – Small (małe), – Testable (testowalne). 2013-04-02 cezarykaminski.pl 34
  • Narzędzia projektowe User Stories - przykłady • Jako użytkownik mogę zalogowad się do sklepu aby potem dokonad zakupów. • Jako administrator mogę zablokowad użytkownika dodającego spam, aby zapewnid czytelnośd serwisu. • Jako redaktor mogę dodawad artykuły, które zostaną opublikowane na stronie głównej portalu. • Jako zalogowany użytkownik sklepu chcę dokonad płatności on-line, dzięki temu system zarejestruje płatnośd w tym samym dniu. 2013-04-02 cezarykaminski.pl 35
  • 3. Proces i podstawowe narzędzia projektowe User Stories - dwiczenie Cel: Przekształd poniższe wymagania w historie użytkownika wraz z kryteriami obioru. • System powinien byd dostępny jedynie dla zalogowanych użytkowników. • System powinien posiadad wbudowany mechanizm pomocy kontekstowej dla wszystkich użytkowników. • Po zakooczeniu transakcji system powinien umożliwiad wydrukowanie polecenia przelewu bankowego wraz z uzupełnionymi danymi klienta oraz sklepu. • Użytkownik powinien mied możliwośd przypomnienia hasła poprzez SMS. • System powinien umożliwiad wygenerowanie korespondencji seryjnej dla listy klientów przygotowanej na podstawie dowolnie wybranych kryteriów (np. wiek, płed, lokalizacja, łączna kwota zamówieo). 2013-04-02 cezarykaminski.pl 36
  • 3. Proces i podstawowe narzędzia projektowe User Stories - dwiczenie • System powinien byd dostępny jedynie dla zalogowanych użytkowników. • Jako użytkownik powinienem móc się zalogowad, aby móc korzystad z systemu. 2013-04-02 cezarykaminski.pl 37
  • 3. Proces i podstawowe narzędzia projektowe User Stories - dwiczenie • System powinien posiadad wbudowany mechanizm pomocy kontekstowej dla wszystkich użytkowników. • Jako użytkownik, powinienem móc skorzystad z pomocy kontekstowej, aby bez potrzeby przeglądania całej instrukcji w każdym momencie móc wyświetlid potrzebną pomoc. 2013-04-02 cezarykaminski.pl 38
  • 3. Proces i podstawowe narzędzia projektowe User Stories - dwiczenie • Po zakooczeniu transakcji system powinien umożliwiad wydrukowanie polecenia przelewu bankowego wraz z uzupełnionymi danymi klienta oraz sklepu. • Jako klient sklepu powinienem móc wydrukowad polecenie przelewu zaraz po dokonaniu zakupu, aby zaoszczędzid czas na wypełnianiu druku ręcznie. 2013-04-02 cezarykaminski.pl 39
  • 3. Proces i podstawowe narzędzia projektowe User Stories - dwiczenie • Użytkownik powinien mied możliwośd przypomnienia hasła poprzez SMS • Jako użytkownik, powinienem móc przypomnied sobie hasło do serwisu za pomocą SMS, aby przyspieszyd proces odzyskiwania hasła. 2013-04-02 cezarykaminski.pl 40
  • 3. Proces i podstawowe narzędzia projektowe User Stories - dwiczenie • System powinien umożliwiad wygenerowanie korespondencji seryjnej dla listy klientów przygotowanej na podstawie dowolnie wybranych kryteriów (np. wiek, płed, lokalizacja, łączna kwota zamówieo). • Jako użytkownik powinienem móc wydrukowad korespondencję seryjną na podstawie dowolnie wybranych kryteriów, w celu wysłania oferty spersonalizowanej pod określoną grupę docelową. 2013-04-02 cezarykaminski.pl 41
  • 3. Proces i podstawowe narzędzia projektowe Proces: Sprint Planning Meeting 2013-04-02 cezarykaminski.pl 42 Źródło grafiki: agileforall.com
  • 3. Proces i podstawowe narzędzia projektowe Planowanie sprintu • DOD – Definition Of Done. • Oznacza stan, w którym uznajemy, że opowieśd użytkownika została zrealizowana tj.: – Kryteria akceptacyjne zostały spełnione, – Wartośd biznesowa została osiągnięta, – Nie zwiększył się dług technologiczny. 2013-04-02 cezarykaminski.pl 43
  • 3. Proces i podstawowe narzędzia projektowe Planowanie sprintu DOD – Przykłady 1. Testy akceptacyjne i regresyjne kooczą się sukcesem. 2. Dokumentacja kodu i pokrycia go testami jednostkowymi kształtuje się na poziomie 60%. 3. Kryteria akceptacyjne zostały spełnione. 4. Kod został pozytywnie oceniony przez architekta lub starszego programistę. 5. Responsywnośd systemu na poziomie 2 sekund. 6. Wszystkie komunikaty błędów w języku polskim. 2013-04-02 cezarykaminski.pl 44
  • 3. Proces i podstawowe narzędzia projektowe Planowanie sprintu Pojęcia: • Planning Poker – technika szacowania czasochłonności historii użytkownika podobna do gry w pokera. Każdy programista wykłada kartę reprezentującą jego szacunek. Jeżeli są rozbieżności – dyskutuje się o nich aż do uzyskania konsensusu. • Estimation – oszacowana wg. przyjętej jednostki czasochłonnośd zadania, jednostką może byd godzina, punkt, dzieo. • Team velocity – pojemnośd zespołu, tj. tyle ile zespół jest w stanie wykonad w czasie sprintu. Jeżeli liczymy w godzinach, to rozsądnie jest przyjąd 6 godzin pracy na osobę w ciągu dnia. 2013-04-02 cezarykaminski.pl 45
  • 3. Proces i podstawowe narzędzia projektowe 2013-04-02 cezarykaminski.pl 46
  • 3. Proces i podstawowe narzędzia projektowe Planowanie sprintu - przebieg • Celem sprintu jest wykonanie przewidzianych zadao. • Określamy dostępnośd członków zespołu a co za tym idzie „pojemnośd zespołu”. • Product Owner wraz z Teamem wybiera pracę na najbliższy sprint: – Dyskutuje się na temat prac, – Uszczegóławia się kryteria akceptacyjne i DOD, – Czasami dokonuje się ponownego szacowania niektórych prac, – Powyższe punkty powtarza się do momentu aż zespół przyjmie zobowiązanie. • Spotkanie nie powinno trwad dłużej niż 4 godziny dla sprintu 2 tygodniowego. • Spotkanie powinno byd podzielone na częśd oficjalną i techniczną. 2013-04-02 cezarykaminski.pl 47
  • 3. Proces i podstawowe narzędzia projektowe Narzędzie: Sprint Backlog 2013-04-02 cezarykaminski.pl 48 Źródło grafiki: agileforall.com
  • 3. Proces i podstawowe narzędzia projektowe Sprint Backlog (Rejestr sprintu) • Rejestr User Stories wybranych przez zespół do realizacji w danym sprincie. • Stanowi informację o tym czym zespół zajmuje się danego dnia. • Umożliwia śledzenie postępu realizacji prac. • Nie powinien byd zmieniany w czasie sprintu. • Jego dane służą do tworzenia wykresu wypalania. 2013-04-02 cezarykaminski.pl 49
  • 3. Proces i podstawowe narzędzia projektowe Tast board • Tradycyjna forma reprezentacji Sprit Backlog. • Umieszczamy na niej User Stories. • Dzielimy ją na kolumny: – Do zrobienia, – W realizacji, – (Opcjonalnie: Testowane), – Zrobione. • Dzielimy na niej US na Taski. 2013-04-02 cezarykaminski.pl 50
  • Narzędzia projektowe 2013-04-02 cezarykaminski.pl 51
  • Proces: Sprint2013-04-02 cezarykaminski.pl 52 Źródło grafiki: agileforall.com
  • Proces sprintu Czym jest sprint • Ustalony, powtarzalny okres czasu, w czasie którego dostarczany jest gotowy pakiet rozwiązao, przetestowanych i możliwych do zweryfikowania przez właściciela produktu. • Nazywany również iteracją. • Przyjmuje się, że sprint nie powinien byd krótszy niż okres tygodnia i nie dłuższy niż miesiąc. • Długośd sprintu zależy od: – Dostępności klienta, – Wielkości zespołu, – Specyfiki zadao (niektórych zadao nie da się podzielid na mniejsze), – Doświadczenia zespołu w prowadzeniu projektów wg. SCRUM. • Jeżeli sprint jest zbyt krótki – zespół nie zdąży wytworzyd testowalnego produktu. • Jeżeli sprint jest z długi – tracimy sens założeo „agile” oraz spada efektywnośd pracy. 2013-04-02 cezarykaminski.pl 53
  • 3. Proces i podstawowe narzędzia projektowe Narzędzia używane każdego dnia 2013-04-02 cezarykaminski.pl 54 Źródło grafiki: agileforall.com
  • 3. Proces i podstawowe narzędzia projektowe Kurczaki i prosiaki Dwa rodzaje zaangażowania: – Prosiaki się poświęcają • Najczęściej programiści, mają prawo głosu standach. – Kurczaki jedynie angażują • Pozostali interesariusze, nie mają głosu na standach. 2013-04-02 cezarykaminski.pl 55
  • 3. Proces i podstawowe narzędzia projektowe Daily standup - założenia • 15 min dziennie, na stojąco. • Prowadzone przez Scrum Mastera. • Bez dyskusji o problemach i szukania rozwiązao. • Celem jest zapoznanie osób z postępem projektu. • Wspomaga aktualizację wykresu wypalania. • Mogą w nim uczestniczyd wszyscy interesariusze (świnki i kurczaki). • Idealnie byłoby, gdyby właściciel produktu również się pojawiał (w praktyce bardzo trudne). 2013-04-02 cezarykaminski.pl 56
  • 3. Proces i podstawowe narzędzia projektowe Daily standup - przebieg • Każdy członek odpowiada na 3 pytania: – Co zrobiłeś? – Co planujesz robid? – Jakie masz blokady? • Gdy wszyscy się wypowiedzą, spotkanie zostaje zakooczone. • Pytania do Product Ownera powinny byd zadawane po spotkaniu. 2013-04-02 cezarykaminski.pl 57
  • 3. Proces i podstawowe narzędzia projektowe Wykresy wypalania • Dwa rodzaje: – Dla sprintu – pozwala śledzid postęp sprintu, – Dla produktu – pozwala śledzid i planowad wydania. • Celem jest osiągnięcie zera najpóźniej w ostatnim dniu sprintu. • Zwykle zawiera dwie linie: – Idealny przebieg – wyliczony automatycznie, – Realny przebieg – na podstawie danych ze tablicy sprintu. 2013-04-02 cezarykaminski.pl 58
  • 3. Proces i podstawowe narzędzia projektowe Sprint burndown (wykres wypalania) 2013-04-02 cezarykaminski.pl 59
  • 3. Proces i podstawowe narzędzia projektowe Proces: Podsumowanie sprintu 2013-04-02 cezarykaminski.pl 60 Źródło grafiki: agileforall.com
  • 3. Proces i podstawowe narzędzia projektowe Podsumowanie sprintu • Prezentacja rzeczywistego, działającego produktu dla klienta. • Pokazywane są jedynie skooczone funkcjonalności. • Prace niezaakceptowane przez klienta wracają do Rejestru Produktu. • Właściciel produktu weryfikuje funkcjonalności z DOD. • Pierwsze spotkania mogą się przedłużad. • Umożliwia wskazanie rozbieżności w rozumieniu User Stories, dzięki czemu kolejne mogą byd pisane bardziej pod zespół projektowy. 2013-04-02 cezarykaminski.pl 61
  • 3. Proces i podstawowe narzędzia projektowe Retrospektywa sprintu • Służy szczerej ocenie pracy podczas sprintu. • Odpowiada na pytania: – Co poszło nie tak? – Co poszło dobrze? • Uczestniczą w nim Product Owner, Scrum Master oraz The Team, • Nie powinna trwad dłużej niż godzinę przy sprincie 2 tygodniowym. 2013-04-02 cezarykaminski.pl 62
  • 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydao) • Umożliwia monitorowanie postępu PROJEKTU. • Budowany na podstawie dotychczasowych wykresów wypalania sprintu tj. pojemności zespołu (Team velocity). • Powinien byd aktualizowany po każdym sprincie. 2013-04-02 cezarykaminski.pl 63
  • 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydao) 2013-04-02 cezarykaminski.pl 64
  • 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydao) 2013-04-02 cezarykaminski.pl 65
  • 4. Dodatkowe narzędzia projektowe Impediments backlog (Rejestr blokad) • Zestawienie zdarzeo/elementów/funkcjonalności opóźniających pracę zespołu. • Prowadzony przez Scrum Mastera, informacje zbiera na codziennych spotkaniach, na których również informuje o ich rozwiązaniu. • Niekoniecznie związany z technologią (np. brak kawy, źle ustawiona klimatyzacja. • Każda blokada opisana przez: – Opis problemu, – Priorytet, – Ewentualne powiązanie z User Story. – Status (nowa, realizowana, rozwiązana). 2013-04-02 cezarykaminski.pl 66
  • 4. Dodatkowe narzędzia projektowe Rejestr ryzyk • Zestawienie zdarzeo/elementów/funkcjonalności mogących spowodowad niepowodzenie projektu/produktu. • Proces zarządzania ryzykiem składa się z etapów: – Identyfikacja ryzyka, – Analiza ryzyka (prawdopodobieostwo wystąpienia, skutki), – Opracowanie działao zaradczych, – Monitorowanie i kontrola. • Rejestr prowadzi Scrum Master. • Ryzyka to nie blokady. • Nie każde ryzyko wymaga podjęcia działao zaradczych! 2013-04-02 cezarykaminski.pl 67
  • 5. Narzędzia wspomagające SCRUM`a Jira – plugin: GreenHopper 2013-04-02 cezarykaminski.pl 68 Źródło grafiki: http://www.atlassian.com
  • 5. Narzędzia wspomagające SCRUM`a Kunagi 2013-04-02 cezarykaminski.pl 69
  • Dziękuje za uwagę! Pytania, sugestie i komentarze: blog@cezarykaminski.pl2013-04-02 cezarykaminski.pl 70