Scrum to ramy zarządzania projektami, która podkreśla pracę zespołową, odpowiedzialność i postępy iteracyjne w kierunku jasno określonych celów. Zaczyna się od prostego założenia: zacznij od tego, co możesz zobaczyć lub wiedzieć. Następnie śledź postępy i dostosuj, jeśli to konieczne.
Trzy filary Scrumu
Scrum opiera się na empiryzmie, który stwierdza, że wiedza pochodzi z doświadczenia, a decyzje powinny opierać się na tym, co jest znane. Te trzy filary łączą Scrum.
Dlaczego Scrum?
Scrum dostarcza funkcjonalności stopniowo, podczas gdy Waterfall dostarcza tylko w fazach. Tradycyjny model Waterfall to proces sekwencyjny, oparty na fazach, w którym wartość nie jest dostarczana, dopóki projekt się nie zakończy. Scrum przekształca ten model, dostarczając nowe funkcje co każdy sprint — zazwyczaj co 2–4 tygodnie — zamiast skupiać się na dużym wydaniu w przyszłości.
Scrum dzieli złożone zadania na zarządzalne fragmenty, dzieli duże organizacje na małe zespoły i przekształca istotne projekty w serię krótkich, ograniczonych czasowosprintów.
Poprzez rozwój iteracyjny i inkrementalny firmy mogą szybciej i efektywniej dostarczać produkty i usługi, których naprawdę potrzebują klienci. Poprzez Scrum możesz otrzymywać i integrować feedback klientów na końcu każdego sprintu, co oznacza, że Twoje wyniki są kształtowane przez rzeczywiste użycie, a nie założenia. To ułatwia utrzymywanie klientów i kluczowych stakeholderów aktywnie zaangażowanych.
Agile vs Scrum
Agile to praktyka, która umożliwia ciągłe iterowanie w procesie rozwoju i testowania przez cały cykl życia oprogramowania. Agile dzieli produkty na mniejsze, zarządzalne elementy.Scrum to tylko jedna z wielu iteracyjnych i inkrementalnych metod rozwoju oprogramowania Agile które pozwalają nam skupić się na dostarczaniu wartości biznesowej w jak najkrótszym czasie.
Scrum zwykle dotyczy wymagań, które mogą się zmieniać lub są nieznane na początku projektu. Scrum charakteryzuje się:
- Lekki
- Łatwy do zrozumienia
- Trudny do opanowania
Zalety Scrumu
Oto zalety, jakie Scrum przynosi organizacjom, zespołom, produktom i osobom:
- Lepsza jakość: Istnieje ramy do osiągnięcia wizji lub celów. Scrum zapewnia ciągłe feedback i przejrzystość, aby zapewnić jak najwyższą jakość. Scrum pomaga zapewnić jakość poprzez praktyki takie jak:
- Zmniejszony czas wypuszczenia na rynek: Scrum wykazał, że dostarcza wartość użytkownikom końcowym o 30%–40% szybciej niż metody tradycyjne.
- Wyższy zwrot inwestycji (ROI): Krótszy czas wypuszczenia na rynek to kluczowy powód, dla którego projekty Scrum osiągają wyższy ROI. Wczesne zyski i gromadzenie korzyści oznacza wyższe całkowite zwroty. Jest to oparte na podstawowym założeniu obliczeń wartości obecnej netto (NPV).
- Wyższe morale zespołu: Praca z szczęśliwymi, zaangażowanymi osobami jest satysfakcjonująca i produktywna. Samoorganizacja przekazuje decyzje, które zwykle podejmują menedżerzy lub organizacje, w ręceZespół Scrum członkowie.
- Silniejsza współpraca zespołu: Gdy zespoły Scrum przejmują projekt i produkt, mogą osiągnąć świetne wyniki. Zespoły Scrum współpracują i poprawiają jakość oraz efektywność projektu poprzez zwiększoną zaangażowanie i komunikację.
Framework Scrum
Scrum jest prosty. Nie jest to zbiór sztywnych, wzajemnie powiązanych nakazów. Scrum nie jest metodologią. Scrum oddaje zasadę naukową empiryzmu. Zastępuje proceduralne, algorytmiczne podejścia metodami heurystycznymi, szanując ludzi i samoorganizację, aby radzić sobie z niemożliwością przewidywania i rozwiązywać złożone problemy. Poniższy diagram przedstawia Scrum w działaniu, jak opisali to Ken Schwaber i Jeff Sutherland w swojej książce „Scrum: Sztuka wykonywania dwukrotnie więcej pracy w połowie czasu”, ilustrując podróż od planowania do dostarczenia oprogramowania.
Składniki procesu Scrum
Sam framework Scrum jest prosty. Określa tylko kilka ogólnych wytycznych, z małą liczbą zasad, role, artefakty, oraz zdarzenia. Jednak każdy z tych składników jest kluczowy dla określonych celów i niezbędny do skutecznego wykorzystania frameworku.
Główne składniki frameworku Scrum to:
- Role w Scrum: Scrum Master, Właściciel produktu, oraz zespół Scrum
- Artefakty: Backlog sprintu, Backlog produktu, Wykres spadku, logi, itd.
- Zdarzenia Scrum: Planowanie sprintu, przeglądy sprintu, Codzienna rozmowa Scrum, retrospektywa sprintu, itd.
- Sprinty
Poniższy diagram przedstawia kluczowe elementy frameworku Scrum. Proces został wizualizowany za pomocą Kanwa procesu Scrum z narzędzi Agile firmy Visual Paradigm.
Role w Scrum
Gdy organizacja przyjmuje Scrum, pierwszą rzeczą do zrozumienia jest to, jak role w Scrum różnią się od tradycyjnych ról w zarządzaniu projektami. Choć w Scrum jest tylko trzech głównych ról, nie muszą one automatycznie odpowiadać znanych tytułów zawodowych. Zaczniemy od krótkich definicji każdej z nich:
Właściciel produktu
Właściciel produktu to rola Scrum odpowiedzialna za reprezentowanie społeczności biznesowej lub użytkowników. Współpracuje wątliwie z użytkownikami w celu określenia funkcji w backlogu produktu. Kluczowe obowiązki obejmują:
- Określanie wizji i strategii produktu, w tym celów krótko- i długoterminowych;
- Dostarczanie lub zbieranie wiedzy na temat produktu lub usługi;
- Zrozumienie i przekazywanie potrzeb klientów do zespołu rozwojowego;
- Zbieranie, priorytetyzowanie i zarządzanie wymaganiami produktu lub usługi;
- Ponoszenie odpowiedzialności za budżetowanie produktu lub usługi, w tym rentowność;
- Określanie dat wydania produktu lub usługi;
- Odpowiadanie na pytania i podejmowanie decyzji codziennie wraz z zespołem rozwojowym;
- Zaakceptowanie lub odrzucenie zakończonej pracy z sprintu;
- Prezentowanie głównych wyników zespołu na końcu każdego sprintu;
- Zarządzanie backlogiem produktu.
Scrum Master
Scrum Master to koordynator zespołu rozwojowego Agile. Scrum pozwala zespołom na samodzielne organizowanie się i szybkie dostosowywanie się do zasad Agile. Scrum Master zarządza przepływem informacji. Kluczowe obowiązki:
- Bycie trenerem, który pomaga zespołowi przestrzegać wartości i praktyk Scrum;
- Pomaganie usuwać przeszkody i chronienie zespołu przed zewnętrznymi rozpraszającymi czynnikami;
- Zapewnianie dobrego współpracy między zespołem a stakeholderami;
- Promowanie zdrowego rozsądku i przejrzystości wewnątrz zespołu;
- Chronienie zespołu przed zakłóceniami organizacyjnymi.
Zespół Scrum
Zespół Scrum (znany również jako Zespół Rozwojowy) składa się z 3 do 9 członków, którzy wspólnie muszą posiadać wszystkie umiejętności techniczne potrzebne do dostarczenia produktu lub usługi. Są bezpośrednio kierowani przez Prowadzącego Scrum, ale nie zarządzane w tradycyjny sposób. Muszą być samodzielnie organizujące się, wielofunkcyjne i odpowiedzialne za ukończenie wszystkich wymaganych zadań.
Zespół rozwojowy odpowiada za dostarczenie potencjalnie gotowego do wysyłki przyrostu produktu na końcu każdego Sprintu – obejmującego analizę, projektowanie, rozwój, testowanie i pisanie techniczne. Ważne cechy zespołu Scrum to:
- Samodzielne organizowanie się: Wszyscy członkowie zespołu zarządzają własną pracą w celu ukończenia przypisanych zadań. W Scrum Agile nie ma lidera zespołu ani menedżera linii. Każdy musi zaangażować się wystarczająco, by prowadzić własne działania i przyczyniać się do sukcesu zespołu. Jeśli ktoś się nie uda, wszyscy się nie uda.
- Wielofunkcyjne: Wszyscy członkowie zespołu muszą posiadać wszystkie niezbędne wiedzę i umiejętności, aby dostarczyć produkt wysokiej jakości gotowy do wysyłki. Eksperci mogą być zaproszeni w celu doradztwa, ale tylko w celu przekazania wiedzy zespołowi w celu wypełnienia luk w kompetencjach.
- Właściciel Produktu wymaga wizji biznesowej: Właściciel Produktu reprezentuje głos klienta i musi przekształcić ich potrzeby w konkretne działania dla Prowadzącego Scrum i zespołu rozwojowego. Jest to zazwyczaj stanowisko pełnoetatowe.
- Prowadzący Scrum nie jest menedżerem linii: Pomagają wychować zespół rozwojowy i usuwają przeszkody, które utrudniają postępy.
Artefakty Scrum
Artefakty Scrum pomagają zdefiniować pracę wchodzącej do zespołu i aktualnie wykonywanej. Choć istnieje więcej artefaktów – takich jak historie użytkownika, listy wydań, wykresy spalania – tutaj skupiamy się na trzech podstawowych:
Listy produktu
Lista produktu to uporządkowana lista historii użytkownika reprezentujących funkcje, które zespół produktu potrzebuje lub oczekuje. Zazwyczaj jej utrzymuje Właściciel Produktu.
Sprintu
Lista Sprintu zawiera zestaw wybranych elementów do ukończenia w trakcie bieżącego Sprintu. Dwa kluczowe aspekty dotyczące relacji między Listą Sprintu a Listą Produktu:
1. Zespół decyduje, co dodać do Sprintu. Dlatego zespół posiada i odpowiada za dostarczenie tych elementów.
2. Przed przeniesieniem elementu z Listy Produktu do Listy Sprintu zespół musi upewnić się, że posiada wszystkie wymagane informacje. Zespół zazwyczaj tworzy listę kontrolną kryteriów, które muszą zostać spełnione, zanim element zostanie dodany.
Lista produktu w porównaniu do Listy Sprintu
Lista Sprintu to lista zadań, które zespół Scrum zobowiązuje się ukończyć w trakcie Sprintu. Podczas spotkania planowania Sprintu zespół zazwyczaj wybiera kilka elementów Listy Produktu w formie historii użytkownika i określa zadania potrzebne do ich ukończenia, jak pokazano poniżej:
Wykres spalania
Wykres spalania to graficzne przedstawienie pozostałej pracy w czasie. Pozostała praca (lub praca w kolejce) jest pokazywana na osi pionowej, a czas – na osi poziomej. Jest to ciągły wykres pracy do wykonania. Może służyć do przewidywania, kiedy cała praca zostanie ukończona. Jest powszechnie używany w metodach rozwoju oprogramowania Agile, takich jak Scrum, ale może być stosowany do każdego projektu z mierzalnym postępem w czasie. Pozostałą pracę można mierzyć w czasie lub w punktach historii.
Zdarzenia Scrum
Komunikacja to klucz! Scrum opiera się na przejrzystości we wszystkich aspektach (Pilier Scrum #1). Biorąc pod uwagę ten podstawowy zasadę, framework opiera się na szeregu kluczowych wydarzeń, aby zapewnić pozostałe dwa filary — Inspekcja i Adaptacja — jak pokazano w poniższej tabeli:
| Wydarzenie | Inspekcja | Adaptacja |
|---|---|---|
| Planowanie Sprintu |
|
|
| Codzienne Scrum |
|
|
| Recenzja Sprintu |
|
|
| Retrospektywa Sprintu |
|
|
Uwaga: Podczas każdego Sprintu w Scrum odbywa się pięć kluczowych spotkań, jak pokazano poniżej:
Planowanie Sprintu
Każdy Sprint zaczyna się od planowania. Zespół musi określić i zobowiązać się do tego, co zamierza dostarczyć w ramach Sprintu. Możliwe elementy są zawsze pobierane z Backlogu Sprintu, jak pokazano poniżej:
To jest miejsce, w którym Scrum Master może się wyróżnić. Product Owner określa, co jest potrzebne z perspektywy biznesowej/klienta, zespół Scrum decyduje, co uważa, że może dostarczyć, a Scrum Master zapewnia najlepsze dopasowanie dla obu stron.
Codzienny spotkanie Scrum
Po tym, jak zespół zobowiąże się do tego, co zamierza dostarczyć w ramach Sprintu, odbywa się codzienny stand-up. Głównym celem jest zapewnienie, aby każdy członek zespołu (i ewentualni obserwatorzy) całkowicie rozumiał stan i postępy pracy:
- Co zrobiłem wczoraj?
- Co zrobię dziś?
- Co mnie blokuje?
Ta codzienna aktualizacja zapewnia natychmiastową odpowiedź zespołowi. Spotkania są krótkie — nie dłużej niż 3 minuty na osobę.
Uwaga:Obserwatorzy są tam, by obserwować. Scrum Master musi minimalizować zewnętrzne i wewnętrzne rozpraszanie.
Spotkanie przeglądu Sprintu
Spotkanie przeglądu Sprintu lub demonstracja odbywa się na końcu Sprintu w celu sprawdzenia Incrementu. Zespół prezentuje Increment na podstawie Definicji Gotowości, skupiając się na celu Sprintu. Product Owner przegląda i akceptuje dostarczony Increment.
Retrospektywa Sprintu
Retrospektywa Sprintu to zazwyczaj ostatnia działalność w ramach Sprintu. Wiele zespołów przeprowadza ją od razu po spotkaniu przeglądu Sprintu. Cały zespół — w tym Scrum Master i Product Owner — powinien wziąć w niej udział. Jedno godzinne spotkanie zwykle wystarcza. To spotkanie pozwala zespołowi zastanowić się nad:
- Czego powinniśmy zacząć robić?
- Czego powinniśmy przestać robić?
- Czego powinniśmy kontynuować robić?
Celem jest ciągłe poprawianie efektywności zespołu.
Dostosowanie Backlogu
Wyobraź sobie Backlog Produktu jako mapę drogową projektu. W trakcie współpracy zespół tworzy i aktualizuje listę wszystkich elementów potrzebnych do zakończenia projektu, zapewniając spełnienie wszystkich wymaganych warunków.
Sprinty
W ramach frameworku Scrum wszystkie działania wymagane do wdrożenia elementu z Backlogu Produktu Scrum są wykonywane w ramach Sprintu (nazywanych również „Iteracjami”). Sprinty są zawsze krótkie — zazwyczaj 2 do 4 tygodni. Każdy Sprint podlega zdefiniowanemu procesowi, jak pokazano poniżej:
Jak zaznaczono, elementy w Backlogu Produktu są priorytetowe i wybierane do Backlogu Sprintu. Sprint zawiera tylko kilka głównych elementów — niedoszacowanie pracy dla jednego elementu może znacząco wpłynąć na Sprint. Ponieważ większe elementy są często trudniejsze do oszacowania i zrozumienia, ryzyko niepowodzenia Sprintu rośnie. Doświadczeni zespoły Scrum poświęcają czas i wysiłek na rozkładanie złożonych lub dużych elementów (np. funkcji użytkownika lub Epików) na mniejsze historie użytkownika (lub dalej na zadania lub podzadania).
Epik
Epik reprezentuje dużą ilość pracy. Jest zasadniczo „dużą historią użytkownika”, którą można podzielić na wiele mniejszych historii. Zakończenie Epiku może trwać kilka Sprintów. Dlatego, gdy używamy Epików w rozwoju, muszą one zostać rozłożone na mniejsze historie użytkownika.
Epiki są wprowadzane na wczesnym etapie cyklu projektu. Są to punkty funkcjonalne na wysokim poziomie, niemalże skupione na marketingu.
Nazywamy duże historie „Epikami”, aby oddać ich skalę. Wyobraź sobie to jak film. Jeśli powiem Ci, że film to „akcja-przygoda”, już wiesz, czego możesz się spodziewać — może prześlizgiwanie się, strzelanina itp. Podobnie oznaczenie historii jako „Epiku” czasem może przekazywać dodatkowy kontekst.
Historia użytkownika
Historia użytkownika to krótkie stwierdzenie wymagania produktu lub przypadku biznesowego. Zazwyczaj jest pisana prostym językiem, aby pomóc czytelnikom zrozumieć, co ma robić oprogramowanie. Product Owner tworzy historię. Następnie członkowie zespołu Scrum dzielą historię na jedno lub więcej zadań Scrum.
Historie użytkownika to zazwyczaj funkcje widoczne dla końcowego użytkownika. Są one zapisywane w formacie: „Chcę [zrobić coś], aby [można było osiągnąć cel]”. Dają wartość klientowi/użytkownikowi. Jest to wymóg produktu klienta.
Przykład: „Jako klient, chcę utworzyć konto, aby móc zobaczyć swoje zakupy z ubiegłego roku i pomóc mi w planowaniu budżetu w przyszłym roku.”
Zadanie
W przeciwieństwie do tego, zadanie jest bardziej techniczne. Zadania często obejmują kod, projektowanie, tworzenie danych testowych, automatyzację itp. Są to zazwyczaj indywidualne obowiązki. Zadania nie są zapisywane w formacie historii użytkownika. Są bardziej techniczne.
Przykład: „Oceń kąt interfejsu użytkownika przy użyciu Material Design” lub „Zgłoś aplikację do App Store.”
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish