Czym jest Scrum?

Scrum to uproszczone ramy postępowania (ang. framework), które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów.

Najprościej rzecz ujmując, Scrum wymaga, aby Scrum Master pomagał w tworzeniu środowiska, w którym:

1. Właściciel Produktu porządkuje pracę niezbędną do rozwiązania złożonego problemu, tworząc Rejestr Produktu.

2. Zespół Scrumowy przekształca wybraną część tej pracy w wartościowy Przyrost w trakcie Sprintu.

3. Zespół Scrumowy  oraz interesariusze sprawdzają efekty i dostosowują swoje działania na potrzeby kolejnego Sprintu.

4. Powtórz

Scrum jest prosty. Wypróbować go należy w takiej postaci, w jakiej został opisany oraz zweryfikować, czy jego filozofia, teoria oraz struktura pomogą ci w osiągnięciu celów i tworzeniu wartości. Scrum rozumiany jako ramy postępowania jest celowo niekompletny, definiuje jedynie elementy niezbędne do wdrożenia teorii Scruma. Scrum opiera się na zbiorowej wiedzy i inteligencji jego użytkowników. Zamiast dawać ludziom szczegółowe instrukcje, reguły Scruma pozwalają kształtować wzajemne relacje i interakcje.

W Scrumie można stosować różnorodne procesy, techniki i metody. Scrum obejmuje istniejące praktyki lub sprawia, że stają się one zbędne. Scrum uwidacznia w skuteczność dotychczasowego sposobu zarządzania, środowiska, technik pracy, aby umożliwiać wprowadzanie usprawnień.

Skąd pochodzi Scrum?

W 2001 roku w Salt Lake City grupa programistów kierowana przez inżyniera oprogramowania Kenta Becka spotkała się, aby podzielić się swoimi frustracjami związanymi z metodologiami i frameworkami dostarczania oprogramowania (PMI, CMMI lub SPICE). Rezultatem tego spotkania był Manifest Agile. W wyniku tej pracy, zaczęliśmy bardziej cenić:

• Ludzi i interakcje od procesów i narzędzi;
• Działające oprogramowanie od szczegółowej dokumentacji;
• Współpracę z klientem od negocjacji umów;
• Reagowanie na zmiany od realizacji założonego planu.

Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.

12 zasad manifestu Agile

Oprócz wspomnianych wcześniej 4 wartości, sygnatariusze Manifestu Agile podkreślili 12 zasad, które się z niego wywodzą i które są równie ważne:

• Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
• Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
• Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
• Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
• Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
• Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jestrozmowa twarzą w twarz.
• Działające oprogramowanie jest podstawową miarą postępu.
• Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
• Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
• Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.
• Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
• W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

Historia Scrum

Pierwsze wzmianki

Hirotaka Takeuchi i Ikujiro Nonaka wprowadzili termin Scrum do opracowywania produktów w swoim artykule z 1986 roku w Harvard Business Review zatytułowanym „The New Product Development Game”. W The Knowledge Creation Company, Takeuchi i Nonaka stwierdzili później, że jest to forma „organizacyjnego tworzenia wiedzy, szczególnie dobra w ciągłym, stopniowym i spiralnym wprowadzaniu innowacji”.

W oparciu o studia przypadków z firm produkcyjnych z branży motoryzacyjnej, kserokopiarek i drukarek, autorzy opisali nowe podejście do rozwoju produktów komercyjnych. Miało ono zwiększyć szybkość i elastyczność. Nazwali to podejściem holistycznym lub rugby. Bowiem cały proces jest wykonywany przez jeden wielofunkcyjny zespół w wielu nakładających się fazach. Zespół „próbuje pokonać dystans jako jednostka, podając piłkę tam i z powrotem”. (W grze rugby scrum jest formacją do wznowienia gry, ponieważ napastnicy każdej drużyny zbierają się ze spuszczonymi głowami i próbują przejąć piłkę.)

Ramy scrum zostały oparte na badaniach Schwabera z Babatunde Ogunnaike w Stacji Badawczej DuPont i na Uniwersytecie Delaware. Ogunnaike poinformował, że próby opracowania złożonych produktów, takich jak oprogramowanie, które nie byłyby oparte na empiryzmie, były skazane na wyższe ryzyko i możliwość niepowodznia w miarę zmiany początkowych warunków i założeń. Najwłaściwszym podejściem jest empiryzm, polegający na częstej inspekcji i adaptacji z zachowaniem elastyczności i przejrzystości.

Powstanie i rozwój frameworku

Na początku lat 90 Ken Schwaber używał tego, co stało się Scrumem, w jego firmie Advanced Development Methods. W tym samym czasie Jeff Sutherland, John Scumniotales i Jeff McKenna opracowali podobne podejście w Easel Corporation, odnosząc się do niego pojedynczym słowem Scrum.

Sutherland i Schwaber pracowali razem, aby zintegrować swoje pomysły w jeden framework, Scrum. Przetestowali Scrum i stale go ulepszali, co doprowadziło do ich artykułu z 1995 roku, wkładu do Manifestu na rzecz Agile Software Development w 2001 roku oraz rozpowszechnienia i używania Scrum na całym świecie od 2002 roku.

