Professional Documents
Culture Documents
(Praca Inzynierska) Prince2vsScrum - 1.1
(Praca Inzynierska) Prince2vsScrum - 1.1
1
Spis Treści
1. Cel...........................................................................................................................................4
2. Informacje o zastosowanych metodach..................................................................................4
3. Rozwiązanie problemu............................................................................................................4
4. Zawartość pracy......................................................................................................................5
5. Dokumentacja techniczna z wykonanego systemu IT............................................................5
1. Przejrzyj zawartość strony............................................................................................7
2. Znajdź wycieczkę..........................................................................................................8
3. Wyszukaj ofertę...........................................................................................................10
4. Dodaj komentarz..........................................................................................................12
5. Pokaż komentarze.......................................................................................................13
6. Rejestruj się.................................................................................................................14
7. Zaloguj się...................................................................................................................16
8. Edytuj dane..................................................................................................................17
9. Zapisz na newsletter...................................................................................................18
10. Zarządzaj schowkiem................................................................................................19
11. Zarezerwuj ofertę.......................................................................................................20
12. Modyfikuj zawartość strony......................................................................................21
13. Zarządzaj użytkownikami..........................................................................................25
14. Zarządzaj grupami użytkowników...........................................................................26
15. Modyfikuj dane klientów...........................................................................................27
16. Modyfikuj rezerwacje................................................................................................28
17. Modyfikuj Emaile......................................................................................................29
6. Diagram związków encji.......................................................................................................30
1. Dodanie nowego newsa przez administratora:............................................................31
2. Dodanie nowego typu wakacji przez administratora...................................................33
3. Dodanie nowego hotelu przez administratora:............................................................34
4. Dodanie pliku do galerii plików..................................................................................36
5. Dodaj użytkownika......................................................................................................37
7. Opis oraz porównanie metodyki Prince2 oraz metodyki Scrum ..........................................38
8. Opis Prince2..........................................................................................................................38
Uruchamianie projektu/Przygotowanie projektu(PP)......................................................40
Zarządzanie strategiczne projektem (ZS)........................................................................40
Planowanie(PL) ..............................................................................................................41
Inicjowanie projektu (IP).................................................................................................41
Sterowanie etapem (SE)..................................................................................................41
Zarządzanie zakresem etapu (ZE)...................................................................................42
Zamykanie projektu (ZP).................................................................................................42
Uzasadnienie biznesowe..................................................................................................43
Organizacja......................................................................................................................43
Role w Prince2:...............................................................................................................43
Zakresy obowiązków.......................................................................................................44
Plany................................................................................................................................45
Elementy sterowania........................................................................................................45
Zarządzanie ryzykiem......................................................................................................46
Parametry ryzyka w PRINCE2........................................................................................46
Jakość w środowisku projektowym.................................................................................46
Zarządzanie konfiguracją.................................................................................................46
2
Sterowanie zmianami......................................................................................................47
Planowanie oparte na produktach....................................................................................47
Sterowanie zmianami......................................................................................................47
Przeglądy jakości.............................................................................................................48
Dokumentacja inicjująca projekt ....................................................................................48
Rejestry............................................................................................................................48
Raporty............................................................................................................................48
Plany................................................................................................................................49
9. Opis Scrum............................................................................................................................49
Mistrz...............................................................................................................................50
Właściciel Produktu.........................................................................................................50
Zespół..............................................................................................................................51
Spotkanie planistyczne wydania......................................................................................51
Sprint...............................................................................................................................52
Spotkanie planistyczne Sprintu.......................................................................................53
Przegląd Sprintu..............................................................................................................54
Retrospektywa Sprintu....................................................................................................54
Codzienny Scrum............................................................................................................54
Rejestr produktowy i wypalanie w projekcie..................................................................55
Rejestr zadaniowy i wypalanie w Sprincie......................................................................56
Wykres wypalania w Sprincie to wykres przedstawiający..............................................57
„Gotowe”, czyli kryterium gotowości produkcyjnej (Definition of Done, DoD)...........57
Planowanie w Prince2.....................................................................................................59
Planowanie w Scrum.......................................................................................................61
Podsumowanie.................................................................................................................62
Zakres obowiązków Komitetu Sterującego ....................................................................63
Zakres obowiązków Głównego użytkownika produktu .................................................63
Zakres obowiązków Głównego dostawcy produktu .......................................................63
Zakres obowiązków Przewodniczącego Komitetu Sterującego .....................................64
Zakres obowiązków Kierownika Projektu .....................................................................64
Zakres obowiązków Nadzoru projektowego...................................................................64
Zakres obowiązków kierownika zespołu.........................................................................64
Zakres obowiązków wsparcia projektowego...................................................................64
Zakres obowiązków właściciela ryzyka..........................................................................65
Zakres obowiązków Interesariusza..................................................................................65
Zakres obowiązków Scrum mastera................................................................................65
Zakres obowiązków Produkt ownera..............................................................................65
Zakres obowiązków członka zespołu..............................................................................65
10. Wymagania funkcjonalne...................................................................................................65
11. Wymagania niefunkcjonalne...............................................................................................67
12. Przeglądy sprintów..............................................................................................................67
13. Przegląd wydania................................................................................................................69
14. Wybór technologii...............................................................................................................70
15. Opis używanych technologii...............................................................................................70
16. Moduły systemu..................................................................................................................71
17. Podsumowanie....................................................................................................................72
3
1. Cel
Celem tej pracy jest porównanie dwóch metodyk prowadzenia projektów informatycznych;
Prince2 oraz Scrum oraz wykonanie aplikacji informatycznej „internetowa firma
turystyczna”, która umożliwia stworzenie portalu internetowego tematycznie związanego z
turystyką. Nad aplikacją pracowaliśmy używając metodyki Scrum.
3. Rozwiązanie problemu
Problem zostanie rozwiązany dzięki wykonaniu aplikacji informatycznej nad którą zespół
będzie pracował według metodyki Scrum. Obserwacje metodyki Scrum zostaną porównane z
metodyką Prince2. Wnioski zostaną zaprezentowane w tym dokumencie.
4
4. Zawartość pracy
dokumentację techniczną z wykonanego systemu IT w której skład wchodzą:
1. słownik systemu
2. role w systemie
3. Diagram przypadków użycia
4. Diagram związków encji
5. Diagram przepływu sterowania
6. Opis oraz porównanie metodyki Prince2 oraz metodyki Scrum
7. Opis metodyki Prince2
8. Opis metodyki Scrum
9. Porównanie metodyki Scrum i Prince2 pod kątem jakości
10. Porównanie metodyki Scrum i Prince2 pod kątem planowania
11. Porównanie metodyki Scrum i Prince2 pod kątem ryzyka
12. Porównanie metodyki Scrum i Prince2 pod kątem ról w zespole projektowym
13. Opis procesu wytwórczego w którego skład wchodzą:
1. wymagania początkowe dla wydania i sprintów wraz z kryteriami
akceptacyjnymi
2. podziału pracy na sprinty(iteracje)
3. przeglądy sprintów
4. przegląd wydania
Słownik pojęć
Pojęcie Opis
Aktor Abstrakcyjny użytkownik systemu, który reprezentuje grupę rzeczywistych
użytkowników lub partnerów systemu o podobnych funkcjach i sposobie
komunikacji z systemem.
Przypadek Grupa interakcji między aktorem a systemem. Interakcje powinny mieć cechy
użycia transakcji(niepodzielnych operacji) w systemie dostarczających aktorowi rezultatu o
mierzalnej wartości.
Użytkownik Bezpośredni konsument usługi; jest to aktor, który jest identyfikowany w modelu
końcowy każdej usługi. W usłudze może uczestniczyć wielu aktorów.
5
Skrót Pełna nazwa/wyjaśnienie
Klient Internetowa firma turystyczna dla której jest przeprowadzony projekt informatyczny
opisany w tym dokumencie. Na potrzeby projektu korzystaliśmy z wymyślonej
firmy
Role w systemie
6
Diagram przypadków użycia
1. Przejrzyj zawartość strony
7
zdarzeń
Wymagania Brak
niefunkcjonalne
Uwagi dodatkowe brak
2. Znajdź wycieczkę
Alternatywne przepływy 3a. Aktor nie wpisuje daty w menu „Znajdź wycieczkę- powrót do punktu 2
8
zdarzeń przypadku użycia.”
Brak
Uwagi dodatkowe brak
Kategoria Nie
wycieczki
Kraj Nie
Miejsce pobytu Nie
Wyjazd od Tak
Przedział Nie
cenowy
9
3. Wyszukaj ofertę
Alternatywne przepływy 2a. Aktor nie wpisuje poprawnej daty w menu „Znajdź wycieczkę- powrót do
1
zdarzeń punktu 2 przypadku użycia.”
Wymagania Brak
niefunkcjonalne
Uwagi dodatkowe Po wyszukaniu określonej wycieczki można ją zarezerwować korzystając z
przypadku Dostosuj ofert. Można również dodać lub przeglądać komentarze
„Dodaj opinię ”, „Zobacz opinię” jak i dodać do schowka ”Dodaj do schowka”
Pole
Nazwa
Typ
transportu
Miejsce
wylotu
Miejsce
lądowania
Standard
Wyżywienie
Rodzaj
wyjazdu
Cena
Dodatki
Pole
Szczegóły
oferty
Informacje o
hotelu
Opinie o
hotelu
1
Informacje o
miejscowości
Nazwa
Lokalizacja
Standard
Opis
Komentarze
Dodaj
opinię
4. Dodaj komentarz
1
Aktorzy Browser, Klient
Opis Przypadek użycia dotyczy dodawania komentarzy do określonej wycieczki.
W celu dodania komentarza należy najpierw wybrać wycieczkę korzystając
ze scenariusza Znajdź wycieczkę lub Wyszukaj ofertę.
Warunek początkowy Brak
Warunek końcowy Brak
Alternatywne przepływy 5a. Aktor używa przycisku „Anuluj” -koniec przypadku użycia
zdarzeń
Wymagania Brak
niefunkcjonalne
Uwagi dodatkowe Brak
5. Pokaż komentarze
1
Autor Adam Rychel, Maciej Sowiński, Marcin Ciesielski, Jan Garczyński
Priorytet normalny
Typ ogólny
Aktorzy Browser, Klient
Opis Przypadek użycia dotyczy wyświetlania komentarzy do określonej
wycieczki. W celu wyświetlenia komentarzy należy najpierw wybrać
wycieczkę korzystając ze scenariusza Znajdź wycieczkę lub Wyszukaj
ofertę.
Warunek początkowy Brak
Warunek końcowy Brak
Wymagania Brak
niefunkcjonalne
Uwagi dodatkowe Brak
6. Rejestruj się
1
Typ Ogólny
Aktorzy Browser
Opis Pozwala zarejestrować swoje dane i założyć konto
Warunek początkowy Brak.
Warunek końcowy Brak
Formularz rejestracji
Pole Wymagania
Login Minimum 5
znaków
Hasło Minimum 5
znaków
Powtórz hasło Pole powinno
mieć taką samą
wartość jak haslo
Imię Minimum 5
znaków
Nazwisko Minimum 5
znaków
Data Pole wymagane
urodzenia
Numer 9 znaków
dowodu
osobistego
Ulica Minimum 3 znaki
1
Numer Brak
mieszkania
Województwo Brak
Numer Brak
telefonu
Numer Brak
telefonu
komórkowego
7. Zaloguj się
1
Aktorzy Klient, Administrator
Opis Pozwala zalogować się na konto
Warunek początkowy Wpisanie loginu i hasła
Warunek końcowy Brak
Alternatywne przepływy 3a. Aktor wpisuje niepoprawny login lub/i hasło i nie zostaje zalogowany –
zdarzeń komunikat o błędzie i koniec przypadku użycia
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
8. Edytuj dane
1
Warunek końcowy Brak
Alternatywne przepływy 3a. Aktor wpisuje niepoprawny login lub/i hasło i nie zostaje zalogowany –
zdarzeń komunikat o błędzie i koniec przypadku użycia
4a. Aktor wpisuje niepoprawne dane-powrót do punktu 4
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
9. Zapisz na newsletter
1
Warunek końcowy Brak
Alternatywne przepływy 2a. Aktor wpisuje niepoprawny adres mailowy – komunikat o błędzie i
zdarzeń koniec przypadku użycia
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
1
zawartości schowka- przycisk „Pokaż schowek”, wyczyszczenie
zawartości schowka- przycisk- „Opróżnij schowek”, dodanie nowej
oferty do schowka – przycisk „Dodaj do schowka”
3. System zapisuje zmiany
4. Koniec przypadku użycia
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
2
4. Koniec przypadku użycia
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
Pole
Terminy i
ceny
Liczba
osób
dorosłych
Liczba
dzieci
Liczba
niemowląt
Liczba
pokoi
2
Nazwa przypadku Modyfikuj zawartość strony
Nr id 12
Autor Adam Rychel, Maciej Sowiński, Marcin Ciesielski, Jan Garczyński
Priorytet Normalny
Typ Ogólny
Aktorzy Administrator
Opis Pozwala wykonywać odpowiednie operacje (Dodaj, Podgląd, Edycja, Usuń)
w odpowiednich sekcjach – Newsy, Artykuły, Typy wakacji, Kraje, Miejsca
pobytu, Hotele, Oferty, Dodatki, Przewodniki, Galerie plików,
Warunek początkowy Zalogowanie się na prawach administratora
Warunek końcowy Brak
Alternatywne przepływy 2a Aktor nie wypełnił wszystkich wymaganych pól lub wypełnił je
zdarzeń niepoprawnie – komunikat o błędzie i powrót do formularza z
danej sekcji – punkt 2
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
Newsy
Pole wymagane
Tytuł tak
Treś tak
ć
2
Artykuły
Pole wymagane
Tytuł tak
Treś tak
ć
Typy wypoczynku
Pole wymagane
Nazwa tak
Opis tak
Obrazek nie
Kraje
Pole wymagane
Nazwa tak
Opis tak
Obrazek nie
Miejsca pobytu
Pole wymagane
Nazwa tak
Kraj tak
Opis tak
Obrazek nie
Hotele
Pole wymagane
Nazwa tak
Standard nie
Opis tak
Obrazek nie
Oferty
Pole wymagane
Nazwa Nie
Terminy Nie
Cena za Nie
2
osobę
Typ Tak
Transportu
Początek Nie
podróży
wyżywienie Tak
Cena Nie
Typ Tak
wypoczynku
Kraj Tak
Miejsce Tak
pobytu
Hotel Tak
Opis Nie
Dodatki Nie
Galeria Nie
plików
Dodatki
Pole wymagane
Nazwa tak
Opis tak
Obrazek nie
Przewodniki
Pole wymagane
Nazwa Nie
Opis Nie
Obrazek nie
Galerie plików
Pole wymagane
Nazwa tak
Plik nie
2
13. Zarządzaj użytkownikami
Alternatywne przepływy 2a. Aktor nie wypełnia wymaganych danych lub wypełnia je niepoprawnie-
zdarzeń komunikat o błędzie – powrót do punktu 2.
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
Pole wymagane
Login Tak od 3 do 20
znaków
Hasło Tak od 5 do 20
znaków
2
Powtórz Tak od 5 do 20
hasło znaków
Grupa Tak
Alternatywne przepływy 2a. Aktor nie wypełnia wymaganych danych lub wypełnia je niepoprawnie-
zdarzeń komunikat o błędzie – powrót do punktu 2.
Wymagania brak
2
niefunkcjonalne
Uwagi dodatkowe brak
Pole Wymagane
Nazwa Tak
Lista Nie
artykułów
Szczegóły Nie
artykułu
Usuwanie Nie
artykułu
2
3. Aktor modyfikuje dane klientów (podgląd lub usuń)
4. System zapisuje zmiany
5. Koniec przypadku użycia
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
2
Alternatywne przepływy brak
zdarzeń
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
Wymagania brak
niefunkcjonalne
Uwagi dodatkowe brak
2
6. Diagram związków encji
3
Diagram przejść ekranów
3
3
2. Dodanie nowego typu wakacji przez administratora
3
3. Dodanie nowego hotelu przez administratora:
3
3
4. Dodanie pliku do galerii plików
3
5. Dodaj użytkownika
3
7. Opis oraz porównanie metodyki Prince2 oraz metodyki
Scrum
8. Opis Prince2
Prince2 to metodyka zarządzania projektami oparta na doświadczeniach nabytych przez
Project managerów z Wielkiej Brytanii. Jest to metodyka uniwersalna i można ją zastosować
do każdego typu projektów.
3
2. Zarządzanie codzienne/bieżące
• Brak właściwych narzędzi do kierowania projektem lub nie poprawne ich
wykorzystanie
• Brak zarządzania zmianami w projekcie
• Błędy podczas planowania/estymowania działań
Historia Prince2
Pierwowzorem dla Prince2 była metodyka PROMPT(Project Resource Organisation
Management Planning Technique), metodyka ta służyła pierwotnie do prowadzenia projektów
IT. PROMPT2 został wzbogacony o część związaną z zarządzaniem jakością i został
wdrożony jako oficjalna rządowa metodyka. Po kupieniu praw do PROMPT2 przez rządową
agencją CCTA został opublikowany standard Prince wydany jako „best practises” dla
projektów każdego typu. Prince szybko stał się de facto oficjalną metodyką dla projektów
prowadzonych w UK w każdym obszarze
PRINCE2 został upubliczniony pierwszy raz w roku 1996 r. jako ogólna metodyka
zarządzania projektami dla każdej dziedziny biznesowej. Od tego czasu Prince2 zyskuje
coraz szersze uznanie na całym świecie stanowiąc główną alternatywę dla PMBOK-a(Project
management book of knowledge) organizacji PMI. W roku 2009 została wydana aktualizacja
do metodyki Prince2 wprowadzająca większy nacisk na wykorzystanie „lessons learned” z
poprzednich projektów.
Procesy Prince2
PRINCE2 cechuje się podejściem procesowym do zarządzania projektami. Definiuje
precyzyjnie osiem procesów, które dalej dzielą się na pod procesy:
1. Strategiczne zarządzanie projektem (ZS)
2. Planowanie (PL)
3. Uruchamianie Projektu/ Przygotowanie projektu (PP)
4. Inicjowanie projektu (IP)
5. Sterowanie Etapem (SE)
6. Zarządzanie Wytwarzaniem Produktów (WP)
7. Zarządzanie Zakresem Etapu (ZE)
8. Zamykanie Projektu (ZP)
3
Zgodnie z Prince2 faza realizacyjna projektu może zostać rozbita na etapy
realizacyjne(Stages).
Procesy
• Uruchamianie Projektu,
• Inicjowanie Projektu
• Zamykanie Projektu
są jednocześnie fazami w cyklu życia projektu. Fazę realizacyjną stanowią procesy
• Sterowania Etapem,
• Zarządzania Wytwarzaniem Produktów
• Zarządzania Zakresem Etapu
4
• Eskalacja od kierownika projektu
Planowanie(PL)
Planowanie jest procesem trwającym przez cały cykl życia projektu.
4
Sterowanie etapem składa się z podprocesów:
1. SE1. Zgoda na wykonanie grupy zadań
2. SE2. Ocena postępów
3. SE3. Rejestrowanie zagadnień projektowych
4. SE4. Analizowanie zagadnień projektowych
5. SE5. Przeglądanie stanu etapu
6. SE6. Raportowanie o ważnych zdarzeniach
7. SE7. Podejmowanie działań korekcyjnych
8. SE8. Eskalowanie zagadnień projektowych
9. SE9. Odbieranie wykonanej grupy zadań
4
Zamykanie projektu składa się z podprocesów:
1. ZP1. Przygotowanie projektu do zamknięcia
2. ZP2. Określanie działań następczych
3. ZP3. Przegląd oceniający projekt
Komponenty
Uzasadnienie biznesowe
Organizacja
Role w Prince2:
1. Komitet Sterujący
2. Przewodniczący Komitetu Sterującego
3. Główny Użytkownik
4
4. Główny Dostawca
5. Kierownik projektu
6. Nadzór projektu
7. Kierownik Zespołu – rola opcjonalna
8. Wsparcie Projektu – rola opcjonalna
9. Właściciel ryzyka
10. Interesariusz
Zakresy obowiązków
4
Zakres obowiązków Członka Zespołu Specjalistycznego
1. Dysponuje umiejętnościami niezbędnymi do wytworzenia specjalistycznych
produktów
2. Wytwarza specjalistyczne produkty cząstkowe oraz końcowe
3. Odpowiada za przygotowywanie produktów do przeglądów jakości
Plany
Plany zgodnie z PRINCE2 muszą być zatwierdzone zanim zostaną przekazane do realizacji.
Wyróżnia się 3 poziomy planu:
1. Plan projektu
2. Plan etapu
3. Plan pracy zespołu
Dodatkowo czwartym typem planu jest plan naprawczy (Exception plan), który zastępuje plan
etapu w gdy pojawi się zdarzenie uniemożliwiające kontynuowanie prac zgodnie z obecnym
harmonogramem.
Elementy sterowania
Elementy sterowania są to elementy zarządcze mające maksymalizować szansę na sukces
projektu. Elementy sterowania są mocno związane z zarządzaniem przez wyjątki, czyli
minimalnym angażowaniu komitetu sterującego w bieżące zarządzanie projektem. Mają
zapewnić pełną i wiarygodną informację zarówno dla kierownika projektu jak i dla komitetu
sterującego.
4
1. Czas
2. Koszty
3. Korzyści
4. Ryzyko
5. Jakość
6. Zakres
Zarządzanie ryzykiem
Z powodu niepowtarzalności projektów definiuje się ryzyko projektowe. Ryzyko jest to
zgodnie z definicją przedstawioną w metodyce Prince2 „niepewność rezultatu działania”.
Jako ryzyko określamy działanie którego nie jesteśmy pewni że wystąpi, natomiast jeśli tak
będzie, jego wystąpienie będzie miało wpływ na projekt. Typowe ryzyka dla projektów IT to:
• Małe zaangażowanie klienta,
• nieprzewidziane problemy przy testowaniu,
• problemy ze zdefiniowaniem wymagań .
Jakość produktów, jakie powstają w PRINCE2, osiągana jest przez podwójną i obiektywną
kontrolę tych produktów. Obiektywizm kontroli gwarantuje wykluczenie z niej kierownika
projektu oraz wytwórców danego produktu.
Zarządzanie konfiguracją
Zarządzanie konfiguracją polega na kontrolowaniu i standaryzacji użycia dokumentacji w
projekcie. Konfiguracją są to wszystkie produkty projektu z uwzględnieniem ich statusów i
wersji.
4
Zarządzanie konfiguracją musi zapewnić:
1. Mechanizmy zarządzania, śledzenia i utrzymywania kontroli nad wszystkimi
produktami projektu.
2. bezpieczeństwo przechowywania każdego produktu..
3. System rejestrowania, śledzenia oraz dokumentowania wszystkich zagadnień
projektowych.
Sterowanie zmianami
Sterowanie zmianami opiera się na technice sterowania zmianami.
Rodzaje zmian
1. wniosek o wprowadzenie zmiany
2. odstępstwo
3. ustępstwo
Techniki
Techniki są to instrukcja postępowania, przy użyciu których w poszczególnych procesach
wytwarzane są produkty projektu. Zarówno te zarządcze jak i specjaliztyczne.
Sterowanie zmianami
W projektach prowadzonych zgodnie z PRINCE2 wszystkie zmiany są traktowane jako
zagadnienia projektowe. Wyróżniamy następujące typy zmian:
1. wnioski o zmianę – dotyczące zmiany w wymaganiach albo produkcie.
2. odstępstwo – rejestrowane kiedy produkt nie przechodzi testów jakości.
3. sugestie
4. zapytania
5. zagadnienia ogólne
4
Kierownik projektu jest odpowiedzialny za zbieranie i ocenianie zagadnień projektowych.
Każde zgłoszenie zagadnienia projektowego musi być dokumentowane, a następnie jeśli
zgodni się na to kierownik projektu analizowane. Jeśli zmiana jaka jest postulowana w
zagadnieniu projektowy może zostać wdrożona w ramach pozostałej na ten etap tolerancji,
ojej wdrożeniu decyduje kierownik projektu. Natomiast jeśli jej wdrożenie wiązałoby się z
przekroczeniem pozostałej tolerancji kierownik eskaluje sytuację do komitetu sterującego
prosząc o decyzję.
Przeglądy jakości
PRINCE2 wymaga aby produkty podlegały przeglądom jakości. Zadaniem przeglądów
jakości jest określenie czy produkt spełnia kryteria jakości określone w specyfikacji tzn. czy
nie zawiera błędów, lub braków i niezgodności ze specyfikacją.
Dokumentacja PRINCE2
Dokumentacja inicjująca projekt
1. Kontekst projektu
2. Instrumenty sterowania
3. Definicja projektu
a. Cele projektu
b. Metody osiągania celów
c. Spodziewane wyniki (produktu)
d. Formula realizacji projektu
e. Ograniczenia, wyłączenia
f. Powiązania projektu
4. Uzasadnienie ekonomiczne
5. Struktura organizacyjna
6. Plan projektu
a. Produkty
b. Działania
c. Zasoby
7. Plan komunikacji
8. Rejestr ryzyka
9. Tolerancje w projekcie
Rejestry
1. Rejestr ryzyka
2. Rejestr zagadnień
3. Rejestr jakości
4. Rejestr doświadczeń
5. Rejestr dzienny
6. Rejestr zarządzania konfiguracją
Raporty
1. Raport okresowy
2. Raport końcowy etapu zarządczego
4
3. Raport końcowy projektu
4. Raport o odchyleniach
5. Raport z punktu kontrolnego
6. Raport z wykorzystania zasobów
7. Raport doświadczeń z projektu
Plany
1. Plan etapu inicjowania projektu
2. Plan jakości projektu
3. Plan projektu
4. Plan zarządzania konfiguracją
5. Plan etapu zarządczego
6. Plan jakości etapu zarządczego
7. Plan awaryjny (rezerwowy)
8. Plan wyjątkowy (naprawczy)
9. Plan wykorzystania budżetu zmian
10. Plan tekstowy
11. Plan pracy zespołu specjalistycznego
12. Plan przeglądu poprojektowego
13. Plan bazowy (stan odniesienia)
9. Opis Scrum
Scrum jest to zwinna(agile) metodyka zarządzania projektami. Jej podstawą są wartości
zadeklarowane w manifeście zwinności1.
Struktura Scrum-a obejmuje: Zespoły wykonawcze oraz związane z nimi role, ograniczenia
czasowe narzędzia jak i ogólne reguły postępowania.
1
http://agilemanifesto.org/
4
Opisane w Scrum ograniczenia czasowe mają za cel zapewnić regularny rytm pracy.
Scrumowe ograniczenia czasowe to:
• spotkanie planistyczne wydania (Release Planning Meeting),
• spotkanie planistyczne Sprintu (Sprint Planning Meeting),
• Sprint,
• Codzienny Scrum (Daily Scrum),
• przegląd Sprintu (Sprint Review)
• retrospektywa Sprintu (Sprint Retrospective).
Głównym elementem Scruma jest Sprint, czyli iteracyjnie wytwarzania produktów. Sugeruje
się aby Sprinty nie przekraczały miesiąca. Raz ustalona długość Sprintu w projekcie powinna
pozostać niezmienna. Każdy Sprint powinien kończyć się oddaniem klientowi działającego
produktu z funkcjonalnościami jakie mają zostać zaimplementowane. Oznacza to że podczas
Sprintu następuje analiza funkcjonalna, analiza techniczna, programowanie, testy oraz
oficjalny odbiór przyrostu funkcjonalności.
Role w Scrumie
Mistrz
Rola Mistrza polega na pilnowaniu tego czy zespół postępuje zgodnie z zasadami Scrium-a.
Mistrz jest odpowiedzialny za odpowiednie wdrożenie Scrum-a do organizacji. Powinien on
być nauczycielem Scrum-a zarówno dla zespołu jak i dla klienta. Scrum master jest również
odpowiedzialny za nauczenie zespołu czym jest samoorganizacja zespołu.
Właściciel Produktu
Właściciel Produktu jest jedyną odpowiedzialną za zarządzanie definiowanie pracy jaka ma
być wykonana przez zespół. Właściciel produktu tworzy listę funkcjonalności jakie mają
trafić do Produkt backloga jak i do Sprint backloga wraz z opisem kryteriów jakościowych.
Właściciel produktu jest również odpowiedzialny za przypisanie pryjorytetu do każdego z
zadań nad którym zespół będzie pracował. Ważne jest to że Właściciel produktu to jedna
osoba a nie kilka. W Strumie nie występuje komitet sterujący, a jego rolę przejmuje właśnie
Produkt Owner.
5
Aby Właściciel Produktu mógł pełnić skutecznie swoją rolę członkowie projektu muszą
traktować do jako najwyższą władzę w projekcie. Tylko produtc owner decyduje o tym nad
czym pracuje zespół i nikt nie może kazać zespołowi pracować nad czymś innym.
Zespół
Zespół jest to grupa osób pracujących nad wytworzeniem programu który implementuje
funkcjonalności zlecone przez Produtc Ownera. Zespoły w Scrum są samoorganizujące, co
oznaczą że nikt nawet Scrum master nie może narzucić zespołowi jak ma pracować. Zespół
aby być w stanie dostarczyć kolejne Sprinty powinien być interdyscyplinarny, czyli posiadać
w sobie ludzi o wszystkich niezbędne umiejętności. Zespół pracuje nad funkcjonalnościami
jakie zleci mu do wykonania Produkt Owner. Zgodnie ze Scrum najlepszą liczebnością
zespołu jest 7 osób plus minus 2.
Ograniczenia czasowe
Ograniczenia czasowe w Scrumie dotyczą: spotkania planistycznego wydania, Sprintu,
spotkania planistycznego Sprintu, przeglądu Sprintu, retrospektywy Sprintu i Codziennego
Scruma.
Etap planowania wydania jest opcjonalny. Jeśli Zespoły Scrum rozpoczną pracę bez tego
etapu, brak jego wyników (planu wydania) będzie stanowić przeszkodę, którą należy usunąć.
Czynności prowadzące do usunięcia tej przeszkody staną się elementem rejestru
produktowego.
W scrumowym planowaniu wydania definiuje się cel całościowy oraz prawdopodobne efekty
pracy. Takie planowanie zwykle wymaga nie więcej niż 15-20% czasu, jaki organizacja
zużywała w tradycyjnym planowaniu. Niemniej w projekcie scrumowym odbywa się również
planowanie dokładnie na czas (just-in-time, JIT) podczas przeglądów Sprintu i spotkań
5
planistycznych Sprintu, oraz codziennie podczas każdego Codziennego Scruma. W ogólnym
rozrachunku, prace planistyczne w Scrumie pochłaniają nieco więcej wysiłku niż tradycyjne
planowanie projektu.
Sprint
Sprint jest iteracją. Sprinty zamykają się w ograniczeniach czasowych. Podczas Sprintu
Mistrz ma za zadanie dopilnować, by nie wprowadzono żadnych zmian, które wpłynęłyby na
Cel Sprintu. Skład osobowy Zespołu i cele jakościowe muszą pozostać niezmienne przez cały
Sprint. Sprinty zawierają i składają się z: spotkania planistycznego Sprintu, prac
programistycznych, przeglądu Sprintu, i retrospektywy Sprintu. Sprinty następują
bezpośrednio po sobie, bez przerw pomiędzy nimi.
Sprint może zostać zakończony przed końcem swojego ograniczenia czasowego. Jedynie
Właściciel Produktu jest uprawniony do zamknięcia Sprintu, choć może tak uczynić za
namową interesariuszy, Zespołu lub Mistrza. Jakie warunki muszą zachodzić, by nastąpiła
konieczność odwołania Sprintu? Kierownictwo może być zmuszone do odwołania Sprintu,
jeśli Cel Sprintu jest nieaktualny. Tak może się stać, gdy firma zmienia kierunek, lub gdy
zmieniają się warunki rynkowe czy technologiczne.
Ogólnie rzecz biorąc, Sprint powinien zostać odwołany, gdy nie ma już sensu jego realizacja,
biorąc pod uwagę zaistniałe okoliczności. Jednak, ponieważ Sprint nie trwa długo,
odwoływanie go jest rzadko sensowne.
Gdy Sprint zostaje odwołany, dokonuje się przeglądu wszystkich wykonanych, zakończonych
elementów rejestru produktowego. Akceptowane są te, które stanowią potencjalnie zbywalny
przyrost. Wszystkie pozostałe trafiają z powrotem do rejestru produktowego z początkowymi
estymacjami. Jakakolwiek wykonana nad nimi praca uznana zostaje za straconą. Zakończenie
Sprintu w ten sposób pochłania zasoby, ponieważ wszyscy muszą się przegrupować podczas
nowego zebrania planistycznego, by rozpocząć nowy Sprint. 3
2
Scrum guide, http://www.scrum.org/scrumguides/
3
Scrum guide, http://www.scrum.org/scrumguides/
5
Spotkanie planistyczne Sprintu
Spotkanie planistyczne Sprintu odbywa się zawsze, gdy trzeba zaplanować nową iterację.
Jego ograniczenie czasowe to osiem godzin przy planowaniu Sprintu
miesięcznego. Dla krótszych Sprintów na ten etap należy przeznaczyć około 5% czasu
trwania Sprintu. Zebranie składa się z dwóch części. W pierwszej, czterogodzinnej części,
decyduje się o tym, co ma być wykonane w czasie Sprintu. W drugiej części, również
trwającej cztery godziny, Zespół ma ustalić, w jaki sposób zbudować funkcjonalność w
postaci przyrostu produktu w czasie tego Sprintu.
Istnieją więc dwie części spotkania planistycznego Sprintu, koncentrujące się kolejno na tym
„co?” i „jak?” należy zrealizować. Niektóre Zespoły scrumowe łączą te dwie części ze sobą.
W części pierwszej Zespół zajmuje się pytaniem „co?”. Wtedy Właściciel Produktu
przedstawia pozycje rejestru produktowego o najwyższym priorytecie. Zespół i Właściciel
współpracują, by ustalić, jaka funkcjonalność ma być wypracowana podczas Sprintu. Danymi
wejściowymi w tym spotkaniu są: rejestr produktowy, ostatnio stworzony przyrost,
możliwości produkcyjne Zespołu w planowanym Sprincie i dotychczasowa wydajność
Zespołu. Ilość pracy wybranej przez Zespół zależy tylko i wyłącznie od niego: jedynie Zespół
może ocenić, ile jest w stanie osiągnąć podczas nadchodzącego Sprintu.
Po wyborze zakresu pracy określa się Cel Sprintu (Sprint Goal). Jest to cel, który zostanie
osiągnięty przez implementację wybranego fragmentu rejestru produktowego. Ustalenie go
ma uzmysłowić Zespołowi, po co buduje kolejny przyrost produktu. Cel Sprintu jest
składową celu wydania.
Cel Sprintu istnieje, aby zapewnić Zespołowi nieco swobody, jeśli chodzi o wytwarzaną
funkcjonalność. Na przykład, celem Sprintu może być: „automatyzacja funkcjonalności
modyfikującej konto klienta poprzez możliwość zastosowania bezpiecznej, odtwarzalnej
transakcji w warstwie pośredniej ”. Podczas pracy Zespół ma w pamięci ten cel. Aby go
zrealizować, Zespół implementuje funkcjonalność i niezbędną infrastrukturę.
Jeśli praca okazuje się trudniejsza niż oczekiwano, Zespół współpracuje z Właścicielem i
implementuje funkcjonalność tylko częściowo.
W drugiej części spotkania planistycznego Sprintu Zespół zajmuje się pytaniem „jak?”. W
czasie tego drugiego, czterogodzinnego spotkania, Zespół zastanawia się, jak przekształcić
elementy wybrane z rejestru produktowego podczas pierwszego bloku spotkania („co?”) w
kompletny przyrost produktu. Zazwyczaj Zespół zaczyna od projektowania pracy; wtedy
właśnie zidentyfikowane zostają zadania, czyli szczegółowe opisy prac prowadzących do
przekształcenia rejestru produktowego w działający program. Prace te powinny zostać
podzielone tak, by każde z nich mogło zostać wykonane w czasie maksymalnie jednego dnia.
Lista tych zadań to rejestr zadaniowy (Sprint Backlog). Zespół organizuje się sam, aby
rozdzielić pracę i podjąć się
zadań z rejestru zadaniowego, czy to podczas spotkania planistycznego Sprintu, czy w miarę
potrzeb, „dokładnie we właściwym czasie” (JIT) podczas trwania Sprintu.
Właściciel Produktu jest obecny podczas drugiej części spotkania planistycznego Sprintu, aby
objaśniać rejestr produktowy i pomagać w osiągnięciu kompromisu pomiędzy swoimi
oczekiwaniami a możliwościami produkcyjnymi Zespołu. Jeśli Zespół ustali, że ma zbyt dużo
lub zbyt mało pracy, może renegocjować zakres pracy z Właścicielem. Nowy Zespół zwykle
w czasie tego spotkania uświadamia sobie po raz pierwszy, że zwycięży lub pójdzie na dno
właśnie jako zespół, razem, nie indywidualnie. Członkowie Zespołu zdają sobie sprawę, że
5
muszą na sobie polegać. Gdy sobie to uświadomią, zaczynają się samoorganizować oraz
nabierają cech i zachowań prawdziwego zespołu.4
Przegląd Sprintu
Pod koniec Sprintu organizuje się spotkanie przeglądu Sprintu (Sprint Review). Jest to
spotkanie zawarte w czterogodzinnym ograniczeniu czasowym (dla miesięcznych Sprintów).
Dla krótszych Sprintów spotkanie nie może trwać dłużej niż 5% długości Sprintu. Podczas
przeglądu Sprintu Zespół scrumowy i interesariusze podsumowują wykonaną pracę.
Opierając się na tym oraz na zmianach wprowadzonych do rejestru produktowego podczas
Sprintu, ustalają, jakie prace mogą zostać wykonane w kolejnych Sprintach. Jest to spotkanie
nieformalne, podczas którego dokonuje się prezentacji funkcjonalności, aby ułatwić wspólną
pracę wszystkich zainteresowanych nad ustalaniem kolejnych kroków.
Retrospektywa Sprintu
Po przeglądzie Sprintu, a przed kolejnym spotkaniem planistycznym, Zespół przeprowadza
retrospektywę Sprintu. W czasie tego spotkania, trwającego nie dłużej niż trzy godziny,
Mistrz zachęca członków Zespołu do przejrzenia, w ramach procesu i praktyki Scrum, ich
pracy programistycznej, aby w kolejnym Sprincie uczynić ją bardziej efektywną i przyjemną.
Istnieje literatura opisująca techniki przydatne w czasie retrospektywy. Celem retrospektywy
jest sprawdzenie przebiegu minionego Sprintu pod względem osób biorących udział w
przedsięwzięciu, relacji zachodzących między nimi, procesu i narzędzi. Inspekcja ta powinna
zidentyfikować i zhierarchizować główne elementy, te, które były pozytywne oraz te, które,
gdyby zostały zrealizowane inaczej, mogłyby wpłynąć pozytywnie na efekt pracy. Dotyczy to
składu Zespołu, rozkładu spotkań, narzędzi, definicji tego, co „gotowe”, metod komunikacji i
procesów stosowanych w przekształcaniu rejestru produktowego w „gotowe” fragmenty
produktu. W trakcie retrospektywy Zespół powinien ustalić kroki naprawcze, które zostaną
podjęte w kolejnych Sprintach. Te zmiany stanowią adaptację wynikłą z empirycznej
inspekcji.6
Codzienny Scrum
Każdy Zespół spotyka się codziennie na piętnastominutowym spotkaniu – Codziennym
Scrumie. To spotkanie odbywa się o tym samym czasie i w tym samym miejscu w ciągu
całego Sprintu. Podczas tego spotkania każdy członek Zespołu wyjaśnia:
• Co zrobił od ostatniego spotkania?
4
Scrum guide, http://www.scrum.org/scrumguides/
5
Scrum guide, http://www.scrum.org/scrumguides/
6
Scrum guide, http://www.scrum.org/scrumguides/
5
• Co będzie robił do następnego spotkania?
• Jakie napotyka przeszkody?
Codzienny Scrum poprawia komunikację, eliminuje potrzebę innych spotkań, identyfikuje i
usuwa przeszkody w pracy, podkreśla i promuje szybkie podejmowanie decyzji i podnosi
poziom znajomości stanu prac projektowych w całym Zespole.
Codzienny Scrum nie jest spotkaniem statusowym w tradycyjnym tego słowa rozumieniu. Nie
jest otwarty dla wszystkich, a jedynie dla osób przekształcających rejestr produktowy w
przyrost produktu (czyli dla Zespołu). Zespół podjął się osiągnięcia Celu Sprintu i
zrealizowania wybranych elementów z rejestru produktowego. Codzienny Scrum jest okazją
do kontroli postępu prac ku Celowi Sprintu (dzięki odpowiedziom na powyższe trzy pytania).
Następnie rozmowy są kontynuowane w krótkich pod-spotkaniach, aby wprowadzić adaptacje
do kolejnych prac w Sprincie. Celem jest optymalizacja prawdopodobieństwa osiągnięcia
przez Zespół Celu Sprintu. Codzienny Scrum jest najważniejszym spotkaniem inspekcyjno-
adaptacyjnym w scrumowym procesie empirycznym.7
Scrumowe narzędzia
Narzędzia stosowane w Scrumie to: rejestr produktowy (Product Backlog), wykres wypalania
dla wydania (Release Burndown), rejestr zadaniowy (Sprint Backlog) i wykres wypalania dla
Sprintu (Sprint Burndown).
7
Scrum guide, http://www.scrum.org/scrumguides/
5
rzeczywistej wartości. Elementy o wyższym priorytecie są przejrzystsze i zawierają więcej
szczegółowych informacji niż elementy o niższym priorytecie. Na podstawie większej
przejrzystości i zwiększonej szczegółowości można dokonać trafniejszych estymacji. Im
niższy priorytet, tym mniej szczegółów, aż do poziomu, na którym ledwie można wyodrębnić
poszczególne elementy rejestru.
W miarę, jak produkt jest używany, jak jego wartość rośnie, a rynek reaguje i dostarcza
informacji zwrotnej, rejestr produktu zmienia się w coraz dłuższą i bardziej wyczerpującą
listę. Wymagania stale się zmieniają. Rejestr jest żywym dokumentem. Zmiany w
wymaganiach biznesowych, warunkach rynku, technologii i obsadzie pracowniczej powodują
zmiany w rejestrze. By zminimalizować przeróbki, jedynie elementy o
najwyższym priorytecie są szczegółowo opisane. Pozycje rejestru, którymi Zespół scrumowy
zajmie się w przeciągu kilku następnych Sprintów, są dokładne i szczegółowe
oraz podzielone w taki sposób, aby każda z nich mogła zostać wykonana w trakcie jednego
Sprintu.
Na wykresie wypalania dla produktu (lub wydania) rejestruje się ilość pozostałej do
wykonania pracy zgodnie z szacunkami w rejestrze w stosunku do czasu realizacji
projektu. Szacowana ilość pracy ukazywana jest w jednostkach pracy, na które zdecydował
się Zespół i organizacja (oś rzędnych). Jednostką czasu (oś odciętych) jest zwykle Sprint.
5
wymagać więcej lub mniej czasu niż się spodziewano. Jeśli pojawia się potrzeba wykonania
dodatkowych prac, Zespół dopisuje je do rejestru zadaniowego. W miarę, jak zadania są
wykonywane i kończone, aktualizuje się godziny przewidywanej pracy pozostałej do końca
każdego zadania. Gdy zadanie uznaje się za zbędne, zostaje ono usunięte. Jedynie Zespół
może zmieniać rejestr zadaniowy w trakcie Sprintu
(dodawać/usuwać zadania), jak również tylko Zespół może zmienić treść zadań lub
estymacje. Rejestr zadaniowy jest dobrze widocznym, rzeczywistym obrazem pracy, jaką
Zespół planuje wykonać w czasie Sprintu i jest własnością tylko i wyłącznie Zespołu.9
„Gotowe" definiuje to, co ma na myśli Zespół, gdy podejmuje się „przygotowania” jednej z
pozycji rejestru produktowego w Sprincie. Niektóre produkty nie wymagają dokumentacji, a
więc definicja „gotowego” nie zawiera istnienia dokumentacji. Całkowicie „gotowy” przyrost
produktu zawiera wszystkie analizy, projekty, kodowanie, refaktoryzację, dokumentację i
testy dla tego przyrostu i dla wszystkich elementów rejestru produktowego wykonanych w
ramach tego przyrostu. Testowanie może obejmować testy jednostkowe, systemowe, przez
użytkownika (funkcjonalne) i regresyjne, jak również testy niefunkcjonalne, na przykład:
wydajności, stabilności, bezpieczeństwa i integracyjne. „Gotowość” obejmuje również
umiędzynarodowienie produktu. Czasami Zespół nie jest w stanie na tym etapie włączyć do
swej definicji „gotowego” wszystkich elementów wymaganych do implementacji. Właściciel
9
Scrum guide, http://www.scrum.org/scrumguides/
5
Produktu musi to rozumieć. Ta pozostała część pracy musi zostać wykonana, zanim produkt
będzie oddany do wdrożenia i użytkowania.10
Prince2 zwraca wprost uwagę na potrzebę planowania jakości w podprocesie IP1 procesu
inicjowania projektu. Zarządzanie jakością w Prince2 opiera się na 4 składnikach:
• Quality Management System, czyli standardom przyjętym w projekcie dla zachowania
jakości. W tym dokumencie zdefiniowane jest wszystko co tyczy jakości, czyli
również elementy z te listy które są wymienione niżej.
• Quality Assurance Function, czyli ciągłe sprawdzanie jakości
• Quality Planning
• Quality Control, czyli „wyrywkowe” dogłębne testowanie jakości przez klienta.
10
Scrum guide, http://www.scrum.org/scrumguides/
5
Porównanie metodyki Scrum i Prince2 pod kątem planowania
Planowanie w Prince2
Planowanie w metodyce Prince2 jeśli się do niego podchodzi całościowo to bardzo
rozbudowane zagadnienie. Planowanie jest tu rozbite na trzy poziomy:
• Plan projektu
• Plan etapu
• Plan zespołu
Planowanie w Prince2 obejmuje również szerszy zakres prac niż tylko wykonanie projektu,
planuje się komunikację, jakość, ryzyka, podział na etapy, podwykonawców i wszystko co w
projekcie może być niezbędne. Planowanie w Prince2 przede wszystkim dotyka obszaru
biznesowego i tego jaki klient będzie miał zwrot z wykonanego projektu. Sama metodyka nie
mówi jak należy przeprowadzić planowanie, mówi tylko co powinno zostać zaplanowane.
Uzasadnienie biznesowe
Przygotowanie projektu
Przygotowanie projektu jest fazą przedprojektową. Jeszcze przed powołaniem projektu należy
zdefiniować i ocenić uzasadnienie biznesowe dla podejmowania projektu. W tej fazie jest
tworzony dokument „podstawowe założenia projektu”, w którym opisuje się uzasadnienie
biznesowe dla projektu, czyli spodziewane korzyści w stosunku do kosztów i ryzyk. W fazie
przygotowania projektu tworzony jest również zespół zarządzania projektem. Pod koniec tego
etapu jest również planowany etap inicjowania projektu.
5
Warto pamiętać że wszystkie prace wykonywane w tym etapie powinny być ograniczone do
minimum. Jest to spowodowane tym że podczas przygotowania projektu nie mamy jeszcze
budżetu.
Inicjowanie projektu
Celem inicjowania projektu jet stworzenie procedur jakie będą używane w projekcie.
Wszelkie procedury zostają spisane w Dokumencie Inicjującym Projekt. Będzie on również
zawierał ogólny plan projektu.
11
Proces planowania
Proces planowania jest procesem, który jest często powtarzany w projekcie. Na etapie
przygotowania projektu będzie powstawał plan etapu inicjowania, podczas etapu inicjowania
– plan projektu w trakcie zarządzania zakresem – plan etapu lub plan nadzwyczajny, w
ramach procesów zarządzania wytwarzaniem produktów – plany pracy dla zespołów.
12
11
Prince2 manual, APMG 2005
12
Proince2 manual, APMG 2005
6
Planowanie obejmuje odpowiedzi na pytania:
• Co jest niezbędne do realizacji planu
• W jaki sposób można to osiągnąć
• Jakie zasoby zostaną wykorzystane
• Kiedy to się wydarzy
Planowanie w Scrum
Planowanie w metodyce Scrum obejmuje tylko planowanie pracy jaka ma zostać wykonana w
różnym horyzoncie czasowym. W Scrum wyróżniamy od trzech do czterech poziomów
planowania:
• Poziom produktu
• Poziom wydania
• Poziom sprintu
• Poziom dnia
13
http://scrum.hypersquare.com/podstawy-scruma.html
6
Schemat procesu planowanie według Scrum pokazuje powyższy rysunek. Projekt zaczyna się
od przygotowania na spotkaniu rejestru produktowego czyli zbioru wymagań jakie musi
realizować projekt..
Jeśli projekt jest dostatecznie duży można Product Backlog podzielić dalej na backlogi dla
wydania(Release Backlog).
Następnie wybiera się zbiór wymagań które będą implementowane podczas Sprint i tworzy
się rejestr przebiegu
Sprint Backlog jest poukładany zgodnie z priorytetami nadanymi poszczególnym elementom
przez klienta.
Rolą Mistrza jest dopilnowanie aby praca zlecona w ramach aktualnego sprintu w jak
najmniejszym stopniu się zmieniała.
Sprint Backlog jest dalej dzielony przez zespół na zadania które będą wykonywane w
najbliższym przebiegu. Najniższy poziom planowanie odzwierciedla codzienne spotkanie
zespołu projektowego, (everyday scrum meeting) na którym następuje planowanie pracy na
najbliższy dzień.
Ważne jest, że końcowym efektem Sprintu jest gotowy w pełni działający produkt cząstkowy.
Podsumowanie
Jak widać Planowanie w metodyce Prince2 i Scrum różni się diametralnie. Prince2
największy nacisk kładzie na biznesowe aspekty projektów i planowanie nie tylko pracy
jakama zostać wykonana ale całego projektu, gdyż powtarzając za definicją projektu według
Prince2 projekt jest to „Warunki zarządzania stworzone w celu dostarczenia jednego lub
wielu produktów natury biznesowej zgodnie z określonym uzasadnieniem biznesowym”.
Scrum koncentruje się tylko na pracy jaka ma być wykonana, jednocześnie wymuszając
zwiększoną komunikację i zaangażowanie klienta. Widać tutaj zgodność Struma z Agile
manifesto14, czyli przedkładanie działania i ludzi na d procedury i dokumentację.
Scrum nie zajmuje się tematyką ryzyka, pozostawia to w gestii zespołu i scrum mastera.
Ryzyko może być zdefiniowane w strumie podczas retrospekcji scrum-a oraz spotkania
planistycznego scrum-a.
14
http://agilemanifesto.org/
6
• Komitet Sterujący (Project Board)
o Przewodniczący Komitetu Sterującego (Executive)
o Główny Użytkownik (Senior User)
o Główny Dostawca (Senior Supplier)
• Kierownik projektu (Project Manager)
• Nadzór projektu (Project Assurance)
• Kierownik Zespołu – rola opcjonalna (Team Manager)
• Wsparcie Projektu – rola opcjonalna (Project Support)
• Właściciel ryzyka
• Interesariusz
6
Zakres obowiązków Przewodniczącego Komitetu Sterującego
6
8. Sporządza projekty dokumentów (raportów, notatek, itp.)
9. Sporządza protokoły z narad komitetów sterujących
10. Sporządza notatki z przeglądów jakości
1. Monitorowanie ryzyka
2. proponowanie sposobów mityzacji ryzyka
3. Cykliczne raportowanie o ryzyku
1. Scrum master
2. Produkt owner
3. Członek zespołu
6
Funkcjonalność sprint Kryteria akceptacyjne
Definiowanie/edycja galerii 1
zdjęć/plików
Edycja zamówień 1
Edycja ofert 1
Hotele 1
Komentarze do ofert/ocena 2
Forum 2
Linki z youtube/wrzuta 2
Pozycjonowanie na google 2
Oglądanie ofert 1
Kraje 1
Zarządzanie userami 2
6
Przestawianie ofert na stronie 2
6
Pierwszy sprint
Funkcjonalność stan Uwagi
Edycja zamówień OK
Edycja ofert OK
Oglądanie ofert OK
Kraje OK
Drugi sprint
Funkcjonalność Stan Uwagi
6
Komentarze do ofert/ocena OK
Zarządzanie userami OK
Sprint końcowy
6
14. Wybór technologii
Ruby on Rails to jak framework napisany za pomocą języka Ruby zmodyfikowanego w celu
uzyskania wysoce produktywnego środowiska do tworzenia nowoczesnych aplikacji
internetowych.
Język Ruby posiada pełną obiektowość i bardzo czytelną składnię. Nie ma podziału
na typ prymitywy i typy referencyjne. Wszystko jest obiektem i wszystko posiada metody.
Dotyczy to nie tylko liczb i napisów ale także obiektu . Każdy obiekt można przeciążyć i/lub
zmodyfikować wewnętrznie (dynamicznie dodając lub usuwając jego metody w trakcie pracy
programu). Daje to możliwości zupełnie nieosiągalne dla innych języków obiektowych.
7
Pisanie skryptów przy pomocy JavaSciptu z biegiem lat stawało się co raz trudniejsze
za sprawą rozwoju wielu konkurencyjnych przeglądarek. Każda z nich postanowiła na własny
sposób zaimplementować obsługę tego języka. Dobrze napisany skrypt pod FireFoxem nie
będzie działał po IE i na odwrót. Prototype jest domyślnie używany w Railsach dlatego
będziemy korzystać z tej biblioteki.
Pisząc nasz projekt opieramy się na sprawdzonych i solidnych narzędziach open
source. W przypdaku bazy danych chcemy postąpić tak samo i dlatego zdecydowaliśmy się
na PostgresSql. Jest to powszechnie uważany za najbardziej uniwersalny i stabilny spośród
baz danych rozprowadzanych na zasadach wolnego dostępu. jego możliwości
wykorzystywane są zarówno przez twórców portali sieciowych, jak i potężnych systemów
korporacyjnych przetwarzających ogromne ilości danych
Architektura systemu
Przede wszystkim aplikcaja będzie się opierała na architekturze dwuwarstwowej typu klient-
serwer. Oznacza to podział naszej aplikacji na dwa moduły: interfejs użytkownika oraz
przetwarzanie i składowanie danych.
Wszystkie operacje będą wykonywane z poziomu przeglądarki www bez żadnych aplikacji
stacjonarnych.
Aplikacja będzie składała się z trzech części:
• Strona biura turystycznego
Strona dla klientów, na której dostępne będą oferty wczasów do wykupienia. Część ta będzie
umożliwiała rejestrację użytkownika w celu przechowywania jego danych osobowych,
wyszukiwanie wycieczek po rozmaitych kryteriach oraz dokonanie zamówienia wycieczki.
• CMS
Cześć dosŧępną tylko dla osób upoważnionych. Służy do dodawania, modyfikacji i usuwania
ofert wycieczek jak i przeglądania danych zarejestrowanych klientów wraz z historią
zakupów w naszym serwisie.
• Baza Danych
Baza dancyh Postresql przechowujące dane potrzebne do funkcjonowania aplikacji.
• Formularz
Będzie służył przede wszystkim do wprowadzania danych do bazy danych takich jak oferty
wycieczek, dane klienta czy faktury. Da również możliwość modyfikacji wyżej
7
wymienionych informacji oraz przeszukiwania bazy w celu odnalezienia interesującej nas
oferty.
• Raport
Za pomocą tego modułu będą prezentowane informacje wydobyte z bazy danych.
• Potwierdzenie email
Klient po złożeniu zamówienia dostanie wiadomość na swoją skrzynkę pocztową w celu
potwierdzenia wykonanej operacji
17. Podsumowanie
W naszym projekcie oprócz porównania dwóch metodyk prowadzeni projektów wykonaliśmy
również aplikację webową. Postanowiliśmy że będziemy nad nią pracować w metodyce
Scrum.
Powodami wyboru Scrum-a jako metodyki w której będziemy pracować były:
-iteracyjność jaką narzuca Scrum pozwoliła nam na łatwiejsze uporządkowanie pracy
-proste i czytelne zasady komunikacji
-brak potrzeby definiowania ról w zespole, każdy mógł zajmować się dowolną częścią pracy.
-timeboxy(Scrumowe organiczenia czasów na wykonywane zadania) bardzo ułatwiają prace
na poziomie developera, przy minimalizacji potrzebnej dokumentacji.
-proste i intuicyjne planowanie.
-duża elastyczność w możliwościach dostosowywania Scrum-a, podejście opisane w
manifeście zwinności(http://agilemanifesto.org)
-prostota zasad, co jest ważne podczas pracy zdalnej nad projektem
Wszystkie wymienione powody dla naszego wyboru Scrum-a, dały się odczuć w codziennej
pracy. Scrum pozwolił nam uporządkować proces wytwarzania projektu, jednocześnie nie
narzucając czynności które trzeba byłoby wykonać tylko dlatego żeby pozostać
„metodycznym”. W szczególny sposób jasne zasady komunikacji i planowania pomogły w
koordynacji prac jakie musiały zostać wykonane.
Jednak „czysty” Scrum nie zapewniał w stu procentach tego czego wymagaliśmy od
metodyki którą chcemy stosować. Postanowiliśmy dodać elementy zarządzania ryzykami z
Prince2, który pozwolił nam już na starcie projektu ominąć wiele problemów. Czerpaliśmy
również z podejścia Prince2 do komunikacji i stworzyliśmy plan komunikacji, gdzie
opisaliśmy zasady na których będziemy raportować stopień zaawansowania w pracach.
Nasze pierwotne podejście okazało się skuteczne, jednak co ma kluczowy wpływ na wynik
przeprowadzonego przez nas porównanie metodyk prowadzenia projektów IT, naszym celem
było tylko stworzenie aplikacji, co prawie nigdy nie ma miejsca w projektach. Zawsze chodzi
o zaspokojenie potrzeby klienta i poprawną komunikację głównie na linii dostawca-klienta a
nie w samym zespole projektowym. Dlatego tez takie silne elementy Prince2 jak:
koncentracja na uzasadnieniu biznesowym, większa dokumentacja projektu, dwa poziomy
zarządzania(operacyjny i strategiczny) nie mogły pokazać pełni swojej przydatności.
W praktyce, czy to w małych projektach gdzie celem jest tylko dostarczenie aplikacji, czy w
większych gdzie sama aplikacja może być tylko niewielkim elementem projektu warto jest
7
znać oba podejścia i używać tych elementów obu metodyk które wniosą największą wartość
dodaną do projektu.