NOWE METODYKI PROWADZENIA PROJEKTU

Transkrypt

1 Dr inż. Dariusz RODZIK Mgr inż. Paweł SIERGIEJUK Mgr inż. Stanisław GRZYWIŃSKI Wojskowa Akademia Techniczna Wydział Mechatroniki i Lotnictwa NOWE METODYKI PROWADZENIA PROJEKTU Streszczenie: W pracy opisano metodologię i podstawowe zasady prowadzenia projektu z wykorzystaniem metodyki Scrum. NEW METHODOLOGY IN PROJECT MANAGEMENT Abstract: The paper describe the methodology and way of using Scrum framework in project management. Słowa kluczowe: agile, scrum, zarządzanie projektem Keywords: agile, scrum, project management 1. WPROWADZENIE Od chwili, gdy pojawił się termin inżynieria oprogramowania, opracowywane są metody efektywnego wytwarzania programów komputerowych w sposób, który przede wszystkim pozwala tworzyć oprogramowanie odpowiadające potrzebom zamawiającego użytkownika, możliwie niewielkim nakładem pracy ludzkiej i z jak najmniejszą ilością błędów. Najstarszą stosowaną metodyką tworzenia oprogramowania jest tzw. model kaskadowy (ang. waterfall). Mimo wielu wad i częstych trudności, metodyka ta jest jeszcze powszechnie spotykana. Jedną z jego głównych wad jest duży narzut czasowy, który wiąże się z realizacją procesu projektowania. Metodyka ta również cechuje się dużą bezwładnością i małą odpornością na nieprzewidziane modyfikacje, co skutecznie uniemożliwia wprowadzanie zmian w czasie trwania projektu. Odpowiedzią na wady modelu kaskadowego stały się nowo opracowane tzw. zwinne metodyki (ang. agile) prowadzenia projektu [1]. Według twórców ruchu agile metodyki kaskadowe nie były już adekwatne do aktualnie istniejących możliwości, jakie dawały między innymi nowe techniki programistyczne, przez co korzystanie z modeli waterfall powodowało duże marnotrawstwo zasobów. Agile preferowało modele iteracyjne, gdzie w każdej iteracji dodaje się do już istniejącego produktu nową funkcjonalność lub rozbudowuje istniejącą. To dzięki dużej liczbie iteracji metodyki agile są efektywniejsze od modeli kaskadowych. Najbardziej znanym zbiorem zwinnych reguł prowadzenia projektów informatycznych jest metodyka Scrum. Nazwa Scrum wywodzi się z gry rugby, gdzie oznacza młyn stały element gry, gdy dwie drużyny stają naprzeciw siebie i walczą o przejęcie piłki. Scruma nie można w pełni nazwać metodyką. Jego autorzy najczęściej nazywają go ramami postępowania, gdyż nie odpowiada on na wszystkie pytania dotyczące prowadzenia projektu. Scrum może być traktowany jako zbiór dobrych praktyk, które podpowiadają, jak należy prowadzić projekt, aby uzyskać wysokie prawdopodobieństwo sukcesu. Praktyki te pochodzą 645

2 z badań, które zostały przeprowadzone w firmach z japońskiego przemysłu motoryzacyjnego oraz informatycznego. 2. METODOLOGIA SCRUM Każda zwinna metodologia tworzenia oprogramowania charakteryzuje się tym, że proces projektowania dzieli się na iteracje nazywane sprintami. Pełny proces Scrum został zamieszczony na rys. 1. Można w nim wyróżnić następujące elementy: backlog project jest to lista rzeczy, jakie należy wykonać w ramach projektu. Lista ta musi być posortowana według priorytetów zadań tak, aby najważniejsze zadania z punktu widzenia klienta były zawsze na początku; sprint jedna iteracja cyklu pracy zespołu. Najczęściej spotyka się 14 lub 30 dni. Długość sprintu zależy od charakteru pracy, środowiska, dziedziny i preferencji zespołu; sprint backlog część zadań projektu, którą zespół zobowiązał się w trakcie danego sprintu przetworzyć na gotowy produkt; daily Scrum codzienne, krótkie spotkanie (maksymalnie 15 min) umożliwiające synchronizację zespołu oraz propagowanie informacji w zespole; product gotowy produkt, który jest wytworzony po każdej iteracji i może zostać potencjalnie wykorzystany przez klienta. Nie są tu dopuszczalne wszelkie braki i półprodukty. W każdym sprincie zespół dodaje do istniejącego produktu nowe funkcjonalności. Rys. 1. Schemat przebiegu procesu tworzenia oprogramowania wg metodyki Scrum [2] Metodyka Scrum opiera się silnie na relacjach samoistnie tworzących się między członkami zespołu. Zakłada się, że zespół będzie dokonywał pewnej samoorganizacji i jest to rzecz, która silnie wpływa na wydajność pracy w metodyce (patrz [3]). Scrum przewiduje następujące funkcje dla uczestników projektu: Scrum Master (mistrz młyna) osoba odpowiedzialna za proces i zespół, która posiada większą wiedzę na temat Scruma od reszty zespołu. Jej zadaniem jest dbanie o to, aby wszystkie procesy toczyły się zgodnie z zasadami Scruma. Ochrania ona również zespół przed negatywnym wpływem z zewnątrz i rozwiązuje jego problemy; 646

3 Product Owner (właściciel produktu) osoba odpowiedzialna za wizję projektu. Przypisuje priorytety dla zadań, definiuje kryteria oraz akceptuje wszystkie zadania. Często jest to osoba, która jest wydelegowana z organizacji klienta; The Team (zespół) kros funkcjonalny, samozarządzający się zespół złożony z ludzi, którzy w sumie posiadają wszystkie zdolności niezbędne do przetworzenia zadań ze sprint backlogu na gotowy produkt. W przypadku projektu informatycznego, w ramach zespołu powinny znaleźć się co najmniej następujące odpowiedzialności: architekt, programista i tester; Others (wszyscy inni) wszelkie inne osoby (np. przyszli użytkownicy, zarząd firmy, członkowie innych projektów itp.), które nie wykonują danego projektu i nie mogą ingerować w proces jego wykonywania bezpośrednio. Scrum jest metodologią zwinną i nie ma w niej zaplanowanych wielu spotkań z zarządem itp. W ciągu każdego sprintu odbywa się kilka spotkań, których wspólną cechą jest to, że mają z góry określony maksymalny przedział czasu, w jakim muszą się zakończyć. Uniemożliwia to ich niepotrzebnie przeciąganie i zmusza do szybkiego, zwięzłego wypełnienia ich celu. W ciągu sprintu wyróżnić można następujące rodzaje spotkań: sprint planning meeting (spotkanie planistyczne) najdłuższe spotkanie w całym sprincie. Przeprowadza się je na początku każdego sprintu. W trakcie spotkania zespół z właścicielem produktu wspólnie ustalają, co ma zostać wykonane w trakcie nadchodzącego sprintu oraz ustalane są również kryteria akceptacyjne do każdego zadania. O tym, ile zadań wchodzi do następnego sprintu, decyduje zespół na podstawie swoich doświadczeń z ostatniego sprintu; sprint review (przegląd sprintu) spotkanie kończące sprint. Na tym spotkaniu zespół prezentuje właścicielowi i wszystkim zainteresowanym osobom efekty swojej pracy. Zespół prezentuje zadanie po zadaniu, a właściciel produktu weryfikuje, czy wszystkie postawione wymagania zostały spełnione. Właściciel może zaakceptować wykonaną pracę lub odrzucić, przez co cały sprint uznaje się za nieudany. W ramach tego spotkania każda osoba na sali może zgłosić uwagi i sugestie; sprint retrospection (retrospektywa sprintu) ostatnie spotkanie zamykające sprint. Retrospekcję wykonuje się po sprint review. Jej celem jest doskonalenie trwającego procesu Scrum, czyli podsumowanie ostatniego sprintu i wyciągnięcie wniosków, dotyczących wprowadzenia ulepszeń w następnej iteracji. Retrospekcja powinna zwykle trwać nieco krócej niż podsumowanie sprintu i umożliwić usprawnienie procesu. W jej trakcie wszyscy członkowie zespołu zgłaszają uwagi, które według nich: 1. Przeszkadzały i należałoby ich zaprzestać. 2. Pomagały zespołowi i należałoby je kontynuować. 3. Warto by było wprowadzić, gdyż mogłyby przynieść pozytywny wpływ na proces. Wszystkie zgłaszane kwestie są krótko omawiane, a następnie poprzez głosowanie wybiera się spośród nich jedną lub dwie, które są najważniejsze dla całego zespołu. Scrum master skupia się na rozwiązywaniu tylko wybranych rzeczy. daily scrum (spotkanie codzienne) jest to najkrótsze spotkanie w całej metodyce Scrum, ale też najczęściej występujące i uznawane przez wiele osób za kwintesencję metodyki. Spotkanie codzienne trwa maksymalnie 15 min. Spotyka się na nim cały zespół, gdzie każdy członek zespołu odpowiada na 3 pytania: 1. Co zrobiłem/am wczoraj? 2. Co planuję zrobić dzisiaj? 3. Czy mam jakieś problemy blokujące moją pracę? 647

