Zarządzanie projektami IT metodyką SCRUM. Cezary Kamiński

Transkrypt

1 Zarządzanie projektami IT metodyką SCRUM Cezary Kamiński

2 Kieruję 11 osobowym zespołem programistów. O mnie Zapewniam utrzymanie i rozwój 14 różnych aplikacji. Podnoszę jakość produktów i efektywność ich wytwarzania. Aktualnie w trakcie Certyfikacji ISTQB Test Manager. W planach na ten rok certyfikacja Prince 2 Practitioner oraz ITIL Foundation. Poza tym lubię turystykę motocyklową oraz muzykę rockową z lat 80-tych v.1.2 cezarykaminski.pl 2

3 Konspekt 1. Metodyki prowadzenia projektów IT. 2. Role projektowe w SCRUM. 3. Proces i podstawowe narzędzia projektowe. 4. Dodatkowe narzędzia projektowe. 5. Narzędzia wspomagające SCRUM v.1.2 cezarykaminski.pl 3

4 1. Metodyki prowadzenia projektów IT v.1.2 cezarykaminski.pl 4

5 1. Metodyki prowadzenia projektów IT Model kaskadowy (waterfall) v.1.2 cezarykaminski.pl 5

6 1. Metodyki prowadzenia projektów IT Model V v.1.2 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 końcu a ich naprawa jest droga. Niska elastyczność. Warunki biznesowe ulegają zmianie v.1.2 cezarykaminski.pl 7

8 Metodyki prowadzenia projektów IT Manifest Agile - geneza 1986 Japończycy Tackeushi i Nonaka opublikowali artykuł opisujący nowy sposób realizacji projektów Pierwsza oficjalna wizja Scruma Deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania, została opracowana na spotkaniu jakie miało miejsce w ośrodku wypoczynkowym Snowbird w USA. Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania v.1.2 cezarykaminski.pl 8 Źródło grafiki: 10yearsagile.org

9 1. Metodyki prowadzenia projektów IT Manifest Agile - treść 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 v.1.2 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 poprawić jakość programowania. Nie mówi: Jak kodować? Jak wersjonować kod? Jak dokumentować kod? SCRUM nie jest modelem ciągłego ulepszania procesów v.1.2 cezarykaminski.pl 10

11 1. Metodyki prowadzenia projektów IT Czym jest SCRUM? v.1.2 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ązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości. Scrum jest: Lekki, Łatwy do zrozumienia, Bardzo trudny do opanowania v.1.2 cezarykaminski.pl 12

13 1. Metodyki prowadzenia projektów IT Kto używa SCRUM? Microsoft SUN IBM Yahoo Google v.1.2 cezarykaminski.pl 13

14 1. Metodyki prowadzenia projektów IT Kiedy warto wdrożyć 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ść za produkt. Gdy jakość produktu jest ważna. Gdy etap produkcji może być jawny dla klienta v.1.2 cezarykaminski.pl 14

15 2. Role projektowe Rola: Product Owner v.1.2 cezarykaminski.pl 15 Źródło grafiki: agileforall.com

16 2. Role projektowe Product Owner (Właściciel produktu) v.1.2 cezarykaminski.pl 16 Źródło grafiki:

17 2. Role projektowe Product Owner (Właściciel produktu) Odpowiedzialność Rozumie ideę projektu. Odpowiada za wartość biznesową projektu i zwrot inwestycji (ROI). Nadaje priorytety wymaganiom. Jest arbitrem w kwestii rozumienia wymagań. Decyduje o wydaniach: dacie i zakresie. Może zmieniać kolejność realizacji wymagań. Może zrezygnować z rozwoju produktu v.1.2 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 uczestniczyć w spotkaniach SCRUM-owych. Jest bezpośrednio związany z produktem. Jest skłonny do negocjowania wymagań v.1.2 cezarykaminski.pl 18

19 2. Role projektowe Rola: The Team v.1.2 cezarykaminski.pl 19 Źródło grafiki: agileforall.com

20 2. Role projektowe Rola: The Team v.1.2 cezarykaminski.pl 20 Źródło grafiki:

21 2. Role projektowe The Team (zespół) Odpowiedzialność Samoorganizacja pracy. Priorytetyzowanie zadań 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 v.1.2 cezarykaminski.pl 21

