Główne przyczyny niepowodzenia projektów (zalążek...
Transcript of Główne przyczyny niepowodzenia projektów (zalążek...
Główne przyczyny niepowodzenia projektów
(zalążek PRINC2)
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
Główne przyczyny niepowodzenia projektów
(zalążek PRINC2) Zarządzanie strategiczne
• Brak poparcia ze strony kierownictwa dla realizowanego projektu
• Brak zastosowania metodyki zarządzania projektem
• 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ź
niesystematycznie
• 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
• 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)
Główne przyczyny niepowodzenia projektów
(zalążek PRINC2)
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
PRINCE2
• Projects In a Controlled Environment
(Projekty w sterowanym środowisku).
projekt według PRINCE2:
„Organizacja powołana na pewien czas w celu wytworzenia - w przyjętym czasie oraz przy wykorzystaniu uprzednio określonych zasobów - niepowtarzalnych, a wcześniej
określonych wyników czy rezultatu”.
„Warunki zarządzania stworzone w celu dostarczenia jednego lub wielu produktów natury biznesowej zgodnie z określonym uzasadnieniem biznesowym”.
Właściwości projektu realizowanego
według PRINCE2
1. Określony i skończony czas trwania projektu
2. Zdefiniowane i mierzalne produkty biznesowe
(wyniki projektu – miara sukcesu)
3. System działań niezbędnych do budowy
produktów biznesowych
4. Określona pula zasobów
5. Struktura organizacyjna z zakresem obowiązków
każdej z ról niezbędnej do zarządzania
projektem
Rodzaje zasobów w PRINCE2
• Pieniądze
• Ludzie
• Sprzęt (wyposażenie)
Komponenty, procesy a techniki PRINCE2
Stosując różne techniki, każdy proces
wykorzystuje i/lub wytwarza komponenty.
PRINCE2 cechuje podejście procesowe do zarządzania
projektem. Definiuje szczegółowo osiem procesów
najwyższego rzędu, które z kolei dzielą się na podprocesy:
PRINCE2 cechuje podejście procesowe do zarządzania
projektem. Definiuje szczegółowo osiem procesów
najwyższego rzędu, które z kolei dzielą się na podprocesy
• 1. Strategiczne zarządzanie projektem (ZS) – Directing a project (DP)
• 2. Planowanie (PL) – Planning (PL)
• 3. Uruchamianie Projektu/Przygotowanie Założeń Projektu (PP) – Starting up a project (SU)
• 4. Inicjowanie projektu (IP) – Initiating a project (IP)
• 5. Sterowanie Etapem (SE) – Controlling a stage (CS)
• 6. Zarządzanie Wytwarzaniem Produktów (WP) – Managing product delivery (MP)
• 7. Zarządzanie Zakresem Etapu (ZE) – Managing stage boundaries (SB)
• 8. Zamykanie Projektu (ZP) – Closing a project (CP)
Projekt zgodny z PRINCE2 musi zawierać co najmniej 2 etapy zarządcze:
• Inicjowanie projektu
• Realizacja projektu
PROCESY:
Przygotowanie założeń projektu/Uruchamianie
projektu (Starting up a project)
• PP1. Mianowanie Przewodniczącego Komitetu Sterującego i Kierownika Projektu (SU1. Appointing a Project Executive and a Project Manager)
• PP2. Projektowanie zespołu zarządzania projektem (SU2. Designing a Project Management Team)
• PP3. Mianowanie zespołu zarządzania projektem (SU3. Appointing a Project Management Team)
• PP4. Przygotowanie podstawowych założeń projektu (SU4. Preparing a Project Brief)
• PP5. Definiowanie formuły realizacyjnej/Definiowanie (SU5. Defining Project Approach)
• PP6. Planowanie etapu inicjowania (SU6. Planning Initiation Stage)
Grupy działań
• Utworzyć zespół zarządzający projektem
• Określić cele projektu
• Zdefiniować w jaki sposób zbudowane będzie rozwiązanie (metoda)
• Zastanowić się nad zasadnością ekonomiczną i ryzykiem
• prace planistyczne nad projektem, określić elementy sterowania i uzyskać zgodę na
inicjowanie
PODPROCESY:
Komponenty Metodyka PRINCE2 obejmuje osiem komponentów wykorzystywanych w zarządzaniu projektem
1. Uzasadnienie biznesowe
2. Organizacja
3. Plany
4. Elementy sterowania
5. Zarządzanie ryzykiem
6. Jakość w środowisku projektu
7. Zarządzanie konfiguracją
8. Sterowanie zmianami
Uzasadnienie biznesowe
Uzasadnienie biznesowe zawiera:
1. Przesłanki przemawiające za podjęciem projektu
2. Możliwe warianty realizacji
3. Oczekiwane korzyści z projektu
4. Zestawienie głównych zagrożeń ciążących nad projektem
5. Koszty realizacji projektu
6. Terminy realizacji części projektu
7. Ocenę opłacalności inwestycji, jaką jest projekt
Plany Plany zgodnie z PRINCE2 muszą być zatwierdzone zanim zostaną przekazane do realizacji.
Wyróżnia się 3 poziomy planu:
• Plan projektu (Project Plans)
• Plan etapu (Stage Plans)
• Plan pracy zespołu (Team Plans)
• Plan naprawczy (Exception plan)
Elementy sterowania Elementy sterowania mają zapewnić, że projekt jest prowadzony zgodnie z planem i
uzasadnieniem biznesowym. PRINCE2 stosuje metodę zwaną 'management by exception',
która angażuje Komitet Sterujący tylko wtedy kiedy pojawia się odchylenie wskazujące na
możliwość wykroczenia projektu poza ramy określone tolerancją i uzasadnieniem.
Za całość realizacji odpowiedzialny jest kierownik projektu
• Inicjowanie projektu (Project Initiation)
• Raporty o ważnych wydarzeniach (Highlight report)
• Raporty o istotnych odchyleniach (Exception report)
• Ocena nadzwyczajna (Exception assessment)
• Ocena końcowa etapu (End stage assessment)
• Zamknięcie projektu (Project closure)
• Tolerancja (Tolerance)
(Tolerancja to dopuszczalne odchylenie od planu),
Parametry tolerancji:
1.Czas 2.Koszty 3.Korzyści 4.Ryzyko 5.Jakość 6.Zakres
ELEMENTY STEROWANIA:
Zarządzanie ryzykiem (1)
(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:
• Tolerancji na ryzyko (Risk Tolerance)
• Odpowiedzialności za ryzyko (Risk Responsibility)
• Własności (przynależność) ryzyka (Risk Ownership)
Parametry ryzyka w PRINCE2
1. Prawdopodobieństwo wystąpienia ryzyka
2. Oddziaływanie na projekt
3. Bliskość czasowa ewentualnego wystąpienia
Zarządzanie ryzykiem (2)
(Zarządzanie ryzykiem polega na utrzymywaniu ryzyka w akceptowalnych granicach w
sposób efektywny i racjonalny kosztowo)
Kroki sterowania ryzykiem
• 1. Identyfikowanie ryzyka
• 2. Kategoryzowanie
• 3. Wyznaczanie właściciela
• 4. Ocena prawdopodobieństwa wystąpienia
• 5. Ocena oddziaływania na projekt
• 6. Ocena oddalenia w czasie
• 7. Ocena ryzyka (iloczyn)
• 8. Wyznaczenie obszaru ryzyka - linii tolerancji
• 9. Określenie opcji działań
1. Prewencja (zapobieganie)
2. Redukcja (ograniczenie)
3. Przeniesienie (transfer)
4. Akceptacja
5. Tworzenie rezerw (działanie awaryjne)
• 10.Zalecanie działania najwłaściwszego
• 11.Wyważenie kosztów ewentualnych działań wiążących ryzyko z kosztami zmaterializowania się ryzyka
Zarządzanie konfiguracją Zarządzanie konfiguracją składa się z 5 elementów:
• Planowanie (Planning)
• Identyfikacja (Identification)
• Kontrola (Control)
• Charakteryzowanie statusu (Status accounting)
• 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 uaktualnieniami.
4. System rejestrowania, śledzenia i dokumentowania wszystkich zagadnień projektowych.
Sterowanie zmianami
Rodzaje zmian
1. wniosek o wprowadzenie zmiany (koszt
pokrywa klient)
2. odstępstwo (koszt naprawy pokrywa
dostawca)
3. ustępstwo (brak działań korygujących)
Dokumentacja PRINCE2 1. Dokumentacja inicjująca projekt
1.Kontekst projektu
2.Instrumenty sterowania
3.Definicja projektu
1.Cele projektu
2.Metody osiągania celów
3.Spodziewane wyniki (produktu)
4.Formula realizacji projektu
5.Ograniczenia, wyłączenia
6.Powiązania projektu
4.Uzasadnienie ekonomiczne
5.Struktura organizacyjna
6.Plan projektu
1.Produkty
2.Działania
3.Zasoby
7.Plan komunikacji
8.Rejestr ryzyka
9.Tolerancje w projekcie
2.Rejestry
1.Rejestr ryzyka
2.Rejestr zagadnień
3.Rejestr jakości
4.Rejestr doświadczeń
5.Rejestr dzienny
6.Rejestr zarządzania konfiguracją
3.Raporty
1.Raport okresowy
2.Raport końcowy etapu zarządczego
3.Raport końcowy projektu
4.Raport o odchyleniach
5.Raport z punktu kontrolnego
6.Raport z wykorzystania zasobów
7.Raport doświadczeń z projektu
4.Plany
1.Plan etapu inicjowania projektu
2.Plan jakości projektu
3.Plan projektu
4.Plan zarządzania konfiguracją
5.Plan etapu zarządczego
6.Plan jakości etapu zarządczego
7.Plan awaryjny (rezerwowy)
8.Plan wyjątkowy (naprawczy)
9.Plan wykorzystania budżetu zmian
10.Plan tekstowy
11.Plan pracy zespołu specjalistycznego
12.Plan przeglądu poprojektowego
13.Plan bazowy (stan odniesienia)
Mocne strony PRINCE2 • Stosowanie tej metodyki zapewnia wysoką standaryzację i powtarzalność
projektów o wspólnym podejściu, terminologii i dokumentacji. Zapewnia to możliwość doskonalenia kompetencji.
• Metodyka w sposób racjonalny opiera się na najlepszych praktykach w zarządzaniu projektami.
• Wprowadza management by exception jako podstawową zasadę, która zapewnia Kierownikowi Projektów swobodę działania bez zbędnej ingerencji, zapewniając jednocześnie zaangażowanie wyższego kierownictwa, wtedy kiedy projekt jest zagrożony wykroczeniem poza granice tolerancji lub przestaje realizować uzasadnienie biznesowe.
• Sprawuje kontrolę nad startem, realizacją i końcem projektu.
• Każdy z dokumentów wymaganych przez PRINCE2 jest dostarczony jako szablon zawierający wymagane metrykę, rozdziały i pola informacyjne co zapewnia przejrzystość, standaryzację i kompletność dokumentacji.
• Przewiduje możliwość adaptacji do specjalnych potrzeb organizacji, programu lub projektu.
• Jej stosowanie nie wymaga opłat autorskich.
• Materiały PRINCE2 są opublikowane i szeroko dostępne co ogranicza prace nad wypracowywaniem własnych standardów i przygotowaniem materiałów szkoleniowych.
Słabe strony PRINCE2 • Dużo organizacji cierpi na syndrom PINO (Prince In Name Only tzn. PRINCE2
tylko z nazwy), wybierając bez głębszej analizy tylko niektóre składniki metodyki nie zwracając uwagi na podstawowe zasady (podobnie jak kilka poniższych zarzutów jest to problem nie metodyki lecz jej stosowania).
• PRINCE2 kładzie duży nacisk na dokumentowanie jako narzędzie sprawnej kontroli sposobu realizacji projektu. W niektórych organizacjach dokumenty stają się jednak celem samym w sobie, a rzeczywiste projekty kończą się niepowodzeniem. Z tego powodu PRINCE2 oskarżany jest czasem o nadmierną biurokratyzację procesu zarządzania.
• PRINCE2 zwraca uwagę na potrzebę dobrej organizacji i regularną wymianę informacji pomiędzy interesariuszami, co może być odbierane jako zachęta do ciągłych bezproduktywnych spotkań zabierających czas niezbędny na rzeczywistą pracę.
• PRINCE2 nie definiuje wprost analizy wymagań. Jako metodyka wdrożeniowa może prowadzić do niepowodzenia projektu z uwagi na przyjęcie fałszywych założeń (z drugiej strony jasno jest określone, kto ponosi odpowiedzialność za przyjęcie złych założeń i akceptację nietrafnego uzasadnienia biznesowego, a przesłanki tych decyzji są udokumentowane i mogą stanowić nauczkę na przyszłość).
• Zbyt ścisłe przestrzeganie PRINCE2 bez odpowiedniej adaptacji do realiów biznesowych może być zbyt pracochłonne w zastosowaniu do małych projektów.
• Niezbyt "zwinna".
WPROWADZENIE
Do SCRUM
„Ludzie i interakcje ponad procesy i narzędzia
Metodyki tradycyjne (PRINCE)
Straty w biegu
sztafetowym Proces „sztafety” w wytwarzaniu
oprogramowania często pozostaje w konflikcie
z jej głównym celem tj. maksymalną szybkością
i uzyskaniem odpowiedniej elastyczności
produktu….
W zamian: holisticzne (proces „rugby”)
podejście do projektu — gdzie zespół próbuje
przebiec dystans jako całość, poddając piłkę do
tyłu i do przodu — znacznie efektywniej
pozwala na realizację wysublimowanych
wymagań dzisiejszych systemów
informatycznych
• Scrum zwinny (agilny) proces pozwalający i skupiający
się na dostarczeniu najwyższej wartości biznesowej
(produkt) w możliwie najkrótszym czasie.
• Scrum pozwala szybko i powtarzalnie prowadzić
inspekcję bieżąco funkcjonującego oprogramowania
(inspekcje – przeglądy co dwa tygodnie w miesiącu).
• Wymagania biznesowe klienta ustalają priorytety do
realizacji. Zespół organizuje się sam dla wybrania
najlepszej drogi do dostarczenia najlepszego prod.
• Co dwa tygodnie (do miesiąca) każdy z zespołu
obserwuje realnie pracujące oprogramowanie, wydaje
je lub kontynuuje prace dla jego zmiany w następnym
sprincie.
Założenia - Scrum
Scrum jest używane
do/dla/w: • Budowanie oprogramowania komercyjnego
• Prowadzenie kontraktów
• Projekty o narzuconej cenie
• Aplikacje finansowe
• ISO 9001-projekty
• Systemy wbudowane
• 24x7 systemy 99.999% efektywności działania
• Gry strategiczne - Joint Strike Fighter
• Duże systemy informatyczne
• Video gry
• FDA- potwierdzone, krytyczne dla zycia systemy (food @ drug administration)
• Oprogramowanie kontroli satelitów
• Oprogramowanie stron www
• Oprogramowanie podręczne
• Aplikacje dla systemów mobilnych
• Aplikacje obsługi i administracji sieci i funkcjonowania sieci
• Aplikacje dla specjalizowanych systemów operacyjnych
Charakterystyka ogólna
SCRUM • Samo–organizujący się zespół
• Rozwój produktu w serii miesięcznych sprintów
• Wymagania są ujmowane jako produkty w liście zwanej portfelem produktów “product backlog”
• Nie ma specyfikacji praktyk inżynierskich
• Użycie twórczych zasad kreujących środowisko agilne dla dostarczenie projektu
• Jeden z tzw. “agile processes”
Manifest – metodyki agilne
zestawienie wartości Procesy i
narzędzia
Indywidualność i
współdziałanie ponad
Podążanie za
planem
Reagować na
zmiany ponad
źródło: www.agilemanifesto.org
Wszechstronna
dokumentacja
Pracujące
oprogramowanie ponad
Negocjacje kontraktu
formalne ustalenia
Współpraca z
Klientem ponad
Bardziej cenimy Doceniamy
Scru
m
Cancel
Gift wrap
Return
Sprint
2-4 tygodni
Spotkanie
(Sprint Planning)
Sprint-cel
Lista zadań i
procochłonności
(Sprint backlog)
Dostarczenie gotowego
przyrostu produktu
Rejestr wymagań /
funkcjonalności
(Product Bucklog)
1 3
2
1
24 godziny (spotkania 15min
Daily Scrums)
1. Centrum procesu – Sprint – ograniczenie
czasowe pozwalające na realizację PRZYROSTU -
używalnej i potencjalnie gotowej funkcjonalności
1. Nad czym pracowałeś wczoraj?
2. Nad czym będziesz pracować
dzisiaj?
3. Czy masz jakiś problem?
SCRUM
Image available at
www.mountaingoatsoftware.com/scrum
Sprints
• Postęp w realizacji projektu następuje w serii tzw.
Sprintów – analogicznie jak w kolejnych iteracjach
programowania extremalnego
• Typowy czas dla sprintu – 2-4 tygodni, nie więcej
jednak jak miesiąc
• Stała długość sprintu pozwala utrzymać odpowiedni
rytm pracy
• W obrębie sprintu produkt jest projektowany,
kodowany i testowany
Sekfencyjne vs. zazębione (współbieżne z
przesunięciem –overlapping) wytwarzanie – rozwój oprogramowania
Zamiast realizować kolejne
elementy w swoim czasie…
...zespół Scrum realizuje
wszystkiego po trochę przez
cały czas trwania projektu
Wymagania Projekt Kod Test
W obrębie sprintu nie
ma zmian
• Czas trwania sprintu powinien być tak
zaplanowany aby gwarantował brak
konieczności wprowadzania zmian do sprintu.
Zmiana
Scrum framework • Właściciel produktu (Product owner)
• Mistrz „Młyna” (ScrumMaster)
• Zespół (Team)
Role
• Spotkanie (Sprint planning)
• Widok zadania (Sprint review)
• Podsumowanie sprintu (Sprint
retrospective)
•Odprawa scrum (Daily scrum
meeting)
Zdarzenia
•Rejestr funkcjonalności (Product backlog)
•Lista zadań i pracochłonność (Sprint
backlog)
• Czas do końca projektu (Burndown charts)
Artefacty
Scrum framework
•Planowanie sprintu
•Przegląd sprintu
•Podsumowanie sprintu
•Dzienna odprawa
Wydarzenia:
•Rejestr funkcjonalności
•Lista zadań
•Czas do końca (wypalenie)
Artefakty:
•Właściciel Produktu
•Mistrz
•Zespół
Role:
Właściciel produktu
• Definiuje własności produktu
• Decyduje o terminie wydania produktu
• Jest odpowiedzialny za dodatnie profity z
produktu
• Ustala priorytety funkcjonalności w
dopasowaniu do rynku
• Dopasowuje własności i priorytety na każdej
iteracji jeżeli potrzeba
• Akceptuje lub odrzuca rezultaty prac
Mistrz Młyna
ScrumMaster • Reprezentuje zarządzanie w projekcie
• Odpowiedzialny za realizację zasad i
praktyk SCRUM
• Usuwa przeszkody
• Zapewnia pełną funkcjonalność i
produktywność zespołu
• Umożliwia ścisłą współpracę pomiędzy
wszystkimi aktorami i ich rolami
• Osłania zespół przed zewnętrznymi
czynnikami
Zespół • Zwykle 5 – 9 ludzi
• Funkcyjnie przekrojowi:
• Programiści, testerzy, doświadczeni przez użytkowników projektanci, etc.
• Członkowie zespołu powinni być zatrudnieni na stałe (Full-time)
• Mogą byś wyjątki (n.p., Administrator bazy danych)
Zespół
• Zespół organizuje się sam
• Idealnie, żadnych tytułów raczej mozliwości
• Uczestnictwo w zespole powinno się zmieniać jedynie pomiędzy sprintami
•Właściciel Produktu
•Mistrz
•Zespół
Role Scrum framework
•Rejestr funkcjonalności
•Lista zadań
•Czas do końca (wypalenie)
Artefakty
•Planowanie sprintu
•Przegląd sprintu
•Podsumowanie sprintu
•Dzienna odprawa
Wydarzenia
Planowanie sprintu
Priorytety w Sprincie
• Analiza i ocena funkcjonalności
• Wybór listy zadań
Planowanie Sprintu
• Określ jak osiągnąć cel sprintu
(projekt)
• Wykreuj listę zadań (sprint backlog)
z rejestru funkcjonalności (user
stories)
• Oszacuj czas realizacji listy zadań
Cel
Sprintu
Lista
zadań
Zasoby
biznesowe
Zdolności
zespołu
Rejestr
funkcjonalnośc
i
Technologia
Bieżący
produkt
Planowanie Sprintu • Zespół wybiera zadania z rejestru
funkcjonalności które zobowiązują się wykonać
• Lista zadań zostaje wykreowana
• Zadania są zidentyfikowane i każde jest oszacowane (1-16h)
• Wspólnie, nie samodzielnie przez ScrumMastera
• Uwzględniamy projektowanie wyższego poziomu
Jako planujący wakacje, Chcę widzieć zdjęcie hoteli.
Kodowanie pośredniego poziomu (8h)
Kod interfejsu użytkownika (4)
Testowanie połączeń (4)
Kodowanie Klas (6)
Testowanie (4)
Odprawa (Daily scrum) • Parametry
• Codziennie
• 15-minut
• Na stojaco (w biegu)
• Nie ma służyć rozwiązaniu problemów
• Wszyscy są zaproszeni (każdy może słuchać)
• Tylko członkowie zespołu, ScrumMaster, właściciel produktu, mogą mówić
• Pomaga uniknąć innych niepotrzebnych spotkań
Każdy odpowiada na 3
pytania
• One nie są zobowiązania dla ScrumMastera
• Są to zobowiązania przed rówieśnikami!!
Co robiłeś wczoraj? 1
Co będziesz robił dzisiaj? 2
Czy masz jakiś problem? 3
Przegląd sprintu
• Zespół przedstawia co zostało zrealizowane w sprincie
• Zwykle przyjmuje to formę prezentacji nowej funkcjonalności i architektury architecture
• Nieformalnie
• 2-h prezentacja zwykle
• Nie przeźrocza
• Cały zespół bierze udział
• Zapraszamy otoczenie
Podsumowanie Sprintu • Okresowo jest sprawdzane co działa i nie
działa w projekcie
• Zwykle 15–30 minut
• Realizowane po każdym sprincie
• Cały zespół bierze udział
• ScrumMaster
• Właściciel produktu (designer, twórca)
• Zespół
• Możliwie klient i zaproszeni
Start / Stop / Continue • Cały zespół dyskutuje co dalej chcieliby robić:
Zaczynamy pracę
Kończymy pracę
Kontynuujemy pracę To jedna z wielu dróg realizacji podsumowania
sprintu.
•Właściciel Produktu
•Mistrz
•Zespół
Role Scrum framework
•Rejestr funkcjonalności
•Lista zadań
•Czas do końca (wypalenie)
Artefakty
•Planowanie sprintu
•Przegląd sprintu
•Podsumowanie sprintu
•Dzienna odprawa
Wydarzenia
•Właściciel Produktu
•Mistrz
•Zespół
Role Scrum framework
•Planowanie sprintu
•Przegląd sprintu
•Podsumowanie sprintu
•Dzienna odprawa
Wydarzenia
•Rejestr funkcjonalności
•Lista zadań
•Czas do końca (wypalenie)
Artefakty
Rejestr
Funkcjonalności(product backlog) •Wymagania
• Lista wszystkich koniecznych prac w projekcie
•Wyrażonych jasno tak że każdy element ma wartość dla użytkownika i klienta produktu
•Uszeregowany przez właściciela produktu
•Ustawione priorytety na starcie każdego sprintu
To jest
product backlog
Przykładowy rejestr
funkcjonalności Element rejestru Szacowanie
Pozwala gościowi zrobić rezerwację 3
Jako gość chcę usunąć rezerwację 5
Jako gość chcę zmienić datę rezerwacji 3
Jako hotelarz, chcę uruchomić aplikację
wskazujacą na dostepnośc pokoii 8
Popraw obsługę wyjatków 8
... 30
... 50
Cel Sprintu • Krótkie zdanie opisujące na jakim zdarzeniu
będzie skupiona praca systemu w realizowanym
sprincie
Zastosowanie Bazy Danych
Wsparcie finansowe
Nauki o życiu
Dostarczają funkcjonalności dla
studiów nad genetyką populacji
Wspiera stronę techniczną
działania firmy ABC w czasie
rzeczywistym.
Pozwala uruchomić aplikację na
SQL-owej bazie ORACLE.