4 Takie codzienne raportowanie sprawia, że scrum master i zespół ma ciągły obraz postępu prac w danym sprincie. Ważne jest, aby nie wykorzystywać danego spotkania do rozwiązywania zgłoszonych problemów, gdyż często powoduje to przedłużanie czasu jego trwania. Wszystkie dodatkowe kwestie są rozwiązywane po spotkaniu przez osoby bezpośrednio zainteresowane daną kwestią. Najczęściej spotkania zamykające i otwierające następny sprint są ze sobą połączone w jedno duże spotkanie. Zaczyna się ono od przeglądu sprintu. Następnie, od razu przechodzi się do retrospektywy, a na końcu spotkania odbywa się planowanie następnego sprintu. Jedną z podstawowych własności, jakich oczekuje się po dowolnej metodyce zarządzania projektami, jest możliwość analizy wyników, jakie osiąga zespół oraz planowanie kolejnych działań w oparciu o te analizy. Najważniejszym narzędziem obrazującym postęp prac jest tzw. wykres spalania (ang. Burn Down Chart) (rys. 2). Wykres ten służy do śledzenia aktualnego postępu zespołu. Na osi pionowej wykresu oznaczono ilość pracy zespołu (np. punktów trudności czy liczba zadań), jaka pozostała do wykonania, a na osi poziomej czas (np. długość sprintu). Rys. 2. Przykładowy przebieg postępów prac zespołu projektowego [4] 3. ZADANIA PROJEKTOWE I ESTYMACJA TRUDNOŚCI W METODYCE SCRUM Zadania projektowe w metodyce Scrum nazywane są historyjkami (ang. story). Są one określane z punktu widzenia użytkownika. Najczęściej stosuje się następujący wzorzec: Jako xxxx, chciałbym mieć yyyy, aby umożliwić mi zzzz, gdzie: xxxx nazwa użytkownika produktu: użytkownik, administrator itd., yyyy nazwa funkcjonalności, zzzz korzyść (ang. benefit), jaką użytkownik uzyska z danej funkcjonalności. Każda historyjka jest pełną działającą funkcjonalnością. W przypadku zwykłej aplikacji posiadającej trzy warstwy strukturalne: interfejs użytkownika, oprogramowanie i bazę danych, każda historyjka zawiera: część interfejsu użytkownika do wykonania, wszystkie niezbędne metody w oprogramowaniu do realizacji jej funkcjonalności oraz tabele w bazie danych, jakie są niezbędne do jej działania. Dzięki temu podejściu każda historyjka przynosi bezpośrednią korzyść dla użytkownika i po wykonaniu, której klient może od razu jej użyć. 648