22 2. Role projektowe The Team (zespół) Pożądane cechy Interdyscyplinarność (grafik, tester, deweloper, architekt, adimistrator, itd.). Umiejętność programowania w parach. Znajomość TDD. Znajomość code smells oraz doświadczenie w refactoringu. Znajomość Continuous Integration. Umiejętność pracy zespołowej. Otwartość na innowacje v.1.2 cezarykaminski.pl 22

23 2. Role projektowe Rola: Scrum Master v.1.2 cezarykaminski.pl 23 Źródło grafiki: agileforall.com

24 2. Role projektowe Scrum Master (Mistrz młyna) v.1.2 cezarykaminski.pl 24 Źródło grafiki:

25 2. Role projektowe Scrum Master (Mistrz młyna) Odpowiedzialność Dba o trzymanie się zasad Scruma. Zapewnia produktywność zespołu oraz podnosi jakość 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ądzać. Chroni zespół przed wpływami zewnętrznymi v.1.2 cezarykaminski.pl 25

26 2. Role projektowe Scrum Master (Mistrz młyna) Pożądane cechy Posiada umocowanie do pełnionej roli. Nie powinien być przełożonym żadnego z członków zespołu. Posiada zdolności przywódcze (team leader). Rozumie wizję Product Ownera. Rozumie pojemność zespołu. Umie rozwiązywać problemy. Posiada zdolności komunikacyjne v.1.2 cezarykaminski.pl 26

27 Narzędzie: Product Backlog v.1.2 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. Istotność wymagań określana poprzez priorytety. Zawiera również bugi i inne zadania, którymi ma się zająć zespół. Jeżeli nie czegoś w nim nie ma, to zespół się tym nie zajmuje. Jego wymagania są podstawą do pracy w sprintach v.1.2 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ść, Szacowaną wartość, Numer sprintu, Status (oczekujący, realizowany, wykonany). Kolejność ma znaczenie na początku są najważniejsze wymagania v.1.2 cezarykaminski.pl 29

30 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) v.1.2 cezarykaminski.pl 30 Źródło grafiki:

31 3. Proces i podstawowe narzędzia projektowe Product Backlog (Rejestr produktu) v.1.2 cezarykaminski.pl 31

32 3. Proces i podstawowe narzędzia projektowe User Stories v.1.2 cezarykaminski.pl 32 Źródło grafiki:

33 3. Proces i podstawowe narzędzia projektowe User Stories (Historie użytkownika) Służą do określenia wymagań uwzględniających różne punkty widzenia (różne role przyszłych użytkowników). Podmiotem jest zawsze użytkownik końcowy. Powinny wnosić wartość biznesową z perspektywy klienta. Powinny być proste i zrozumiałe. Powinny zawierać kryteria akceptacyjne (DOD). Skomplikowane historie to tzw. EPICS powinny zostać podzielone na user stories. Budowa: Czym są? Jako.. mogę.. dzięki temu v.1.2 cezarykaminski.pl 33

34 3. Proces i podstawowe narzędzia projektowe User Stories Jak je tworzyć? Zasada INVEST: Independent (niezależne), Negotiable (negocjowalne), Valuable (wartoścowe), Estimable (mierzalne), Small (małe), Testable (testowalne) v.1.2 cezarykaminski.pl 34

35 Narzędzia projektowe User Stories - przykłady Jako użytkownik mogę zalogować się do sklepu aby potem dokonać zakupów. Jako administrator mogę zablokować użytkownika dodającego spam, aby zapewnić czytelność serwisu. Jako redaktor mogę dodawać artykuły, które zostaną opublikowane na stronie głównej portalu. Jako zalogowany użytkownik sklepu chcę dokonać płatności on-line, dzięki temu system zarejestruje płatność w tym samym dniu v.1.2 cezarykaminski.pl 35

36 3. Proces i podstawowe narzędzia projektowe User Stories - ćwiczenie Cel: Przekształć poniższe wymagania w historie użytkownika wraz z kryteriami obioru. System powinien być dostępny jedynie dla zalogowanych użytkowników. System powinien posiadać wbudowany mechanizm pomocy kontekstowej dla wszystkich użytkowników. Po zakończeniu transakcji system powinien umożliwiać wydrukowanie polecenia przelewu bankowego wraz z uzupełnionymi danymi klienta oraz sklepu. Użytkownik powinien mieć możliwość przypomnienia hasła poprzez SMS. System powinien umożliwiać wygenerowanie korespondencji seryjnej dla listy klientów przygotowanej na podstawie dowolnie wybranych kryteriów (np. wiek, płeć, lokalizacja, łączna kwota zamówień) v.1.2 cezarykaminski.pl 36

