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

Like this? Share it with your network

Share

Zarządzanie projektami it metodyką scrum

on

  • 2,588 views

Prezentacja ze szkolenia dla studentów UMCS.

Prezentacja ze szkolenia dla studentów UMCS.

Statistics

Views

Total Views
2,588
Views on SlideShare
2,584
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 Presentation Transcript

  • 1. Zarządzanieprojektami IT metodyką SCRUM Cezary Kamioski
  • 2. 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
  • 3. 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
  • 4. 1. Metodyki prowadzenia projektów IT 2013-04-02 cezarykaminski.pl 4
  • 5. 1. Metodyki prowadzenia projektów IT Model kaskadowy 2013-04-02 cezarykaminski.pl 5
  • 6. 1. Metodyki prowadzenia projektów IT Model V 2013-04-02 cezarykaminski.pl 6
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 1. Metodyki prowadzenia projektów IT Czym jest SCRUM? 2013-04-02 cezarykaminski.pl 11 Źródło grafiki: agileforall.com
  • 12. 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
  • 13. 1. Metodyki prowadzenia projektów IT Kto używa SCRUM? • Microsoft • SUN • IBM • Yahoo • Google 2013-04-02 cezarykaminski.pl 13
  • 14. 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
  • 15. 2. Role projektowe Rola: Product Owner 2013-04-02 cezarykaminski.pl 15 Źródło grafiki: agileforall.com
  • 16. 2. Role projektowe Product Owner (Właściciel produktu) 2013-04-02 cezarykaminski.pl 16 Źródło grafiki: www.mspy.com
  • 17. 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
  • 18. 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
  • 19. 2. Role projektowe Rola: The Team 2013-04-02 cezarykaminski.pl 19 Źródło grafiki: agileforall.com
  • 20. 2. Role projektowe Rola: The Team 2013-04-02 cezarykaminski.pl 20 Źródło grafiki: www.mozaicworks.com
  • 21. 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
  • 22. 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
  • 23. 2. Role projektowe Rola: Scrum Master 2013-04-02 cezarykaminski.pl 23 Źródło grafiki: agileforall.com
  • 24. 2. Role projektowe Scrum Master (Mistrz młyna) 2013-04-02 cezarykaminski.pl 24 Źródło grafiki:www.fennassociates.com
  • 25. 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
  • 26. 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
  • 27. Narzędzie: Product Backlog2013-04-02 cezarykaminski.pl 27 Źródło grafiki: agileforall.com
  • 28. 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
  • 29. 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
  • 30. 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) 2013-04-02 cezarykaminski.pl 30 Źródło grafiki: www.romanpichler.com
  • 31. 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) 2013-04-02 cezarykaminski.pl 31
  • 32. 3. Proces i podstawowe narzędzia projektowe User Stories 2013-04-02 cezarykaminski.pl 32 Źródło grafiki: www.solutionsiq.com
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 3. Proces i podstawowe narzędzia projektowe Proces: Sprint Planning Meeting 2013-04-02 cezarykaminski.pl 42 Źródło grafiki: agileforall.com
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. 3. Proces i podstawowe narzędzia projektowe 2013-04-02 cezarykaminski.pl 46
  • 47. 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
  • 48. 3. Proces i podstawowe narzędzia projektowe Narzędzie: Sprint Backlog 2013-04-02 cezarykaminski.pl 48 Źródło grafiki: agileforall.com
  • 49. 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
  • 50. 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
  • 51. Narzędzia projektowe 2013-04-02 cezarykaminski.pl 51
  • 52. Proces: Sprint2013-04-02 cezarykaminski.pl 52 Źródło grafiki: agileforall.com
  • 53. 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
  • 54. 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
  • 55. 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
  • 56. 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
  • 57. 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
  • 58. 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
  • 59. 3. Proces i podstawowe narzędzia projektowe Sprint burndown (wykres wypalania) 2013-04-02 cezarykaminski.pl 59
  • 60. 3. Proces i podstawowe narzędzia projektowe Proces: Podsumowanie sprintu 2013-04-02 cezarykaminski.pl 60 Źródło grafiki: agileforall.com
  • 61. 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
  • 62. 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
  • 63. 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
  • 64. 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydao) 2013-04-02 cezarykaminski.pl 64
  • 65. 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydao) 2013-04-02 cezarykaminski.pl 65
  • 66. 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
  • 67. 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
  • 68. 5. Narzędzia wspomagające SCRUM`a Jira – plugin: GreenHopper 2013-04-02 cezarykaminski.pl 68 Źródło grafiki: http://www.atlassian.com
  • 69. 5. Narzędzia wspomagające SCRUM`a Kunagi 2013-04-02 cezarykaminski.pl 69
  • 70. Dziękuje za uwagę! Pytania, sugestie i komentarze: blog@cezarykaminski.pl2013-04-02 cezarykaminski.pl 70