[praca inzynierska]Prince2vsScrum

Metodyki Prowadzenia Projektów IT na podstawie projektu internetowej firmy turystycznej.

1

Spis Treści1. Cel...........................................................................................................................................42. Informacje o zastosowanych metodach..................................................................................43. Rozwiązanie problemu............................................................................................................44. Zawartość pracy......................................................................................................................45. Dokumentację techniczną z wykonanego systemu IT............................................................5

1. Przejrzyj zawartość strony............................................................................................62. Znajdź wycieczkę..........................................................................................................73. Wyszukaj ofertę...........................................................................................................104. Dodaj komentarz..........................................................................................................125. Pokaż komentarze.......................................................................................................136. Rejestruj się.................................................................................................................147. Zaloguj się...................................................................................................................168. Edytuj dane..................................................................................................................179. Zapisz na newsletter...................................................................................................1810. Zarządzaj schowkiem................................................................................................1911. Zarezerwuj ofertę.......................................................................................................2012. Modyfikuj zawartość strony......................................................................................2113. Zarządzaj użytkownikami..........................................................................................2514. Zarządzaj grupami użytkowników...........................................................................2615. Modyfikuj dane klientów...........................................................................................2716. Modyfikuj rezerwacje................................................................................................2817. Modyfikuj Emaile......................................................................................................291. Dodanie nowego newsa przez administratora:............................................................312. Dodanie nowego typu wakacji przez administratora...................................................333. Dodanie nowego hotelu przez administratora:............................................................344. Dodanie pliku do galerii plików..................................................................................365. Dodaj użytkownika......................................................................................................37

6. Opis oraz porównanie metodyki Prince2 oraz metodyki Scrum ..........................................387. Opis Prince2..........................................................................................................................38

Przygotowanie założeń projektu/Uruchamianie projektu (Starting up a project)...........40Zarządzanie strategiczne projektem (Directing a project)...............................................40Planowanie (Planning).....................................................................................................41Inicjowanie projektu (Initiating a project).......................................................................41Sterowanie etapem (Controlling a stage).........................................................................41Zarządzanie zakresem etapu (Managing stage boundaries)............................................42Zamykanie projektu (Closing a project)..........................................................................42Uzasadnienie biznesowe..................................................................................................43Organizacja......................................................................................................................43Plany................................................................................................................................46Elementy sterowania........................................................................................................46Zarządzanie ryzykiem......................................................................................................46Parametry ryzyka w PRINCE2........................................................................................47Jakość w środowisku projektowym.................................................................................47Zarządzanie konfiguracją.................................................................................................47Sterowanie zmianami......................................................................................................48Planowanie oparte na produktach....................................................................................48Sterowanie zmianami......................................................................................................48Przeglądy jakości.............................................................................................................49

2

Dokumentacja inicjująca projekt ....................................................................................49Rejestry............................................................................................................................49Raporty............................................................................................................................49Plany................................................................................................................................50

8. Opis Scrum............................................................................................................................50Mistrz...............................................................................................................................51Właściciel Produktu.........................................................................................................51Zespół..............................................................................................................................52Spotkanie planistyczne wydania......................................................................................53Sprint...............................................................................................................................53Spotkanie planistyczne Sprintu.......................................................................................54Przegląd Sprintu..............................................................................................................55Retrospektywa Sprintu....................................................................................................56Codzienny Scrum............................................................................................................56Rejestr produktowy i wypalanie w projekcie..................................................................57Rejestr zadaniowy i wypalanie w Sprincie......................................................................58Wykres wypalania w Sprincie to wykres przedstawiający..............................................58„Gotowe”, czyli kryterium gotowości produkcyjnej (Definition of Done, DoD)...........58Planowanie w Prince2.....................................................................................................60Planowanie w Scrum.......................................................................................................64Podsumowanie.................................................................................................................65Zakres obowiązków Komitetu Sterującego ....................................................................65Zakres obowiązków Głównego użytkownika produktu .................................................66Zakres obowiązków Głównego dostawcy produktu .......................................................66Zakres obowiązków Przewodniczącego Komitetu Sterującego .....................................66Zakres obowiązków Kierownika Projektu .....................................................................66Zakres obowiązków Nadzoru projektowego...................................................................67Zakres obowiązków kierownika zespołu.........................................................................67Zakres obowiązków wsparcia projektowego...................................................................67Zakres obowiązków właściciela ryzyka..........................................................................67Zakres obowiązków Interesariusza..................................................................................67Zakres obowiązków Scrum mastera................................................................................68Zakres obowiązków Produkt ownera..............................................................................68Zakres obowiązków członka zespołu..............................................................................68

9. Wymagania funkcjonalne.....................................................................................................6810. Wymagania niefunkcjonalne...............................................................................................7011. Przeglądy sprintów..............................................................................................................7012. Przegląd wydania................................................................................................................7213. Diagram związków encji.....................................................................................................7414. Wybór technologii...............................................................................................................7415. Opis używanych technologii...............................................................................................7416. Moduły systemu..................................................................................................................76

3

1. CelCelem 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.

2. Informacje o zastosowanych metodachMetody zastosowane w projekcie w celu stworzenia aplikacji są następujące:

Zebranie wymagań użytkownika Stworzenie diagramu przypadków użycia Stworzenie diagramu związków encji Użycie kryteriów akceptacyjnych

Metody zastosowane w projekcie w celu porównania metodyki Prince2 i Scrum

Opis metodyki Prince2 Opis metodyki Scrum Porównanie metodyki Scrum i Prince2 pod kątem jakości Porównanie metodyki Scrum i Prince2 pod kątem planowania Porównanie metodyki Scrum i Prince2 pod kątem ryzyka Porównanie metodyki Scrum i Prince2 pod kątem ról w zespole projektowym Porównanie metodyki Scrum i Prince2 pod kątem milestones

3. Rozwiązanie problemuProblem 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ść pracy1. dokumentację techniczną z wykonanego systemu IT w której skład wchodzą:2. słownik systemu3. role w systemie4. Diagram przypadków użycia5. Diagram związków encji6. Diagram przepływu7. Opis oraz porównanie metodyki Prince2 oraz metodyki Scrum 8. Opis metodyki Prince29. Opis metodyki Scrum10. Porównanie metodyki Scrum i Prince2 pod kątem jakości

4

11. Porównanie metodyki Scrum i Prince2 pod kątem planowania12. Porównanie metodyki Scrum i Prince2 pod kątem ryzyka13. Porównanie metodyki Scrum i Prince2 pod kątem ról w zespole projektowym14. 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ów4. przegląd wydania

5. Dokumentację techniczną z wykonanego systemu IT

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 użycia

Grupa interakcji między aktorem a systemem. Interakcje powinny mieć cechy transakcji(niepodzielnych operacji) w systemie dostarczających aktorowi rezultatu o mierzalnej wartości.

Diagram kontekstowy

Graficzne przedstawienie elementów środowiska, z którymi definiowany system pozostaje w interakcji. Elementy środowiska przedstawia się za pomocą aktorów.

Użytkownik końcowy

Bezpośredni konsument usługi; jest to aktor, który jest identyfikowany w modelu każdej usługi. W usłudze może uczestniczyć wielu aktorów.

Skrót Pełna nazwa/wyjaśnienie

Klient Internetowa firma turystyczna dla której jest przprowadzeny projekt informatyczny opisany w tym dokumencie

5

Projekt Proces wytważania aplikacji dla klienta

Metodyka agile

Metody prowadzenia projektów z grupy agile

Team Zespół tworzący projekt

Artefakt Dokument który jest tworzony w ramach metodyki

Role w systemie

Rola Opis Roli

Klient Osoba zarejestrowana w systemie. Posiada pełne możliwości przeglądania strony, dodawania komentarzy, rezerwacji wycieczki.

Browser Osoba odwiedzająca stronę. Posiada możliwość przeglądania ogólnie dostępnych treści

Administrator Pracownik posiadający uprawnienia do wprowadzania danych konfiguracyjnych dla aplikacji- na przykład do modyfikacji list słownikowych

Diagram przypadków użycia

1. Przejrzyj zawartość strony

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

Główny przepływ zdarzeń Aktor uruchamia przypadek.

Określenie żądanego zakresu danych do wyświetlenia

System wyświetla informacje zawarte w określonej sekcji strony..

Aktor odczytuje informacje.

Koniec przypadku użycia

Alternatywne przepływy zdarzeń

Brak

Wymagania niefunkcjonalne

Brak

Uwagi dodatkowe brak

2. Znajdź wycieczkę

7

Nazwa przypadku Znajdź wycieczkę

Nr id 2


Priorytet normalny

Typ ogólny


Opis Przypadek użycia dotyczy wyszukiwania ofert wycieczek przy wykorzystaniu wyszukiwarki w menu „Znajdź wycieczkę”



Główny przepływ zdarzeń 1. Aktor uruchamia przypadek.

2. Aktor wprowadza określone kryteria na formularzu Znajdź wycieczkę

3. Wyszukanie rekordów poprzez wciśnięcie przycisku „Szukaj”

4. System wyświetla informacje dotyczące wycieczki spełniające kryteria.

5. Aktor odczytuje informacje.

6. Koniec przypadku użycia