37 3. Proces i podstawowe narzędzia projektowe User Stories - ćwiczenie System powinien być dostępny jedynie dla zalogowanych użytkowników. Jako użytkownik powinienem móc się zalogować, aby móc korzystać z systemu v.1.2 cezarykaminski.pl 37

38 3. Proces i podstawowe narzędzia projektowe User Stories - ćwiczenie System powinien posiadać wbudowany mechanizm pomocy kontekstowej dla wszystkich użytkowników. Jako użytkownik, powinienem móc skorzystać z pomocy kontekstowej, aby bez potrzeby przeglądania całej instrukcji w każdym momencie móc wyświetlić potrzebną pomoc v.1.2 cezarykaminski.pl 38

39 3. Proces i podstawowe narzędzia projektowe User Stories - ćwiczenie Po zakończeniu transakcji system powinien umożliwiać wydrukowanie polecenia przelewu bankowego wraz z uzupełnionymi danymi klienta oraz sklepu. Jako klient sklepu powinienem móc wydrukować polecenie przelewu zaraz po dokonaniu zakupu, aby zaoszczędzić czas na wypełnianiu druku ręcznie v.1.2 cezarykaminski.pl 39

40 3. Proces i podstawowe narzędzia projektowe User Stories - ćwiczenie Użytkownik powinien mieć możliwość przypomnienia hasła poprzez SMS Jako użytkownik, powinienem móc przypomnieć sobie hasło do serwisu za pomocą SMS, aby przyspieszyć proces odzyskiwania hasła v.1.2 cezarykaminski.pl 40

41 3. Proces i podstawowe narzędzia projektowe User Stories - ćwiczenie System powinien umożliwiać wygenerowanie korespondencji seryjnej dla listy klientów przygotowanej na podstawie dowolnie wybranych kryteriów (np. wiek, płeć, lokalizacja, łączna kwota zamówień). Jako użytkownik powinienem móc wydrukować korespondencję seryjną na podstawie dowolnie wybranych kryteriów, w celu wysłania oferty spersonalizowanej pod określoną grupę docelową v.1.2 cezarykaminski.pl 41

42 3. Proces i podstawowe narzędzia projektowe Proces: Sprint Planning Meeting v.1.2 cezarykaminski.pl 42 Źródło grafiki: agileforall.com

43 Proces sprintu Czym jest sprint Ustalony, powtarzalny okres czasu, w czasie którego dostarczany jest gotowy pakiet rozwiązań, przetestowanych i możliwych do zweryfikowania przez właściciela produktu. Nazywany również iteracją. Przyjmuje się, że sprint nie powinien być krótszy niż okres tygodnia i nie dłuższy niż miesiąc. Długość sprintu zależy od: Dostępności klienta, Wielkości zespołu, Specyfiki zadań (niektórych zadań nie da się podzielić na mniejsze), Doświadczenia zespołu w prowadzeniu projektów wg. SCRUM. Jeżeli sprint jest zbyt krótki zespół nie zdąży wytworzyć testowalnego produktu. Jeżeli sprint jest z długi tracimy sens założeń agile oraz spada efektywność pracy v.1.2 cezarykaminski.pl 43

44 3. Proces i podstawowe narzędzia projektowe Planowanie sprintu - przebieg Celem sprintu jest wykonanie przewidzianych zadań. Określamy dostępność członków zespołu a co za tym idzie pojemność 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 trwać dłużej niż 4 godziny dla sprintu 2 tygodniowego. Spotkanie powinno być podzielone na część oficjalną i techniczną v.1.2 cezarykaminski.pl 44

45 3. Proces i podstawowe narzędzia projektowe Planowanie sprintu DOD Definition Of Done. Oznacza stan, w którym uznajemy, że opowieść użytkownika została zrealizowana tj.: Kryteria akceptacyjne zostały spełnione, Wartość biznesowa została osiągnięta, Nie zwiększył się dług technologiczny v.1.2 cezarykaminski.pl 45

46 3. Proces i podstawowe narzędzia projektowe Planowanie sprintu DOD Przykłady 1. Testy akceptacyjne i regresyjne kończą 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ść systemu na poziomie 2 sekund. 6. Wszystkie komunikaty błędów w języku polskim v.1.2 cezarykaminski.pl 46

47 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ść zadania, jednostką może być godzina, punkt, dzień. Team velocity pojemność zespołu, tj. tyle ile zespół jest w stanie wykonać w czasie sprintu. Jeżeli liczymy w godzinach, to rozsądnie jest przyjąć 6 godzin pracy na osobę w ciągu dnia v.1.2 cezarykaminski.pl 47

48 3. Proces i podstawowe narzędzia projektowe v.1.2 cezarykaminski.pl 48

49 3. Proces i podstawowe narzędzia projektowe Narzędzie: Sprint Backlog v.1.2 cezarykaminski.pl 49 Źródło grafiki: agileforall.com

50 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 być zmieniany w czasie sprintu. Jego dane służą do tworzenia wykresu wypalania v.1.2 cezarykaminski.pl 50

51 3. Proces i podstawowe narzędzia projektowe Task 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 v.1.2 cezarykaminski.pl 51

52 Narzędzia projektowe v.1.2 cezarykaminski.pl 52

53 Proces: Sprint v.1.2 cezarykaminski.pl 53 Źródło grafiki: agileforall.com

54 3. Proces i podstawowe narzędzia projektowe v.1.2 cezarykaminski.pl 54

55 3. Proces i podstawowe narzędzia projektowe Narzędzia używane każdego dnia v.1.2 cezarykaminski.pl 55 Źródło grafiki: agileforall.com

56 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 v.1.2 cezarykaminski.pl 56

57 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ązań. Celem jest zapoznanie osób z postępem projektu. Wspomaga aktualizację wykresu wypalania. Mogą w nim uczestniczyć wszyscy interesariusze (świnki i kurczaki). Idealnie byłoby, gdyby właściciel produktu również się pojawiał (w praktyce bardzo trudne) v.1.2 cezarykaminski.pl 57

58 3. Proces i podstawowe narzędzia projektowe Daily standup - przebieg Każdy członek odpowiada na 3 pytania: Co zrobiłeś? Co planujesz robić? Jakie masz blokady? Gdy wszyscy się wypowiedzą, spotkanie zostaje zakończone. Pytania do Product Ownera powinny być zadawane po spotkaniu v.1.2 cezarykaminski.pl 58

59 3. Proces i podstawowe narzędzia projektowe Wykresy wypalania Dwa rodzaje: Dla sprintu pozwala śledzić postęp sprintu, Dla produktu pozwala śledzić i planować 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 v.1.2 cezarykaminski.pl 59

60 3. Proces i podstawowe narzędzia projektowe Sprint burndown (wykres wypalania) v.1.2 cezarykaminski.pl 60

61 3. Proces i podstawowe narzędzia projektowe Proces: Podsumowanie sprintu v.1.2 cezarykaminski.pl 61 Źródło grafiki: agileforall.com

62 3. Proces i podstawowe narzędzia projektowe Podsumowanie sprintu Prezentacja rzeczywistego, działającego produktu dla klienta. Pokazywane są jedynie skończone 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żać. Umożliwia wskazanie rozbieżności w rozumieniu User Stories, dzięki czemu kolejne mogą być pisane bardziej pod zespół projektowy v.1.2 cezarykaminski.pl 62

63 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 trwać dłużej niż godzinę przy sprincie 2 tygodniowym v.1.2 cezarykaminski.pl 63

64 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydań) Umożliwia monitorowanie postępu PROJEKTU. Budowany na podstawie dotychczasowych wykresów wypalania sprintu tj. pojemności zespołu (Team velocity). Powinien być aktualizowany po każdym sprincie v.1.2 cezarykaminski.pl 64

65 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydań) v.1.2 cezarykaminski.pl 65

66 4. Dodatkowe narzędzia projektowe Release burndown (wykres wydań) v.1.2 cezarykaminski.pl 66

67 4. Dodatkowe narzędzia projektowe Impediments backlog (Rejestr blokad) Zestawienie zdarzeń/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) v.1.2 cezarykaminski.pl 67

68 4. Dodatkowe narzędzia projektowe Rejestr ryzyk Zestawienie zdarzeń/elementów/funkcjonalności mogących spowodować niepowodzenie projektu/produktu. Proces zarządzania ryzykiem składa się z etapów: Identyfikacja ryzyka, Analiza ryzyka (prawdopodobieństwo wystąpienia, skutki), Opracowanie działań zaradczych, Monitorowanie i kontrola. Rejestr prowadzi Scrum Master. Ryzyka to nie blokady. Nie każde ryzyko wymaga podjęcia działań zaradczych! v.1.2 cezarykaminski.pl 68