Przewodnik po Scrum

Cel Przewodnika po Scrum

Scruma opracowaliśmy na początku lat 90. W 2010 roku napisaliśmy pierwszą wersję Przewodnika po Scrum, aby pomóc ludziom na całym świecie zrozumieć Scrum. Od tego czasu rozwijało się ten przewodnik przez małe, funkcjonalne aktualizacje. Wspólnie za nim stoimy.

Przewodnik po Scrum zawiera definicję Scruma. Każdy element frameworka służy określonemu celowi, który jest niezbędny dla ogólnej wartości i wyników osiąganych dzięki Scrumowi. Zmiana podstawowego projektu lub idei Scruma, pomijanie elementów lub nieprzestrzeganie zasad Scruma zasłania problemy i ogranicza korzyści ze Scruma, a nawet może uczynić go bezsżitecznym.

Z pokorą obserwujemy rosnące zastosowanie Scruma w coraz bardziej złożonym świecie. Widzimy, jak Scrum jest przyjmowany w wielu dziedzinach wymagających złożonej pracy, wychodzących poza tworzenie oprogramowania, gdzie Scrum ma swoje korzenie. W miarę jak zastosowanie Scruma się poszerza, pracę tę wykonują programiści, badacze, analitycy, naukowcy i inni specjaliści. Używamy słowa „deweloperzy” w Scrumie nie po to, by kogoś wykluczyć, ale dla uproszczenia. Kto także świadczy czerpie wartość ze Scruma, uważaj siebie za uwzględnionego.

Podczas stosowania Scruma można odkrywać, stosować i opracowywać wzorce, procesy i spostrzeżenia pasujące do frameworka Scruma opisanego w tym dokumencie. Ich opis wykracza poza cel Przewodnika po Scrum, ponieważ są one zależne od kontekstu i różnią się znacznie w zależności od sposobu używania Scruma. Takie taktyki stosowania w ramach Scruma są bardzo różnorodne i opisane gdzie indziej.

Ken Schwaber & Jeff Sutherland, listopad 2020

Definicja Scruma

Scrum to lekki framework, który pomaga ludziom, zespołom i organizacjom generować wartość poprzez adaptacyjne rozwiązania złożonych problemów.

Krótko mówiąc, Scrum wymaga, aby Scrum Master tworzył środowisko, w którym:

• Product Owner porządkuje pracę nad złożonym problemem w Product Backlog.
• Scrum Team przekształca wybraną pracę w Increment wartości podczas Sprintu.
• Scrum Team i jego interesariusze sprawdzają wyniki i dostosowują je na następny Sprint.
• Powtórzaj

Scrum jest prosty. Wypróbuj go takim, jakim jest, i oceń, czy jego filozofia, teoria i struktura pomagają osiągać cele i tworzyć wartość. Framework Scruma jest celowo niekompletny – definiuje tylko części niezbędne do wdrożenia teorii Scruma. Scrum opiera się na zbiorowej inteligencji osób, które go stosują. Zamiast dostarczać ludziom szczegółowych instrukcji, zasady Scruma kierują ich relacjami i interakcjami.

W ramach frameworka można stosować różne procesy, techniki i metody. Scrum otacza istniejące praktyki lub sprawia, że stają się one zbędne. Scrum uwidacznia względną skuteczność obecnych technik zarządzania, środowiska i pracy, dzięki czemu można wprowadzać ulepszenia.

Teoria Scruma

Scrum jest oparty na empiryzmie i myśleniu Lean. Empiryzm głosi, że wiedza pochodzi z doświadczenia i że decyzje podejmuje się na podstawie obserwacji. Myślenie Lean redukuje marnotrawstwo i koncentruje się na tym, co istotne.

Scrum stosuje iteracyjne, przyrostowe podejście w celu optymalizacji przewidywalności i kontroli ryzyka. Scrum angażuje grupy ludzi, które wspólnie posiadają wszystkie umiejętności i wiedzę niezbędne do wykonywania pracy i dzielenia się nimi lub zdobywania ich w razie potrzeby.

Scrum łączy cztery formalne eventy inspekcji i adaptacji w ramach zawierającego je eventu – Sprintu. Te eventy działają, ponieważ wdrażają empiryczne filary Scruma: transparentność, inspekcję i adaptację.

