Egzamin PRINCE2 Agile Klucz odpowiedzi Przykładowy arkusz 1

Transkrypt

Egzamin PRINCE2 Agile
Klucz odpowiedzi
Przykładowy arkusz 1
Wydanie z czerwca 2015
© AXELOS Limited 2015
Wszystkie prawa zastrzeżone.
Reprodukcja tych materiałów wymaga zgody firmy AXELOS Limited.
Logo w kształcie wiru (Swirl logo™) jest znakiem handlowym firmy AXELOS Limited.
PRINCE2 AGILE™ jest znakiem handlowym firmy AXELOS Limited.
1
PRINCE2AGILE_2015_PRP_Rationale_PL_SamplePaper1_V4.0/
1. Temat z sylabusa: 1.1
Prawidłowa odpowiedź: D
Cel: LO1 - Rozumie podstawowe pojęcia dotyczące ogólnych zasad zwinnego stylu pracy
a)
b)
c)
d)
Kanban to sposób na poprawę płynności oraz poprawę systemu poprzez kontrolę
pracy w toku (Tabela 2.1).
DevOps służy tylko do pracy związanej z IT. Jest to podejście polegające na
współpracy pomiędzy rozwojem i operacjami w celu stworzenia produktu lub usługi,
przy którym dwa rodzaje pracy i nawet zespoły jednoczą się najbardziej jak to tylko
możliwe (Tabela 2.1).
SAFe (Scaled Agile Framework) to szerokie zastosowanie zwinnego stylu pracy
w całej organizacji (Tabela 2.1).
Lean Startup pierwotnie było podejściem do tworzenia i zarządzania firmami start-up,
teraz natomiast stosowane jest w przypadku każdej firmy, której celem jest jak
najszybsza dostawa produktów do klienta (Tabela 2.1).
Prawidłowa odpowiedź: B
a)
b)
c)
d)
W środowisku zwykłej działalności biznesowej zadania są ustalane według priorytetów
i mogą zostać przypisane do timeboxów. Gdy praca jest zakończona, istniejący
produkt z czasem ewoluuje (1.2.2).
Przykładem mógłby być projekt, w ramach którego tworzony jest nowy produkt lub
usługa, może istnieć potrzeba zaangażowania wielu interesariuszy i istnieje znaczny
stopień niepewności (1.2.2). PRINCE2 Agile nadaje się do stosowania tylko
w przypadku projektów (1.2).
W przypadku zwykłej działalności biznesowej zazwyczaj istniałaby długa lista zadań,
które regularnie pojawiałyby się w czasie cyklu życia produktu (1.2.1). PRINCE2 Agile
nadaje się do stosowania tylko w przypadku projektów (1.2).
2
PRINCE2AGILE_2015_Rationale_PL_SamplePaper1_V4.0/
Prawidłowa odpowiedź: A
a)
b)
c)
d)
Kanban to sposób na poprawę płynności oraz systemu poprzez wizualizację i kontrolę
pracy w toku (Tabela 2.1).
Tradycyjny, kaskadowy cykl życia projektu jest rozbity na etapy „techniczne”, takie jak
Analiza, Projekt, Budowa, Testowanie i Wdrażanie (6.4.2).
Mapa rozwoju produktu to wykres lub dokument, który pokazuje zamierzoną ścieżkę
rozwoju produktu. Zazwyczaj jest to plan długoterminowy, który może obejmować kilka
miesięcy lub lat (Glosariusz).
Prawidłowa odpowiedź: C
Cel: LO2 - Rozumie cel oraz kontekst połączenia PRINCE2 ze zwinnym stylem pracy
a)
b)
c)
d)
PRINCE2 nie jest „tradycyjnym podejściem do zarządzania projektem”, które opisuje
projekt w szczegółach na początku (big design up front) (3.7, punkt 2).
PRINCE2 nie jest „tradycyjnym podejściem do zarządzania projektem”, będąc głównie
podejściem „kaskadowym” (3.7, punkt 2). Metoda kaskadowa jest liniowa i
sekwencyjna, posiada oddzielne cele dla każdego etapu rozwoju (Glosariusz).
PRINCE2 nie jest „tradycyjnym podejściem do zarządzania projektem”, będąc głównie
podejściem „biurokratycznym” z systemem „sterowania i kontroli” (3.7, punkt 2).
PRINCE2 może współdziałać z podejściem zwinnym i nie trzeba niczego usuwać ani
wprowadzać większych zmian (3.7, punkt 1).
3
a)
b)
c)
d)
Jest to korzyść dla organizacji PRINCE2, które spotykają się z podejściem zwinnym –
rozumieją je, ale go nie wprowadzają (Tabela 3.1).
PRINCE2 Agile skupia się na tych osobach ze społeczności PRINCE2, które chcą
wprowadzić podejście zwinne. Chcą wprowadzić podejście zwinne w istniejące
praktyki PRINCE2, aby odnieść korzyść wynikającą z tego podejścia do pracy (Tabela
3.1).
Jest to korzyść dla tych, którzy już wprowadzili podejście zwinne i chcą przyjąć
podejście PRINCE2 (Tabela 3.1).
Dojrzała organizacja zwinna, może chcieć poznać PRINCE2 Agile, aby dodać tę
metodykę do zasobów wiedzy (Tabela 3.1).
a)
b)
c)
d)
Ci, którzy używają podejścia zwinnego, aby bezproblemowo zintegrować się z etosem
PRINCE2, który polega na kontroli poprzez decyzyjne umocowanie pracowników i
zapewnianie, że projekt pozostaje zasadny (3.1).
Ci, którzy kierują i zarządzają projektem w kontekście zwinnym, muszą przyjąć zwinną
dyscyplinę i zachowania (3.1). Zespół używający podejść zwinnych powinien już
korzystać z tych zachowań (Tabela 2.2).
Ci, którzy kierują i zarządzają projektem w kontekście zwinnym, muszą przyjąć zwinną
dyscyplinę i zachowania (3.1). Zespół używający podejść zwinnych powinien już
PRINCE2 Agile ma stanowić połączenie z typowymi zachowaniami zwinnymi, np.
z tworzeniem timeboxów (2.2). Zespół używający podejść zwinnych powinien już
4
Cel: LO5 - Jest w stanie zastosować lub dostosować pryncypia PRINCE2, tematy, procesy i
produkty zarządcze do projektu w kontekście podejścia zwinnego
a) Koncentracja na produktach jest związana z opisami produktu, kryteriami jakości
i tolerancjami jakości. Można je elastycznie dopasować, aby skupić się na
dostarczaniu wartości (Tabela 7.1).
b) Zespół dowiedział się, że firma ma problem z rozpoznawalnością na rynkach
nieanglojęzycznych. W związku z tym wydano zalecenia (Tabela 7.1).
c) Zespół dowiedział się, że firma ma problem z rozpoznawalnością na rynkach
nieanglojęzycznych. W związku z tym wydano zalecenia (Tabela 7.1).
d) Retrospektywa projektu odbywa się w ramach procesu Zamykanie Projektu, a nie pod
koniec etapu (Tabela 22.1).
a)
b)
c)
d)
Jest to przykład „sprawdzenia wykonalności” lub eksperymentu, który pomoże określić
„wersję produktu końcowego, co pozwoli na maksymalne zdobywanie potwierdzonych
informacji przy jak najmniejszym wysiłku”, tzn. minimum viable product (MVP) dla
nowego zapisu firmowego (Tabela 7.1 oraz Glosariusz).
Może to mieć pozytywny wpływ na panujące otoczenie zwinne. Jednakże jest to forma
„sprawdzenia możliwości przeprowadzenia” lub eksperymentu, który ma służyć
określeniu MVP dla nowego zapisu firmowego (Tabela 7.1, Część 24.3, Glosariusz).
MVP to „wersja produktu końcowego, która pozwala na maksymalne zdobywanie
potwierdzonych informacji przy jak najmniejszym wysiłku” i nie należy jej mylić
z opłacalnością całego projektu (Glosariusz).
To prawda, że nowe logo firmowe może nie być dostatecznie rozpoznawalne
i unikatowe, ale jest to przykład „sprawdzenia wykonalności” lub eksperymentu, który
pomoże określić „wersję produktu końcowego, co pozwoli na maksymalne zdobywanie
potwierdzonych informacji przy jak najmniejszym wysiłku”, tzn. minimum viable
product dla nowego zapisu firmowego (Tabela 7.1 oraz Glosariusz).
5
a)
b)
c)
d)
Wyniki związane z Festiwalem Sera nie stanowią części zakresu Rebrandingu. Jest to
„szansa”, która prawdopodobnie nie zablokuje postępów Zespołu ds. Rebrandingu
(Część 13.3). Należy to zgłosić Kierownikowi Projektu.
Wyniki związane z Festiwalem Sera nie stanowią części zakresu Rebrandingu. Jest to
„zagrożenie”, które prawdopodobnie nie zablokuje postępów Zespołu ds. Rebrandingu
(Część 13.3). Należy to zgłosić Kierownikowi Projektu.
Kampania marketingowa nie stanowi części zakresu Rebrandingu. Jest to zagadnienie
projektowe, które prawdopodobnie nie zablokuje postępów Zespołu ds. Rebrandingu
(Część 13.3). Kierownik Projektu powinien już o tym wiedzieć.
Podczas codziennego spotkania dobrze jest zapytać, czy są świadomi czegoś, co
„potencjalnie mogłoby” zablokować ich postępy (Część 13.3).
a)
b)
c)
d)
Prawdą jest, że samoorganizujące się zespoły powinny dowolnie radzić sobie ze zmianą
w dynamiczny sposób i na poziomie szczegółowym, ale ta zmiana miałaby wpływ nie
tylko na Grupę Zadań i zespół. W związku z tym nie znajduje się na poziomie
szczegółowym (Część 14.3).
Jest to zgodne z zachowaniem zwinnym PRINCE2 Agile dotyczącym Eksploracji.
Jednakże nie jest to odpowiednie, ponieważ miałoby wpływ nie tylko na Grupę Zadań
i zespół. W związku z tym nie znajduje się na poziomie szczegółowym (Część 13.3 oraz
14.4.1).
Raporty Nadzwyczajne do Komitetu Sterującego w razie potrzeby zostałyby zgłoszone
przez Kierownika projektu w ramach procesu Sterowanie Etapem (Rysunek 10.2, Tabela
19.1, Część 19.5).
Zmiana ta miałaby wpływ nie tylko na Grupę Zadań i zespół. W związku z tym nie
znajduje się na poziomie szczegółowym. Wynikające z tego zagadnienie należy zgłosić
szybko i upewnić się, że nie ma wpływu na cele Sprintu i Wydanie (Część 13.3, 14.4.1
i 19.3, Tabela 20.1).
6
a) To prawda, że samoorganizujące się zespoły powinny dowolnie radzić sobie ze
zmianą w dynamiczny sposób i na poziomie szczegółowym, ale jest to zmiana zakresu
i trzeba się nią zająć w sposób formalny; należy podjąć decyzje na odpowiednim
poziomie zarządzania (Część 14.3).
b) To prawda, że Właściciel Produktu powinien na bieżąco ustalać priorytety pracy
w Backlogu Produktu, opierając się na wartości i maksymalizując wartość, ale jest to
zmiana zakresu i trzeba się nią zająć w sposób formalny (Część 9.2 oraz 14.3).
c) Samoorganizujące się zespoły powinny dowolnie radzić sobie ze zmianą w
dynamiczny sposób i na poziomie szczegółowym. Jednakże jest to zmiana zakresu,
trzeba się nią zająć w sposób formalny i poradzić na odpowiednim poziomie
zarządzania (Część 14.3).
d) To prawda, że jeśli zmieni się ilość pracy, nie zostanie to łatwo uchwycone na
wykresie spalania, dlatego należy użyć wykresu wypalania. Jest to zmiana zakresu
i należy się nią zająć w sposób formalny; decyzje muszą zostać podjęte na
odpowiednim poziomie zarządzania (Część 14.3 i 15.4.1).
a) Eksperyment bezpieczny w razie niepowodzenia ma ograniczony wpływ na system lub
plan w razie niepowodzenia (Tabela 13.1 oraz Glosariusz).
b) To prawda, że odpowiedzialnością osoby zarządzającej zespołem (tj. Kierownika
Zespołu) jest zarządzenie ryzykiem na poziomie dostarczania, ale eksperyment
bezpieczny w razie niepowodzenia ma na celu zbadanie wpływów (tj. ograniczonych
wpływów) na system lub plan w razie niepowodzenia, a nie prawdopodobieństwa
zaistnienia niepewnego wydarzenia (Część 13.3, Tabela 13.1 oraz Glosariusz).
c) Jest to „przyczyna” lub źródło ryzyka związanego z udanym zakończeniem pracy
zespołu. W związku z tym należy się tym zająć jako ryzykiem (Część 13.3).
d) Eksperyment bezpieczny w razie niepowodzenia ma na celu zbadanie wpływów (tj.
ograniczonych wpływów) na system lub plan w razie niepowodzenia, a nie
prawdopodobieństwa zaistnienia niepewnego wydarzenia (Część 13.3, Tabela 13.1 oraz
Glosariusz).
7
a) Zależności mogą być przyczyną ryzyk. Jednakże ryzyka istniejące pomiędzy
obszarami pracy są ryzykami projektowymi, które w razie konieczności są
rejestrowane przez Kierownika Projektu (Część 13.3 i Załącznik A.25.1).
b) Interfejsy, które muszą zostać utrzymane podczas opracowywania projektu, powinny
być ujęte w dokumentacji Grupy Zadań, którą Kierownik Projektu oraz Kierownik
Zespołu (wraz z zespołem) powinni zdefiniować wspólnie (Część 20.3.1, Załącznik
A.26.2).
c) Jednocześnie w Opisie Produktu powinno się udokumentować przeznaczenie
produktu, użytkowników oraz to, czy stanowi on środek do celu, czy też sam cel
(Załącznik A.17.2).
d) Backlog Produktu służy do ustalenia priorytetów pracy (przez Właściciela Produktu)
w oparciu o wartość i maksymalizację tej wartości. Nie dokumentuje on wzajemnych
zależności (Część 9.2).
a) Podejmowanie decyzji może być w większym stopniu oparte na informacjach uzyskanych
z projektu, a nie na informacjach zgłoszonych w sposób formalny. Przegląd informacji na
wykresach spalania w pokoju projektowym umożliwia regularny, bogaty i nieformalny
przepływ informacji (18.3).
b) Kluczowe jest upewnienie się, że zarządzanie z wykorzystaniem tolerancji działa
sprawnie dla całego zespołu zarządzania projektem, ponieważ tworzy to otoczenie
sprzyjające zwinnym metodom pracy, w którym osoby organizują się samodzielnie.
Kierownik Projektu powinien radzić się Przewodniczącego tylko wtedy, gdy Komitet
Sterujący nie zapewnia Kierownikowi Projektu jasnych wytycznych (18.4 / 18.1).
c) Kierownik Projektu poinformuje Komitet w razie wystąpienia sytuacji nadzwyczajnej. Jest
to prawidłowe podejście, nawet jeśli Komitet Sterujący czerpie informacje z wykresu
spalania projektu (18.1).
d) Komitet Sterujący zarządza z wykorzystaniem tolerancji. Monitoruje za pomocą raportów
i sprawuje kontrolę za pośrednictwem małej liczby punktów decyzyjnych. Nie powinna
zaistnieć potrzeba przeprowadzania innych „spotkań na temat postępów” dla Komitetu
Sterującego. Jednakże podejmowanie decyzji zgodnie z PRINCE2 Agile może być w
większym stopniu oparte na informacjach uzyskanych z projektu, a nie na informacjach
zgłoszonych w sposób formalny (18.1 / 18.3).
8
a) Mimo że cała praca mieści się w ramach jednego etapu, nadal będzie istnieć potrzeba
jakiejś formy planowania (12.3.5).
b) PRINCE2 wspiera każdy styl planowania, od Wykresu Gantta do prostej listy backlog.
Oba style są zgodne z opisem produktu Plan. Może się zdarzyć, że w ramach jednego
projektu wykorzystuje się więcej stylów planowania (12.3).
c) Podczas akceptacji Grupy Zadań można skorzystać z backlogów sprintu i wydania.
Empiryczne i wyłaniające się planowanie ma większą szansę zaistnieć na niższym
poziomie planowania, na przykład w przypadku dostarczenia produktu w ramach procesu
Zarządzanie Dostarczaniem Produktów (tj. gdzie głównie używa się podejścia zwinnego),
ponieważ ramy czasowe (a zatem także horyzonty planowania) będą krótsze, np. od
dwóch do czterech tygodni (Tabela 20.1 / 12.3.3).
d) Zgoda na to, co wydaje Grupa Zadań (jeśli w ogóle) i preferowany rozmiar timeboxów jeśli jest ich więcej niż jeden. Nie wyjaśnia to jednak użycia timeboxów w ramach procesu
Zarządzanie Dostarczaniem Produktów (20.3.1).
a) Raport z Punktu Kontrolnego służy do zgłaszania statusu Grupy Zadań przy
częstotliwości zdefiniowanej w Grupie Zadań. Dzieje się to podczas projektu, a nie pod
koniec projektu. Także Brand-u-Like nie udokumentowałoby tej informacji o sobie w
Raporcie z Punktu Kontrolnego (A.3.1).
b) Najbardziej prawdopodobny jest Raport Nadzwyczajny, ponieważ przewidywana do
dostarczenia ilość może przekroczyć tolerancję. Podana informacja nie spowoduje
sytuacji nadzwyczajnej (Tabela 23.3).
c) Ocena zachowań zwinnych zawsze powinna być zawarta w Raporcie Końcowym
Projektu i powinna odnosić się do decyzji podjętych przy użyciu Agilometer (Tabela 23.3).
d) Zestawienie Statusu Produktów może odnosić się do dużego stopnia zmian ze względu
na regularną iteracyjność produktów w zarządzaniu konfiguracją. Podana informacja nie
jest związana z produktami (Tabela 23.3).
9
a) Treść Zapisu Obiektu Konfiguracji (ZOK) zostanie zdefiniowana w Strategii Zarządzania
Konfiguracją (SZK) projektu. Potrzeba użycia ZOK nie ma wpływu na zarządzanie
zmianami dotyczącymi produktu (A.5.2).
b) Mimo iż podejście do opracowania SZK powinno opierać się na współpracy, wymagania
należy określić na wysokim lub średnim poziomie, ale nie szczegółowo (28.3).
c) Poziom, na którym odbywa się zarządzanie konfiguracją, powinien brać pod uwagę fakt,
że projekt lub zmiana na poziomie etapu może mieć wpływ na ustalony poziom
odniesienia, a zmiany szczegółowe raczej nie (Tabela 23.1). Zmiana powinna zostać
umożliwiona na poziomie dostarczania produktu, aby skorzystać na pozytywnej zmianie
(14.3).
d) SZK w dowolnej formie będzie kluczowy dla projektu. Iteracyjna i przyrostowa natura
podejścia zwinnego oznacza, że będzie istnieć wiele wersji produktów i że zmiana jest
nieunikniona, należy ją więc przyjąć i odpowiednio wykorzystać. W otoczeniu, w którym
dochodzi do automatyki oraz częstych wydań do użytku, mogą istnieć konkretne
narzędzia oraz jasne definicje ich wykorzystania (Tabela 23.1).
Cel: LO5 - Jest w stanie zastosować lub dostosować pryncypia PRINCE2, tematy, procesy
i produkty zarządcze do projektu w kontekście podejścia zwinnego
a) Zwinny styl pracy musi być wprowadzony do Strategii Zarządzania Jakością (SZJ), aby
zapewnić osiągnięcie poziomu jakości (Tabela 23.1).
b) SZJ służy do definiowania technik jakości oraz standardów, które należy zastosować.
Reputacja dostawcy nie ma związku z wymaganiami (A.22.1).
c) SZJ służy do określania techniki i standardów jakości, jakie będą stosowane w projekcie,
wraz z różnymi obowiązkami niezbędnymi dla osiągnięcia wymaganych poziomów
jakości. (A.22.1).
d) Mimo że w pewnych środowiskach zwinnych nacisk może być położony na planowanie
jakości oraz zarządzanie jakością na początku projektu, SZJ określi, w jaki sposób
osiągnie się zdefiniowany standard przy pomocy kontroli jakości podczas opracowywania
produktu (11.2).
10
19. Temat z sylabusa: 4.1 a)
Cel: LO4 - Jest w stanie dopasować sześć aspektów projektu w kontekście podejścia zwinnego
- Jakość
a) W tym stwierdzeniu brakuje potrzeby zamieszczenia filmu w serwisie YouTube (Część
11.2).
b) To stwierdzenie nie odnosi się do tego, gdzie dostępny jest film (Tabela 6.1).
c) Nie wszystkie elementy tego stwierdzenia są kluczowe, dlatego zerowa tolerancja
wszystkich elementów nie jest odpowiednia (Tabela 6.1).
d) Zerowa tolerancja służy kluczowym oczekiwaniom jakościowym klienta (dostępność na
YouTube). Tolerancje można wykorzystać, jeśli są pożądane, lecz nie kluczowe
(dostępność na Instagram) (Tabela 6.1).
20. Temat z sylabusa: 4.1 b)
– Zakres
a) Kluczowe jest, aby ponownie oceniony zakres pracy określał wystarczające cechy warte
dostarczenia. Dostosowanie zakresu reklam oznaczonych „Powinno być”
prawdopodobnie jest wykonalne (Część 9.2 i Tabela 6.1).
b) Zerowa tolerancja powinna obejmować zakres produktów, które są kluczowe.
Dostosowanie zakresu może odbyć się dla produktów, które są pożądane, lecz nie
kluczowe. Reklam oznaczonych jako „Musi być” nie powinno się dostosowywać (Tabela
6.1).
c) Dostosowanie zakresu może odbyć się dla produktów, które są pożądane, lecz nie
kluczowe. Typowa reakcja zwinna to ponowne ustalenie priorytetów oraz celu, aby w
następnym timeboxie ująć zagadnienia, którymi nie można się zająć obecnie (Tabela 6.1
/ 14.2).
d) Zerowa tolerancja powinna obejmować zakres produktów kluczowych, dlatego w ramach
tego timeboxu należy dostarczyć wszystkie wymagania oznaczone jako „Musi być”
(Tabela 6.1).
11
21. Temat z sylabusa: 4.1 c)
– Czas/koszt/korzyść/ryzyko
a) Zerowa tolerancja musi obejmować poziom określony jako „minimalna opłacalność”
w Uzasadnieniu Biznesowym – w tym przypadku jest to 10% wzrost sprzedaży.
Długofalowe korzyści z reklam telewizyjnych w tym przypadku nie odzwierciedlają
minimalnej wykonalności (Tabela 6.1).
b) Korzyści można ustalić (na poziomie „minimalnej wykonalności”) lub dostosować. Zerowa
tolerancja musi obejmować dodatkowe koszty na wszystkich poziomach planu (Tabela
6.1).
c) Mimo że korzyści i ryzyka można dostosowywać, należy ustalić stałą „minimalną
wykonalność” w Uzasadnieniu Biznesowym (Tabela 6.1).
d) Zerowa tolerancja musi obejmować poziom określony jako „minimalna opłacalność”
w Uzasadnieniu Biznesowym – w tym przypadku jest to 10% wzrost sprzedaży.
Tolerancja może zostać wykorzystana powyżej poziomu określonego jako „minimalna
wykonalność” w Uzasadnieniu Biznesowym - w tym przypadku jest to dostosowanie
reklam telewizyjnych (Tabela 6.1).
– Dotrzymywanie terminów
a) Bogata komunikacja jest zachowaniem PRINCE2 Agile, które powinno być widoczne
w zespołach podczas projektu (7.4.3). Te kampanie pozwalają na bogatą komunikację
z potencjalnymi klientami. Jednakże nie wyjaśnia to, dlaczego Zespół ds. Marketingu
powinien dotrzymywać terminów (6.4.1).
b) Korzyści z dotrzymywania terminów obejmują: wczesną realizację korzyści, pewność
postępów i ograniczenie prawdopodobieństwa wystąpienia dodatkowych kosztów (6.4.1).
Korzyści te dadzą Komitetowi Sterującemu pewność co do opłacalności projektu.
c) Ograniczenie testowania jest wynikiem braku ochrony jakości (6.4.2), a nie
niedotrzymania terminów (6.4.1).
d) Współpraca jest zachowaniem PRINCE2 Agile, które powinno być widoczne w zespołach
podczas projektu. Skupienie na krytycznych wymaganiach nie warunkuje dobrej
współpracy – współpraca wymaga zmotywowanego i pełnego szacunku zespołu (7.4.2).
12
– Ochrona poziomu jakości
a) Częste wydania pozwalają na uzyskanie informacji zwrotnych oraz ograniczają ryzyko
dostawy nieodpowiedniego produktu (27.1). Jednakże nie wyjaśnia to potrzeby ochrony
jakości, która wpływa na finalny produkt (6.4.1).
b) Dostarczenie kampanii przed Międzynarodowym Festiwalem Sera polega na ukończeniu
pracy w terminie, którego nie można zmienić – dotrzymywanie terminów (6.4.1).
c) Narażenie poziomu jakości jakiegokolwiek elementu dostarczanego podczas projektu
może mieć różne formy, lecz wynika z niekompletnej dokumentacji, nieoptymalnego
projektu i nieprzestrzegania standardów. Tego typu kompromisu należy unikać, ponieważ
może prowadzić do nieodpowiedniego działania oraz braku kontaktu ze społecznością
użytkownika (6.4.2).
d) Minimum viable product (MVP) w wielu aspektach pokrywa się z poglądem Lean Startup,
który jest „końcową wersją produktu, która pozwala na maksymalne zdobywanie
potwierdzonych informacji przy jak najmniejszym wysiłku” (Glosariusz). Określone
kryterium akceptacji jest zorientowane na wynik - powinno już generować zainteresowanie
ze strony klientów (Tabela 23.1).
– Przyjmij zmianę
a) To, że zespół działał w oparciu o współpracę nie wyjaśnia, dlaczego zajęto się aspektem
– Przyjmij zmianę (7.4.2).
b) Koszty własności finalnego produktu są związane z kompromisami w poziomie jakości,
które wynikają ze zmniejszonej przydatności, zwiększonej potrzeby wsparcia, gorszego
działania i braku zaangażowania ze strony społeczności użytkownika (6.1.3).
c) Jest to związane z celem, który mówi, że projekt używający PRINCE2 Agile akceptuje
fakt, iż klient nie potrzebuje wszystkiego (Tabela 6.2 / 6.4.5).
d) Zmiana powinna być postrzegana jako coś pozytywnego, ponieważ prawdopodobnie
zaowocuje bardziej dokładnym produktem końcowym (Tabela 6.2 / 6.4.3).
13
25. Temat z sylabusa: 4.2 d)
– Stabilność zespołów
a)
b)
c)
d)
Ilość ról w zespołach będzie różnić się w zależności od potrzeb zespołu dostarczającego.
Jedna osoba może pełnić wiele ról (np. przewodzić zespołowi i szkolić go). Kilka osób
może pełnić jedną rolę (np. tworzyć produkt) (10.3.3).
Być może należy rozważyć koszty, ale ważniejsze jest rozważenie wpływu zwinnego
stylu pracy. Jest to związane z czasem szkolenia, wzrostem komunikacji, a zwłaszcza z
wpływem na zmianę dynamiki zespołu (6.4.4).
Może zaistnieć potrzeba, aby członkowie zespołu zmieniali się w czasie trwania projektu
w zależności od potrzeb wynikających ze zmiany projektu. Unikanie angażowania
dodatkowych osób, aby zwiększyć postępy, ma zastosowanie głównie w krótkiej
perspektywie – na przykład w ciągu czterech tygodni lub mniej, jak w przypadku sprintu
(6.4.4).
Chestertonowie prawdopodobnie także skorzystają na fakcie, że Brand-u-Like wie więcej
o ich działalności. Ważniejsze jest rozważenie wpływu podejścia zwinnego przy każdej
zmianie członka zespołu (6.4.4).
26. Temat z sylabusa: 4.2 e)
– Akceptacja, że klient nie potrzebuje wszystkiego
a)
b)
c)
d)
Projekt używający PRINCE2 Agile nie zakłada dostawy wszystkiego, ale jego celem jest
dotrzymanie terminów i ochrona poziomu jakości poprzez odpowiednią redukcję
dostarczanych produktów (6.4.5).
dostarczanych produktów (6.4.5).
dostarczanych produktów (6.4.5). Podczas etapu dostawy należy określić szczegółowe
wymagania za pomocą dekompozycji (Rysunek 25.1 i Tabela 25.2).
Współpraca jest jednym z zachowań PRINCE2 Agile, które powinno być obecne podczas
projektu (7.4.2). Jednakże nie wyjaśnia to, dlaczego klient nie potrzebuje wszystkiego
oraz że ważniejsza jest terminowa dostawa o odpowiedniej jakości (6.4.5).
14
Cel: LO5 - Jest w stanie zastosować lub dopasować pryncypia PRINCE2, tematy, procesy
i produkty zarządcze do projektu w kontekście zwinnego podejścia
a)
b)
c)
d)
Praca w zwinny sposób bardziej skupia się na tolerowaniu tego, co jest dostarczane,
i ograniczaniu tolerancji w zakresie czasu i kosztów (Tabela 7.1). Zatem czas nie zostałby
zwiększony; dopasowany zostałby zakres.
Praca w zwinny sposób bardziej skupia się na ustanowieniu tolerancji tego, co jest
dostarczane i ograniczaniu tolerancji w zakresie czasu i kosztów (Tabela 7.1).
Kluczowe jest nie tylko korzystanie z pryncypium zarządzania z wykorzystaniem tolerancji
oraz zapewnienie jej prawidłowego wdrożenia, lecz także dopilnowanie, aby
najważniejsza była samoorganizacja i kontrola przy odpowiednim poziomie zarządzania
podczas korzystania z PRINCE2 oraz podejścia zwinnego. Praca w zwinny sposób
bardziej skupia się na ustanowieniu tolerancji tego, co jest dostarczane i ograniczaniu
tolerancji w zakresie czasu i kosztów (Tabela 7.1).
Praca w zwinny sposób bardziej skupia się na ustanowieniu tolerancji tego, co jest
dostarczane i ograniczaniu tolerancji w zakresie czasu i kosztów (Tabela 7.1).
Uwzględnienie tyko jednej cechy w timeboxie pierwszym nie pozwala na elastyczność w
zakresie dostarczanych produktów, a zatem istnieje większe ryzyko przekroczenia
terminu.
Cel: LO5 - Jest w stanie zastosować lub dopasować pryncypia PRINCE2, tematy, procesy
i produkty zarządcze do projektu w kontekście zwinnego podejścia
a)
b)
c)
d)
Podejście zwinne ewoluowało na przestrzeni lat, a wiele osób zastąpiło kontrolę pracy
przy pomocy timeboxów (np. Scrum) systemami opartymi na przepływie poprzez
wykorzystanie Kanban (12.2). Scrum i Kanban inaczej podchodzą do planowania.
Można ustalić priorytety i dokonać dekompozycji Opisu Produktu, kryteriów jakości
oraz tolerancji jakości, aby umożliwić dopasowanie dostarczanych produktów, ułatwić
kontrolę oraz skupić się na dostarczaniu wartości (Tabela 7.1).
PRINCE2 oraz PRINCE2 Agile nie faworyzują jednych podejść zwinnych ponad inne
(czasem jest to określane mianem „agnostyki zwinnej”). Podejścia te, przy
odpowiedniej rozwadze, można połączyć z podejściem zwinnym, aby zapewnić
holistyczne zarządzanie projektem, które można dopasować do wielu warunków
środowiska pracy (2.1).
Celem retrospektywy jest poprawa skuteczności zespołu poprzez zmniejszenie ilości
błędów oraz zachęcanie do odpowiednich zachowań oraz praktyk, które nie skupiają
się na produktach (10.4.3).
15
a)
b)
c)
d)
Niektóre podejścia zwinne, np. Dynamic Systems Development Method (DSDM),
określają klika ról, które jasno definiują poziomy odpowiedzialności, podczas gdy inne,
np. Kanban, nie definiują ich wcale (10.2). Dodanie struktury zespołu zarządzania
projektem z PRINCE2 do zwinnych ról związanych z dostarczaniem tworzy bardzo
mocne połączenie (10.3).
Scrum Master jest rolą w Scrum, a nie w Kanban (10.2). Scrum Master może zostać
Kierownikiem zespołu, ale Zespół Web&Go stosuje podejście Kanban i nie mógłby być
kierowany przez Scrum Mastera.
Do ujęcia „pracy w toku (WIP)” powinna zostać wykorzystana Tablica Kanbanowa, a nie
wykresy organizacyjne (Rysunek 20.2).
Niektóre podejścia zwinne, np. DSDM, określają klika ról, które jasno definiują poziomy
odpowiedzialności, podczas gdy inne, np. Kanban, nie definiują ich wcale (10.2). Dodanie
struktury zespołu zarządzania projektem z PRINCE2 do zwinnych ról związanych
z dostarczaniem tworzy bardzo mocne połączenie (10.3).
a)
b)
c)
d)
Podejścia zwinne zazwyczaj wykorzystują empiryzm (wczorajsza pogoda) do
określenia pracy, a nie racjonalizm, w przypadku którego to logika służy do ustalania
założeń (12.2.1).
Kanban wykorzystuje czasy realizacji do ustalenia założeń (Rysunek 12.2). Czasy
realizacji określają, jak długo elementowi pracy zajmie przejście przez system
(Glosariusz).
Wszystkie podejścia zwinne preferują, aby planowanie odbyło się w ostatnim
możliwym momencie (inna nazwa to JIT lub Just in time planning) (12.2). Brak danych
z Etapu 2, które mogłyby posłużyć do dokonania oceny.
Plan zwinny skupia się na dostarczonych cechach, a nie na funkcjach etapów
technicznych, takich jak projektowanie, tworzenie i testowanie (12.2).
16
a)
b)
c)
d)
Jednym ze sposobów prezentacji Uzasadnienia Biznesowego jest opisanie najlepszych
i najgorszych scenariuszy, które odnoszą się do ilości cech planowanych do dostarczenia
(9.3).
Najlepszy scenariusz może odzwierciedlać wszystko, co jest planowane do dostarczenia.
Scenariusze te można obliczyć tylko przy użyciu wymagań wysokiego poziomu lub (być
może) średniego poziomu. Mało prawdopodobne jest bezpośrednie ukazanie
szczegółowych wymagań w Uzasadnieniu Biznesowym (9.3).
Komitetowi Sterującemu podczas oceny Uzasadnienia Biznesowego w kontekście
zwinnym może przydać się jasna informacja o tym, co jest oczekiwane w dostawie,
a zatem stworzenie prognozy, która opiera się na dwóch ekstremach, chociaż
niekoniecznie będzie to wartość pośrednia (9.3).
Scenariusze te można obliczyć tylko przy użyciu wymagań wysokiego poziomu lub (być
może) średniego poziomu. Mało prawdopodobne jest bezpośrednie ukazanie
szczegółowych wymagań w Uzasadnieniu Biznesowym (9.3).
a)
b)
c)
d)
Obecne tempo postępu można określić przy pomocy trendu tej linii (np. jej gradientu),
która pokazuje pozostały nakład pracy. W społeczności zwinnej jest to często określane
mianem „tempa”. Zakładając, że w zespole istnieje stabilność i spójność, można to
wykorzystać, aby przewidzieć, kiedy zakończy się praca, jak również aby określić, czy
odbędzie się w terminie (15.4.1).
Jedną z najpopularniejszych technik w społeczności zwinnej jest ukazanie postępów przy
pomocy linii na wykresie z osiami x i y. Wykresy te są określane mianem wykresów
spalania (15.4.1). Jednakże nie wyjaśnia to, dlaczego nie można ukończyć pracy
w ramach timeboxów.
Wykresy spalania służą do pokazania pozostałej pracy (15.4.1). Jednakże nie wyjaśnia
to, dlaczego nie można ukończyć pracy w ramach timeboxów.
Jedynym ograniczeniem wykresów spalania jest to, iż zakładana ilość pracy nie zmienia
się (15.4.1). Jednakże nie wyjaśnia to, dlaczego nie można ukończyć pracy w ramach
timeboxów.
17
a) Zebranie odpowiedniej ilości informacji oznacza, że należy przyjrzeć się wielu
obszarom, ponieważ mogą mieć wpływ na Uzasadnienie Biznesowe. Zazwyczaj może
to dotyczyć dokumentu, lecz także prezentacji twarzą w twarz. Większość z tych
informacji, jeśli nie wszystkie, można zobaczyć na ścianie pokoju zespołu, która
obejmuje wiele wizualizacji (17.3).
b) Zebranie odpowiedniej ilości informacji oznacza, że należy przyjrzeć się wielu
obejmuje wiele wizualizacji (17.3). Poprzez omówienie zagadnienia, ryzyk, kosztów
oraz korzyści każdego z pomysłów przedstawionych w pokoju narad z Komitetem
Sterującym.
c) Zebranie odpowiedniej ilości informacji oznacza, że należy przyjrzeć się wielu
d) Zebranie odpowiedniej ilości informacji oznacza, że należy przyjrzeć się wielu
a) Akceptacja użytkownika odbywałaby się regularnie, jednakże należy upewnić się, że
akceptacja użytkownika nie jest zbyt nieformalna podczas zamknięcia projektu, aby
zapewnić zgodność z oczekiwaniami jakościowymi oraz kryteriami akceptacji (22.3).
b) Ciągłe wykorzystanie „sprawdzania i dostosowania” oznaczałoby, że raporty
doświadczeń utworzono w trakcie projektu, a wiele doświadczeń już zostałoby
wprowadzonych i ocenionych podczas retrospektyw na poziomie projektu i dostarczania
(22.3).
c) Przekazania do użytku prawdopodobnie wydarzyły się wiele razy ze względu na
przyrostową naturę dostawy produktu, więc końcowe przekazanie powinno być
formalnością (22.3).
d) Szkolenie oraz dokumentacja techniczna zostałaby sfinalizowana (nie opracowana),
ponieważ elementy te byłyby tworzone iteracyjne i przyrostowo na przestrzeni projektu
(22.3).
18
a) Przygotowanie jest kluczowe w przypadku udanego warsztatu i może trwać tyle samo
co warsztat i powinno obejmować cele, uczestników oraz plan warsztatu (26.4.1).
Retrospektywa powinna być przeprowadzana według tych samych kroków co warsztat
(19.4.1). Jednakże nie wyjaśnia to, dlaczego Retrospektywa powinna skupiać się na
zastosowaniu kluczowych doświadczeń.
b) Retrospektywy obejmują przyjrzenie się przeszłym wydarzeniom oraz próbę oceny
wydarzeń pod kątem pracy zespołu, aby poprawić jego pracę w przyszłości (19.4.1).
c) Retrospektywy obejmują przyjrzenie się przeszłym wydarzeniom oraz próbę oceny
Objęłoby to zewnętrzne i wewnętrzne zespoły.
d) Retrospektywy obejmują przyjrzenie się przeszłym wydarzeniom oraz próbę oceny
Objęłoby to zewnętrzne i wewnętrzne zespoły.
a) Wykorzystanie limitów prac w toku (WIP) wzmacnia system typu „pull”, który
charakteryzuje sposób, w jaki Kanban unika planowania pracy w konkretnych
momentach (20.4.1.2). Projekt używający PRINCE2 Agile nie zakłada dostawy
wszystkiego, ale jego celem jest dotrzymanie terminów i ochrona poziomu jakości
poprzez odpowiednią redukcję dostarczanych produktów (6.4.5). Web&Go nie
powinno rozpoczynać zmiany zakresów elementów oznaczonych jako „Powinno być”.
b) Lean Startup polega na dostawie produktów w momencie, gdy istnieje niepewność.
Aby odnieść sukces, należy skupić się na nauce (20.4.2.2). Musi istnieć możliwość
zmierzenia procesu nauki (20.4.2.3). Zmierzenie ilości udanych żądań płatności
miałoby miejsce pod koniec tego timeboxu, a nie na początku.
c) Zwinne plany zwykle są nieformalne i mało skomplikowane technicznie na poziomie
dostawy (Tabela 23.1). Wykorzystanie limitów (WIP) wzmacnia system typu „pull”,
który charakteryzuje sposób, w jaki Kanban unika planowania pracy w konkretnych
momentach (20.4.1.2).
d) Kanban jest oparty na przepływie i limitach WIP (Rysunek 12.2). W związku z tym
praca nad trzecim wymaganiem nie powinna się rozpocząć.
19
Kanban, a nie Scrum, korzysta z czasów organizacji oraz limitów WIP, aby dostarczyć
pracę w ramach timeboxu (20.4.1.2).
b) Zespół IT korzysta z podejść zwinnych i będzie używać sprintu, a nie Kanban. W ramach
współpracy można zdefiniować jedną lub więcej Grup Zadań jako wynik spotkania
związanego z planowaniem sprintu. Ekspert merytoryczny klienta (SME klienta)
prawdopodobnie pomoże przy ustalaniu priorytetów pracy (Tabela 23.1).
c) Autoryzacja Grupy Zadań powinna zostać przeprowadzona wspólnie i powinna być
wynegocjowana przez Kierownika Projektu oraz Kierownika Zespołu, a także być może
przez zespół wytwórczy. Grupa Zadań może zawierać jeden lub więcej produktów, nie
trzeba zatem tworzyć trzech Grup Zadań dla dwutygodniowego sprintu (Tabela 23.1).
d) Autoryzacja Grupy Zadań powinna zostać przeprowadzona wspólnie i powinna być
wynegocjowana przez Kierownika Projektu oraz Kierownika Zespołu, a także być może
przez zespół wytwórczy. Grupa Zadań może zawierać jeden lub więcej produktów, nie
trzeba zatem tworzyć trzech Grup Zadań dla dwutygodniowego sprintu (Tabela 23.1).
a)
a) Opis ryzyka obejmuje przyczynę, niepewne zdarzenie i skutek ryzyka, lecz nie ocenia
przewidywanego wpływu (który zostałby oceniony przy pomocy standardowej skali)
(A.25.2).
b) Ryzyka określone przez zwinną ocenę ryzyka (Agilometer) można uwzględnić
w Rejestrze Ryzyk (Tabela 23.2).
c) Rejestr Ryzyk może być nieformalny i mało techniczny (Tabela 23.2). Może mieć
także bardziej formalną formę.
d) Charakter podejścia zwinnego łagodzi wiele ryzyk związanych z innymi podejściami
(13.2). Jednakże nie wszystkim ryzykom można zapobiec poprzez użycie podejścia
zwinnego, a mogą pojawić się także nowe ryzyka – dlatego przydatność podejścia
zwinnego należy oceniać w trakcie projektu (24.2). Ryzyka powinno się rejestrować
w Rejestrze Ryzyk, który może być nieformalny i mało techniczny (Tabela 23.2).
20
Cel: LO3 - Jest w stanie ocenić kluczowe obszary i zastosować je do projektu w kontekście
podejścia zwinnego – Agilometer
a)
b)
c)
d)
Działania zmierzające do zniesienia barier i stworzenia kultury jednego zespołu będą
miały wpływ na suwak „Poziom współpracy” (24.4).
Kopiowanie wiadomości e-mail obniży poziom współpracy i nie jest podejściem, które
poprawiłoby łatwość komunikacji. Należy promować nieformalną i mało techniczną
komunikację twarzą w twarz lub przez telefon (24.4 / 24.7).
Nowe cechy produktów można uwzględnić na liście z priorytetami, która nazywa się
Backlog Produktu. Jednakże rozmieszczenie każdego tygodnia nie jest związane
z zespołem i należy promować nieformalną oraz mało techniczną komunikację twarzą
w twarz lub przez telefon (2.2 / 24.4 / 24.7).
Wideokonferencja oraz planowanie zgodnie ze strefami czasowymi to sposób na
poprawienie sytuacji dotyczącej suwaka „Łatwość komunikacji”.
a)
b)
c)
d)
Suwak jest związany z zachowaniami, które tworzą kulturę jednego zespołu oraz
doskonałą współpracę zewnętrzną i wewnętrzną. Istnieje wysoki poziom zaufania oraz
chęć niesienia pomocy. Brak partnerstwa oraz „bagaż doświadczeń” związany z
przeszłymi wydarzeniami może wskazywać na przyczynę niskiego ustawienia tego
suwaka (22.7.2).
Suwak określa, czy komunikacja jest łatwa wśród wszystkich zaangażowanych stron.
Otoczenie ma bogatą komunikację, interakcje są twarzą w twarz, a informacje wizualne
są ogólnodostępne w takich formach jak prototypy i modele (24.7.3).
Ten suwak jest związany z łatwością, z jaką projekt jest w stanie zapewnić korzyść
klientowi poprzez regularne dostawy częściowe końcowego produktu (24.7.4).
Ten suwak jest związany z tym, czy ogólne środowisko pracy zachęca do zwinnych
metod pracy. Pracownicy pracują w pełnym wymiarze godzin, posiadają odpowiednie
umiejętności oraz bardzo skuteczną platformę pracy (24.7.5).
21
podejścia zwinnego – Wymagania
a)
b)
c)
d)
Opis Produktu Końcowego Projektu powinien skupiać się na tym, jak można określić
wynik projektu, aby w jego trakcie dopasować rezultaty i korzyści. Ekwiwalentnym
produktem zwinnym jest Wizja (Część 17.3 i Tabela 25.1).
Opisy Produktów zapewniają średni/niski poziom szczegółów i są tworzone na etapie
wstępnym, na odpowiednim poziomie szczegółów (a następnie ewoluują). Ogólne
wymagania dla Kierownika Obsługi linii produkcyjnej są na zbyt wysokim poziomie dla
Opisu Produktu (Tabela 25.1, Część 25.3, Tabela 25.2).
Historyjka użytkownika jest narzędziem używanym do zapisu wymagania w formie kto, co
i dlaczego. Historyjki użytkownika należy postrzegać jako podsumowanie kluczowych
informacji o wymaganiu. Ogólne wymagania dla Kierownika Obsługi linii produkcyjnej są
na zbyt wysokim poziomie dla Opisu Produktu (25.6.1).
Opowieść to historyjka „super-użytkownika” na wysokim poziomie, która z czasem
zostanie podzielona na historyjki użytkownika na poziomie szczegółowości, nad którymi
mogą pracować zespoły. Ogólne wymagania dla Kierownika Obsługi linii produkcyjnej są
na zbyt wysokim poziomie i stworzyłyby Opowieść (25.6.1).
a)
b)
c)
d)
Każda ważna zmiana, która może mieć wpływ na zestaw poziomów odniesień lub
poziom projektu, musi być zgłoszona do członka Komitetu Sterującego pełniącego rolę
Obsługi Zmian, jeśli została ustanowiona. Jednakże zespół najpierw powinien poszukać
sposobów na poradzenie sobie ze zmianą w sposób dynamiczny, na szczegółowym
poziomie i w ramach zdefiniowanych tolerancji (14.3).
Zmiana wymagań bez „handlowania” lub „wymiany” nie miałaby miejsca przy projekcie
zwinnym. Zespół powinien określić, które wymaganie/wymagania zostaną zmienione w
celu stworzenia przestrzeni dla nowego wymagania (25.5).
Inną techniką zmiany ilości wymaganego nakładu pracy dla elementów Musi być jest
bardziej szczegółowy podział wymagania. Jest to normalne dla wymagania wysokiego
poziomu, które posiada priorytet Musi być, aby podzielić je dalej na dodatkowe
wymagania Musi/Powinno/Może być, tworząc w ten sposób rezerwę (bufor) w postaci
Powinno być i Może być (25.5).
Po zatwierdzeniu Dokumentacji Inicjowania Projektu można ustawić zerową tolerancję
dla czasu i kosztów, w odniesieniu do nadwyżek, aby skupić się tylko na zarządzaniu
ilością dostarczanych elementów (9.3).
22
podejścia zwinnego – Komunikacja i umowy
a)
b)
c)
d)
Kiedy komunikacja obejmuje opinie i emocje, słowo pisane nie jest tak skuteczne jak
rozmowa telefoniczna lub komunikacja twarzą w twarz (26.3.2).
Wizualizacja stanowi idealne uzupełnienie dla komunikacji twarzą w twarz, ale
niekoniecznie można jej używać samodzielnie (26.3.1).
Warsztat jest dość ważnym wydarzeniem, które wymaga nakładu czasu i środków. Zatem
zawsze należy rozważyć, czy warsztat jest rzeczywiście potrzebny, czy też istnieje inny
sposób osiągnięcia celu (np. małe spotkanie) (26.4.1.5).
Jednym z najbardziej skutecznych sposobów komunikacji są jak najczęstsze spotkania
twarzą w twarz. Zespół powinien organizować się samodzielnie i podejmować własne
decyzje (26.3.1 / 10.2).
a)
b)
c)
d)
Jednym z celów obszaru skupienia na częstych wydaniach jest widoczne i poparte
dowodami upewnienie się co do postępów projektu. Jednakże byłoby to mniej przydatne
niż identyfikacja zagadnienia w związku z produktem końcowym (27.1).
Jednym z celów obszaru skupienia na częstych wydaniach jest umożliwienie uzyskania
informacji zwrotnej. Jednakże byłoby to mniej przydatne niż identyfikacja zagadnienia
w związku z produktem końcowym (27.1).
Jednym z celów obszaru skupienia na częstych wydaniach jest zmniejszenie ryzyka
dostawy nieprawidłowego produktu. Ważne byłoby określenie zagadnienia związanego z
faktem, iż ciężarówki nie są w stanie dojechać na miejsce (27.1).
Jednym z celów obszaru skupienia na częstych wydaniach jest umożliwienie uzyskania
informacji zwrotnej. Jednakże byłoby to mniej przydatne niż identyfikacja zagadnienia
w związku z produktem końcowym (27.1).
23
a)
b)
c)
d)
Zbyt wiele wymagań wskazuje na niskie ustawienie suwaka „Elastyczność dostawy”
(24.7).
Chęć pracy z wykorzystaniem podejścia kaskadowego wskazuje na niskie ustawienie
suwaka „Elastyczność dostawy” (24.7).
Znajomość technik zwinnych jest mała, wskazuje więc na niskie ustawienie suwaka
„Akceptacja zwinności (24.7).
Chęć stosowania częstych dostaw oraz rozpoczęcia przy niewielkim nakładzie środków
jest aspektem suwaka „Umiejętność pracy iteracyjnej i dostawy przyrostowej” (24.7).
a)
b)
c)
d)
Suwak „Poziom współpracy” odnosi się do kultury jednego zespołu w zespole projektu,
z partnerskim podejściem pomiędzy klientem i dostawcą (24.7.2 / 10.5.1.2).
Suwak „Łatwość komunikacji” odnosi się do wysokiego poziomu widoczności
i przejrzystości: np. plany na ścianach. Wiele informacji jest traktowanych w sposób
„mało techniczny” i/lub namacalny (24.7.3).
Suwak „Akceptacja zwinności” odnosi się to faktu, że wszyscy akceptują filozofię zwinną
i rozumieją, czym różni się ona od tradycyjnego podejścia do pracy. Ludzie zostali
przeszkoleni na odpowiednim poziomie (24.7.6).
Suwak „Poziom współpracy” odnosi się do ludzi, którzy pracują szybko, pomagają innym
i troszczą się o nich (24.7.2).
24
a)
b)
c)
d)
Kryteria jakości zostałyby dodane jako dokumentacja dodatkowa. Historyjka użytkownika
nie zawiera kryteriów jakości (25.6.1.7).
Korzyść musi być możliwa do zmierzenia. Cele nie są cechą historyjek użytkownika
(25.6.1.7).
„Niezależność” w mnemonice INVEST oznacza, że ktoś może pracować nad historyjką
użytkownika bez wpływania na pracę innej osoby i bez zależności ze strony innej osoby.
Odnosi się to do całej historyjki użytkownika, a nie do roli (25.6.1.3).
Istnieją trzy pola, które określają kto, co i dlaczego. Informacja jest celowo
niewystarczająca, aby doprowadzić do rozmowy z klientem (25.6.1.2).
a)
b)
c)
d)
Etap przed projektem powinien obejmować kluczowe cele projektu w formie
wypunktowanej – w miarę możliwości mniej niż 10 punktów (Tabela 25.2).
Etap inicjacji powinien obejmować wymagania na poziomie średnim – w miarę
możliwości więcej niż 10, ale mniej niż 100 (Tabela 25.2).
Etap dostarczania powinien obejmować wymagania na poziomie szczegółowym –
w miarę możliwości więcej niż 100. Proces wysyłki jest częścią całego projektu (Tabela
25.2).
Podany poziom jest szczegółowy, nawet jeśli stanowi tylko część projektu (Tabela 25.2).
25
a)
b)
c)
d)
Umożliwienie osiągnięcia korzyści dla klienta stanowi przewagę w zakresie częstej
dostawy. Posiadanie planu z oznaczeniami wspomoże dostawę, lecz nie przedstawi
korzyści dla klienta (27.1).
Zespół zwinny musi pracować dużo szybciej ze względu na iteracyjną i responsywną
naturę podejścia zwinnego. Dlatego podejście zwinne często wykorzystuje warsztaty,
spotkania twarzą w twarz, wizualizacje w formie modeli i prototypów, jak również filmy
(26.3.3).
Wymagania dla skomplikowanego elementu, np. dla linii produkcyjnej, będą potrzebować
informacji dodatkowych, takich jak historyjki użytkownika, bardziej szczegółowe
specyfikacje pisemne, rysunki lub modele. Model nie będzie wykorzystany do
udokumentowania szczegółowych wymagań (25.6.1 / 24.7).
Rozwój oparty na testach polega na pisaniu testów lub kontrolach jakości przed, a nie po
stworzeniu produktu lub sub-produktu. Dokonanie zaznaczeń przetestuje, czy linie
produkcyjne zmieszczą się, lecz bardziej stanowi przykład ulepszania wymagań (11.3.3).
a)
b)
c)
d)
Istnieje wiele zalet wynikających z częstych dostaw, np. umożliwienie osiągnięcia
korzyści klientowi, możliwość uzyskania informacji zwrotnej, redukcja ryzyka oraz
zachęcanie do pewności siebie i zaangażowania. Pomoc w zdefiniowaniu wymagań nie
jest dobrym powodem częstych dostaw (27.1).
Częste dostawy użytecznych elementów pozwalają na informacje zwrotne, redukują
ryzyko i generują korzyści (27.1).
Strategia częstej dostawy oraz sposobu jej planowania wymaga rozważenia, ponieważ
istnieje wiele kompromisów, które należy wziąć pod uwagę. Należy zaplanować
rozwiązanie problemów, dla których stosuje się podejście dostawy (27.1).
Ostatecznym celem są ciągłe wydania, jeśli pozwalają na to warunki, jak również jeśli
realizowane są korzyści. Strategia częstej dostawy oraz sposobu jej planowania wymaga
rozważenia, ponieważ istnieje wiele kompromisów, które należy wziąć pod uwagę (27.3 /
27.1).
26

Egzamin PRINCE2 Agile Klucz odpowiedzi Przykładowy arkusz 1

Transkrypt

Podobne dokumenty

Strona - Orylion

Gra strategiczna –zespół w projekcie

Harmonogram szkoleń dofinansowanych z EFS

Egzamin PRINCE2 Agile Przykładowy arkusz 1 Scenariusz

Trener

• Przygotowanie Projektu Zarządzanie Strategiczne projektem i

• Przygotowanie Projektu Zarządzanie Strategiczne projektem i

SĄD WYŻSZEJ INSTANCJI (HIGH COURT) Sygn. akt

Czy bardzo tanie szkolenie PRINCE2® może być