5 Estymacja trudności zadań projektowych w metodyce Scrum odbywa się za pomocą tzw. Planning Pokera i punktów trudności. Punkty trudności stanowią relatywną skalę porównawczą między poszczególnymi historyjkami. Historyjka z 8 punktami jest 4 razy bardziej trudniejsza od historyjki z 2 punktami. Bardzo ważne jest, aby nie wiązać bezpośrednio czasu z punktami trudności. Skalę punktów trudności najczęściej przyjmuje się następującą: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Procedura estymacji trudności zadań projektowych za pomocą Planning Pokera wygląda następująco: 1. Zespół omawia dane zadanie projektowe (historyjkę). 2. Następuje pierwsza tura oceny zadania, w której każdy członek zespołu ocenia stopień trudności zadania. 3. Osoby, które oceniły trudność zadania najwyżej i najniżej, uzasadniają swoją ocenę przed całym zespołem. 4. Następuje kolejna tura oceny trudności zadania ( ) 5. Głosowanie prowadzi się do momentu, aż zespół wypracuje wspólną ocenę trudności zadania. Dzięki takiej procedurze estymacja stopnia trudności zadania projektowego jest szybka i precyzyjna. Poza tym dzięki używaniu punktów trudności w prosty sposób zespół może zaplanować prace na przyszły sprint. Jeżeli zespół w ramach ostatniego sprintu uzyskał 30 punktów trudności, to do następnego sprintu może zaplanować taką samą ilość punktów. 4. PODSTAWOWE ZASADY PRACY W METODYCE SCRUM W metodyce Scrum przewiduje się następujące zasady pracy: bliska współpraca z klientem metodyka Scrum opiera się na pętli sprzężenia zwrotnego z klientem. Zespół co iterację pokazuje klientowi to, co udało się zrobić, a klient wyraża swoją opinię. Taki model pracy jest bardzo korzystny dla obu stron, gdyż klient widząc nowo zaimplementowane funkcjonalności, może bardzo wcześnie dostrzec nieprawidłowości lub też nowe możliwości, o których nie myślał wcześniej. Zespół natomiast ma pewność, że to, co robi, odpowiada potrzebom klienta; adaptowalność ponad trzymanie się planu, ludzie ponad proces jeśli aktualnie stosowany proces nie działa w poprawny sposób, zespół dopasowuje proces do swoich potrzeb. Dzieje się to głównie za pomocą spotkań retrospektywnych. Zespół kładzie duży nacisk na wydajność swojej pracy i minimalizuje straty; samozarządzający się zespół zespół sam zarządza swoją pracą i decyduje, które zadania wybiera. Nie ma tu również odpowiedzialności indywidualnej za zadania jest tylko odpowiedzialność zbiorowa za ukończenie sprintu w terminie; wszystkie zadania są ograniczone czasowo w metodyce Scrum nie może być zadań, które trwają dłużej niż jeden sprint. Jest to spowodowane tym, że na koniec sprintu należy przedstawić gotowy produkt; przezroczystość na poziomie klient-zespół, co sprint pokazuje, co udało się osiągnąć. Na poziome wewnętrznym zespołu wszyscy codziennie widzą, co udało się zrobić innym członkom zespołu. 649

6 5. PODSUMOWANIE Zbiór zasad, wzorów artefaktów i sposobów postępowania, które służą określonemu celowi, nazywany jest metodyką. W inżynierii oprogramowania można wyróżnić m.in. metodyki zarządzania projektami, wytwarzania oprogramowania czy prowadzenia badań. Tworzy się je w celu uzyskania powtarzalnego, dobrego rezultatu wykonywanych czynności. Opisane w artykule zasady prowadzenia projektów informatycznych za pomocą metodyki Scrum w niektórych organizacjach są często niedoceniane ze względu na swoją prostotę i dużą swobodę pracowników. Wynika to głównie z braku zaufania. W ostatnich trzech latach obserwowany jest duży wzrost dostępności różnego rodzaju informacji (konferencje, artykuły i szkolenia) z zakresu prowadzenia projektów wg metodyki Scrum, co może sugerować, że staje się ona coraz bardziej popularna i znajduje zastosowanie w różnych branżach przemysłu. Choć metodyka Scrum wywodzi się z branży informatyki, to z powodzeniem wiele organizacji stosuje ją również w innych dziedzinach nauki i techniki. Dla przykładu NASA część swoich projektów kosmicznych realizowała, stosując metodykę Scrum. Powyższy artykuł jest tylko próbą sygnalizacji danego zagadnienia. Poruszone w nim kwestie opisują podstawowe mechanizmy działa oraz zależności w wykorzystywane w metodyce Scrum. LITERATURA [1] Beck K., Beedle M., van Bennekum A., Cockburn A., Cunningham W., Fowler M., Grenning J., Highsmith J., Hunt A., Jeffries R., Kern J., Marick B., Martin R.C., Mellor S., Shwaber K., Sutherland J., Thomas D.: Agile manifesto. web, February [2] Shwaber K., Sutherland J.: Scrum guide, February [3] Kędziora A.F.: Metodyka scrum w małych i średnich projektach informatycznych, praca magisterska, Uniwersytet im. A. Mickiewicza w Poznaniu, Poznań [4] 650