Transparentność

Powstający proces i praca muszą być widoczne zarówno dla osób wykonujących pracę, jak i dla tych, którzy ją otrzymują. W Scrumie ważne decyzje opierają się na postrzeganym stanie jego trzech formalnych artefaktów. Artefakty o niskiej transparentności mogą prowadzić do decyzji, które obniżają wartość i zwiększają ryzyko.

Transparentność umożliwia inspekcję. Inspekcja bez transparentności jest myląca i nieefektywna.

Inspekcja

Artefakty Scruma i postępy w kierunku uzgodnionych celów muszą być często i starannie sprawdzane, aby wykryć potencjalnie niepożądane odchylenia lub problemy. Aby wespomec inspekcję, Scrum zapewnia rytm w postaci pięciu eventów.

Inspekcja umożliwia adaptację. Inspekcja bez adaptacji jest uważana za bezcelową. Eventy Scruma są zaprojektowane tak, aby wywoływać zmiany.

Adaptacja

Jeżeli jakiekolwiek aspekty procesu wykraczają poza akceptowalne granice lub jeśli produkt końcowy jest nie do przyjęcia, stosowany proces lub produkowane materiały muszą zostać dostosowane. Dostosowanie musi nastąpić jak najszybciej, aby zminimalizować dalsze odchylenia.

Adaptacja staje się trudniejsza, gdy osoby zaangażowane nie są upełnomocnione lub nie zarządzają sobą samodzielnie. Oczekuje się, że Scrum Team dostosuje się w momencie, gdy dowie się czegoś nowego poprzez inspekcję.

Wartości Scruma

Udane stosowanie Scruma zależy od tego, czy ludzie stają się coraz bardziej biegli w praktykowaniu pięciu wartości:

• Commitment (zaangażowanie)
• Focus (skupienie)
• Openness (otwartosc)
• Respect (szacunek)
• Courage (odwaga)

Scrum Team zobowiązuje się do osiągania swoich celów i wzajemnego wspierania się. Jego główne skupienie dotyczy pracy Sprintu, aby poczynić jak najlepszy postęp w kierunku tych celów. Scrum Team i jego interesariusze są otwarci na temat pracy i wyzwań. Członkowie Scrum Teamu szanują się nawzajem jako zdolne, niezależne osoby i są tak samo szanowani przez osoby, z którymi pracują. Członkowie Scrum Teamu mają odwagę robić właściwe rzeczy i pracować nad trudnymi problemami.

Te wartości nadają Scrum Teamowi kierunek w odniesieniu do jego pracy, działań i zachowań. Decyzje, kroki i sposób stosowania Scruma powinny wzmacniać te wartości, a nie je umniejszać lub podważać. Członkowie Scrum Teamu uczą się i odkrywają wartości podczas pracy z eventami i artefaktami Scruma. Gdy te wartości są uciełeśniane przez Scrum Team i osoby, z którymi współpracuje, empiryczne filary Scruma – transparentność, inspekcja i adaptacja – ożywają, budując zaufanie.

Scrum Team

Podstawową jednostką Scruma jest mały zespół ludzi – Scrum Team. Scrum Team składa się z jednego Scrum Mastera, jednego Product Ownera i Deweloperów. W Scrum Teamie nie ma podzespołów ani hierarchii. Jest to spójna jednostka profesjonalistów skupionych na jednym celu naraz – Celu Produktu.

Scrum Teamy są wielofunkcyjne, co oznacza, że członkowie mają wszystkie umiejętności niezbędne do tworzenia wartości w każdym Sprincie. Są również samoorganizujące się, co oznacza, że wewnętrznie decydują, kto co robi, kiedy i jak.

Scrum Team jest wystarczająco mały, żeby pozostać zwinnym, i wystarczająco duży, aby wykonać znaczącą pracę w Sprincie – zazwyczaj 10 osób lub mniej. Ogólnie rzecz biorąc, stwierdziliśmy, że mniejsze zespoły lepiej się komunikują i są bardziej produktywne. Jeśli Scrum Teamy stają się zbyt duże, powinny rozważyć reorganizację w kilka spójnych Scrum Teamów, z których każdy skupia się na tym samym produkcie. Dlatego powinny współdzielić ten sam Cel Produktu, Product Backlog i Product Ownera.

Scrum Team odpowiada za wszystkie działania związane z produktem: współpracę z interesariuszami, weryfikację, utrzymanie, obsługę, eksperymenty, badania i rozwój oraz wszystko inne, co może być wymagane. Jest zorganizowany i upełnomocniony przez organizację do zarządzania własną pracą. Praca w Sprintach w zrównoważonym tempie poprawia skupienie i spójność Scrum Teamu.

Cały Scrum Team odpowiada za tworzenie wartościowego, użytecznego Incrementu w każdym Sprincie. Scrum definiuje trzy konkretne zakresy odpowiedzialności w Scrum Teamie: Deweloperzy, Product Owner i Scrum Master.

Deweloperzy

Deweloperzy to osoby w Scrum Teamie, które są zaangażowane w tworzenie dowolnego aspektu użytecznego Incrementu w każdym Sprincie.

Konkretne umiejętności wymagane od Deweloperów są często szerokie i zmieniają się w zależności od dziedziny pracy. Jednak Deweloperzy zawsze odpowiadają za:

• Tworzenie planu Sprintu – Sprint Backlog;
• Zapewnienie jakości poprzez przestrzeganie Definicji Ukończenia (Definition of Done);
• Codzienne dostosowywanie planu w kierunku Celu Sprintu; oraz
• Wzajemne rozliczanie się jako profesjonaliści.

Product Owner

Product Owner odpowiada za maksymalizację wartości produktu wynikającej z pracy Scrum Teamu. Sposób jego działania może się znacznie różnić w zależności od organizacji, Scrum Teamów i osób.

Product Owner odpowiada również za efektywne zarządzanie Product Backlogiem, co obejmuje:

• Opracowywanie i wyraźne komunikowanie Celu Produktu;
• Tworzenie i jasne komunikowanie elementów Product Backlogu;
• Porządkowanie elementów Product Backlogu; oraz
• Zapewnianie, że Product Backlog jest transparentny, widoczny i zrozumiały.

Product Owner może wykonywać powyższe prace samodzielnie lub delegować odpowiedzialność innym. Niezależnie od tego Product Owner pozostaje odpowiedzialny.

Aby Product Ownerzy mogli odnieść sukces, cała organizacja musi szanować ich decyzje. Decyzje te są widoczne w treści i kolejności Product Backlogu oraz poprzez możliwy do inspekcji Increment na Sprint Review.

Product Owner to jedna osoba, a nie komitet. Product Owner może reprezentować potrzeby wielu interesariuszy w Product Backlogu. Ci, którzy chcą zmienić Product Backlog, mogą to zrobić, próbując przekonać Product Ownera.

Scrum Master

Scrum Master odpowiada za ustanowienie Scruma zgodnie z definicją w Przewodniku po Scrum. Robi to, pomagając wszystkim zrozumieć teorię i praktykę Scruma, zarówno w Scrum Teamie, jak i w organizacji.

Scrum Master odpowiada za skuteczność Scrum Teamu. Robi to, umożliwiając Scrum Teamowi doskonalenie praktyk w ramach frameworka Scrum.

Scrum Masterzy to prawdziwi liderzy służący Scrum Teamowi i większej organizacji. Scrum Master służy Scrum Teamowi na kilka sposobów, w tym:

• Coaching członków zespołu w zakresie samoorganizacji i wielofunkcyjności;
• Pomaganie Scrum Teamowi w skupieniu się na tworzeniu wysokowartościowych Incrementów spełniających Definicję Ukończenia;
• Powodowanie usuwania przeszkód w postępie Scrum Teamu; oraz
• Zapewnianie, że wszystkie eventy Scruma odbywają się i są pozytywne, produktywne oraz mieszczą się w określonym timebox.

Scrum Master służy Product Ownerowi na kilka sposobów, w tym:

• Pomaganie w znajdowaniu technik skutecznego definiowania Celu Produktu i zarządzania Product Backlogiem;
• Pomaganie Scrum Teamowi w zrozumieniu potrzeby jasnych i zwięzłych elementów Product Backlogu;
• Pomaganie w ustanowieniu empirycznego planowania produktu w złożonym środowisku; oraz
• Ułatwianie współpracy z interesariuszami na żądanie lub w razie potrzeby.