3a. Aktor nie wpisuje daty w menu „Znajdź wycieczkę- powrót do punktu 2 przypadku użycia.”


Wyświetlenie listy wycieczek spełniających kryteria określone przez aktora.

BrakUwagi dodatkowe brak

8

Pola znajdujące się w narzędziu „Znajdź wycieczkę ” będą następujące:

Nazwa pola Wymagalność

Kategoria wycieczki

Nie

Kraj Nie

Miejsce pobytu Nie

Wyjazd od Tak

Liczba dni Nie

Przedział cenowy

Nie

9

3. Wyszukaj ofertę

Nazwa przypadku Wyszukaj ofertę

Nr id 3


Priorytet normalny

Typ ogólny


Opis Przypadek użycia dotyczy wyszukiwania ofert przy wykorzystaniu następujących sekcji: Oferty tematyczne, Najpopularniejsze kraje, Najpopularniejsze miejsca pobytu, Najwyżej oceniane hotele




2. Aktor wybiera określoną sekcję do wyszukania oferty

3. Aktor wybiera określoną subkategorię w ramach danej sekcji..

4. System wyświetla informacje dotyczące wybranej wycieczki lub grupy wycieczek..

5. Aktor używa przycisku „Pokaż oferty ” w celu wyświetlenia wyników wyszukiwania

6. System wyświetla listę wraz z następującymi danymi: zdjęcie, szczegóły wycieczki, Standard, Najbliższy termin, Cena.

7. Użytkownik wybiera określoną ofertę poprzez kliknięcie na pole „Nazwa” lub kliknięcie na pole „Zakwaterowanie”.

8. System wyświetla informacje dotyczące określonej wycieczki lub też miejsca Zakwaterowania. Dokładny opis pól dostępnych znajduje się w tabeli,


Alternatywne przepływy 2a. Aktor nie wpisuje poprawnej daty w menu „Znajdź wycieczkę- powrót do

1

zdarzeń punktu 2 przypadku użycia.”


Brak

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”

Tabela pola dostępne po wybraniu określonej wycieczki

Pole

Nazwa

Typ transportu

Miejsce wylotuMiejsce lądowania

Standard

Wyżywienie

Rodzaj wyjazduCena

Dodatki

Pola widoczne w menu dolnym:

Pole

Szczegóły oferty

Informacje o hotelu

Opinie o hotelu

1

Informacje o miejscowości

Pola dostępne po wybraniu menu „Zakwaterowanie”:Pole

Nazwa

Lokalizacja

Standard

Opis

Komentarze

Dodaj opinię

4. Dodaj komentarz

Nazwa przypadku Dodaj komentarz

Nr id 4


Priorytet normalny

Typ ogólny

1


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ę.




2. Aktor używa przycisku „Dodaj opinię”

3. System wyświetla formularz dodawania opinii.

4. Aktor wypełnia formularz dodania opinii uzupełniając pole „Autor ” oraz „Treść”.

5. Aktor zatwierdza dodanie opinii poprzez naciśnięcie przycisku „Dodaj opinię”

6. System zapisuje opinię, wyświetla komunikat „Komentarz został dodany pomyślnie!” oraz pokazuje listę komentarzy do danej oferty



5a. Aktor używa przycisku „Anuluj” -koniec przypadku użycia


Brak

Uwagi dodatkowe Brak

5. Pokaż komentarze

Nazwa przypadku Pokaż komentarze

Nr id 5

1


Priorytet normalny

Typ ogólny


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ę.




2. Aktor używa przycisku „Komentarze”

3. System wyświetla listę dostępnych komentarzy dla danej wycieczki.



Brak


Brak

Uwagi dodatkowe Brak

6. Rejestruj się

Nazwa przypadku Rejestruj się

Nr id 6


Priorytet Normalny

1

Typ Ogólny

Aktorzy Browser

Opis Pozwala zarejestrować swoje dane i założyć konto

Warunek początkowy Brak.


Główny przepływ zdarzeń 1. Aktor uruchamia przypadek

2. .System wyświetla formularz rejestracji

3. Aktor wypełnia formularz.

4. System sprawdza poprawność danych.

5. System zakłada konto.

6. Aktor zostaje zalogowany.



3a. Zerwane połączenie – koniec przypadku użycia.

5a. System odrzuca dane w przypadku niezgodności z wymaganiami i wyprowadza komunikat o niepoprawności – powrót do kroku 2.


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 urodzenia

Pole wymagane

Numer dowodu osobistego

9 znaków

Ulica Minimum 3 znaki

Numer domu Brak

Numer Brak

1

mieszkania

Miasto Minimum 3 znaki

Kod pocztowy

Pole wymagane

Województwo Brak

Numer telefonu

Brak

Numer telefonu komórkowego

Brak

E-mail Poprawny adres e-mail

7. Zaloguj się

Nazwa przypadku Zaloguj się

Nr id 7


Priorytet Normalny

Typ Ogólny

Aktorzy Klient, Administrator

1

Opis Pozwala zalogować się na konto

Warunek początkowy Wpisanie loginu i hasła



2. System sprawdza login i hasło

3. Aktor zostaje zalogowany, i dostaje dostęp do konta



3a. Aktor wpisuje niepoprawny login lub/i hasło i nie zostaje zalogowany – komunikat o błędzie i koniec przypadku użycia


brak


8. Edytuj dane

Nazwa przypadku Edytuj dane

Nr id 8


Priorytet Normalny

Typ Ogólny

Aktorzy Klient, Administrator

Opis Pozwala edytować dane użytkownika

Warunek początkowy Wpisanie loginu i hasła


1


2. System sprawdza login i hasło

3. Aktor zostaje zalogowany, i dostaje dostęp do swoich danych

4. Aktor modyfikuje swoje dane.

5. System zapisuje zmiany



3a. Aktor wpisuje niepoprawny login lub/i hasło i nie zostaje zalogowany – komunikat o błędzie i koniec przypadku użycia

4a. Aktor wpisuje niepoprawne dane-powrót do punktu 4


brak


9. Zapisz na newsletter

Nazwa przypadku Zapisz na newsletter

Nr id 9


Priorytet Normalny

Typ Ogólny

Aktorzy Klient, Browser

Opis Pozwala zarejestrować się na subskrypcję Newsletteru



1


2. Aktor wprowadza swojego maila.




2a. Aktor wpisuje niepoprawny adres mailowy – komunikat o błędzie i koniec przypadku użycia


brak


10. Zarządzaj schowkiem

Nazwa przypadku Zarządzaj schowkiem

Nr id 10


Priorytet Normalny

Typ Ogólny

Aktorzy Klient, Browser

Opis Pozwala dodawać wybrane przez aktora oferty do schowka i zarządzać nimi.




2. Aktor wywołuje odpowiednie operacje na schowku ofert(pokazanie zawartości schowka- przycisk „Pokaż schowek”, wyczyszczenie

1

zawartości schowka- przycisk- „Opróżnij schowek”, dodanie nowej oferty do schowka – przycisk „Dodaj do schowka”




Brak


brak


11. Zarezerwuj ofertę

Nazwa przypadku Zarezerwuj ofertę

Nr id 11


Priorytet Normalny

Typ Ogólny

Aktorzy Klient

Opis Pozwala rezerwować wybraną ofertę.

Warunek początkowy Realizacja scenariusza „Zaloguj się” a następnie wybranie oferty poprzez scenariusz „Wyszukaj ofertę” lub „Znajdź wycieczkę”



2. Aktor wypełnia wybiera dane w formularzu i naciska przycisk „Zapisz”



2


Brak


brak


Pola w formularzu zamówienia:

Pole

Terminy i ceny

Liczba osób dorosłych

Liczba dzieci

Liczba niemowląt

Liczba pokoi

12. Modyfikuj zawartość strony

2

Nazwa przypadku Modyfikuj zawartość strony

Nr id 12


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



2. Aktor wybiera odpowiednią sekcję i wykonuje operacje(dodaj, usuń, edytuj lub podgląd)




2a Aktor nie wypełnił wszystkich wymaganych pól lub wypełnił je niepoprawnie – komunikat o błędzie i powrót do formularza z danej sekcji – punkt 2


brak


Newsy

Pole wymaganeTytuł takTreść tak

2

Artykuły

Pole wymaganeTytuł takTreść tak

Typy wypoczynku

Pole wymaganeNazwa takOpis takObrazek nie

Kraje


Miejsca pobytu

Pole wymaganeNazwa takKraj takOpis takObrazek nie

Hotele

Pole wymaganeNazwa takStandard nieOpis takObrazek nie

Oferty

Pole wymaganeNazwa NieTerminy NieCena za osobę

Nie

Typ Tak

2

Transportu

Początek podróży

Nie

Cel podróży Nie

wyżywienie Tak

Cena NieTyp wypoczynku

Tak

Kraj Tak

Miejsce pobytu

Tak

Hotel Tak

Opis Nie

Dodatki Nie

Galeria plików

Nie

Dodatki


Przewodniki

Pole wymaganeNazwa NieOpis NieObrazek nie

Galerie plików

Pole wymaganeNazwa takPlik nie

2

13. Zarządzaj użytkownikami

Nazwa przypadku Zarządzaj użytkownikami

Nr id 13


Priorytet Normalny

Typ Ogólny


Opis Pozwala dodawać, edytować oraz usuwać dane użytkowników.




2. Aktor modyfikuje dane użytkownika (dodaj, usuń, edytuj)




2a. Aktor nie wypełnia wymaganych danych lub wypełnia je niepoprawnie- komunikat o błędzie – powrót do punktu 2.


brak


Pole wymaganeLogin Tak od 3 do 20

znakówHasło Tak od 5 do 20

znaków

2

Powtórz hasło

Tak od 5 do 20 znaków

Grupa Tak

14. Zarządzaj grupami użytkowników

Nazwa przypadku Zarządzaj grupami użytkowników

Nr id 14


Priorytet Normalny

Typ Ogólny


Opis Pozwala dodawać, edytować oraz usuwać grupy użytkowników




2. Aktor modyfikuje dane grup użytkowników (dodaj, usuń, edytuj)




2a. Aktor nie wypełnia wymaganych danych lub wypełnia je niepoprawnie- komunikat o błędzie – powrót do punktu 2.

Wymagania brak

2

niefunkcjonalneUwagi dodatkowe brak

Pole WymaganeNazwa Tak Lista artykułów

Nie

Szczegóły artykułu

Nie

Usuwanie artykułu

Nie

15. Modyfikuj dane klientów

Nazwa przypadku Modyfikuj dane klientów

Nr id 15


Priorytet Normalny

Typ Ogólny






2. System wyświetla listę dostępnych klientów

2

3. Aktor modyfikuje dane klientów (podgląd lub usuń)




brak


brak


16. Modyfikuj rezerwacje

Nazwa przypadku Modyfikuj rezerwacje

Nr id 16


Priorytet Normalny

Typ Ogólny






2. System wyświetla listę rezerwacji.

3. Aktor modyfikuje dane klientów (podgląd lub usuń)



2


brak


brak


17. Modyfikuj Emaile

Nazwa przypadku Modyfikuj Emaile

Nr id 17


Priorytet Normalny

Typ Ogólny






2. System wyświetla listę email.

3. Aktor modyfikuje email (usuń)




brak


brak


2

Diagram związków encji

Diagram przejść ekranów

1. Dodanie nowego newsa przez administratora:

3

2. Dodanie nowego typu wakacji przez administratora

3

3. Dodanie nowego hotelu przez administratora:

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 Prince2Prince2 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.

Główne przyczyny niepowodzenia projektów według Prince21. Produkty

Brak rozróżnienia pomiędzy celami a produktami (wynikami) projektu Wymagania i kryteria akceptacji produktu przez klienta oraz kryteria jakości

albo wcale nieokreślone, albo nie dość precyzyjnie określone, albo określone w sposób niezrozumiały dla odbiorcy bądź dostawcy produktu

1. Zarządzanie strategiczne Uzasadnienie ekonomiczne albo nieobecne, albo niedostateczne Brak „środowiska klient-dostawca” Błędy w rozdziale ról w projekcie Klient zaangażowany w realizację w sposób dorywczy bądź niesystematyczne Zaangażowanie kierownictwa firm, które realizują projekt, maleje w miarę

postępów projektu Nadmierny optymizm w planowaniu wykorzystania zasobów Nadmiar biurokracji Brak zdrowego rozsądku

3

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 Prince2U ź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.

Projekt według Prince2Warunki zarządzania stworzone w celu dostarczenia jednego lub wielu produktów natury biznesowej zgodnie z określonym uzasadnieniem biznesowym.

Procesy Prince2PRINCE2 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))4. Inicjowanie projektu (IP) (Initiating a project (IP))

3

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)_

Projekt zgodny z PRINCE2 musi zawierać co najmniej 2 etapy zarządcze: Inicjowanie projektu Realizacja projektu

Faza realizacji projektu może być rozbita na etapy realizacyjne.

Procesy Przygotowanie Założeń Projektu, Inicjowanie projektu i Zamykanie projektu to jednocześnie określone fazy cyklu życia projektu. W fazę realizacji projektu wdrożone są procesy Sterowanie Etapem, Zarządzanie Wytwarzaniem Produktów i Zarządzanie Zakresem Etapu. Proces Strategiczne Zarządzanie Projektem obejmuje cały cykl życia projektu, podczas gdy Planowanie jest aktywny we wszystkich fazach z wyjątkiem ostatniego – Zamykanie projektu.

Przygotowanie założeń projektu/Uruchamianie projektu (Starting up a project)Celem tego procesu jest przygotowanie projektu do uruchomienia. Jest to proces poprzedzający projekt. Ma on zapewnić, że projekt będzie wart ponoszonych kosztów i że da się go zrealizować. Informacją wejściową dla procesu jest Zlecenie Przygotowania Projektu (Project Mandate). W proces zaangażowane jest wyższe kierownictwo organizacji, które ustanawia i wybiera Komitet Sterujący (Project Board), który nadzoruje projekt i wybiera Kierownika Projektu. Uzasadnienie projektu jest zarysowane w Podstawowych Założeniach Projektu. W zależności od specyfiki projektu wybierana jest formuła realizacyjna. Wykonany jest także plan etapu inicjowania projektu.

Przygotowanie założeń projektu obejmuje następujące podprocesy:1. PP1. Mianowanie Przewodniczącego Komitetu Sterującego i Kierownika Projektu

(SU1. Appointing a Project Executive and a Project Manager)2. PP2. Projektowanie zespołu zarządzania projektem (SU2. Designing a Project Man-

agement Team)3. PP3. Mianowanie zespołu zarządzania projektem (SU3. Appointing a Project Manage-

ment Team)4. PP4. Przygotowanie podstawowych założeń projektu (SU4. Preparing a Project Brief)5. PP5. Definiowanie formuły realizacyjnej/Definiowanie (SU5. Defining Project

Approach)6. PP6. Planowanie etapu inicjowania (SU6. Planning Initiation Stage)

Zarządzanie strategiczne projektem (Directing a project)Proces ten realizuje funkcje, za które odpowiedzialny jest Komitet Sterujący. Kierownik Projektu informuje Komitet Sterujący w raportach okresowych o stanie projektu. Bieżące zarządzanie pozostawione jest w wyłącznej kompetencji Kierownika Projektu. Komitet Sterujący angażuje się tylko na granicach etapów zarządczych, gdzie decyduje, czy należy kontynuować prace przechodząc do następnego etapu. Fundamentalną zasadą PRINCE2 jest zarządzanie poprzez wyjątki (management by exception), co oznacza, że jedyną dodatkową

3

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.

Zarządzanie Strategiczne Projektem obejmuje następujące podprocesy:1. ZS1. Zezwolenie na inicjowanie projektu (DP1. Authorising Initiation)2. ZS2. Zezwolenie na realizację projektu (DP2. Authorising a Project)3. ZS3. Zezwolenie na realizację etapu lub planu awaryjnego (DP3. Authorising a Stage

or Exception Plan)4. ZS4. Podejmowanie decyzji doraźnych (DP4. Giving Ad Hoc Direction)5. ZS5. Zatwierdzenie zamknięcia projektu (DP5. Confirming Project Closure)

Planowanie (Planning)Planowanie jest procesem trwającym przez cały cykl życia projektu.

Planowanie obejmuje następujące podprocesy:1. PL1. Projektowanie planu (PL1. Designing a Plan)2. PL2. Definiowanie i analizowanie produktów (PL2. Defining and Analysing Products)3. PL3. Określanie działań i zależności (PL3. Identifying Activities and Dependencies)4. PL4. Szacowanie (PL4. Estimating)5. PL5. Harmonogramowanie (PL5. Scheduling)6. PL6. Analizowanie ryzyka (PL6. Analysing Risks)7. PL7. Kompletowanie planu (PL7. Completing a Plan)

Inicjowanie projektu (Initiating a project)Aby projekt uzyskał akceptację musi być starannie zaplanowany w sposób wystarczająco precyzyjny, żeby było zrozumiałe jak mają być zrealizowane jego cele. Wymaga to szczegółowego szacowania pracochłonności i kosztów. Wszystkie te parametry stanowią podstawę do zdefiniowania głównego dokumentu procesu, tj. Dokumentu Inicjującego Projekt, który musi zostać zaakceptowany przez Komitet Sterujący zanim etap realizacji zostanie uruchomiony.

Inicjowanie projektu obejmuje następujące podprocesy:1. IP1. Planowanie jakości (IP1. Planning Quality)2. IP2. Planowanie projektu (IP2. Planning a Project)3. IP3. Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka (IP3. Refining the Busi-

ness Case and Risks)4. IP4. Ustanowienie elementów sterowania (IP4. Setting Up Project Controls)5. IP5. Ustanowienie dokumentacji projektowej (IP5. Setting Up Project Files)6. IP6. Zestawienie Dokumentu Inicjującego Projekt (IP6. Assembling a Project Initia-

tion Document)

Sterowanie etapem (Controlling a stage)Projekty realizowane wg metodyki PRINCE2 są podzielone na etapy zarządcze. Dokładna ilość etapów nie jest określona, zależy ona od wielkości projektów, poziomu ryzyka i ilości planowanych punktów decyzyjnych, w których następowałaby decyzja, czy projekt jest nadal uzasadniony biznesowo i czy należy kontynuować prace. W tym procesie realizowane jest bieżące zarządzanie projektem Kierownika Projektu.