W 1995 roku Sutherland i Schwaber wspólnie przedstawili artykuł opisujący framework Scrum na warsztatach Business Object Design and Implementation Workshop. Odbyły się one w ramach Object-Oriented Programming, Systems, Languages ​​& Applications ’95 (OOPSLA ’95) w Austin w Teksasie. Przez kolejne lata Schwaber i Sutherland współpracowali. Starali się połączyć tę koncepcję ze swoim doświadczeniem i rozwijającą się dobrą praktyką. Efekt ich pracy, stał się znany jako Scrum.

W 2001 roku Schwaber współpracował z Mikiem Beedle, aby opisać metodę w książce Agile Software Development with Scrum. Podejście Scrum do planowania i zarządzania rozwojem produktu polega na doprowadzeniu władzy decyzyjnej do poziomu właściwości i pewników operacyjnych.

W 2002 roku Schwaber wraz z innymi założył Scrum Alliance i stworzył serię akredytacji Certified Scrum. Schwaber opuścił Scrum Alliance pod koniec 2009 roku i założył Scrum.org, który nadzoruje równoległą serię akredytacji Professional Scrum.

W 2009 roku dokument publiczny pod nazwą The Scrum Guide został opublikowany i zaktualizowany przez Schwabera i Sutherlanda. Jego aktualna wersja datowana jest na listopad 2020 roku.

Na czym opiera się Framework Scrum?

Ponieważ mieści się w zwinnych metodykach, Scrum opiera się na takich aspektach, jak:

• Elastyczność w dostosowywaniu się do zmian i nowych wymagań podczas złożonego projektu
• Czynnik ludzki
• Współpraca i interakcja z klientem
• Rozwój iteracyjny to sposób na zapewnienie dobrych wyników

Zalety frameworku Scrum

• Scrum jest łatwy do nauczenia: odpowiedzialności, spotkania i artefakty są przejrzyste i mają cel. Czyni go to sposobem pracy ściśle powiązanym z naszymi codziennymi przyzwyczajeniami.
• Klient może szybko rozpocząć użytkowanie produktu.
• Proces jest łatwiejszy w zarządzaniu, biorąc pod uwagę częste wydania.
• Mniejsza szansa na niespodzianki lub problemy, ponieważ klient często zapoznaje sie z projektem i ma szanse na przekazanie informacji zwrotnej.

Wady frameworku Scrum

• Chociaż Scrum jest łatwy do nauczenia, trudno go wdrożyć. Wymaga aktywnej postawy i zmiany kultury organizacyjnej, która przechodzi od menedżerów do klienta.
• Potrzeba posiadania interdyscyplinarnych zespołów może być problemem. Trudno jest bowiem znaleźć osoby, które są w stanie wykonać różne rodzaje pracy w zespole.
• Zespół może mieć tendencję do obierania najkrótszej ścieżki do osiągnięcia celów sprintu, co nie zawsze zapewnia wysokiej jakości wyniki.

Czym Scrum nie jest?

Wbrew obiegowej opinii nie jest to metoda zarządzania projektami. Zamiast tego jako projekt może być rozumiany tylko pojedynczy Sprint.

Scrum nie jest też nowym narzędziem do powodowania aby ludzie pracowali szybciej i dostarczali więcej. Chociaż Jeff Sutherland obiecuje wzrost wydajności, wymaga to zmian w procesach i usunięcia przeszkód. Samo wprowadzenie frameworku nie przyniesie takiego efektu.

Scrum nie są sposobem na terminowe dostarczanie wymagań, ani nie jest sposobem niezawodnego szacowania pracy. Zamiast tego koncentrujemy się na dostarczaniu wartości biznesowej i działającego, przydatnego produktu. Nie oznacza to, że wszystkie wymagania zostały wdrożone bez modyfikacji.

Scrum nie jest receptą na sukces ani srebrną kulą, która eliminuje wszelkie problemy. Zamiast tego Scrum sprawia, że wszystkie problemy będą bardziej widoczne, a poradzenie sobie z nimi zależy od organizacji.

Podsumowanie

Framework Scrum jest korzystny podczas pracy w wysoce niepewnych środowiskach, gdy istnieje duże prawdopodobieństwo, że w planie mogą zajść zmiany. Jeśli wymagania nie są precyzyjne i jeśli klient potrzebuje szybko wprowadzić produkt na rynek lub potrzebuje MVP, Scrum jest idealnym frameworkiem. Scrum pozwala nam dostarczać produkt w kolejnych działających i niezależnych częściach, w szybkim tempie i z możliwością korygowania błędów w danym momencie.

Ken Schwaber i Jeff Sutherland porównali Scrum do szachów. Nie ma on wielu zasad, ale możliwości grania w grę są nieskończone. Wprawdzie są pewne praktyki i sposoby grania, ale każda gra jest unikalna. Co innego – znać zasady, a co innego – wygrać. Nauka zasad jest bardzo prosta, ale aby zostać mistrzem, trzeba ciężko i regularnie ćwiczyć.