Zarządzanie projektami it metodyką scrum

5,481 views
5,150 views

Published on

Prezentacja ze szkolenia dla studentów UMCS.

Published in: Business

Zarządzanie projektami it metodyką scrum

  1. 1. Zarządzanieprojektami IT metodyką SCRUM Cezary Kamioski
  2. 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. 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. 4. 1. Metodyki prowadzenia projektów IT 2013-04-02 cezarykaminski.pl 4
  5. 5. 1. Metodyki prowadzenia projektów IT Model kaskadowy 2013-04-02 cezarykaminski.pl 5
  6. 6. 1. Metodyki prowadzenia projektów IT Model V 2013-04-02 cezarykaminski.pl 6
  7. 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. 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. 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. 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. 11. 1. Metodyki prowadzenia projektów IT Czym jest SCRUM? 2013-04-02 cezarykaminski.pl 11 Źródło grafiki: agileforall.com
  12. 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. 13. 1. Metodyki prowadzenia projektów IT Kto używa SCRUM? • Microsoft • SUN • IBM • Yahoo • Google 2013-04-02 cezarykaminski.pl 13
  14. 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. 15. 2. Role projektowe Rola: Product Owner 2013-04-02 cezarykaminski.pl 15 Źródło grafiki: agileforall.com
  16. 16. 2. Role projektowe Product Owner (Właściciel produktu) 2013-04-02 cezarykaminski.pl 16 Źródło grafiki: www.mspy.com
  17. 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. 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. 19. 2. Role projektowe Rola: The Team 2013-04-02 cezarykaminski.pl 19 Źródło grafiki: agileforall.com
  20. 20. 2. Role projektowe Rola: The Team 2013-04-02 cezarykaminski.pl 20 Źródło grafiki: www.mozaicworks.com
  21. 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. 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. 23. 2. Role projektowe Rola: Scrum Master 2013-04-02 cezarykaminski.pl 23 Źródło grafiki: agileforall.com
  24. 24. 2. Role projektowe Scrum Master (Mistrz młyna) 2013-04-02 cezarykaminski.pl 24 Źródło grafiki:www.fennassociates.com
  25. 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. 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. 27. Narzędzie: Product Backlog2013-04-02 cezarykaminski.pl 27 Źródło grafiki: agileforall.com
  28. 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. 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. 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. 31. 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) 2013-04-02 cezarykaminski.pl 31
  32. 32. 3. Proces i podstawowe narzędzia projektowe User Stories 2013-04-02 cezarykaminski.pl 32 Źródło grafiki: www.solutionsiq.com
  33. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 46. 3. Proces i podstawowe narzędzia projektowe 2013-04-02 cezarykaminski.pl 46
  47. 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. 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. 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. 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. 51. Narzędzia projektowe 2013-04-02 cezarykaminski.pl 51
  52. 52. Proces: Sprint2013-04-02 cezarykaminski.pl 52 Źródło grafiki: agileforall.com
  53. 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. 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. 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. 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. 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. 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. 59. 3. Proces i podstawowe narzędzia projektowe Sprint burndown (wykres wypalania) 2013-04-02 cezarykaminski.pl 59
  60. 60. 3. Proces i podstawowe narzędzia projektowe Proces: Podsumowanie sprintu 2013-04-02 cezarykaminski.pl 60 Źródło grafiki: agileforall.com
  61. 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. 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. 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. 64. 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydao) 2013-04-02 cezarykaminski.pl 64
  65. 65. 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydao) 2013-04-02 cezarykaminski.pl 65
  66. 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. 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. 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. 69. 5. Narzędzia wspomagające SCRUM`a Kunagi 2013-04-02 cezarykaminski.pl 69
  70. 70. Dziękuje za uwagę! Pytania, sugestie i komentarze: blog@cezarykaminski.pl2013-04-02 cezarykaminski.pl 70

×