4

Sterowanie etapem obejmuje następujące podprocesy:1. SE1. Zgoda na wykonanie grupy zadań (CS1. Authorising Work Package)2. SE2. Ocena postępów (CS2. Assessing Progress)3. SE3. Rejestrowanie zagadnień projektowych (CS3. Capturing Project Issues)4. SE4. Analizowanie zagadnień projektowych (CS4. Examining Project Issues)5. SE5. Przeglądanie stanu etapu (CS5. Reviewing Stage Status)6. SE6. Raportowanie o ważnych zdarzeniach (CS6. Reporting Highlights)7. SE7. Podejmowanie działań korekcyjnych (CS7. Taking Corrective Action)8. SE8. Eskalowanie zagadnień projektowych (CS8. Escalating Project Issues)9. SE9. Odbieranie wykonanej grupy zadań (CS9. Receiving Completed Work Package)

Zarządzanie wytwarzaniem produktów (Managing product delivery)PRINCE2 to metodyka oparta na produktach. Produktem może być rzecz materialna np. książka. Może nim być też rzecz bardziej niematerialna np. poziom usług serwisowych. W zasadzie wszystko, co zostało wytworzone przez projekt zgodny z PRINCE2, włączając w to dokumenty jest produktem. Produkt może być wytworzony przez kogokolwiek, także przez zewnętrznego dostawcę. W tym procesie wytwarza produkty specjalistyczne projektu, dla których został on uruchomiony i w tym procesie użytkowana jest zdecydowana większość zasobów.

Zarządzanie Wytwarzaniem Produktów obejmuje następujące podprocesy:1. WP1. Przyjęcie grupy zadań do realizacji (MP1. Accepting a Work Package)2. WP2. Wytwarzanie grupy zadań (MP2. Executing a Work Package)3. WP3. Dostarczanie grupy zadań (MP3. Delivering a Work Package)

Zarządzanie zakresem etapu (Managing stage boundaries)Zgodnie z PRINCE2 każdy etap musi być ukończony i zaakceptowany zanim Komitet Sterujący autoryzuje przejście do następnego etapu. W tym procesie weryfikowane jest, czy etap dostarczył wszystkie wymagane produkty i czy pierwotne parametry biznesowe nie uległy zmianie. Planowany jest też w tym kontekście uszczegółowiony plan następnego etapu.

Zarządzanie Zakresem Etapu obejmuje następujące podprocesy:1. ZE1. Planowanie etapu (SB1. Planning a Stage)2. ZE2. Uaktualnienia planu projektu (SB2. Updating a Project Plan)3. ZE3. Uaktualnienie uzasadnienia biznesowego projektu (SB3. Updating a Project

Business Case)4. ZE4. Uaktualnienie rejestru ryzyka (SB4. Updating the Risk Log)5. ZE5. Raportowanie końca etapu (SB5. Reporting Stage End)6. ZE6. Opracowanie planu naprawczego (SB6. Producing an Exception Plan)

Zamykanie projektu (Closing a project)Według metodyki PRINCE2 projekty muszą być zamykane w sposób uporządkowany i kontrolowany. Wszystkie doświadczenia zdobyte w trakcie prowadzenia projektu są rejestrowane, tworzony jest dokument przekazania i planowany jest przegląd powdrożeniowy. Po zakończeniu projektu w zaplanowanym momencie pozwalającym na należytą ocenę skutków biznesowych projektu przeprowadzany jest przegląd poprojektowy.

4

Zamykanie projektu ma następujące podprocesy:1. ZP1. Przygotowanie projektu do zamknięcia (CP1. Decommissioning a Project)2. ZP2. Określanie działań następczych (CP2. Identifying Follow-on Actions)3. ZP3. Przegląd oceniający projekt (CP3. Project Evaluation Review)

Komponenty

Komponent to grupa produktów zarządczych wytwarzana i/lub wykorzystywana w procesie, jaki toczy się w projekcie.

Metodyka PRINCE2 obejmuje osiem komponentów wykorzystywanych w zarządzaniu projektem:

1. Uzasadnienie biznesowe2. Organizacja3. Plany4. Elementy sterowania5. Zarządzanie ryzykiem6. Jakość w środowisku projektu7. Zarządzanie konfiguracją8. Sterowanie zmianami

Uzasadnienie biznesowe

Przeznaczeniem Uzasadnienia Biznesowego jest określenie mierzalnych celów uzasadniających zaangażowanie zasobów w projekcie. Uzasadnienie biznesowe musi być aktualizowane przez cały cykl życia projektu. Właścicielem uzasadnienia biznesowego jest Przewodniczący Komitetu Sterującego.

Uzasadnienie biznesowe zawiera:1. Przesłanki przemawiające za podjęciem projektu2. Możliwe warianty realizacji3. Oczekiwane korzyści z projektu4. Zestawienie głównych zagrożeń ciążących nad projektem5. Koszty realizacji projektu6. Terminy realizacji części projektu7. Ocenę opłacalności inwestycji, jaką jest projekt

Organizacja

Struktura organizacyjna definiuje role i odpowiedzialności osób zarządzających i realizujących projekt. Kierownik Projektu występuje w roli pracownika najemnego, biorącego na siebie obowiązek wytworzenia produktów projektu. Projekt na zewnątrz reprezentuje Komitet Sterujący. W skład Komitetu Sterującego powinny wchodzić wyłącznie osoby, które mają władzę przydzielania zasobów do projektu. PRINCE2 opiera się na kontraktach co sprawia, że w tej metodyce brak poleceń służbowych. Odpowiedzialność za nadzór spoczywa na każdego członka Komitetu Sterującego. Przewodniczący Komitetu Sterującego jednoosobowo odpowiada za powodzenie projektu. Przewodniczący Komitetu Sterującego powinien być właścicielem uzasadnienia biznesowego. Zakaz kumulowania ról: Komitetu

4

Sterującego i Kierownika Projektu; Kierownika Projektu i Kontrolera Jakości; Kierownika Projektu i Nadzoru projektu.

Role1. 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 ryzyka10. Interesariusz

Zakresy obowiązków

Zakres obowiązków Komitetu Sterującego 1. Strategiczne zarządzanie projektem (przydział zasobów niezbędnych do utrzymania

cyklu życia projektu).2. Strategiczne sterowanie projektem (podejmowanie decyzji stanowiących o cyklu życia

projektu).3. Odpowiedzialność za nadzór spoczywa na każdego członka Komitetu Sterującego4. Komitet sterujący jest jedynym ciałem upoważnionym do oficjalnego reprezentowania

projektu przed Zarządem. Komunikacja Komitetu Sterującego z otoczeniem projektu: a. Zawiadomienie o rozpoczęciu inicjowania projektub. Zawiadomienie o rozpoczęciu realizacji projektuc. Informacje zwrotned. Zawiadomienie o rozpoczęciu zamykania projektue. Zawiadomienie o zamknięciu projektu

Zakres obowiązków Głównego użytkownika produktu 1. Reprezentuje interesy przyszłych użytkowników produktu2. Przydziela i zwalnia konieczne zasoby3. Nadaje priorytet zagadnieniom projektowym, które dotykają użytkowników, których

repre-zentuje4. Dokonuje cząstkowej i końcowej akceptacji produktów5. Odpowiada za spełnienie przez produkty przyjętych wymagań funkcjonalnych i

jakościowych6. Odpowiada za to, aby produkty przyniosły w przyszłości spodziewane korzyści7. Sprawuje nadzór nad projektem

Zakres obowiązków Głównego dostawcy produktu1. Reprezentuje interesy jednostek, których zadaniem jest budowa produktów2. Przydziela i zwalnia konieczne zasoby3. Referuje zagadnienia projektowe, które dotykają jego zadań (główne specjalistyczne)4. Odpowiada za spójność planowanych działań specjalistycznych z ich zarządzaniem na

pozio-mie specjalistycznym5. Sprawuje specjalistyczny nadzór nad projektem oraz nadzór nad przyszłą eksploatacją

i utrzymaniem produktu

4

Zakres obowiązków Przewodniczącego Komitetu Sterującego1. Reprezentuje interesy, które łączą dostawcę i odbiorcę produktów projektu2. Odgrywa rolę arbitrażową – rozwiązuje konflikty pomiędzy przyszłymi

użytkownikami a do-stawcami produktu3. W ewentualnych konfliktach zwraca szczególną uwagę na interesy odbiorcy produktu4. Przewodniczy posiedzeniom Komitetu Sterującego5. Przewodzi projektowi, którego jest główną siłą napędową

Zakres obowiązków Kierownika Projektu1. Ponosi odpowiedzialność za bieżące planowanie, zarządzanie i sterowanie2. Odpowiada za dostarczenie produktów3. Odpowiada za opracowanie i aktualizację wszelkich planów w projekcie4. Udziela pracownikom specjalistycznym na wykonanie grupy zadań5. Dokonuje odbioru grupy zadań6. Prowadzi dokumentację projektu7. Dokonuje rejestracji zagadnień projektowych8. Aktualizuje plany9. Analizuje skutki wprowadzanych zmian10. Składa raporty Komitetowi Sterującemu ze stanu zaawansowania i postępów projektu11. Pełni rolę przywódcy: dostarcza motywacji dla pracowników specjalistycznych

