Scrum
Scrum jest jednym z najszybciej zdobywających popularność sposobów realizacji zwinnego (ang. agile) podejścia do produkcji oprogramowania. Jest prostym w zamyśle (lecz stosunkowo trudnym do wdrożenia) rozwiązaniem złożonych problemów związanych z produkcją oprogramowania (m.in. terminowości i zbieżności końcowego produktu z potrzebami klienta). Rozwiązaniem tak prostym, że jego twórcy na ogół nie nazywają go metodyką, paradygmatem czy nawet procesem, lecz metodą lub strukturą (framework) wokół której organizuje się praca zespołu. Struktura ta wyznaczona jest zestawem praktyk i zasad mających swoje korzenie w Lean Thinking, wspierających podstawowe elementy metod zwinnych czyli przyrostowy proces wytwórczy, adaptacyjność procesu i samoorganizację zespołu.
Scrum przełamuje utarte schematy, wyzwala kreatywność i innowacyjność w zespole, jednocześnie zapewniając solidne narzędzia kontroli przebiegu projektu. Umożliwia tworzenie i dostarczanie wysokiej jakości oprogramowania w krótkich odstępach czasu (zwykle co kilka tygodni). Scrum, podobnie jak inne zwinne metody, realizuje adaptacyjne podejście typu wizja–eksploracja, w odróżnieniu do podejścia tradycyjnego typu plan–wykonanie.
W kontekście produkcji oprogramowania wspomniana adaptacyjność odnosi się do ciągłego procesu analizy, dostosowywania i doskonalenia, dotyczącego w równej mierze tworzonego oprogramowania jak i stosowanych w procesie jego produkcji procedur i narzędzi. Takie podejście, oparte o cykle analizy i adaptacji umożliwiają pracownikom jak i kadrze kierowniczej ciągłą weryfikację planów projektowych na podstawie rzeczywistych danych. W metodzie Scrum podstawowym kryterium decyzyjnym są kolejne, działające (potencjalnie zbywalne) wersje produktu (oprogramowania).
Określenia samoorganizacja i samostanowienie, nierozłącznie związane z takim sposobem pracy, odnoszą się do struktury organizacyjnej zespołu tworzącego oprogramowanie i powierzonego mu zakresu odpowiedzialności. Niezbyt liczny, interdyscyplinarny (międzyfunkcjonalny) zespół zyskuje pełną swobodę decyzyjną w zakresie niezbędnym do wytworzenia wysokiej jakości produktu, w pełni spełniającego oczekiwania klienta, w tym wyboru stosowanych procedur i narzędzi. Zespół projektowy z założenia jest hiper-komunikatywny, a zasadą tą objęty jest również klient, bądź jego reprezentant, biorący aktywny udział w procesie wytwórczym. Dzięki ciągłemu dialogowi, analizie i dostosowywaniu, zarówno produkt jak i proces produkcji „wyłaniają się” z coraz lepszym przybliżeniem z każdym ukończonym cyklem produkcyjnym (iteracją). Samoorganizacja sprawdza się najlepiej w środowiskach o przejrzystych granicach odpowiedzialności, w których możliwe jest wytyczenie jasnych celów. Z tego powodu konieczny jest bliski kontakt z klientem i umiejętność delegowania obowiązków (odejście od nakazowo–rozdzielczego stylu zarządzania w kierunku modelu przywództwo–współpraca). Otwartość, szczerość i przejrzystość są w Scrumie najbardziej pożądanymi zachowaniami na wszystkich szczeblach hierarchii i pomiędzy wszystkimi osobami zaangażowanymi w produkcję.
Zastosowanie podejścia typu wizja–eksploracja do produkcji oprogramowania nie jest nowością. Od kilkudziesięciu lat znane i stosowane są narzędzia ułatwiające realizację złożonych projektów m.in. wiele wariantów modelu przyrostowego, model spiralny i prototypowanie. Jednakże zwinne metody (a szczególnie Scrum) w swoich założeniach idą o krok dalej, ustanawiając proces przyrostowy (iteracyjny i inkrementalny), adaptacyjność i samoorganizację fundamentem działania przedsiębiorstwa. To zmiana, której wiele organizacji nie może podołać, mimo iż jej wprowadzenie prowadzi (w dłuższym horyzoncie czasu) do radykalnego poprawienia zbieżności finalnego produktu z potrzebami (wymaganiami i oczekiwaniami) odbiorcy oprogramowania, redukcji kosztów, poprawy organizacji pracy, zwiększenia produktywności oraz zaangażowania pracowników i ich zadowolenia z wykonywanej pracy.
Choć w pierwszej chwili głęboka zmiana związana z wdrożeniem Scruma może wydawać się ryzykowna i kosztowna, organizacje odrzucające ciężkie, zdefiniowane procesy stają się automatycznie bardziej elastyczne i otwarte na zmienne realia rynkowe, zwiększając tym samym swoje szanse w walce z konkurencją. Natomiast organizacje wdrażające Scruma głównie jako narzędzie porządkujące chaos organizacyjny, obserwują obniżenie kosztów i zwiększoną efektywność pracy zespołów projektowych. Dla tych którzy dokonali przełomu i w pełni zaadaptowali Scruma i jego filozofię, tradycyjne sposoby prowadzenia projektów wydają się być niewyobrażalnym marnotrawstwem czasu i energii.
Charakteryzując Scrum w kilku punktach można powiedzieć, że:
- jest zwinnym (ang. agile) sposobem planowania i kontrolowania przebiegu prac projektowych
- jest iteracyjnym i inkrementalnym sposobem wytwarzania oprogramowania (szczególnie o wysokim stopniu złożoności i/lub ryzyka)
- jest narzędziem porządkującym i kontrolującym interesy osób zaangażowanych w realizację projektu
- jest narzędziem porządkującym komunikację i maksymalizującym stopień współpracy wewnątrz– i pozazespołowej
- jest sposobem zwiększenia produktywności zespołu
- nie wprowadza nowych i nie interferuje z już stosowanymi praktykami inżynierskimi (często stosowany jest w tandemie z eXtreme Programming; Scrum nie traktuje o praktykach inżynierskich, skupiając się na zagadnieniach związanych z organizacją pracy i zarządzaniem projektami)
- jest skalowalny od pojedynczych projektów do całych organizacji i przedsiębiorstw
Scrum jest terminem pochodzącym z rugby (polska nazwa tej formacji to „młyn”). Po raz pierwszy analogię do rugby i termin „scrum” w odniesieniu do procesów wytwórczych zastosowali akademicy japońscy Ikujiro Nonaka i Hirotaka Takeuchi w artykule „The New New Product Development Game” (Harvard Business Review 86116:137-146, 1986) opisując holistyczne (całościowe) procesy produkcyjne w firmach Fuji Xerox, Canon, Honda, NEC, Epson, 3M i Hewlett-Packard. Termin ten został przeniesiony na grunt produkcji oprogramowania przez Jeffa Sutherlanda, Johna Scumniotalesa and Jeffa McKenna w 1993. W 1995 roku Ken Schwaber przedstawił Scrum Development Process na konferencji OOPSLA.
W 2003 roku powołano do życia (inicjatywą Kena Schwabera, Mike'a Cohna i Esther Derby) organizację Scrum Alliance, która stawia sobie za cel zwiększanie świadomości o metodzie Scrum wśród osób związanych z produkcją oprogramowania oraz udostępnianie informacji (w postaci opracowań problemowych, studiów przypadku itp.) wspierających wdrażanie Scrum-a w organizacjach tworzących oprogramowanie. Jakkolwiek Scrum Alliance jest organizacją typu non-profit - nie są pobierane opłaty licencyjne za stosowanie metody Scrum, nie praktykuje się również audytowania organizacji wdrażających bądź stosujących Scrum a opłaty członkowskie przeznaczane są na rozwój lokalnych grup wsparcia metodyki - wprowadziła ona i aktywnie promuje model certyfikacyjny co do którego wielu entuzjastów lekkich metod produkcji oprogramowania pozostaje w jawnej opozycji oraz związany z nim cykl szkoleń certyfikacyjnych. Faktem jest, że pomimo iż Scrum Alliance wyznacza społeczności trenerskiej standardy co do zakresu materiału szkoleniowego, szkolenia certyfikacyjne różnią się dość znacznie pod względem zawartości merytorycznej i w dużej mierze bazują na osobistym dorobku i doświadczeniu trenerów.
W 2009 roku, Ken Schwaber – jeden z twórców metody – nie będąc w pełni usatysfakcjonowanym wysiłkami Scrum Alliance w propagację Scruma i utrzymanie wysokiego poziomu merytorycznego instruktorów, a także w odpowiedzi na zarzuty części społeczności dotyczące "szafowania" certyfikatami bez solidnej weryfikacji wiedzy nabytej podczas szkoleń, postanowił uruchomić własne przedsięwzięcie Scrum.org. Zostało ono oparte o powszechnie dostępny (aczkolwiek na swoich wyższych poziomach płatny) wielostopniowy egzamin sprawdzający w postaci testu wielokrotnego wyboru oraz zestaw szkoleń przygotowujących do tych egzaminów. Jakkolwiek sama metoda nie uległa zmianie, podstawowa wiedza o niej została uporządkowana pod postacią Przewodnika po metodzie Scrum (The Scrum Guide) autorstwa Kena Schwabera i Jeffa Sutherlanda, a wszyscy zainteresowani jej wykorzystaniem mogą teraz dokonać sprawdzenia swojej wiedzy poprzez przystąpienie do jednego z wielu dostępnych testów. Ze szczegółami modelu proponowanego przez Scrum.org można zapoznać się tutaj.
Bibliografia
- Schwaber Ken, Sutherland Jeff, "The Scrum Guide" - przewodnik po metodzie Scrum w języku polskim, 2010
- Schwaber Ken, Beedle Mike, "Agile Software Development with Scrum
, Prentice Hall, 2001
- Schwaber Ken, "Agile Project Management with Scrum
", Microsoft Press, 2004
- Schwaber Ken, "The Enterprise and Scrum
", Microsoft Press, 2007
- Wikipedia: Scrum - development
- Wikipedia: Software Development Process

Komentarze (0)