Quizz Końcowy

Trzy filary empiryzmu to:

• Planowanie, Inspekcja i Adaptacja

• Szacunek do ludzi, Kaizen, Eliminowanie strat

• Inspekcja, Przejrzystość, Adaptacja

• Przejrzystość, Eliminowanie strat, Kaizen

• Planowanie, Demo, Retrospektywa,

Scrum Team składa się z:

• Scrum Master

• Klienci

• Właściciel produktu

• Użytkownicy

• Developerzy

Jak definiujemy proces Scrumowy?

• Złożony

• Zdefiniowany

• Hybrydowy

• Empiryczny

Kto obowiązkowo musi być obecny na Scrum Daily

• Developerzy oraz Scrum Master

• Developerzy oraz Product Owner.

• Developerzy

• Zespół Scrumowy.

• Scrum Master oraz Product Owner.

Jaka jest najważniejsza korzyść z obecności Scrum Mastera na Daily?

• Upewnia się, że każdy członek zespołu odpowiada na 3 pytania

• Zbiera i raportuje do managementu informacje o statusie i postępie

• Nie musi tak być, jego zadaniem jest upewnienie się iż Daily się odbywa i ma właściwy cel

• Zapisuje każde zmiany w Sprint Backlogu oraz dodaje do niego nowe elementy, śledzi również postęp za pomocą burn-down

Podczas planowania sprintu Developrzy planują pracę, która będzie możliwa do dostarczenia w na koniec Sprintu. W czasie tego planowania biorą pod uwagę Definicje Ukończenia. Wszyscy muszą zdawać sobie sprawę że na koniec Sprintu konieczne jest dostarczenia Ukończonego przyrostu.

Co to znaczy że Przyrost jest Ukończony? (2 odpowiedzi)

• Jest możliwy do wydania i dostarczenia końcowym klientom

• Jest możliwy do przekazania Product Ownerowi do testów akceptacyjnych

• Jest możliwy do zintegrowania z innymi Przyrostami dostarczonymi przez inne zespoły

• Wszystkie punkty z Definicji ukończenia są ukończone

• Praca developerska jest ukończona i Przyrost może być testowany w następnym Sprincie

Jesteś Scrum Masterem zespołu Scrumowego zajmującego się produktem o wysokiej krytyczności i znaczeniu dla organizacji. Biorąc pod uwagę cały kontekst i historię prac, oczekuje się, że po produkcie pojawią się liczne opinie użytkowników i prośby o nowe funkcje lub zmiany w istniejących funkcjach.

Po długim oczekiwaniu, podczas przeglądu obecnego Sprintu, Właściciel Produktu decyduje, że produkt zostanie wydany użytkownikom końcowym. Obecni interesariusze proszą następnie, aby zespół deweloperski przestał pracować, aby działać szybciej w odniesieniu do informacji zwrotnych od użytkowników końcowych. Właściciel produktu jest przeciwny temu pomysłowi i chce, aby zespół programistów nadal pracował nad następną wersją, Jakie są dwa akceptowalne wyniki tej dyskusji?

• Zespół powinien kontynuować pracę i dołączać feedback użytkowników do Backlogu Produktu

• Zespół powinien przestać pracować i czekać na feedback aby działać szybciej w przypadku pilnego żądania

• Zespół powinien pracować ale w krótszych Sprintach by skrócić pętle feedbacku

• Zespół powinien pracować ale też dodawać pojawiające się żądania do Sprint Backlogu

Po dwóch miesiącach korzystania z nowego produktu kluczowy interesariusz kontaktuje się z właścicielem produktu i narzeka na wydajność oprogramowania. Właściciel produktu w pełni zgadza się z zarzutem kluczowego interesariusza.

Co możesz zrobić jako Scrum Master, aby pomóc w tej sytuacji?

• Zachęć Product Ownera by podzielił się uwagami z Developerami. Pracuj z nimi wspólnie nad poprawieniem wydajności oraz rozbudowaniem DOD o parametry związane z wydajnością

• Wyjaśnij Produkt Ownerowi że to w po stronie Developerów jest ocena czy parametry wydajnościowe są odpowiednie czy nie

• Nie rób nic od razu. Poczekaj na Retrospektywe Sprintu bo to najlepszy moment dla Zespołu Scrumowego by porozmawiać o DOD

• Zmuś Developerów by przygotowali i wykonywali lepsze testy wydajnościowe. Umieść te testy w DOD

Właśnie zostałeś zatrudniony jako Scrum Master w dużej organizacji IT, która używa Scruma do rozwijania swoich czterech głównych produktów. Pierwszego dnia pracy czujesz napięcie w powietrzu. Dowiadujesz się, że organizacja ma trudności z określeniem liczby właścicieli produktów potrzebnych do opracowania swoich czterech głównych produktów.

Jakie są dwie realne opcje?

• Powinno być tylu Product Ownerów ile potrzeba. W końcu Scrum to proces empiryczny pozwalający na dużą liczbe eksperymentów

• Powinien być jeden Product Owner do wszystkich produktów. Jeżeli zajdzie taka potrzeba może delegować swoje zadania.

• Powinno być 4 Product Ownerów - po jednym na każdy produkt. Jeżeli zajdzie potrzeba mogą oni delegować swoje zadania.

• Powinno być 4 Product Ownerów – po jednym na każdy produkt. Ale ponieważ Product to ich odpowiedzialność nie wolno im delegować swoich zadań na innych.

Samozarządzanie generuje kreatywność, umiejętności rozwiązywania konfliktów i poczucie odpowiedzialności.

• Prawda

• Fałsz