Zakres obowiązków Kierownika Zespołu Specjalistycznego1. Odpowiada za opracowanie planów2. Odpowiada za sterowanie pracami specjalistycznymi projektu3. Składa kierownikowi projektu raporty z punktów kontrolnych

Zakres obowiązków Członka Zespołu Specjalistycznego1. Dysponuje wiedzą i umiejętnościami specjalistycznymi niezbędnymi do wytworzenia

specja-listycznych produktów2. Wytwarza specjalistyczne produkty cząstkowe i końcowe3. Odpowiada za przygotowanie produktów do przeglądów jakości4. Odpowiada za adekwatność zakładanej i rzeczywistej jakości produktów

Zakres obowiązków Biura projektów1. Udziela wsparcia administracyjnego uczestnikom projektu2. Czuwa nad standardami zarządzania projektem3. Czuwa nad standardami zarządzania jakością4. Prowadzi dokumentację projektu5. Odpowiada za operacyjne zarządzanie konfiguracją6. Dokonuje rejestracji zagadnień projektowych7. Aktualizuje plany i analizuje skutki wprowadzanych zmian8. Sporządza projekty dokumentów (raportów, notatek, itp.)9. Sporządza protokoły z narad komitetów sterujących10. Sporządza notatki z przeglądów jakości

PlanyPlany zgodnie z PRINCE2 muszą być zatwierdzone zanim zostaną przekazane do realizacji. Wyróżnia się 3 poziomy planu:

4

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 sterowaniaElementy 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.

Podstawowymi elementami sterowania są:1. Inicjowanie projektu (Project Initiation)2. Raporty o ważnych wydarzeniach (Highlight report)3. Raporty o istotnych odchyleniach (Exception report)4. Ocena nadzwyczajna (Exception assessment)5. Ocena końcowa etapu (End stage assessment)6. Zamknięcie projektu (Project closure)7. Tolerancja (Tolerance)

Tolerancja to dopuszczalne odchylenie od planu, które nie wymaga poinformowania o nim wyższego szczebla zarządzania projektem. Kierownik projektu musi informować komitet sterujący o wszelkich prognozowanych i istotnych odchyleniach od zatwierdzonego planu. Parametry tolerancji:

1. Czas2. Koszty3. Korzyści4. Ryzyko5. Jakość6. Zakres

Zarządzanie ryzykiemKaż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.

Zarządzanie ryzykiem opiera się na 3 zasadach:1. Tolerancji na ryzyko (Risk Tolerance)2. Odpowiedzialności za ryzyko (Risk Responsibility)3. Własności (przynależność) ryzyka (Risk Ownership)

4

Parametry ryzyka w PRINCE21. Prawdopodobieństwo wystąpienia ryzyka2. Oddziaływanie na projekt3. Bliskość czasowa ewentualnego wystąpienia

Jakość w środowisku projektowym

Celem projektu jest wytworzenie produktów, zgodnych z ich przeznaczeniem, zaspokajających potrzeby oraz oczekiwania jakościowe klienta. Oczekiwania jakościowe są określone w Zleceniu Projektu (Project Mandate), Założeniach Projektu (Project Brief) oraz Dokumencie Inicjującym Projekt (Project Initiation Document).

Zarządzanie jakością opiera się na 4 składnikach:1. Systemie Zarządzania Jakością (Quality Management System)2. Funkcji zapewniania jakości (Quality Assurance Function)3. Planowaniu jakości (Quality Planning)4. Kontroli jakości (Quality Control)

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.

Zarządzanie konfiguracją składa się z 5 elementów:1. Planowanie (Planning)2. Identyfikacja (Identification)3. Kontrola (Control)4. Charakteryzowanie statusu (Status accounting)5. Weryfikacja (Verification)

Zarządzanie konfiguracją musi zapewnić:1. Mechanizmy zarządzania, śledzenia i utrzymywania kontroli nad wszystkimi

produktami projektu.2. Pewne i bezpieczne przechowywanie każdego produktu.3. Możliwość wyboru składników, które zawierać będzie ukończony, funkcjonujący

produkt. Zakłada to oddanie gotowego produktu wraz z jego aktualnieniami.4. System rejestrowania, śledzenia i dokumentowania wszystkich zagadnień

projektowych.

4

Sterowanie zmianamiSterowanie zmianami opiera się na technice sterowania zmianami.

Rodzaje zmian1. wniosek o wprowadzenie zmiany (koszt pokrywa klient)2. odstępstwo (koszt naprawy pokrywa dostawca)3. ustępstwo (brak działań korygujących)

TechnikiTechnika 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.

PRINCE2 definiuje trzy techniki projektowe:1. Planowanie oparte na produktach2. Sterowanie zmianami3. Przeglądy jakości

Planowanie oparte na produktachPRINCE2 stosuje planowanie oparte na produktach nie zaś oparte na działaniach. Polega to na tym, że PRINCE2 planuje i mierzy postęp projektu realizacją poszczególnych precyzyjnie zdefiniowanych produktów a nie subiektywnie mierzonych działań.

Planowanie oparte na produktach stosuje następujące produkty:1. Struktura produktowa (Product Breakdown Structure)2. Opisy produktów (Product Description)3. Diagram następstwa produktów (Product Flow Diagram)

Sterowanie zmianamiW 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)

Obsługa wszystkich zagadnień projektowych jest w gestii Kierownika Projektu. Ich zgłoszenia muszą być udokumentowane w Rejestrze zagadnień (Issue Log). Wnioski o zmianę muszą być zaakceptowane przez Komitet Sterujący lub Komitet ds. zmian (Change Authority). Przed akceptacją zmiany musi być wykonana analiza wpływu zmiany. Odstępstwa (Off specification) mogą być załatwiane w ramach działań korygujących przez Kierownika Projektu o ile nie wykraczają one poza określone dla projektu granice tolerancji. Komitet Sterujący może zaakceptować odstępstwa bez uruchamiania działań korygujących definiując je jako ustępstwo.

4

Przeglądy jakościPRINCE2 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 projektu2. Instrumenty sterowania3. Definicja projektu

a. Cele projektub. Metody osiągania celówc. Spodziewane wyniki (produktu)d. Formula realizacji projektue. Ograniczenia, wyłączeniaf. Powiązania projektu

4. Uzasadnienie ekonomiczne5. Struktura organizacyjna6. Plan projektu

a. Produktyb. Działaniac. Zasoby

7. Plan komunikacji8. Rejestr ryzyka9. Tolerancje w projekcie

Rejestry1. Rejestr ryzyka2. Rejestr zagadnień3. Rejestr jakości4. Rejestr doświadczeń5. Rejestr dzienny6. Rejestr zarządzania konfiguracją

Raporty1. Raport okresowy2. Raport końcowy etapu zarządczego3. Raport końcowy projektu4. Raport o odchyleniach5. Raport z punktu kontrolnego6. Raport z wykorzystania zasobów7. Raport doświadczeń z projektu

Plany1. Plan etapu inicjowania projektu

4

2. Plan jakości projektu3. Plan projektu4. Plan zarządzania konfiguracją5. Plan etapu zarządczego6. Plan jakości etapu zarządczego7. Plan awaryjny (rezerwowy)8. Plan wyjątkowy (naprawczy)9. Plan wykorzystania budżetu zmian10. Plan tekstowy11. Plan pracy zespołu specjalistycznego12. Plan przeglądu poprojektowego13. Plan bazowy (stan odniesienia)

8. Opis ScrumStruktura 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.

Zespoły Scrum są zaprojektowane tak, aby zoptymalizować ich elastyczność i wydajność; dlatego są samoorganizujące i interdyscyplinarne (międzyfunkcjonalne) oraz pracują w cyklicznych Sprintach.

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 fragmentproduktu w ciągu jednego Sprintu.

Stosowane w Scrumie ograniczenia czasowe zapewniają regularny rytm pracy. Elementy Struma ograniczone czasowo to: spotkanie planistyczne wydania (Release Planning Meeting), spotkanie planistyczne Sprintu (Sprint Planning Meeting), Sprint, Codzienny Scrum (Daily Scrum), przegląd Sprintu (Sprint Review) oraz retrospektywa Sprintu (Sprint Retrospective). Głównym elementem Scruma jest Sprint, czyli cykl pracy obejmujący okres maksymalnie jednego miesiąca, którego czas trwania pozostaje niezmienny w całym procesie wytwarzania produktu. We wszystkich Sprintach używa się tej samej struktury scrumowej i wszystkie dostarczają potencjalnie zbywalny przyrost finalnego produktu. Sprinty następują bezpośrednio po sobie.

W Scrumie używa się czterech podstawowych narzędzi. Rejestr produktowy (Product Backlog) to zhierarchizowana lista wszelkich elementów składających się na ostateczną postać produktu. Rejestr zadaniowy (Sprint Backlog) to lista zadań, których wykonanie doprowadzi do przetworzenia wybranych w danym Sprincie pozycji rejestru produktowego w gotowy fragment potencjalnie zbywalnego produktu. Wykres wypalania (Burndown Chart) to podstawowe narzędzie oceny postępu prac w projekcie. Pomiar wypalania dla projektu (Release Burndown) pokazuje elementy pozostające

