Académique Documents
Professionnel Documents
Culture Documents
1
Spis Treści
1. Cel...........................................................................................................................................4
2. Informacje o zastosowanych metodach..................................................................................4
3. Rozwiązanie problemu............................................................................................................4
4. Zawartość pracy......................................................................................................................4
5. Dokumentację techniczną z wykonanego systemu IT............................................................5
1. Przejrzyj zawartość strony............................................................................................6
2. Znajdź wycieczkę..........................................................................................................7
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
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
6. Opis oraz porównanie metodyki Prince2 oraz metodyki Scrum ..........................................38
7. Opis Prince2..........................................................................................................................38
Przygotowanie założeń projektu/Uruchamianie projektu (Starting up a project)...........40
Zarządzanie strategiczne projektem (Directing a project)...............................................40
Planowanie (Planning).....................................................................................................41
Inicjowanie projektu (Initiating a project).......................................................................41
Sterowanie etapem (Controlling a stage).........................................................................41
Zarządzanie zakresem etapu (Managing stage boundaries)............................................42
Zamykanie projektu (Closing a project)..........................................................................42
Uzasadnienie biznesowe..................................................................................................43
Organizacja......................................................................................................................43
Plany................................................................................................................................46
Elementy sterowania........................................................................................................46
Zarządzanie ryzykiem......................................................................................................46
Parametry ryzyka w PRINCE2........................................................................................47
Jakość w środowisku projektowym.................................................................................47
Zarządzanie konfiguracją.................................................................................................47
Sterowanie zmianami......................................................................................................48
Planowanie oparte na produktach....................................................................................48
Sterowanie zmianami......................................................................................................48
2
Przeglądy jakości.............................................................................................................49
Dokumentacja inicjująca projekt ....................................................................................49
Rejestry............................................................................................................................49
Raporty............................................................................................................................49
Plany................................................................................................................................50
8. Opis Scrum............................................................................................................................50
Mistrz...............................................................................................................................51
Właściciel Produktu.........................................................................................................51
Zespół..............................................................................................................................52
Spotkanie planistyczne wydania......................................................................................53
Sprint...............................................................................................................................53
Spotkanie planistyczne Sprintu.......................................................................................54
Przegląd Sprintu..............................................................................................................55
Retrospektywa Sprintu....................................................................................................56
Codzienny Scrum............................................................................................................56
Rejestr produktowy i wypalanie w projekcie..................................................................57
Rejestr zadaniowy i wypalanie w Sprincie......................................................................58
Wykres wypalania w Sprincie to wykres przedstawiający..............................................58
„Gotowe”, czyli kryterium gotowości produkcyjnej (Definition of Done, DoD)...........58
Planowanie w Prince2.....................................................................................................60
Planowanie w Scrum.......................................................................................................64
Podsumowanie.................................................................................................................65
Zakres obowiązków Komitetu Sterującego ....................................................................65
Zakres obowiązków Głównego użytkownika produktu .................................................66
Zakres obowiązków Głównego dostawcy produktu .......................................................66
Zakres obowiązków Przewodniczącego Komitetu Sterującego .....................................66
Zakres obowiązków Kierownika Projektu .....................................................................66
Zakres obowiązków Nadzoru projektowego...................................................................67
Zakres obowiązków kierownika zespołu.........................................................................67
Zakres obowiązków wsparcia projektowego...................................................................67
Zakres obowiązków właściciela ryzyka..........................................................................67
Zakres obowiązków Interesariusza..................................................................................67
Zakres obowiązków Scrum mastera................................................................................68
Zakres obowiązków Produkt ownera..............................................................................68
Zakres obowiązków członka zespołu..............................................................................68
9. Wymagania funkcjonalne.....................................................................................................68
10. Wymagania niefunkcjonalne...............................................................................................70
11. Przeglądy sprintów..............................................................................................................70
12. Przegląd wydania................................................................................................................72
13. Diagram związków encji.....................................................................................................72
14. Wybór technologii...............................................................................................................73
15. Opis używanych technologii...............................................................................................73
16. Moduły systemu..................................................................................................................75
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. Zawartość pracy
1. dokumentację techniczną z wykonanego systemu IT w której skład wchodzą:
2. słownik systemu
3. role w systemie
4. Diagram przypadków użycia
5. Diagram związków encji
6. Diagram przepływu
7. Opis oraz porównanie metodyki Prince2 oraz metodyki Scrum
8. Opis metodyki Prince2
4
9. Opis metodyki Scrum
10. Porównanie metodyki Scrum i Prince2 pod kątem jakości
11. Porównanie metodyki Scrum i Prince2 pod kątem planowania
12. Porównanie metodyki Scrum i Prince2 pod kątem ryzyka
13. Porównanie metodyki Scrum i Prince2 pod kątem ról w zespole projektowym
14. 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.
Klient Internetowa firma turystyczna dla której jest przprowadzeny projekt informatyczny
opisany w tym dokumencie
5
Projekt Proces wytważania aplikacji dla klienta
Role w systemie
6
Nazwa przypadku Przejrzyj zawartość strony
Nr id 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 przeglądania zawartości strony w różnych
sekcjach: Aktualności, Ubezpieczenia, Słowniczek Turysty, Centrum
Prasowe, Kursy i Szkolenia, Pomoc Konsularna, Kontakt, O nas, Porady
zdrowotne, Przewodniki
Warunek początkowy Brak
Warunek końcowy Brak
Wymagania Brak
niefunkcjonalne
Uwagi dodatkowe brak
2. Znajdź wycieczkę
7
Nazwa przypadku Znajdź wycieczkę
Nr id 2
Autor Adam Rychel, Maciej Sowiński, Marcin Ciesielski, Jan Garczyński
Priorytet normalny
Typ ogólny
Aktorzy Browser, Klient
Opis Przypadek użycia dotyczy wyszukiwania ofert wycieczek przy
wykorzystaniu wyszukiwarki w menu „Znajdź wycieczkę”
Warunek początkowy Brak
Warunek końcowy Brak
Alternatywne przepływy 3a. Aktor nie wpisuje daty w menu „Znajdź wycieczkę- powrót do punktu 2
zdarzeń przypadku użycia.”
Brak
Uwagi dodatkowe brak
8
Pola znajdujące się w narzędziu „Znajdź wycieczkę ” będą następujące:
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
3
Diagram związków encji
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
6. Opis oraz porównanie metodyki Prince2 oraz metodyki
Scrum
7. Opis Prince2
Prince2 to metodyka zarządzania projektami oparta na pozytywnych i negatywnych
doświadczeniach uzyskanych przez kierowników projektów z krajów anglosaskich.
Zastosować ją można do zarządzania i sterowania projektami wszelkiego rodzaju i wszelkiej
wielkości.
3
• Brak zdrowego rozsądku
• Brak rezerw umożliwiających działania awaryjne
• Błędy w zarządzaniu punktem styku pomiędzy kierownictwem firm a
projektem (np. w przydziale zasobów)
2. Zarządzanie bieżące
• Brak właściwych instrumentów sterowania projektem i niewłaściwe ich
wykorzystanie
• Brak systemu zarządzania zmianami
• Błędy w planowaniu działań, które złożą się na projekt
Nazwa jest skrótem ang. słów: Projects In a Controlled Environment tzn. Projekty w
sterowanym środowisku
Historia Prince2
U źródeł metodyki PRINCE2 leży PROMPT (Project Resource Organisation Management
Planning Technique) metodyka prowadzenia projektów informatycznych opracowana przez
firmę prywatną Simpact Systems Limited w połowie lat 70. Na zamówienie rządowe
wzbogacono metodykę o kwestię zarządzania jakością. Część standardu pod nazwą PROMPT
II została w 1983 r. wprowadzona w jednostkach administracji rządowej Wielkiej Brytanii. Po
wykupieniu praw do metodyki PROMPT przez firmę LBMS, w 1989 r. brytyjska agenda
rządowa Central Computer and Telecommunications Agency (CCTA) opublikowało standard
pod nową nazwą – PRINCE (Projects in Controlled Environments) i wskazała jako zbiór
najlepszych praktyk zarządzania projektami informatycznymi. Wkrótce jednak metodyka
zaczęła być stosowana także poza obszarem IT.
PRINCE2 został opublikowany po raz pierwszy w 1996 r. jako ogólna metoda zarządzania
projektami niezależna od dziedziny biznesowej zastosowania. PRINCE2 szybko zdobywał
popularność i stał się standardem de facto w Wielkiej Brytanii. Zyskuje też coraz szersze
uznanie na całym świecie stanowiąc główną alternatywę (nie wykluczającą) dla metodyki
PMBOK instytutu PMI. Ostatnie zmiany zostały opublikowane w 2005 przez Office for
Government Commerce (OGC) – następcę CCTA. W 2009 roku została opublikowana nowa
wersja.
Procesy Prince2
PRINCE2 cechuje podejście procesowe do zarządzania projektem. Definiuje szczegółowo
osiem procesów najwyższego rzędu, które z kolei dzielą się na podprocesy:
1. Strategiczne zarządzanie projektem (ZS) (Directing a project (DP))
2. Planowanie (PL) (Planning (PL))
3. Uruchamianie Projektu/Przygotowanie Założeń Projektu (PP) (Starting up a project
(SU))
3
4. Inicjowanie projektu (IP) (Initiating a project (IP))
5. Sterowanie Etapem (SE) (Controlling a stage (CS))
6. Zarządzanie Wytwarzaniem Produktów (WP) (Managing product delivery (MP))
7. Zarządzanie Zakresem Etapu (ZE) (Managing stage boundaries (SB))
8. Zamykanie Projektu (ZP) (Closing a project (CP)_
4
zarządzanie poprzez wyjątki (management by exception), co oznacza, że jedyną dodatkową
sytuacją, kiedy Komitet Sterujący angażuje się w podejmowanie decyzji projektowych jest
moment, gdy uzyska informacje, że projekt jest zagrożony wyjściem poza zakres tolerancji.
Planowanie (Planning)
Planowanie jest procesem trwającym przez cały cykl życia projektu.
4
uzasadniony biznesowo i czy należy kontynuować prace. W tym procesie realizowane jest
bieżące zarządzanie projektem Kierownika Projektu.
4
Po zakończeniu projektu w zaplanowanym momencie pozwalającym na należytą ocenę
skutków biznesowych projektu przeprowadzany jest przegląd poprojektowy.
Komponenty
Uzasadnienie biznesowe
Organizacja
4
jednoosobowo odpowiada za powodzenie projektu. Przewodniczący Komitetu Sterującego
powinien być właścicielem uzasadnienia biznesowego. Zakaz kumulowania ról: Komitetu
Sterującego i Kierownika Projektu; Kierownika Projektu i Kontrolera Jakości; Kierownika
Projektu i Nadzoru projektu.
Role
1. Komitet Sterujący (Project Board)
2. Przewodniczący Komitetu Sterującego (Executive)
3. Główny Użytkownik (Senior User)
4. Główny Dostawca (Senior Supplier)
5. Kierownik projektu (Project Manager)
6. Nadzór projektu (Project Assurance)
7. Kierownik Zespołu – rola opcjonalna (Team Manager)
8. Wsparcie Projektu – rola opcjonalna (Project Support)
9. Właściciel ryzyka
10. Interesariusz
Zakresy obowiązków
4
5. Sprawuje specjalistyczny nadzór nad projektem oraz nadzór nad przyszłą eksploatacją
i utrzymaniem produktu
4
Plany
Plany zgodnie z PRINCE2 muszą być zatwierdzone zanim zostaną przekazane do realizacji.
Wyróżnia się 3 poziomy planu:
1. Plan projektu (Project Plans)
2. Plan etapu (Stage Plans)
3. Plan pracy zespołu (Team Plans)
Ponadto czwartym typem planu jest plan naprawczy (Exception plan), który zastępuje plan
etapu w wypadku pojawienia się zagrożenia istotnymi odchyleniami przekraczającymi
tolerancję.
Elementy sterowania
Elementy sterowania mają zapewnić, że projekt jest prowadzony zgodnie z planem i
uzasadnieniem biznesowym. PRINCE2 stosuje metodę zwaną 'management by exception',
która angażuje Komitet Sterujący tylko wtedy kiedy pojawia się odchylenie wskazujące na
możliwość wykroczenia projektu poza ramy określone tolerancją i uzasadnieniem
biznesowym. Cała odpowiedzialność za bieżące zarządzanie projektem oraz podejmowanie
decyzji zmierzających do realizacji zadań projektowych zgodnie z planem spoczywa na
Kierowniku Projektu.
Zarządzanie ryzykiem
Każdy projekt z uwagi na niepowtarzalność parametrów realizacyjnych oraz zmiany w
otoczeniu biznesowym musi brać pod uwagę możliwość wystąpienia zdarzeń nieplanowanych
mogących mieć istotny wpływ na sposób jego realizacji. Ryzyko to niepewność wyniku.
Zarządzanie ryzykiem polega na utrzymywaniu ryzyka w akceptowalnych granicach w
sposób efektywny i racjonalny kosztowo.
4
1. Tolerancji na ryzyko (Risk Tolerance)
2. Odpowiedzialności za ryzyko (Risk Responsibility)
3. Własności (przynależność) ryzyka (Risk Ownership)
Jakość produktów, jakie powstają w projekcie PRINCE2, osiągnięta musi być poprzez
podwójną - obiektywną - kontrolę. Obiektywizm tej kontroli polega na wykluczeniu z jej
przebiegu zarówno Kierownika Projektu jak wytwórców produktów. Sprawowana jest przez
strukturę niezależnych testerów oraz przez nadzór projektu.
Zarządzanie konfiguracją
Zarządzanie konfiguracją zajmuje się kontrolowaniem wszystkich produktów projektu.
Konfiguracja to zbiór logicznie powiązanych produktów, które muszą być traktowane i
zarządzane jako złożona całość uwzględniająca zależności pomiędzy wersjami części
składowych i ich statusami.
4
Sterowanie zmianami
Sterowanie zmianami opiera się na technice sterowania zmianami.
Rodzaje zmian
1. wniosek o wprowadzenie zmiany (koszt pokrywa klient)
2. odstępstwo (koszt naprawy pokrywa dostawca)
3. ustępstwo (brak działań korygujących)
Techniki
Technika to instrukcja postępowania krok po kroku, przy użyciu której w poszczególnych
procesach wytwarzane lub wykorzystywane są produkty specjalistyczne i zarządcze.
Sterowanie zmianami
W PRINCE2 wszystkie zmiany są traktowane jako zagadnienia projektowe:
1. wnioski o zmianę (Request for change) – dotyczące zmiany w wymaganiach albo
produkcie.
2. odstępstwo (Off specification) – rejestrowane kiedy produkt nie spełnia wymagań.
3. sugestie (suggestions)
4. zapytania (queries)
5. zagadnienia ogólne (general issue)
4
Przeglądy jakości
PRINCE2 wymaga aby produkty podlegały przeglądowi jakości. Zadaniem przeglądów
jakości jest określenie czy produkt spełnia kryteria jakości określone w Opisie Produktu tzn.
czy nie zawiera błędów, braków lub innych niezgodności.
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
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
4
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)
8. Opis Scrum
Struktura metodyki Scrum obejmuje: Zespoły Scrum (Scrum Teams) i powiązane z nimi role,
ograniczenia czasowe (time-boxes), narzędzia (artifacts) i reguły postępowania.
W każdym Zespole Scrum występują trzy role: 1) Mistrz (Scrum Master) odpowiedzialny za
zrozumienie i spełnienie założeń procesu przez zespół; 2) Właściciel Produktu (Product
Owner) odpowiedzialny za maksymalizację wartości pracy wykonywanej przez zespół; oraz
3) Zespół (The Team), który wykonuje pracę. Zespół składa się ze specjalistów posiadających
wszelkie umiejętności konieczne do przekształcenia wymagań Właściciela Produktu w
potencjalnie zbywalny fragment
produktu w ciągu jednego Sprintu.
5
podstawowe narzędzie oceny postępu prac w projekcie. Pomiar wypalania dla projektu
(Release Burndown) pokazuje elementy pozostające
w rejestrze produktowym w stosunku do czasu zakończenia projektu, natomiast pomiar
wypalania dla Sprintu (Sprint Burndown) ukazuje zadania pozostające w rejestrze
zadaniowym w stosunku do końca Sprintu.
Reguły postępowania spajają ograniczenia czasowe, role i narzędzia. Są one kolejno opisane
w tym poradniku. Przykładowo, jedną z zasad obowiązujących w Scrumie
jest zabieranie głosu podczas Codziennego Scruma tylko przez członków Zespołu
scrumowego, czyli osoby zaangażowane w przekształcanie rejestru produktowego
w przyrost produktu.
Role w Scrumie
Zespół Scrum (The Scrum Team) składa się z Mistrza, Właściciela Produktu i Zespołu.
Członkowie Zespołu scrumowego to „świnki”, zaś wszyscy inni to „kurczaki”. Kurczaki nie
mogą mówić świnkom, jak mają wykonywać swoją pracę. Kurczaki i świnki pochodzą z tej
historyjki:
Kurczak i świnka siedzieli sobie razem, gdy nagle kurczak
powiedział: „Załóżmy restaurację!”
Świnka zastanowiła się i zapytała: „A jak ją nazwiemy?”
Kurczak odparł: „Jaja na boczku!”
Na to świnka odrzekła: „O nie, dziękuję! Ty się w to tylko
zaangażujesz, a ja – ja się poświęcę!”
Mistrz
Zadaniem Mistrza jest dopilnowanie przestrzegania przez Zespół scrumowy wartości, praktyk
i reguł Scruma. Mistrz ma pomóc Zespołowi oraz organizacji zastosować metodykę Scrum.
Uczy on Zespół, trenując i prowadząc jego członków do osiągnięcia
większej wydajności i tworzenia produktów o wyższej jakości. Mistrz pomaga Zespołowi
zrozumieć i stosować zasady samozarządzania i wielofunkcyjności. Jednak Mistrz nie
zarządza Zespołem: Zespół organizuje się sam.
Właściciel Produktu
Właściciel Produktu jest jedyną osobą odpowiedzialną za zarządzanie rejestrem produktowym
i za czuwanie nad wartością pracy wykonywanej przez Zespół. Ta osoba
prowadzi rejestr produktowy i ma za zadanie dopilnować, aby był on dla wszystkich
widoczny. Dzięki temu wszyscy wiedzą, które elementy rejestru mają najwyższy priorytet, a
więc wiedzą nad czym będą pracować w kolejnych Sprintach. Właściciel Produktu to jedna
osoba, nie komitet. Mogą istnieć grupy, które doradzają tej osobie lub wpływają na nią, ale
jeśli ktoś chce zmienić priorytet jednej z pozycji rejestru, musi przekonać Właściciela. Firmy,
które zaczynają stosować Scrum, mogą się przekonać, że z upływem czasu wpłynie to na ich
metody ustanawiania priorytetów i wymagań.
Aby Właściciel Produktu odniósł sukces, wszyscy członkowie organizacji muszą szanować
jego decyzje. Nikomu nie wolno nakazać Zespołowi, by pracował z innym zestawem
priorytetów, a Zespołowi nie wolno słuchać kogoś, kto mówi coś innego niż Właściciel. Jego
decyzje są widoczne w zawartości i priorytetach elementów rejestru produktowego. Potrzeba
5
zapewnienia tej przejrzystości sprawia, że Właściciel Produktu musi zawsze robić wszystko
co w jego mocy, przez co jego rola staje się trudniejsza, ale też daje więcej satysfakcji.
Zespół
Zespół programistów w czasie każdego Sprintu przetwarza rejestr produktowy w kolejne
przyrosty potencjalnie zdatnej do wydania funkcjonalności. Zespoły są także
interdyscyplinarne; członkowie Zespołu muszą posiadać wszystkie umiejętności potrzebne do
wytworzenia kolejnego przyrostu produktu. Często członkowie Zespołu posiadają
wyspecjalizowane umiejętności, na przykład: programowanie, kontrola jakości, analiza
biznesowa, architektura, projektowanie interfejsu użytkownika, czy
zarządzanie bazami danych. Jednak umiejętności wspólne dla wszystkich członków Zespołu –
to znaczy umiejętność podjęcia wymagania i przekształcenia go w
używalny produkt – są ważniejsze od umiejętności, których ze sobą nie dzielą. Ci, którzy nie
chcą tworzyć kodu, ponieważ są architektami czy projektantami, nie
pasują do Zespołu. Każdy musi dołożyć swoją cząstkę pracy, nawet, jeśli wymaga to nabycia
nowych umiejętności lub przypomnienia sobie starych. W Zespołach Scrum nie istnieje
hierarchia służbowa, nie stosuje się również nazewnictwa stanowisk i
od tej reguły nie ma wyjątków. Zespoły nie składają się też z podzespołów oddanych
konkretnym obszarom pracy, jak na przykład testowanie czy analiza biznesowa.
Zespoły są samoorganizujące się. Nikt – nawet Mistrz – nie może mówić Zespołowi, jak
przekształcić rejestr produktowy w zbywalną funkcjonalność. Zespół dochodzi do tego sam.
Każdy członek Zespołu wykorzystuje swoje kompetencje do rozwiązania
każdego problemu. Powstająca synergia podnosi całkowitą wydajność i skuteczność Zespołu.
Optymalna liczebność Zespołu to siedem osób, plus minus dwie. Gdy członków Zespołu jest
mniej niż pięcioro, zachodzi mniej interakcji i uzyskuje się mniejszą produktywność. Co
więcej, Zespół może doświadczyć niedoboru umiejętności w pewnych etapach Sprintu i nie
będzie w stanie dostarczyć zbywalnego fragmentu produktu. Natomiast gdy w Zespole jest
więcej niż dziewięć osób, wymagana jest intensywniejsza koordynacja. Duże Zespoły
generują zbyt wielką złożoność zarządzania empirycznym procesem. Jednak znane są
przypadki Zespołów, które przekroczyły dolną lub górną granicę liczebności, a jednak
odniosły sukces. Właściciel Produktu i Mistrz nie są w tej liczbie uwzględniani.
Skład Zespołu może się zmienić jedynie z końcem Sprintu. Za każdym razem, gdy zmienia
się skład Zespołu, zmniejsza się jego produktywność uzyskana dzięki samoorganizacji.
Dlatego zmianom składu osobowego Zespołu towarzyszyć musi duża ostrożność.
Ograniczenia czasowe
Ograniczenia czasowe w Scrumie dotyczą: spotkania planistycznego wydania, Sprintu,
spotkania planistycznego Sprintu, przeglądu Sprintu, retrospektywy Sprintu i Codziennego
Scruma.
5
Spotkanie planistyczne wydania
Przedmiotem spotkania planistycznego wydania jest ustalenie celu i planu realizacji projektu,
które Zespoły i reszta organizacji może zrozumieć i będzie wspierać. Planowanie wydania
odpowiada na pytania: "W jaki sposób przekształcić wizję w produkt, który odniesie sukces
na rynku?", "Jak możemy sprostać oczekiwaniom klienta i zapewnić wymagany zwrot
inwestycji, a nawet je przewyższyć?". W planie realizacji ustala się: cel ostateczny projektu,
wstępne założenia rejestru produktowego, opis cech i funkcjonalności, które produkt będzie
zawierał w chwili wydania, oraz
główne zagrożenia związane z realizacją projektu. Plan ten wyznacza również przypuszczalną
datę zakończenia pracy i koszt wytworzenia produktu, które powinny być wiążące, o ile do
planu nie zostaną wprowadzone zmiany. Dzięki temu organizacja może ze Sprintu na Sprint,
w oparciu o kolejne przyrosty produktu, nadzorować postęp prac i dokonywać niezbędnych
korekt w planie realizacji projektu.
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ń
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.
5
Jeśli horyzont jest zbyt odległy, może zdarzyć się tak, że zmieni się definicja produktu,
pojawi się zbyt dużo zmiennych, ryzyko będzie zbyt duże, itd. Scrum jest metodyką
odpowiednią dla projektów na tyle złożonych, że przygotowywanie planów o horyzoncie
czasowym dłuższym niż jeden miesiąc byłoby dla nich zbyt ryzykowne. Przewidywalność
projektu musi być kontrolowana przynajmniej co miesiąc, a ryzyko, że projekt może
wymknąć się spod kontroli lub stanie się nieprzewidywalny, powinno być kontrolowane i
minimalizowane nie rzadziej niż co miesiąc.
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.
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
5
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
muszą na sobie polegać. Gdy sobie to uświadomią, zaczynają się samoorganizować oraz
nabierają cech i zachowań prawdziwego zespołu.
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.
5
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.
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?
• 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.
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).
5
Rejestr produktowy i wypalanie w projekcie
Wymagania dotyczące produktu wytwarzanego przez Zespół spisane są w rejestrze
produktowym. Odpowiedzialnym za jego zawartość, dostępność i ustalenie priorytetów jest
Właściciel Produktu. Rejestr produktowy nigdy nie jest zamknięty. Jego pierwsza
wersja zawiera jedynie początkowo znane i najlepiej rozumiane wymagania. Rejestr
produktowy ewoluuje wraz z produktem i środowiskiem, w którym będzie używany.
Rejestr jest dynamiczny w tym znaczeniu, że stale się zmienia, aby uwzględnić to, czego
produkt wymaga, aby być odpowiednim, konkurencyjnym i użytecznym. Rejestr
istnieje tak długo, jak istnieje produkt.
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
jest Zespół. Właściciel Produktu może wpływać na Zespół, pomagając mu zrozumieć problem
i dokonać wyboru, gdy zachodzi konieczność kompromisu (trade-offs), ale ostateczna
estymacja jest dokonywana przez
sam Zespół. Właściciel Produktu przez cały czas, na bieżąco, uaktualnia wykres wypalania
produktu według rejestru produktowego. Linia trendu jest wyznaczana na podstawie zmian w
ilości pozostałej pracy.
5
W tworzeniu oprogramowania, stwierdzenie, że funkcjonalność jest „gotowa” może dla
jednych oznaczać, że kod źródłowy jest w miarę czysty, zrefaktoryzowany,
przetestowany jednostkowo, zbudowany i po testach akceptacyjnych. Dla innych może to
oznaczać, że po prostu istnieje kod. Jeżeli nie wszyscy wiedzą, jaka jest obowiązująca
definicja „gotowego”, to nie zadziałają dwa pozostałe filary empirycznej kontroli procesu.
Jeśli określamy coś jako „gotowe”, wszyscy muszą wiedzieć, co „gotowe” oznacza.
„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
Produktu musi to rozumieć. Ta pozostała część pracy musi zostać wykonana, zanim produkt
będzie oddany do wdrożenia i użytkowania.
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łądnikach:
• 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.
5
Projektu jak wytwórców produktów. Sprawowana jest przez strukturę niezależnych testerów
oraz przez nadzór projektu
W Scrum jakość jest osiągana przez stworzenie roli Właściciela produktu, który jest
odpowiedzialny za zbieranie wymagań dla projektu, a ponieważ jest to osoba ze strony
klienta, minimalizuje się tutaj ryzyko złej komunikacji. Scrum dużą uwagę zwraca na
podniesienie komunikacji i przejrzystości w projekcie, służą do tego:
• Spotkanie planistyczne sprintu
• Przegląd sprintu
• Retrospekcja sprintu
• Wykresy wypalania
• Codzienne scrumy
tak aby każdy zainteresowany wiedział co jest wykonywane w projekcie i jakie problemy
napotyka zespół. Wreszcie Scrum zwraca uwagę na potrzebę implementacji „najlepszych
praktyk”, a część jak iteracyjność, czy planowanie „just in time” sam narzuca. Scrum dla
uzyskania wysokiej jakości jest często łączony z techniką extremme programming.
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
Zgodnie z metodyką PRINCE2 projekt jest to „Środowisko zarządzania stworzone w celu
dostarczenia jednego lub więcej liczby produktów biznesowych stosownie do specyficznych
wymagań biznesu”. Z definicji tej wynika wprost najważniejszy element projektu – potrzeba
biznesowa. Ta potrzeba biznesowa będzie stanowiła podstawę do sporządzenia jednego z
pierwszych dokumentów zarządczych – uzasadnienia biznesowego projektu stanowiącego
podstawę dalszego planowania i realizacji projektu.
Definicja określa również sposób, w jaki potrzeba biznesowa zostanie zaspokojona mówiąc o
produktach biznesowych. To właśnie wytworzone i wdrożone do eksploatacji produkty
biznesowe określane również mianem produktów technicznych bądź specjalistycznych mają
za zadanie zaspokoić potrzebę biznesową. Produktowe podejście do planowania będzie
konsekwentnie podtrzymywane podczas procesu planowania poprzez nieliczne wskazywane
przez metodykę PRINCE2 techniki: strukturę produktową (PBS - Product Breakdown
Structure) i diagram następstwa produktów.
6
Dzięki spójnemu podejściu do projektu od potrzeby biznesowej do sposobu jej zaspokojenia
przez produkty oraz produktowemu podejściu do planowania metodyka gwarantuje, że:
• Zakres prac projektowych obejmuje jedynie pracę niezbędną do osiągnięcia celu
biznesowego przy akceptowalnym poziomie ryzyka
• Uzasadnienie biznesowe projektu jest cały czas aktualne i stanowi podstawę do
planowania i realizacji wszystkich działań
• Projekt jest prowadzony w sposób kontrolowany i bezpieczny
Przygotowanie projektu
Przyjrzyjmy się fazie przedprojektowej. Początkiem każdego projektu jest potrzeba
biznesowa. Potrzeba biznesowa sformalizowana poprzez dokument Zlecenia Podstawowych
Założeń Projektu (Project Mandate) lub w jakiś inny sposób trafia do osoby w organizacji,
która ma kompetencje do podjęcia decyzji, czy w ogóle warto się sprawą zająć. Jeśli
przyczyna dla której projekt ma zostać powołany jest istotna a spodziewane korzyści
uzasadniają podjęcie ryzyka realizacji projektu zapewne zapadnie decyzja o uruchomieniu
procesów przygotowania projektu (PP). W ramach tych procesów powstanie Zespół
Zarządzania Projektem oraz określona zostanie formuła realizacyjna projektu. Natomiast w
procesie PP4 zostaną przygotowane Założenia Projektu. Celem Założeń Projektu jest
umożliwienie Komitetowi Sterującemu podjęcia decyzji, czy istnieje wystarczające
uzasadnienie aby ponieść koszty w etapie Inicjowania Projektu. Innymi słowy na etapie
Przygotowania Projektu:
• Zbudowany zostanie zespół zarządzania projektem
• Zebrane zostaną dane niezbędne do podjęcia decyzji o ustanowieniu projektu
• Zaplanowany zostanie etap inicjowania projektu
Warto zwrócić uwagę na to, że wszelkie prace na tym etapie ograniczone są do absolutnego
minimum niezbędnego do realizacji powyższych punktów. Ponieważ nie wiadomo, czy
projekt zostanie uruchomiony Nie ma sensu ponosić na tym etapie nieuzasadnionych
kosztów.
Inicjowanie projektu
Celem etapu inicjowania projektu jest stworzenie swoistego „kontraktu” pomiędzy
Komitetem Sterującym a Kierownikiem Projektu. Kontrakt ten w formie Dokumentu
Inicjującego Projekt (DIP) będzie opisywał standardy dotyczące jakości, komunikacji, ryzyka,
obszarów kompetencji. Jednym z jego elementów będzie również ogólny planu projekt
powstały na skutek dekompozycji zakresu projektu. Punktem wyjścia tej dekompozycji
powinny być określone w Podstawowych Założeniach Projektu cele produktowe. Plan
projektu powinien być sporządzony na dużym poziomie ogólności. Powinien dzielić obszar
projektu na etapy zarządcze, wskazując główne produkty wytwarzane w ramach konkretnych
etapów.
6
1
Proces planowania
Proces planowania (PL) jest procesem, który bierze udział praktycznie we wszystkich fazach
projektu. W etapie przygotowania projektu będzie powstawał plan etapu inicjowania, w etapie
inicjowania – plan projektu, podczas zarządzania zakresem – plan etapu bądź plan
nadzwyczajny, w ramach procesów zarządzania wytwarzaniem produktów – plany dla
zespołów zadaniowych (realizacyjnych).
6
• Kiedy to się wydarzy
6
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
Schemat procesów według Scrum przedstawia powyższy rysunek. Projekt zaczyna się zawsze
od przygotowania na spotkaniu Product Backlog czyli zbioru wymagań do wykonania aby
osiągnąć cel projektu.
Jesli projekt jest dostatecznie duży można Product Backlog podzielić dalej na backlogi dla
wydania(Release Backlog).
Następnie wybiera się (na spotkaniu planistycznym sprintu) zbiór wymagań które będą
implenemtowane podczas Sprint i tworzy Spring Backlog.
Sprint Backlog jest uszeregowany zgodnie z priorytetami nadanymi poszczególnym
funkcjonalnością przez przedstawiciela klienta(product owner).
Rolą Scrum mastera 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 sprincie. 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.
Definicje „w pełni działającego produktu” zespół ustala wraz z klientem( podpunkt
„„Gotowe”, czyli kryterium gotowości produkcyjnej (Definition of Done, DoD) w opisie
metodyki Scrum” ).
3
http://scrum.hypersquare.com/podstawy-scruma.html
6
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
manifesto4, 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.
6
1. Zawiadomienie o rozpoczęciu inicjowania projektu
2. Zawiadomienie o rozpoczęciu realizacji projektu
3. Informacje zwrotne
4. Zawiadomienie o rozpoczęciu zamykania projektu
5. Zawiadomienie o zamknięciu projektu
6
Zakres obowiązków Nadzoru projektowego
1. Monitorowanie ryzyka
2. proponowanie sposobów mityzacji ryzyka
3. Cykliczne raportowanie o ryzyku
1. Scrum master
6
2. Produkt owner
3. Członek zespołu
9. Wymagania funkcjonalne
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
6
Oglądanie ofert 1
Kraje 1
Zarządzanie userami 2
6
Przeglądanie ofert biura 1
Edycja zamówień OK
Edycja ofert OK
Oglądanie ofert OK
7
Załączenie plików do artykułów OK
Kraje OK
Drugi sprint
Funkcjonalność Stan Uwagi
Komentarze do ofert/ocena OK
Zarządzanie userami OK
7
sprintu
Sprint końcowy
7
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
Obiektowy skryptowy język programowania, najczęściej stosowany na stronach WWW.
Pisząc skrytpy skorzytamy z biblioteki prototpe co da nam pewność, że nasz kod
będzie poprawnie interpretowany przez większość przeglądarek internetowych.
• Ajax
Asynchroniczny JavaScript i XML – technika tworzenia aplikacji internetowych, w której
interakcja użytkownika z serwerem odbywa się bez przeładowywania całego dokumentu.
• PostgreSQL
Obok MySQL i Firebird, jeden z trzech najpopularniejszych wolnodostępnych systemów
zarządzania relacyjnymi bazami danych. Zalicza się do baz typu RDBMS z rozszerzeniami
obiektowymi.
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
7
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
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