Marta Żuchewicz
Transkrypt
Marta Żuchewicz
Scrum - iteracyjna i inkrementalna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile. W metodyce tej rozwój produktu podzielony jest na mniejsze, trwające od tygodnia do miesiąca, iteracje zwane sprintami następującymi bezpośrednio po sobie. Po każdym sprincie zespół pracujący nad rozwojem produktu jest w stanie dostarczyć działającą wersję produktu. Scrum jest często stosowany podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej dziedziny. Ogólne założenia metodyki zostały zaprezentowane przez Hirotaka Takeuchi i Ikujiro Nonaka w artykule The New Product Development Game, opublikowanym w Harvard Business Review w styczniu 1986 roku. Pełna metodyka oraz definicja została sformalizowana przez Kena Schwabera w 1986. OGÓLNE ZASADY Zespół pracuje w określonym przedziale czasowym zwanym przebiegiem (ang. sprint). Efektem przebiegu za każdym razem powinno być dostarczenie użytkownikom kolejnej działającej wersji produktu. Zasadą jest to, że zmiany wprowadzane w jednym przebiegu muszą być namacalne dla użytkowników. Muszą wnosić wartość funkcjonalną. Przebieg może trwać od 1 do 4 tygodni. Zaleca się stosowanie przebiegów o stałych długościach. Na początku pracy nad produktem zbierana jest lista wymagań użytkownika, są one przeważnie gromadzone w postaci "historyjek" (ang. User Stories). Każda historyjka opisuje jedną cechę systemu. Właściciel produktu (ang. Product Owner) jest też zobowiązany do przedstawienia priorytetu wymagań oraz głównego celu pierwszego przebiegu. Po tym formułowany jest rejestr wymagań (ang. Product Backlog). Cel przebiegu jest zapisywany w widocznym miejscu w pokoju członków zespołu. Następnie podczas planowania przebiegu (ang. Sprint Planning) wybierane są zadania o najwyższym priorytecie, a jednocześnie przyczyniające się do realizacji celu przebiegu. Szacuje się czas realizacji, pracochłonność, złożoność i ryzyko każdego zadania. Lista zadań wraz z oszacowaną czasochłonnością nosi nazwę rejestru zadań przebiegu (ang. Sprint Backlog). Po planowaniu zespół przechodzi do realizacji przebiegu. W jego trakcie właściciel produktu powinien cały czas pracować z zespołem nad jak najlepszym zrozumieniem wymagań nie ingerując jednocześnie w sposób ich implementacji. Nie powinno się także zmieniać zakresu sprintu. Jako że zespół z założenia jest samoorganizującym się ciałem, nie ma mowy o odgórnym przypisywaniu zadań do poszczególnych członków zespołu, lecz samodzielnie dokonują oni wyboru realizowanych zadań, według wspólnych ustaleń, umiejętności czy innych preferencji. Naczelną zasadą metody jest przeprowadzanie codziennych (maksymalnie 15minutowych) spotkań (ang. Daily Scrum), na których omawiane są zadania zrealizowane poprzedniego dnia, problemy występujące przy ich realizacji oraz zadania do wykonania w dniu spotkania. Sprint kończy się spotkaniem będącym przeglądem przebiegu (ang. Sprint Review), na którym prezentowany jest wynik pracy zespołu, poprzez prezentowanie produktu wykonanego podczas przebiegu. Powinni w nim uczestniczyć wszyscy zainteresowani projektem. Na spotkaniu każdy członek zespołu może zabrać głos i wyrazić opinię o produkcie. Po omówieniu produktu ustalany jest termin spotkania planistycznego do następnego przebiegu. Metodyka skupia się na: dostarczaniu kolejnych, coraz bardziej dopracowanych wyników projektu, włączaniu się przyszłych użytkowników w proces wytwórczy, samoorganizacji zespołu projektowego. ZESPÓŁ Zazwyczaj zespół Scrum składa się z od 3 do 9 osób. Dobrze, gdy ma charakter interdyscyplinarny i składa się z osób reprezentujących różne umiejętności. Osoby uczestniczące w zespole nie mogą uczestniczyć w innych zespołach. Główne role w projekcie grają: "Mistrz Młyna" (ang. Scrum Master), właściciel produktu (ang. Product Owner) i członkowie zespołu (ang. Development Team). Role główne: Zespół - grupa osób, składająca się od trzech do dziewięciu osób, odpowiedzialna za dostarczenie produktu Właściciel produktu - osoba reprezentująca klienta. Właściciel produktu może być członkiem zespołu, jednak nie jest zalecane, aby jednocześnie był Scrum Masterem Scrum Master - osoba odpowiedzialna za usuwanie wszelkich przeszkód uniemożliwiających zespołowi wykonanie zadania, oraz za poprawną implementację procesu i metod. WARTOŚCI W SCRUMIE Scrum to inaczej proces o niepowtarzającym się przebiegu, szkielet dla reguł, ról i zasad, które pomagają indywidualnym osobom i organizacjom stworzyć swój własny proces, odpowiadający ich konkretnym potrzebom. Scrum tworzy prostą podstawę działania, która zastępuje dotychczasowe procesy rozwoju produktu. Korzyści płynące ze Scruma są większe, jeżeli uzupełni się je o usprawnione lub zmienione praktyki w zakresie wytwarzania, zarządzania produktem, pracy zespołu czy funkcjonowania organizacji. Zmiana podstawowych założeń Scruma i nieprzestrzeganie jego reguł zatuszuje natomiast problemy i ograniczy, a nawet wyeliminuje, korzyści płynące z podejmowania dodatkowych działań. Fakt, że podstawowe wartości Scruma są mało znane i prawdopodobnie za słabo podkreślane, wcale nie oznacza, że należy je pomijać. Mimo że nie zostały one opracowane specjalnie na potrzeby Scruma i na jego wyłączny użytek, to jednak nadają one kierunek pracy i wpływają na zachowania i działania. Podejmowane decyzje i kroki, sposób realizacji procesu, poszerzanie Scruma o dodatkowe zadania, a także wszelkie czynności powinny przyczyniać się do wzmacniania tych wartości, a nie je umniejszać czy podważać. Zaangażowanie Odwaga Skupienie SCRUM Szacunek Otwartość Nawiązywanie do wartości w celu oceny wartości dodanej działań okazuje się niezwykle przydatne. Stanowią one pomoc już na etapie samego rozważania, czy zastosować reguły Scruma, czy nie. Oto szczegółowe spojrzenie na wartości i na to, jak mogą one pokierować krokami i zachowaniem w kontekście Scruma: ZAANGAŻOWANIE Zaangażowanie w kontekście Scruma jest powszechnie źle interpretowane. Bierze się to stąd, że kiedyś oczekiwano od zespołów scrumowych zobowiązania się do zrealizowania celu danego sprintu i wybranych elementów z rejestru produktu. Z powodu przestarzałego, przemysłowego sposobu myślenia (które niestety zbyt długo pokutowało w obszarach związanych z wytwarzaniem oprogramowania) oczekiwano dostarczenia całości za wszelką cenę. „Zobowiązanie” zostało uznane za sztywny wymóg, choć miało ono znaczyć tylko tyle, że zespół będzie maksymalnie przykładał się do swojej pracy w sprincie i dostarczał przejrzystych informacji co do postępu prac. Zresztą w złożonym, kreatywnym i nieprzewidywalnym świecie wytwarzania oprogramowania jakiekolwiek zobowiązania odnośnie zakresu prac są po prostu niemożliwe. Definicja słowa podana przez Oxford Dictionaries najlepiej oddaje jego „scrumowe” pierwotne znaczenie: Zaangażowanie – stan lub cecha bycia oddanym jakiejś sprawie, działaniu, etc. A zatem poprzez „zaangażowanie” należy rozumieć aktywne uczestnictwo odnoszące się do podejmowanych działań i włożonego wysiłku, a nie ostatecznego produktu. W Scrum Guide zastąpiono słowo „zaangażowanie”, wynikające z planowania sprintu, hasłem „prognoza”. Dzięki powiązaniu prognozy z zakresem prac unika się błędnej interpretacji. Dodatkowo świetnie współgra ona z faktyczną naturą Scruma. Zaangażowanie wciąż pozostanie jednak jedną z kluczowych wartości. Członkowie zespołu angażują się: w pracę zespołu, w podnoszenie jakości, we współpracę, w uczenie się nowych rzeczy starają się wykrzesać wszystkie siły, by każdego dnia dawać z siebie wszystko by osiągnąć cel sprintu i by działać profesjonalnie w samo-organizację, dążenie do doskonałości i przestrzeganie zwinnych wartości by stworzyć działające oprogramowanie w poszukiwanie ulepszeń i przestrzeganie reguł Scruma by spełnić definicję ukończenia, by działać zgodnie z wartościami i ukończyć pracę w badanie rzeczywistości i dostosowywanie się do niej dążąc do przejrzystości. SKUPIENIE SIĘ NA NAJWAŻNIEJSZYM Charakterystyczna w Scrumie praca w iteracjach, polegająca na dostarczaniu kolejnych przyrostów, i narzucone ramy czasowe pracy pomagają się skoncentrować. Członkowie zespołów skupiają się na: tym, co istotne tu i teraz, bez zastanawiania się na tym, co może stać się ważne za jakiś czas tym, co wiedzą w danej chwili bez analizowania zbędnych alternatyw najbliższej przyszłości, ponieważ ta dalsza jest zbyt niepewna, a chcą uczyć się dziś, aby zdobyć doświadczenie niezbędne do przyszłych zadań pracy, by wykonać to, co do nich należy najprostszych rzeczach, które mogą zadziałać. OTWARTOŚĆ Scrum wymaga przejrzystości i otwartości dlatego członkowie zespołów powinni być otwarci na: badanie rzeczywistości, aby móc się do niej przystosować w rozsądny sposób krytykę, uwagi dotyczące ich pracy, dokonywanych postępów, sposobu uczenia się i napotykanych problemów ludzi i współpracę z nimi, postrzeganie innych jako rzeczywiste osoby, a nie zasoby, roboty czy części większej machiny, które łatwo zastąpić – ostatecznie tworzenie oprogramowania nadal pozostaje domeną człowieka współpracę ze specjalistami z różnych dziedzin, posiadającymi różne umiejętności współpracę z interesariuszami i szerszym otoczeniem wzajemne uczenie się zmianę, gdyż organizacja i rzeczywistość, w której funkcjonują, zmienia się ciągle w sposób nagły i trudny do przewidzenia. SZACUNEK Członkowie zespołów powinni okazywać szacunek: ludziom, ich doświadczeniu i pochodzeniu różnorodności, która sprawia, że stają się silniejsi odmiennym zdaniom, które pozwalają im się uczyć sponsorom, nie tworząc funkcjonalności, z których i tak nikt nie będzie korzystał poprzez nie marnowanie środków na coś, co jest nic niewarte lub nigdy nie będzie wdrożone czy wykorzystane użytkownikom, rozwiązując ich problemy poprzez przestrzeganie zasad, którymi kieruje się Scrum otoczeniu, nie zachowując się jak samotna wyspa umiejętnościom, specjalistycznej wiedzy i intuicji innych poprzez akceptację podziału ról w Scrumie. ODWAGA Zespoły scrum’owe charakteryzują się odwagą: by nie tworzyć czegoś, czego nikt nie chce przyznawania, że wymagania nigdy nie będą idealne oraz, że nawet najlepszy plan nie uwzględni w pełni rzeczywistości i stopnia jej złożoności by traktować zmianę jako źródło inspiracji i motywacji by nie dostarczać oprogramowania, które nie jest skończone by dzielić się wszystkimi informacjami (przejrzystość), które mogą pomóc zespołowi i organizacji przyznawania, że nikt nie jest doskonały zmiany obranego kierunku by informować się nawzajem o ryzyku i korzyściach promowania Scruma oraz podejścia w procesie radzenia sobie ze skomplikowanymi zadaniami by wznieść się ponad zwodnicze pewniki przeszłości by działać zgodnie z wartościami Scruma. PODSUMOWANIE SCRUM W PUNKTACH: jest opartym o empiryzm, 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 opartym o samoorganizację sposobem zwiększania produktywności zespołu prowadzi do głębokich strukturalnych przemian organizacji mających na celu jej uzwinnienie i wyszczuplenie nie wprowadza nowych i nie interferuje z już stosowanymi praktykami inżynierskimi (często stosowany w tandemie z eXtreme Programming Scrum nie traktuje o praktykach inżynierskich, skupiając się na zagadnieniach związanych z organizacją pracy) jest skalowalny od pojedynczych zespołów do całych organizacji i przedsiębiorstw