4

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 Scrumiejest zabieranie głosu podczas Codziennego Scruma tylko przez członków Zespołu scrumowego, czyli osoby zaangażowane w przekształcanie rejestru produktowegow przyrost produktu.

Role w ScrumieZespół 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 kurczakpowiedział: „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 tylkozaangażujesz, a ja – ja się poświęcę!”

MistrzZadaniem 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ęciawię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 ProduktuWłaściciel Produktu jest jedyną osobą odpowiedzialną za zarządzanie rejestrem produktowym i za czuwanie nad wartością pracy wykonywanej przez Zespół. Ta osobaprowadzi 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 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.

5

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, czyzarzą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 wuż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, niepasują 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 iod 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ązaniakaż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 czasoweOgraniczenia czasowe w Scrumie dotyczą: spotkania planistycznego wydania, Sprintu, spotkania planistycznego Sprintu, przeglądu Sprintu, retrospektywy Sprintu i Codziennego Scruma.

Spotkanie planistyczne wydaniaPrzedmiotem 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

5

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, orazgłó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 metodyce Scrum produkty tworzone są iteracyjnie: każdy Sprint wytwarza przyrost produktu, począwszy od elementów najbardziej pożądanych i najbardziej ryzykownych. Kolejne Sprinty tworzą dodatkowe elementy produktu. Każdy z przyrostów jest potencjalnie zbywalnym wycinkiem całości. Gdy powstanie ilość elementów wystarczająca, aby produkt stał się wartościowy i użyteczny dla inwestora, następuje wydanie produktu klientowi.

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.

Planowanie wydania wymaga estymacji i przypisania priorytetów kolejnym pozycjom rejestru produktowego. Istnieje wiele technik spoza metodyki Scrum, które można skutecznie wykorzystać w tym procesie.

SprintSprint 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.

Aby coś osiągnąć, tworzymy projekt. W produkcji oprogramowania stosuje się go do stworzenia produktu lub systemu. Definicja projektu obejmuje opis tego, co ma powstać, plan, jak to coś wytworzyć, prace wykonywane według planu oraz powstały w rezultacie produkt końcowy. Każdy projekt posiada horyzont, czyli zaakceptowane ramy czasowe.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ść

5

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.

Spotkanie planistyczne SprintuSpotkanie planistyczne Sprintu odbywa się zawsze, gdy trzeba zaplanować nową iterację. Jego ograniczenie czasowe to osiem godzin przy planowaniu Sprintumiesię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ścimodyfikują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ę.

5

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 SprintuPod 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.

Spotkanie to zawiera przynajmniej następujące punkty: Właściciel Produktu stwierdza, które funkcjonalności zostały wykonane, a które nie; Zespół omawia prace wykonane w trakcie Sprintu zakończone sukcesem, jak również napotkane problemy i metody ich rozwiązania; następnie Zespół prezentuje wykonaną pracę i odpowiada na pytania; Właściciel Produktu omawia stan rejestru produktowego oraz wysuwa propozycje prawdopodobnych terminów zakończenia pracy przy różnych założeniach co do tempa pracy; następnie cała grupa omawia przedstawione fakty i ich istotność w ustaleniu zakresu kolejnych prac. Tym samym przegląd Sprintu dostarcza cennych informacji do wykorzystania w trakcie kolejnego spotkania planistycznego Sprintu.

Retrospektywa SprintuPo 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

5

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 ScrumKaż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.

Mistrz ma obowiązek dopilnować, by spotkanie się odbyło. Zespół jest odpowiedzialny zapoprowadzenie Codziennego Scruma. Mistrz uczy Zespół, jak utrzymać krótki czas spotkań, egzekwując przestrzeganie reguł i pilnując, by wszyscy mówili zwięźle. Mistrz również ma za zadanie dopilnować, by „kurczaki” nie zabierały głosu i w żaden inny sposób nie przeszkadzały w Codziennym Strumie.

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ędziaNarzę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).

Rejestr produktowy i wypalanie w projekcieWymagania 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

5

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. Rejestristnieje tak długo, jak istnieje produkt.

Rejestr produktowy reprezentuje wszystko, co potrzebne, by stworzyć i wypuścić na rynek udany produkt. Rejestr jest listą wszystkich cech, funkcji, technologii, ulepszeń i napraw błędów, reprezentujących zmiany, które zostaną wprowadzone w produkcie przed kolejnym jego wypuszczeniem na rynek. Elementy rejestru posiadają następujące atrybuty: opis, priorytet i koszt realizacji. Priorytet ustala się na podstawie ryzyka, wartości i konieczności realizacji danego elementu rejestru. Istnieje wiele technik ustalania wartości tych atrybutów.

Rejestr produktowy jest uszeregowany według priorytetu. Pozycje o najwyższym priorytecie pozwalają natychmiast podjąć prace programistyczne nad nimi. Im wyższy priorytet, tym pilniejsza praca, tym bardziej jest przemyślana i tym większa istnieje zgoda co do jej 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 onajwyż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ółoweoraz podzielone w taki sposób, aby każda z nich mogła zostać wykonana w trakcie jednego Sprintu.

Często kilka Zespołów scrumowych pracuje nad jednym produktem, a do wyznaczenia kolejnych prac używa się jednego rejestru produktowego. Stosuje się wtedy dodatkowy atrybut, który grupuje elementy rejestru – według cech, technologii lub architektury – i który jest często używany celu zorganizowania pracy Zespołów.

Na wykresie wypalania dla produktu (lub wydania) rejestruje się ilość pozostałej do wykonania pracy zgodnie z szacunkami w rejestrze w stosunku do czasu realizacjiprojektu. 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.

Wstępne estymacje elementów rejestru produktowego są wyznaczane podczas planowania wydania (Release Planning). Dla elementów pojawiających się w trakcie trwania projektu estymacje wyznaczane są na bieżąco. W procesie cyzelowania rejestru estymacje poddawane są analizie i w każdej chwili mogą zostać zmienione. Za wszystkie estymacje odpowiedzialny 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

5

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.

Rejestr zadaniowy i wypalanie w SprincieRejestr zadaniowy zawiera opis prac, które Zespół ma wykonać, aby przekształcić elementy rejestru produktowego w gotowy przyrost produktu. Wiele z tych zadań opracowuje się podczas spotkania planistycznego Sprintu. Rejestr reprezentuje całość prac, które Zespół uznaje za niezbędne, aby osiągnąć Cel Sprintu. Zadania w rejestrze zadaniowym muszą być zdekomponowane. Taka dekompozycja jest konieczna, by zmiany w postępie pracy były zrozumiałe w trakcie komunikowania ich na Codziennych Scrumach.

Zespół modyfikuje rejestr zadaniowy w czasie trwania Sprintu, w szczególności dodaje zadania wynikłe już w trakcie Sprintu. Kiedy przychodzi do realizacji indywidualnych zadań, może się okazać, że potrzeba ich będzie więcej lub mniej, lub że dane zadanie będzie 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.

Wykres wypalania w Sprincie to wykres przedstawiającyilość zadań z rejestru pozostałych do wykonania w Sprincie w stosunku do czasu Sprintu. By stworzyć ten wykres, należy ustalić, ile pracy pozostało, sumującestymacje zadań z rejestru w każdym dniu Sprintu. Ilość pracy pozostałej do wykonania w Sprincie jest sumą pracy pozostałej do wykonania w całym rejestrze zadaniowym.Sumy te należy kontrolować codziennie, tworząc w ten sposób wykres pozostałej do wykonania pracy w stosunku do czasu. Rysując linię łączącą punkty wykresu, Zespół może kontrolować postęp wykonywania swych prac w Sprincie. W Scrumie nie jest istotny czas już spędzony na wykonaniu prac – jedynymi ważnymi wskaźnikami są ilość pozostałej pracy i data końcowa Sprintu.

„Gotowe”, czyli kryterium gotowości produkcyjnej (Definition of Done, DoD)Metodyka Scrum wymaga od Zespołu, aby w każdym Sprincie powstał przyrost funkcjonalności produktu. Ten przyrost musi być potencjalnie zbywalny, ponieważ Właściciel Produktu musi być w stanie w każdym momencie podjąć decyzje o wdrożeniutej funkcjonalności. Aby tak się mogło stać, przyrost musi być skończoną porcją całości – musi być „gotowy”. Każdy przyrost musi być zintegrowany z poprzednimi i dokładnieprzetestowany, aby dać nam pewność, że wszystkie fragmenty produktu działają po połączeniu.

W tworzeniu oprogramowania, stwierdzenie, że funkcjonalność jest „gotowa” może dla jednych oznaczać, że kod źródłowy jest w miarę czysty, zrefaktoryzowany,

5

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.

Porównanie metodyki Scrum i Prince2 pod kątem jakości

Metodyka Prince2 oraz Scrum przedstawiają odmienne podejścia do jakości w projekcie. Kiedy Prince2 przedstawia komplet narzędzi do planowania i kontroli jakości (46). Scrum koncentruje się na poprawie komunikacji, optymalizacji procesu wytwórczego oraz jak najlepszym wprowadzeniu „najlepszych praktyk” które mają zapewnić jakość projektowi.