Scrum Master służy organizacji na kilka sposobów, w tym:

• Prowadzenie, szkolenie i coaching organizacji w zakresie przyjęcia Scruma;
• Planowanie i doradzanie w zakresie wdrożeń Scruma w organizacji;
• Pomaganie pracownikom i interesariuszom w rozumieniu i wdrażaniu empirycznego podejścia do złożonej pracy; oraz
• Usuwanie barier między interesariuszami a Scrum Teamami.

Eventy Scruma

Sprint jest kontenerem dla wszystkich innych eventów. Każdy event w Scrumie jest formalną okazją do inspekcji i adaptacji artefaktów Scruma. Te eventy są specjalnie zaprojektowane, aby umożliwić wymaaganą transparentność.

Nieprzeprowadzenie jakichkolwiek eventów zgodnie z zaleceniami skutkuje utratą możliwości inspekcji i adaptacji. Eventy są używane w Scrumie w celu tworzenia regularności i minimalizowania potrzeby spotkań niezdefiniowanych w Scrumie.

Optymalnie wszystkie eventy odbywają się w tym samym czasie i miejscu, aby ograniczyć złożoność.

Sprint

Sprinty to serce Scruma, gdzie pomysły są przekształcane w wartość.

Są to eventy o stałej długości jednego miesiąca lub krótszej, aby zapewnić spójność. Nowy Sprint zaczyna się natychmiast po zakończeniu poprzedniego Sprintu.

Wszelka praca niezbędna do osiągnięcia Celu Produktu, w tym Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective, odbywa się w ramach Sprintów.

W trakcie Sprintu:

• Nie wprowadza się zmian, które zagrażałyby Celowi Sprintu;
• Jakość nie maleje;
• Product Backlog jest udoskonalany w razie potrzeby; oraz
• Zakres może być wyjaśniany i ponownie negocjowany z Product Ownerem w miarę poznawania czegoś nowego.

Sprinty umożliwiają przewidywalność, zapewniając inspekcję i adaptację postępów w kierunku Celu Produktu co najmniej raz w miesiącu kalendarzowym. Gdy horyzont Sprintu jest zbyt długi, Cel Sprintu może stać się nieaktualny, złożoność może wzrosnąć, a ryzyko może się zwiększyć. Krótsze Sprinty mogą być stosowane, aby generować więcej cykli uczenia się i ograniczać ryzyko kosztów i wysiłku do mniejszego przedziału czasowego. Każdy Sprint może być traktowany jako krótki projekt.

Istnieją różne metody prognozowania postępów, takie jak wykresy burndown, burnup lub cumulative flow. Mimo że okazały się przydatne, nie zastępują one ważności empiryzmu. W złożonych środowiskach to, co się wydarzy, jest nieznane. Tylko to, co już nastąpiło, może być używane do podejmowania decyzji z wyprezdeniem.

Sprint może zostać anulowany, jeśli Cel Sprintu stanie się nieaktualny. Tylko Product Owner ma uprawnienia do anulowania Sprintu.

Sprint Planning

Sprint Planning inicjuje Sprint, określając pracę do wykonania podczas Sprintu. Plan ten jest tworzony przez wspólną pracę całego Scrum Teamu.

Product Owner zapewnia, że uczestnicy są przygotowani do omówienia najważniejszych elementów Product Backlogu i ich powiązania z Celem Produktu. Scrum Team może również zapraszać inne osoby na Sprint Planning w celu udzielenia porady.

Sprint Planning porusza następujące tematy:

Temat pierwszy: Dlaczego ten Sprint jest wartościowy?
Product Owner proponuje, w jaki sposób produkt może zwiększyć swoją wartość i użyteczność w bieżącym Sprincie. Następnie cały Scrum Team współpracuje, aby zdefiniować Cel Sprintu, który komunikuje, dlaczego Sprint jest wartościowy dla interesariuszy. Cel Sprintu musi zostać sfinalizowany przed końcem Sprint Planningu.