W Prince2 jakość jest ważnym elementem dokumentów: Project Mandate Project Brie Project Initiation Document

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.

Należy zwrócić uwagę na to że jakość produktów, jakie powstają w projekcie prowadzonym zgodnie z 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 projektuW 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

5

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.

Porównanie metodyki Scrum i Prince2 pod kątem planowania

Planowanie w Prince2Planowanie 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 biznesoweZgodnie 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.

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ń

5

Projekt jest prowadzony w sposób kontrolowany i bezpieczny

Przygotowanie projektuPrzyjrzyjmy 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 projektuCelem 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.

1

1 Prince2 manual, APMG 2005

6

Na etapie inicjowania projektu w ramach procesu IP3 (Doprecyzowanie uzasadnienia biznesowego i ryzyka) mogą zostać zastosowane techniki związane z analizą opłacalności inwestycji, takie jak obecna wartość netto (NPV) bądź stopa zwrotu. Na tym etapie dysponujemy już bowiem planem projektu, który powstał w procesie IP2 (Planowanie projektu), więc mamy dane dotyczące przepływów finansowych w projekcie niezbędnych do przeprowadzenia analizy finansowej inwestycji.

Proces planowaniaProces 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).

2

Planowanie obejmuje 7 podprocesów PL1-PL7 dostarczających informację wszystkim zainteresowanym stronom:

Co jest wymagane do realizacji planu na danym etapue W jaki sposób to zostanie osiągnięte i przez kogo Jakie specjalistyczne zasoby i sprzęt zostanie wykorzystany Kiedy to się wydarzy

Plany realizowane są w oparciu o identyfikację produktów. Jest to jedna z nielicznych technik wymaganych przez metodykę PRINCE2. Technika planowania oparta o produkty zapewnia początek pracom planistycznym i określa strukturę planowania. Obejmuje ona:

Ustalenie listy produktów potrzebnych w danym planie – hierarchia produktów Opisanie tych produktów i ich kryteriów jakości (akceptacji) Ustalenie kolejności wytwarzania – diagram następstwa produktów

Po identyfikacji produktów kolejną czynnością planistyczną jest identyfikacja działań niezbędnych do wytworzenia produktów (PL3). Na tym poziomie może powstać diagram sieciowy, który po procesie szacowania (PL4) zostanie uzupełniony o obliczenie ścieżki krytycznej i zapasów czasu. Następnie sieć działań może zostać przedstawiona w postaci wykresu Gantta a do działań mogą zostać przypisane zasoby. Po zbilansowaniu zasobów powstaje harmonogram zawierający działania i zasoby niezbędne do wytworzenia produktów

2 Proince2 manual, APMG 2005

6

spójnych z celem projektu. Harmonogram stanowi jednocześnie podstawę do analizy budżetu poprzez przypisanie kosztów do zasobów. Po sporządzeniu harmonogramu metodyka PRINCE2 wymaga przeprowadzenia analizy zagrożeń (PL6). Analizowanie zagrożeń jest procesem iteracyjnym, który może spowodować konieczność powtórnego przejścia przez procesy PL2 – PL5. W ramach procesu PL6 zastosowanie będą miały techniki związane z zarządzaniem ryzkiem projektu takie jak mapa ryzyka, analiza Monte-carlo czy też analiza drzew decyzyjnych. Narzędziami będzie tu burza mózgów, czy też metoda delficka. Sposób oraz rodzaj narzędzi nie jest narzucany przez metodykę PRINCE2, która określa jedynie, że w ramach procesu PL6 należy przeanalizować zagrożenia, zwrócić uwagę na to, czy ze względu na nowe produkty będące wynikiem planowania reakcji na ryzyko nie następuje sprzężenie zwrotne do procesu PL2 oraz sposób zarządzania ryzykiem opisać w planie zarządzania ryzykiem.

Na skutek planowania reakcji na zidentyfikowane ryzyko (typ reakcji: unikanie, przeniesienie, łagodzenie) mogą zostać zidentyfikowane nowe produkty techniczne, które należy uwzględnić w tworzonym planie. W związku z tym niezbędne będzie powtórne przejście pętli planowania (procesy PL2 – PL5). W ramach procesu PL6 mogą również powstać plany awaryjne (typ reakcji: akceptacja aktywna), które wraz z określeniem niezbędnych rezerw budżetowych będą stanowić element planu zarządzania ryzykiem.

Poziom szczegółowości planu będącego wynikiem procesu planowania zależy od procesu, który wywołał planowanie. Jeżeli wejście do procesu planowania nastąpiło z procesów IP2 (Planowanie projektu) bądź ZE2 (Uaktualnienie planu projektu) produktem zarządczym procesu planowania będzie plan projektu sporządzony na dużym poziomie ogólności. Jeśli jednak proces planowania zostanie wywołany z procesów PP6 (Planowanie etapu inicjowania), ZE1 (Planowanie etapu), ZE6 (Opracowanie planu nadzwyczajnego) bądź WP1 (Przyjmowanie grupy zadań do wykonania) to plan będący wynikiem procesu planowania będzie planem etapu rozpisanym do poziomu grupy zadań bądź planem zespołu realizacyjnego. Jednak w tych wszystkich wypadkach proces planowania będzie uwzględniał te same podprocesy, przetwarzające dane wejściowe na różnym poziomie szczegółowości.

Planowanie w ScrumPlanowanie 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

6

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” ).

PodsumowanieJak 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”.

3 http://scrum.hypersquare.com/podstawy-scruma.html

6

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ę.

Porównanie metodyki Scrum i Prince2 pod kątem ryzykaW metodyce Prince2 duży istotny nacisk został położony na temat ryzyka. W projekcie prowadzonym zgodnie w Prince2 o ryzyku komunikuje się już na etapie przygotowania projektu, w podprocesie Przygotowanie podstawowych założeń projektu (PP4), jak również w etapie inicjowanie projektu w podprocesie Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka(IP3), natomiast regularne przeglądy ryzyka SA dokonywane w procesie zarządzania zakresem etapu w podprocesie: Uaktualnienie rejestru ryzyka (ZE4).

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.

Porównanie metodyki Scrum i Prince2 pod kątem ról w zespole projektowymPrince2 wyróżnia następujące role:

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

Zakres obowiązków Komitetu Sterującego

1. Strategiczne zarządzanie projektem (przydział zasobów niezbędnych do utrzymania cyklu życia projektu).

2. Strategiczne sterowanie projektem (podejmowanie decyzji stanowiących o cyklu życia projektu).

3. Odpowiedzialność za nadzór spoczywa na każdego członka Komitetu Sterującego4. Komitet sterujący jest jedynym ciałem upoważnionym do oficjalnego reprezentowania

projektu przed Zarządem. Komunikacja Komitetu Sterującego z otoczeniem projektu: 1. Zawiadomienie o rozpoczęciu inicjowania projektu2. Zawiadomienie o rozpoczęciu realizacji projektu3. Informacje zwrotne4. Zawiadomienie o rozpoczęciu zamykania projektu5. Zawiadomienie o zamknięciu projektu

4 http://agilemanifesto.org/

6

Zakres obowiązków Głównego użytkownika produktu

1. Reprezentuje interesy przyszłych użytkowników produktu2. Przydziela i zwalnia konieczne zasoby3. Nadaje priorytet zagadnieniom projektowym, które dotykają użytkowników, których

repre-zentuje4. Dokonuje cząstkowej i końcowej akceptacji produktów5. Odpowiada za spełnienie przez produkty przyjętych wymagań funkcjonalnych i

jakościowych6. Odpowiada za to, aby produkty przyniosły w przyszłości spodziewane korzyści7. Sprawuje nadzór nad projektem

Zakres obowiązków Głównego dostawcy produktu

1. Reprezentuje interesy jednostek, których zadaniem jest budowa produktów2. Przydziela i zwalnia konieczne zasoby3. Referuje zagadnienia projektowe, które dotykają jego zadań (główne specjalistyczne)4. Odpowiada za spójność planowanych działań specjalistycznych z ich zarządzaniem na

pozio-mie specjalistycznym5. Sprawuje specjalistyczny nadzór nad projektem oraz nadzór nad przyszłą eksploatacją

i utrzymaniem produktu

Zakres obowiązków Przewodniczącego Komitetu Sterującego

1. Reprezentuje interesy, które łączą dostawcę i odbiorcę produktów projektu2. Odgrywa rolę arbitrażową – rozwiązuje konflikty pomiędzy przyszłymi

użytkownikami a do-stawcami produktu3. W ewentualnych konfliktach zwraca szczególną uwagę na interesy odbiorcy produktu4. Przewodniczy posiedzeniom Komitetu Sterującego5. Przewodzi projektowi, którego jest główną siłą napędową

Zakres obowiązków Kierownika Projektu

1. Ponosi odpowiedzialność za bieżące planowanie, zarządzanie i sterowanie2. Odpowiada za dostarczenie produktów3. Odpowiada za opracowanie i aktualizację wszelkich planów w projekcie4. Udziela pracownikom specjalistycznym na wykonanie grupy zadań5. Dokonuje odbioru grupy zadań6. Prowadzi dokumentację projektu7. Dokonuje rejestracji zagadnień projektowych8. Aktualizuje plany9. Analizuje skutki wprowadzanych zmian10. Składa raporty Komitetowi Sterującemu ze stanu zaawansowania i postępów projektu11. Pełni rolę przywódcy: dostarcza motywacji dla pracowników specjalistycznych

Zakres obowiązków Nadzoru projektowego

1. weryfikacją produktów projektu2. weryfikacją harmonogramu, budżetu, ryzyka oraz uzasadnienia biznesowego projektu3. weryfikacja pracy kierownika projektu

6

4. weryfikacja zarządzania ryzykiem

Zakres obowiązków kierownika zespołu

1. Odpowiedzialność za wykonanie pracy którą uzgodnił z kierownikiem projektu w ramach procesu Zarządzanie Wytwarzaniem Produktów

2. raportowanie do kierownika projektów3. przeprowadzenie testów akceptacyjnych

Zakres obowiązków wsparcia projektowego

1. Udziela wsparcia administracyjnego uczestnikom projektu2. Czuwa nad standardami zarządzania projektem3. Czuwa nad standardami zarządzania jakością4. Prowadzi dokumentację projektu5. Odpowiada za operacyjne zarządzanie konfiguracją6. Dokonuje rejestracji zagadnień projektowych7. Aktualizuje plany i analizuje skutki wprowadzanych zmian8. Sporządza projekty dokumentów (raportów, notatek, itp.)9. Sporządza protokoły z narad komitetów sterujących10. Sporządza notatki z przeglądów jakości

Zakres obowiązków właściciela ryzyka

1. Monitorowanie ryzyka2. proponowanie sposobów mityzacji ryzyka3. Cykliczne raportowanie o ryzyku

Zakres obowiązków Interesariusza

1. Prezentowanie wymagań do projektu

Scrum wyróżnia następujące role:

1. Scrum master2. Produkt owner3. Członek zespołu

6

Zakres obowiązków Scrum mastera1. Zapewnienie aby zespół pracował zgodnie z regułami Scrum-a2. Przeprowadzanie codziennych scrumów3. Pomoc zespołowi4. Ochrona zespołu przed częstymi zmianami w wymaganiach

Zakres obowiązków Produkt ownera1. Reprezentowanie klienta2. Wylistowywanie funkcjonalności jaka ma być zaimplementowana3. Priorytetyzacja pracy jaka ma być wykonana

Zakres obowiązków członka zespołu1. Wykonanie pracy jaka została zlecona

9. Wymagania funkcjonalne

5. wymagania początkowe dla wydania i sprintów wraz z kryteriami akceptacyjnymi

6. podziału pracy na sprinty(iteracje)7. przeglądy sprintów8. przegląd wydania

Funkcjonalność sprint Kryteria akceptacyjne

Definiowanie/edycja galeriizdjęć/plików

1

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

Uprawnienia użytkowników panelu/ edycja 1

Uprawnienia użytkowników portalu 2

6

Złożenie zamówienia przez klienta/edycja przez klienta 1

Artykuły (strony statyczne) 1

Załączenie plików do artykułów 1

Newsy (dodanie nowej tabeli) 1

Oferty wakacyjne (typ wakacji) 1

Kraje 1

Miejsca pobytu (ze zdjęciami) 1

Atrakcje dodatkowe do miejsc pobytu (wycieczki) 2

Podpinanie artykułów pod kraje itd... 2

Przewodniki (oddzielna tabela) – podpinany pod kraj 1

Rozbudowa newsów (kiedy wyświetlane) 2

Rejestracja klienta na stronie głównej 1

Zarządzanie userami 2

Przestawianie ofert na stronie 2

Linki z youtube, muzyka 2

Wyświetlanie niezrealizowanych zamówień w bazie wycieczek

1

Usuwanie zamówień w bazie wycieczek 2

Rejestrowanie się na stronie internetowej 1

Logowanie się na stronie internetowej 1

Przeglądanie ofert aktualnych wycieczek na stronie 2

Sprawdzanie stanu zamówień 2

Składanie zamówień na wycieczki 2

Przeglądanie ofert biura 1

Wprowadzanie zmian w ofercie biura 2

6

10. Wymagania niefunkcjonalne

Z punktu widzenia klienta: aplikacja powinna bezproblemowo udostępniać dane dla 2000 użytkowników

jednocześnie stacja robocza wyposażona w system operacyjny Windows lub Linkuks z

przeglądarką internetową Każda funkcja aplikacji powinna dać odpowiedź w przeciągu maksimum 3 sekund

Z punktu widzenia pracowników biura turystycznego: Niezbędne dane do działania aplikacji w bazie danych Postgresql Pracownicy biura będą mieli dostęp za pomocą części CMS Raporty powinny być generowane w okresie nie dłuższym niż 1 minuta System powinien umożliwiać drukowanie wcześniej zdefiniowanych raportów

11. Przeglądy sprintów

Pierwszy sprint

Funkcjonalność stan Uwagi

Definiowanie/edycja galeriizdjęć/plików

OK drobne błędy do poprawy

Edycja zamówień OK

Edycja ofert OK

Hotele NOK Błędy podczas wyświetlania informacji o hotelach, task do dokończenia w sprincie2

Oglądanie ofert OK

Uprawnienia użytkowników panelu/ edycja OK

Złożenie zamówienia przez klienta/edycja przez klienta OK

Artykuły (strony statyczne) OK

Załączenie plików do artykułów OK

Newsy (dodanie nowej tabeli) OK

Oferty wakacyjne (typ wakacji) OK

Kraje OK

Miejsca pobytu (ze zdjęciami) OK

6

Przewodniki (oddzielna tabela) – podpinany pod kraj OK

Rejestracja klienta na stronie głównej OK


NOK Nie działą, do dorobienia w sprincie 2

Rejestrowanie się na stronie internetowej OK

Logowanie się na stronie internetowej OK

Przeglądanie ofert biura NOK Błędy przy wyświetlaniu, do dokończenia w sprincie2

Drugi sprint

Funkcjonalność Stan Uwagi

Komentarze do ofert/ocena OK

Forum NOK Przeniesione na końcowy sprint

Linki z youtube/wrzuta OK.

Pozycjonowanie na google OK.

Uprawnienia użytkowników portalu OK.

Atrakcje dodatkowe do miejsc pobytu (wycieczki) OK.

Podpinanie artykułów pod kraje itd... OK.

Rozbudowa newsów (kiedy wyświetlane) OK.

Zarządzanie userami OK

Przestawianie ofert na stronie OK

Linki z youtube, muzyka NOK Przeniesione do końcowego sprintu

Usuwanie zamówień w bazie wycieczek OK

Przeglądanie ofert aktualnych wycieczek na stronie OK

Sprawdzanie stanu zamówień OK

Składanie zamówień na wycieczki OK

Wprowadzanie zmian w ofercie biura OK

7

Przeglądanie ofert biura OK


OK

Hotele OK

Sprint końcowy

12. Przegląd wydania

13. Diagram związków encji

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.

15. Opis używanych technologii

W naszym projekcie staramy się stosować nowoczesne technologie lecz sprawdzone i pewne w działaniu. Jest to korzyść dla klienta, który zamawia usługę, ale i dla nas, czyli projektantów, którzy nie marnują czasu na zmagania się z problemami używanych narzędzi, mogą całą uwagę poświęcić istotnym potrzebom swojego klienta.

Ruby on Rails

Nasza główna technologia. Framework open source do szybkiego tworzenia aplikacji webowych. RoR został napisany w języku Ruby z użyciem architektury MVC

JavaScript (prototype)

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.

Uzasadnienie wyboru technologii

Ruby on Rails jest powszechnie używany poza granicami naszego kraju. Przede wszystkim jest to framework oparty na technologi MVC, posiadający dobrze przemyślaną konfigurację domyślną, wsparcie dla technologii ajax, bardzo dobry orm z zabezpieczonymi zapytaniami sql pozwalający podpiąc niemalże dowolną bazę danych nie zmieniając przy tym ani kawałĸa kodu. Wyżej wymienione cechy pozwalają od razu rozpocząć pracę nad aplikacją nie tracąc czasu na konfigurację. Wszystkie pliki są odpowiednio poukładane dzięki MVC, co zapewnia porządek i czystość w projekcie. Praktycznie bez znajomości JavaScriptu możemy tworzyć zaawansowane mechanizmy ajaxowe. To co stanowi o potędze Ruby on Rails to język Ruby. To dzięĸi niemu Railsy są potężnym frameworkiem do pisania dobrze zabezpieczonych, czystych, przetestowanych aplikacji www.

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

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.

16. Moduły systemu

Postawowymi modłami będą:moduł dla pracownika – wprowadzanie informacji o wyczieczkach, opisy, dodawanie

zdjęć, ustawianie promocji, odpisywanie na maile klientów.Moduł dla klienta – logownie/rejestracja, przeglądanie oferty biura podróży,

dokonywanie transakcji.

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

7

[praca inzynierska]Prince2vsScrum

Documents

Transcript of [praca inzynierska]Prince2vsScrum