Temat drugi: Co można ukończyć w tym Sprincie?
Poprzez dyskusję z Product Ownerem Deweloperzy wybierają elementy z Product Backlogu do włączenia do bieżącego Sprintu. Scrum Team może udoskonalać te elementy podczas tego procesu, co zwiększa zrozumienie i pewność.

Wóber tego, ile można ukończyć w Sprincie, może być trudny. Jednak im więcej Deweloperzy wiedzą o swoich dotychczasowych wynikach, nadchodzącej pojemności i Definicji Ukończenia, tym bardziej pewni będą swoich prognoz Sprintu.

Temat trzeci: Jak wybrana praca zostanie wykonana?
Dla każdego wybranego elementu Product Backlogu Deweloperzy planują pracę niezbędną do stworzenia Incrementu spełniającego Definicję Ukończenia. Odbywa się to często poprzez rozbicie elementów Product Backlogu na mniejsze elementy pracy o długości jednego dnia lub krótszej. Sposób tego robienia jest wyłącznie w gestii Deweloperów. Nikt inny nie mówi im, jak przekształcać elementy Product Backlogu w Incrementy wartości.

Cel Sprintu, elementy Product Backlogu wybrane na Sprint oraz plan ich dostarczenia są łącznie określane jako Sprint Backlog.

Sprint Planning jest ograniczony czasowo do maksymalnie ośmiu godzin dla miesiącznego Sprintu. Dla krótszych Sprintów event jest zwykle krótszy.

Daily Scrum

Celem Daily Scrum jest inspekcja postępów w kierunku Celu Sprintu i adaptacja Sprint Backlogu w razie potrzeby, dostosowując nadchodzącą zaplanawaną pracę.

Daily Scrum to 15-minutowy event dla Deweloperów Scrum Teamu. Aby ograniczyć złożoność, jest organizowany o tej samej porze i w tym samym miejscu każdego dnia roboczego Sprintu. Jeśli Product Owner lub Scrum Master aktywnie pracują nad elementami Sprint Backlogu, uczestniczą jako Deweloperzy.

Deweloperzy mogą wybierać dowolne struktury i techniki, o ile ich Daily Scrum koncentruje się na postępach w kierunku Celu Sprintu i tworzy wykonalny plan na następny dzień pracy. Tworzy to skupienie i poprawia samoorganizację.

Daily Scrum poprawia komunikację, identyfikuje przeszkody, wspiera szybkie podejmowanie decyzji i w konsekwencji eliminuje potrzebę innych spotkań.

Daily Scrum nie jest jedynym momentem, w którym Deweloperzy mogą dostoswywać swój plan. Często spotykają się w ciągu dnia, aby przeprowadzić bardziej szczegółowe dyskusje na temat adaptacji lub ponownego planowania reszty pracy Sprintu.

Sprint Review

Celem Sprint Review jest inspekcja wyniku Sprintu i określenie przyszłych adaptacji. Scrum Team przedstawia wyniki swojej pracy kluczowym interesariuszom i omawia postępy w kierunku Celu Produktu.

Podczas eventu Scrum Team i interesariusze przeglądają to, co zostało osiągnięte w Sprincie i co zmieniło się w ich środowisku. Na podstawie tych informacji uczestnicy wspólnie ustalają, co robić dalej. Product Backlog może być również dostosowany w celu wykorzystania nowych możliwości. Sprint Review jest sesją roboczą, a Scrum Team powinien unikać ograniczania go do prezentacji.

Sprint Review jest przedostatnim eventem Sprintu i jest ograniczony czasowo do maksymalnie czterech godzin dla miesiącznego Sprintu. Dla krótszych Sprintów event jest zwykle krótszy.

Sprint Retrospective

Celem Sprint Retrospective jest planowanie sposobów zwiększenia jakości i skuteczności.

Scrum Team sprawdza, jak przebiegł ostatni Sprint w odniesieniu do osób, interakcji, procesów, narzędzi i Definicji Ukończenia. Sprawdzane elementy często różnią się w zależności od dziedziny pracy.

Założenia, które doprowadziły do błędnych wniosków, są identyfikowane i badane pod kątem ich przyczyn. Scrum Team omawia, co poszło dobrze podczas Sprintu, jakie problemy napotkał i jak te problemy zostały (lub nie zostały) rozwiązane.

Scrum Team identyfikuje najbardziej pomocne zmiany mające na celu poprawę skuteczności. Najważniejsze usprawnienia są realizowane jak najszybciej. Mogą nawet zostać dodane do Sprint Backlogu na następny Sprint.

Sprint Retrospective kończy Sprint. Jest ograniczona czasowo do maksymalnie trzech godzin dla miesiącznego Sprintu. Dla krótszych Sprintów event jest zwykle krótszy.

Artefakty Scruma

Artefakty Scruma reprezentują pracę lub wartość. Są zaprojektowane tak, aby maksymalizować transparentność kluczowych informacji. Dzięki temu każdy, kto je sprawdza, ma tę samą podstawę do adaptacji.

Każdy artefakt zawiera zobowiązanie (commitment), aby zapewnić dostarczanie informacji zwiększających transparentność i skupienie, dzięki którym można mierzyć postępy:

• Dla Product Backlogu jest to Cel Produktu.
• Dla Sprint Backlogu jest to Cel Sprintu.
• Dla Incrementu jest to Definicja Ukończenia.

Te zobowiązania istnieją po to, aby wzmacniać empiryzm i wartości Scruma dla Scrum Teamu i jego interesariuszy.

Product Backlog

Product Backlog to emergentna, uporzaadkowana lista tego, co jest potrzebne do ulepszenia produktu. Jest to jedyne źródło pracy podejmowanej przez Scrum Team.

Elementy Product Backlogu, które mogą zostać ukończone przez Scrum Team w jednym Sprincie, są uważane za gotowe do wyboru na evencie Sprint Planning. Zwykle osiągają ten stopień transparentności po czynnościach udoskonalania (refinementu). Udoskonalanie Product Backlogu to czynność polegająca na rozbijaniu i dalszym definiowaniu elementów Product Backlogu na mniejsze, bardziej precyzyjne elementy. Jest to ciągła czynność mająca na celu dodawanie szczegółów, takich jak opis, kolejność i rozmiar. Atrybuty często różnią się w zależności od dziedziny pracy.

Deweloperzy wykonujący pracę są odpowiedzialni za szacowanie. Product Owner może wpływać na Deweloperów, pomagając im zrozumieć i dokonywać kompromisów.

Zobowiązanie: Cel Produktu

Cel Produktu opisuje przyszły stan produktu, który może służyć jako cel Scrum Teamu w planowaniu. Cel Produktu znajduje się w Product Backlogu. Reszta Product Backlogu wyłania się, aby zdefiniować „co” spełni Cel Produktu.

Produkt to pojazd do dostarczania wartości. Ma wyraźne granice, znanych interesariuszy, dobrze zdefiniowanych użytkowników lub klientów. Produkt może być usługą, produktem fizycznym lub czymś bardziej abstrakcyjnym.

Cel Produktu jest długoterminowym celem Scrum Teamu. Musi on wypełnić (lub porzucić) jeden cel, zanim przejdzie do następnego.

Sprint Backlog

Sprint Backlog składa się z Celu Sprintu (dlaczego), zestawu elementów Product Backlogu wybranych na Sprint (co) oraz wykonalnego planu dostarczenia Incrementu (jak).

Sprint Backlog to plan stworzony przez Deweloperów i dla Deweloperów. Jest to wysoce widoczny, bieżący obraz pracy, którą Deweloperzy planują wykonać podczas Sprintu, aby osiągnąć Cel Sprintu.

W konsekwencji Sprint Backlog jest aktualizowany przez cały Sprint w miarę zdobywania wiedzy. Powinien zawierać wystarczającą ilość szczegółów, aby Deweloperzy mogli sprawdzać swoje postępy podczas Daily Scrum.

Zobowiązanie: Cel Sprintu

Cel Sprintu to jedyny cel Sprintu. Choć Cel Sprintu jest zobowiązaniem Deweloperów, zapewnia elastyczność w zakresie dokładnej pracy potrzebnej do jego osiągnięcia. Cel Sprintu tworzy również spójność i skupienie, zachęcając Scrum Team do wspólnej pracy, a nie do realizacji oddzielnych inicjatyw.

Cel Sprintu jest tworzony podczas eventu Sprint Planning, a następnie dodawany do Sprint Backlogu. Podczas pracy Deweloperów w trakcie Sprintu mają oni na uwadze Cel Sprintu. Jeśli okaże się, że praca jest inna niż oczekiwali, współpracują z Product Ownerem w celu negocjowania zakresu Sprint Backlogu w ramach Sprintu bez wpływu na Cel Sprintu.

Increment

Increment to konkretny krok w kierunku Celu Produktu. Każdy Increment jest addytywny do wszystkich poprzednich Incrementów i jest dokładnie zweryfikowany, zapewniając, że wszystkie Incrementy działają razem. Aby dostarczyć wartość, Increment musi być użyteczny.

W ramach Sprintu można stworzyć wiele Incrementów. Suma Incrementów jest prezentowana na Sprint Review, wspierając empiryzm. Increment może jednak zostać dostarczony interesariuszom przed końcem Sprintu. Sprint Review nigdy nie powinien być uważany za bramę do wydawania wartości.

Pracy nie można uważać za część Incrementu, dopóki nie spełni ona Definicji Ukończenia.

Zobowiązanie: Definicja Ukończenia

Definicja Ukończenia to formalny opis stanu Incrementu, gdy spełnia on miary jakości wymagane dla produktu.

W momencie, gdy element Product Backlogu spełni Definicję Ukończenia, rodzi się Increment.

Definicja Ukończenia tworzy transparentność, zapewniając wszystkim wspólne zrozumienie, jaka praca została ukończona jako część Incrementu. Jeśli element Product Backlogu nie spełnia Definicji Ukończenia, nie może być wydany ani nawet prezentowany na Sprint Review. Zamiast tego wraca do Product Backlogu do przyszłego rozważenia.

Jeśli Definicja Ukończenia dla Incrementu jest częścią standardów organizacji, wszystkie Scrum Teamy muszą jej przestrzegać jako minimum. Jeśli nie jest standardem organizacyjnym, Scrum Team musi stworzyć Definicję Ukończenia odpowiednią dla produktu.

Deweloperzy są zobowiązani do przestrzegania Definicji Ukończenia. Jeśli nad jednym produktem pracuje wiele Scrum Teamów, muszą one wspólnie zdefiniować i przestrzegać tej samej Definicji Ukończenia.

Uwaga końcowa

Scrum jest bezpłatny i oferowany w tym Przewodniku. Framework Scruma, jak opisano tutaj, jest niezmienny. Choć możliwe jest wdrożenie tylko części Scruma, wynik nie jest Scrumem. Scrum istnieje tylko w całości i sprawnie funkcjonuje jako kontener dla innych technik, metodologii i praktyk.

Podzękowania

Osoby
Spośród tysięcy osób, które przyczyniły się do Scruma, należy wyróżnić tych, którzy byli kluczowi na początku: Jeff Sutherland pracował z Jeffem McKenną i Johnem Scumniotalesem, a Ken Schwaber pracował z Mikem Smithem i Chrisem Martinem – i wszyscy współpracowali razem. Wielu innych wniosło swój wkład w kolejnych latach i bez ich pomocy Scrum nie byłby tak dopracowany jak dziś.

Historia Przewodnika po Scrum

Ken Schwaber i Jeff Sutherland po raz pierwszy wspólnie zaprezentowali Scrum na konferencji OOPSLA w 1995 roku. W zasadzie dokumentowała ona wiedzę, którą Ken i Jeff zdobyli przez poprzednie kilka lat, i publicznie udostępniała pierwszą formalną definicję Scruma.

Przewodnik po Scrum dokumentuje Scrum opracowany, rozwinięty i utrzymywany przez ponad 30 lat przez Jeffa Sutherlanda i Kena Schwabera. Inne źródła dostarczają wzorów, procesów i spostrzeżeń uzupełniających framework Scruma. Mogą one zwiększyć produktywność, wartość, kreatywność i zadowolenie z wyników.

Kompletna historia Scruma jest opisana gdzie indziej. Aby uhonorować pierwsze miejsca, w których był on testowany i sprawdzony, doceniamy Individual Inc., Newspage, Fidelity Investments i IDX (obecnie GE Medical).

© 2020 Ken Schwaber and Jeff Sutherland

This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.