Wydawnictwa AGH, Kraków 2012 ISBN

Transkrypt

1

2

3 KU 0477 pozycja wydawnictw naukowych Akademii Górniczo-Hutniczej im. Stanisława Staszica w Krakowie Wydawnictwa AGH, Kraków 2012 ISBN Redaktor Naczelny Wydawnictw AGH: Jan Sas Komitet Naukowy Wydawnictw AGH: Tomasz Szmuc (przewodniczący) Marek Capiński Jerzy Klich Witold K. Krajewski Tadeusz Sawik Mariusz Ziółko Recenzenci: Prof. dr hab. Tadeusz Grabiński Prof. dr hab. Jerzy Klamka Afiliacje autorów: Jan Werewka, Grzegorz J. Nalepa, Michał Turek, Szymon Bobek, Krzysztof Kaczor AGH Akademia Górniczo-Hutnicza Redakcja: Magdalena Grzech Projekt okładki i strony tytułowej: Maria Werewka Skład komputerowy: Wydawnictwo JAK, Wydawnictwa AGH al. Mickiewicza 30, Kraków tel , tel./faks redakcja@wydawnictwoagh.pl

4 Spis treści 1. Wstęp do tomu trzeciego (Jan Werewka) Klasyczne i zwinne metodyki zarządzania projektami Zakres opracowania... 9 Literatura Klasyczne zarządzanie projektami informatycznymi na przykładzie PMBOK (Jan Werewka) Wstęp Cele PMI PMBOK rozwój i zasady Zdarzenia grupowanie procesów według cyklu projektowego Artefakty Role Procesy Dyscypliny PMBOK Narzędzia i techniki metodyki PMBOK Wnioski Literatura Systematyczny opis metodyki Scrum dla zespołów projektowych (Jan Werewka, Michał Turek, Tomasz Włodarek) Zagadnienie konstrukcji systematycznego opisu metodyk wytwarzania i zarządzania Scrum geneza i rozwój Postulaty metodyk zwinnych Scrum jako proces empiryczny filary procesu Scrum jako metodyka normatywna (szkielet pracy) Zdarzenia metodyki Scrum Artefakty

5 3.6. Role Procesy Planowanie sprintu Rozwój produktu (część wykonawcza sprintu) Kontrola i monitorowanie sprintu Przegląd sprintu Retrospektywa sprintu Realizacja rekomendacji retrospektywy Zestawienie składowych i pojęć metodyki Scrum Podsumowanie Literatura Zarządzanie projektem w przedsiębiorstwie według metodyki Scrum (Jan Werewka, Michał Turek) Wstęp Zdarzenia metodyki Scrum w zarządzaniu projektem Zestawienie procesów metodyki Scrum w zarządzaniu projektem Opracowanie wizji projektu Rozpoczęcie projektu Planowanie wydania Wydanie produktu Zamknięcie projektu Monitorowanie wydania Gromadzenie wymagań Pielęgnacja (utrzymanie) rejestru produktowego Usuwanie przeszkód Warsztat Praktyki Narzędzia Techniki Skalowanie Scrum Podsumowanie Literatura Programowanie ekstremalne (XP) (Michał Turek) Wprowadzenie XP a Scrum Uniwersalne zasady (pryncypia) Artefakty Role Procesy

6 5.7. XP wytwarzanie kodu Programowanie w parach Standaryzacja kodu źródłowego Ciągła integracja Współwłasność kodu Refaktoryzacja godzinny tydzień pracy Współpraca z klientem Zarządzanie ryzykiem w projektach XP Podsumowanie Literatura Zarządzanie jakością oprogramowania: wprowadzenie do testowania (Grzegorz J. Nalepa, Krzysztof Kaczor) Podstawy testowania Wstęp Zasady testowania Proces testowy Psychologia testowania Testowanie w procesie wytwarzanie oprogramowania Poziomy testów Typy i cele testów Testowanie w fazie utrzymania Testowanie statyczne Projektowanie testów Techniki czarnoskrzynkowe Techniki białoskrzynkowe Techniki oparte na doświadczeniu Zarządzanie procesem testowym Niezależność testowania Planowanie testowania Nadzór testowania Zarządzanie incydentami Klasy narzędzi testowych Narzędziowe wsparcie testowania statycznego Narzędziowe wsparcie tworzenia specyfikacji testów Narzędziowe wsparcie wykonywania testów Narzędziowe wsparcie testowania wydajności Narzędzia wspierające testowanie w określonych dziedzinach Wybrane otwarte narzędzia wspomagające testowanie Podsumowanie Literatura

7 7. Środowiska wytwarzania oprogramowania: wybrane narzędzia (Grzegorz J. Nalepa, Szymon Bobek) Wstęp Zintegrowane środowiska programistyczne NetBeans Eclipse KDevelop Systemy wersjonowania i zarządzania zmianami kodu RCS protoplasta systemów wersjonowania Scentralizowane systemy wersjonowania Podejście rozproszone do wersjonowania Systemy wersjonowania dostępne on-line Systemy wspomagające dokumentowanie kodu JavaDoc Doxygen Systemy kontroli i śledzenia błędów Podsumowanie Literatura

8 1. Wstęp do tomu trzeciego Rozwój branży informatycznej, która ma duże znaczenie gospodarcze i strategiczne, zależy w dużym stopniu od powodzenia prowadzonych różnorodnych projektów informatycznych w tej branży. W zarządzaniu projektami utrwaloną rolę odgrywają metodyki klasyczne (tradycyjne). W ostatnim okresie obserwuje się rozwój metodyk zarządzania określanych, jako zwinne. Powstaje podstawowe pytanie, w jaki sposób klasy metodyk mogą być stosowane w przedsiębiorstwie informatycznym [1]. W poszukiwaniu odpowiedzi na to pytanie w opracowaniu przedstawiono szerszy kontekst zagadnień, którego znajomość jest niezbędna do podjęcia prawidłowych decyzji Klasyczne i zwinne metodyki zarządzania projektami Rozwój metodyk zarządzania projektami informatycznymi jest obszarem wiedzy, który podlega dynamicznemu rozwojowi. W praktyce istnieje dużo rozwiązań opartych na tradycyjnym (klasycznym) lub zwinnym procesie zarządzania projektami. Prowadzonych jest wiele prac związanych z wykorzystaniem obu typów metodyk w obszarze funkcjonowania przedsiębiorstwa informatycznego. Do metodyk klasycznych można zaliczyć PMBOK, PRINCE2 oraz COBIT i inne, jednak za metodykę referencyjną zdecydowano się uznać PMBOK [2] ze względu na jej rozpowszechnienie. PMBOK jest otwartą metodyką PMI związaną z zarządzaniem projektami, a także standardem ANSI. Z kolei wynik badań popularności metodyk zwinnych przeprowadzonych przez VersionOne Inc. [3] w 2008 roku na ponad 3 tysiącach respondentów wskazał Scrum jako najpopularniejszą metodykę zwinną 49% udziału w rynku (oraz na drugim miejscu hybryda Scrum i XP z 22,3% udziału), podczas gdy pozostałe metodyki, do których należą: AgileUP, FDD, Lean Development, DSDM, OpenUP, Agile Modeling, Crystal mają łącznie około 10% udziału. Podstawowa różnica pomiędzy tradycyjnymi i zwinnymi metodykami zarządzania polega na różnym podejściu do planowania i wytwarzania produktu w projekcie. Tradycyjne metody są zorientowane na plan. W przypadku dostarczanych produktów projektu definiowane są wymagania, na podstawie tego wyznaczany jest harmonogram i koszt projektu. Projekt ma dostarczyć produkty o zadanych wymaganiach. W takich metodykach planowanie odgrywa centralną rolę, zadania do wykonania przekazywane są z procesów planowania do procesów wykonania (wykonanie takie, jakie zostało zaplanowane). Kierowanie wykonaniem projektu polega na metodzie termostatu, w którym 7

9 postęp projektu jest sprawdzany względem planu. W przypadku odchyłek, planowane i wykonywane są czynności naprawcze. Metodyki zwinne bazują na wartości dostarczanych produktów, natomiast koszt i przedział czasowy jest ustalony wcześniej. Po tym przedziale czasowym ma powstać produkt, który daje największą wartość biznesową. W metodach zwinnych istnieje lista właściwości (wymagań) produktu, która określa zmiany względem istniejącego prototypu produktu oprogramowania. Kierownik projektu (lub podobna rola projektowa) maksymalizuje wartość dostarczanego produktu poprzez odpowiednie wybranie właściwości dla aktualnej iteracji i usuwa ewentualne przeszkody stojące przed zespołem rozwojowym. Ten sposób postępowania umożliwia wczesne sprawdzenie (walidację) wymagań. W wyniku obserwacji, dzięki nabytemu doświadczeniu w zarządzaniu projektami w firmach informatycznych oraz po dokonaniu przeglądu literaturowego, można stwierdzić, że firmy dryfują w obszarze zarządzania projektami, nie uzyskując spodziewanych efektów. Doświadczenia i badania wskazują, że w warunkach działania firm informatycznych najlepiej skoncentrować się na pewnym szkielecie (ang. framework) powstałym z połączenia metodyk klasycznych i zwinnych. Elementy tego szkieletu po operacji skalowania i konfiguracji powinny zostać dostosowane do zarządzania konkretnym projektem [4]. Co więcej, na poziomie przedsiębiorstwa warto się skoncentrować tylko na najbardziej popularnych metodykach zarządzania projektami i wykorzystywać je choćby ze względów organizacyjnych i dobrego wsparcia narzędziowego. Postulowane podejście powinno również umożliwiać jednolite spojrzenie z poziomu wyższych warstw zarządzania na projekty prowadzone według różnych metodyk. Taka perspektywa umożliwi ich porównanie, ocenę i łatwiejsze podejmowanie decyzji. Podejście to jest również uzasadnione przez obserwację, że w większości firm metodyki zarządzania projektami nie są stosowane w sposób całkowicie zgodny z pierwowzorami. Należy także uwzględnić fakt, że proponowane rozwiązania mają być dostosowane do wielkości i złożoności projektów, a także do ograniczeń wynikających między innymi z dojrzałości organizacyjnej przedsiębiorstwa. Zagadnienie integracji zarządzania projektami odgrywa szczególną rolę w działalności przedsiębiorstw informatycznych, gdyż posiada duże znaczenie gospodarcze i logistyczne. Dobitnym przykładem opisywanym w literaturze gospodarczej i naukowej jest fuzja dwóch gigantów informatycznych: HP i Compaq. W tym przypadku poszukiwano także optymalnego rozwiązania w zakresie zarządzania projektami [10]. Ten przykład studyjny świadczy o tym, że pogląd, iż dla każdego projektu należy dobierać metodykę, nie jest możliwy do zaakceptowania ze względu na rzeczywiste potrzeby i uwarunkowania przedsiębiorstw. Reasumując, można stwierdzić istnienie potrzeby integracji i skalowania metodyk zarządzania projektami oraz rozwoju narzędzi, które wspierałyby proces doboru i wdrażania tych metodyk. Jako przesłanki można wskazać następujące potrzeby i sytuacje: Realizacja różnego typu projektów w ramach przedsiębiorstwa, których wydajność uzależniona jest od struktury organizacyjnej. Z punktu widzenia zarządu firm konieczne jest posiadanie ogólnego obrazu projektów, stosowanych narzędzi i rozwiązań. Z punktu widzenia kadry konieczne jest posiadanie wzorców zawierających informacje o procedurach, rolach zakresach odpowiedzialności itp. 8

10 Przedsiębiorstwa informatyczne chcą wprowadzać metodyki zwinne (i stosują swoje adaptacje). Poszukują one docelowych rozwiązań, ale drogą ewolucyjną bez naruszania produktywności. Występuje brak jednolitego opisu zasobów, procesów związanych z zarządzaniem projektami w przedsiębiorstwach. Firmy takie poszukują narzędzi umożliwiających dużą elastyczność opisu i łatwą adaptację do ich potrzeb. Na rynku brakuje takich rozwiązań. Łączenie firm o różnych standardach zarządzania projektami (przykład fuzji Compaq i HP). Realizacja projektów w heterogonicznych wirtualnych strukturach organizacyjnych (np. projekty międzynarodowe, unijne). W środowisku przedsiębiorstw branży IT, których podstawową formą jest działalność projektowa, panuje pogląd, że poprawę efektywności wytwarzania oprogramowania i większą konkurencyjność można uzyskać przez wdrożenie sprawdzonych metodyk zarządzania projektami, jak PMBOK [7] i Scrum [6]. Pomiędzy klasycznymi i zwinnymi metodykami zarządzania projektami zachodzą znaczne różnice. Metodyki klasyczne ukierunkowane są na klasyfikację i identyfikację procesów projektowych, co jest zgodne z holistycznym podejściem stosowanym w Enterprise Architecture Framework [7]. Z kolei metodyki zwinne nie definiują jawnie procesów projektowych, ale określają ścisłe reguły postępowania (które mogą być traktowane jak procesy) i zasady organizacji projektu. Problem wyboru określonej metodyki i zdefiniowania organizacji projektu dostosowanej do lokalnych warunków jest bardzo złożony, ponieważ musi uwzględniać istniejące ograniczenia i uwarunkowania wynikające ze struktury organizacyjnej przedsiębiorstwa, dostępnych zasobów i wiedzy zgromadzonej w przedsiębiorstwie. Z drugiej strony oczekuje się, że zdefiniowana architektura procesów zarządzania projektem powinna być optymalna lub suboptymalna ze względu na rozmaite kryteria (np. wartość dodana, ryzyko projektowe) Zakres opracowania W przypadku większości przedsiębiorstw informatycznych podstawowym trybem działania jest realizacja projektów. Z perspektywy kadry zarządzającej istotna jest znajomość otoczenia związanego z zarządzaniem projektami. Zamierzeniem opracowania jest zaproponowanie poprawnie metodologicznie zbudowanej metodyki zarządzania projektami integrującej różne rozwiązania i skalowalnej w zależności od potrzeb. W tym celu w opracowaniu rozpatrzono zagadnienia opisu różnych metodyk zarządzania projektami w powiązaniu z wytwarzaniem oprogramowania w przedsiębiorstwach informatycznych. W tej części opisano zagadnienia: klasycznego zarządzania projektami informatycznymi na przykładzie PMBOK, systematycznego opisu metodyki Scrum dla zespołów projektowych, systematycznego opisu metodyki Scrum w organizacji bazującej na zarządzaniu projektami, opisu programowania ekstremalnego (XP), zarządzania jakością oprogramowania w powiązaniu z testowaniem, wykorzystania narzędzi w środowiskach wytwarzania oprogramowania. 9

11 W niniejszym opracowaniu umieszczono materiał z zakresu zarządzania projektami ze szczególnym uwzględnieniem projektów informatycznych i przeznaczono je zarówno dla studentów, jak i praktyków. Materiał ten został zweryfikowany w trakcie realizacji studiów podyplomowych zarządzanie projektami informatycznymi, które są współfinansowane ze środków Europejskiego Funduszu Społecznego w ramach Programu Operacyjnego Kapitał Ludzki. Studia te mają na celu przygotowanie kadr do sprawnego zarządzania projektami informatycznymi. Dzięki przedstawieniu najbardziej popularnych klasycznych i zwinnych metod zarządzania uczestnik studiów nabędzie umiejętności wyboru najbardziej efektywnego sposobu prowadzenia projektu zintegrowanego ze środowiskiem działania przedsiębiorstwa i skalowalnego do wielkości i złożoności projektu. Autorzy publikacji pragną podziękować wszystkim tym, którzy zgłosili cenne uwagi mające wpływ na poprawę jakości opracowania. W szczególności dotyczy to spostrzeżeń zgłoszonych przez Łukasza Czyżyńskiego, Łukasza Grzesika, Karolinę Jarosz, Żanetę Kałużną, Dariusza Kocznura, Tomasza Kowalskiego, Grzegorza Kurkę, Łukasza Kurowskiego, Jacka Paculę, Mariusza Paculę, Patryka Ziobronia. Literatura [1] Werewka J., Szwed P., Rogus G.: Integration of classical and agile project management methodologies based on ontological models, w: Zarządzanie przedsiębiorstwem teoria i praktyka, AGH, Wydział Zarządzania, Kraków 2010 [2] A Guide to the Project Management Body of Knowledge Fourth Edition (PMBOK Guide), Approved American National Standard ANSI/PMI , PMI 2008 [3] The state of Agile Development, 3rd annual Survey:2008, Full Data Report Conducted June-July VersionOne Inc. [4] Werewka J., Scaling Management of IT Projects Depending on their Size and Complexity, 1st CEE Symposium on Business Informatics, ACS, Vienna 2009, s [5] Mobilizing HP, Project Management as an Executive Priority. Benchmark Implementation: Primavera, Case Study, 2004 Benchmarking Partners [6] Schwaber K., Beedle S: Agile software development with Scrum, Upper Saddle River, N.J., Prentice Hall, 2002 [7] Franke U., Hook D., Konig J., Lagerstrom R., Narman P., Ullberg J., Gustafsson P., Ekstedt M.: EAF2 A Framework for Categorizing Enterprise Architecture Frameworks, ACIS International Conference on Software Engineering, Artificial Intelligences, Networking and Parallel/Distributed Computing, 2009, SNPD 09, s

12 2. Klasyczne zarządzanie projektami informatycznymi na przykładzie PMBOK 2.1. Wstęp Wyróżniamy dwie podstawowe klasy metodyk zarządzania projektami: są to metodyki klasyczne bazujące na planie projektu oraz metodyki zwinne bazujące na aktualnym stanie produktu i jego rozwoju. Należy od razu zauważyć, że utożsamianie metodyk klasycznych z metodami kaskadowymi jest błędne. Plan projektu może mieć charakter nakładających się faz, w tym dopuszczalny jest model iteracyjny (niezgodnie z modelem kaskadowym) lub faz występujących po sobie (podobnie jak w modelu kaskadowym). Metody klasyczne odgrywają dużą rolę, w przypadku gdy produkty projektu należy dostarczyć w ściśle określonym czasie. Ma to szczególne znaczenie wtedy, gdy działalność gospodarcza klienta projektu zależy ściśle od realizacji planu projektu. W rozdziale skoncentrowano się na najbardziej rozpowszechnionej w świecie metodyce klasycznej PMBOK (Project Management Body of Knowledge) zarządzania projektami. Metodyka ta, będąca standardem ANSI, jest opisana w obszernym dokumencie [1] (lub [2] wydanie w języku polskim). Organizacją odpowiedzialną za rozwój standardu jest PMI (Project Management Institute). Standard ten został skonstruowany i wciąż jest rozwijany dzięki doświadczeniom profesjonalistów w dziedzinie zarządzania projektami skupionymi wokół PMI. Poznanie zasad związanych z metodyką PMBOK będzie możliwe po zapoznaniu się z zasadami działania i celami PMI Cele PMI PMBOK jest standardem PMI (Project Management Institute). PMI został utworzony w 1969 głównie w celu identyfikacji wspólnych praktyk zarządzania projektami w rożnych obszarach przemysłowych. Przy identyfikacji zasad PMBOK należy założyć, że są one zgodne z zasadami PMI. Podstawowym celem PMI jest uzyskanie postępu w działaniach praktycznych, nauce i w obszarze zarządzania projektami (pojmowanego ogólnie tzn. dla wszystkich branż) na całym świecie w sposób świadomy i proaktywny, tak aby organizacje wykorzystały zarządzanie projektami do odniesienia sukcesów. Przeglądając strony PMI ( można określić, jak jest rozumiana wizja i misja PMI oraz jakie cele strategiczne przyświecają tej organizacji. 11

13 Analiza stron PMI pozwala na identyfikację wizji jako uzyskanie ogólnoświatowej doskonałości w zarządzaniu projektami. Natomiast misja PMI może być rozumiana jako wsparcie rozwoju kompetencji oraz poszerzania wiedzy w zakresie zarządzania projektami, ukierunkowane na doświadczonych i nowych praktyków oraz ich klientów. Celami strategicznymi PMI są: Członkostwo PMI. Członkostwo w PMI wspiera i zachęca wszystkich ekspertów zarządzania projektami do uzyskania równowagi pomiędzy ogólnymi i lokalnymi najlepszymi praktykami budowania relacji i dzielenia zasobów. Globalne standardy. W obszarze szeroko pojętego zarządzania projektami PMI definiuje standardy mające charakter globalny (ogólnoświatowy). Z tym związane są ogólne rozwiązania, które mogą być zastosowane w wielu różnorodnych obszarach. Kwalifikacje zawodowe (ang. credentials). Zakłada się, że do prowadzenia projektów konieczne jest posiadanie odpowiednich kompetencji. Posiadanie tych kompetencji jest wymogiem, by być ekspertem w obszarach zarządzania projektami. Kompetencje te umożliwiają także rozwój i karierę zawodową w tym obszarze. Sieć akredytowanych jednostek edukacyjnych (REP Registreted Education Provider) pozwala na rozwój szkoleń przez jednostki szkoleniowe, uniwersytety i inne organizacje. Jednostki takie są oceniane przez PMI. Dokonywana jest akredytacja akademickich programów szkoleniowych. Działania te sprawiają, że kształcenie będzie mieć wymagany poziom. Programy naukowo-badawcze. PMI posiada dedykowane badania dotyczące zarządzania projektami. Podstawowe standardy PMI będące standardami ANSI: standard zarządzania projektem [1, 2], standard zarządzania programem [3], standard zarządzania portfelem projektów [4], model dojrzałości organizacyjnej w zakresie zarządzania projektem [5]. Standardy PMI do wspomagania zarządzania projektami: praktyczny standard harmonogramowania [6], praktyczny standard do zarządzania ryzykiem [7], praktyczny standard dla struktur podziału prac [8], praktyczny standard zarządzania konfiguracją projektu [9], praktyczny standard do zarządzania wartością wypracowaną [10], praktyczny standard dla estymacji projektu [11]. Standardy PMI specjalistyczne dla dziedziny: rozszerzenie przewodnika PMBOK w zakresie projektów budowlanych [12], rozszerzenie przewodnika PMBOK w zakresie projektów rządowych [13]. 12

14 Standard rozwoju kompetencji osobowych: szkielet rozwoju kompetencji kierownika projektu [14]. Aktualnie rozwijane standardy PMI: leksykon zarządzania projektami (Project Management Lexicon). PMI przeprowadza egzaminy dotyczących kwalifikacji zawodowych, w wyniku których można uzyskać certyfikaty eksperta w zakresie: zarządzania projektami PMP (Project Management Professional) lub certyfikowany partner w zarządzaniu projektami CAPM (Certifi ed Associate in Project Management), zarządzania harmonogramem projektu PMI-SP (PMI Scheduling Professional), zarządzania ryzykiem projektowym PMI-RMP (PMI Risk Management Professional), zarządzania programem PMP (Program Management Professional), praktyk zwinnego podejścia PMI-ACP (Agile Certifi ed Practitioner). Ważną rolę odgrywają wartości dotyczące zarządzania projektami, które PMI wyznaje. Wartości takie zostały podane w kodeksie etyki i postępowania zawodowego [15]. Rysunek 2.1 przedstawia strukturę kodeksu, a tabele od 2.1 do 2.4 wyjaśniają rozumienie poszczególnych wartości dotyczących odpowiedzialności, poszanowania, bezstronności i uczciwości. Rys Struktura kodeksu etyki i postępowania zawodowego 13

15 Tabela 2.1 Odpowiedzialność według kodeksu etyki i postępowania zawodowego Wyjątki z kodeksu etyki PMI Należy: chronić prawnie zastrzeżone lub poufne informacje, które zostały nam powierzone; informować się i utrzymać w mocy polityki, zasady, przepisy i ustawy, które rządzą naszą pracą, zawodem i wolontariatem; przestrzegać tego kodeksu i rozliczać zachowanie niezgodne z zasadami kodeksu. Przykłady zastosowania Należy: opracować podstawowe reguły postępowania, dostosowane do kodeksu postępowania, według którego kierownictwo lub grupa będą razem pracować. Nie należy: ujawniać informacji poufnych nieupoważnionym stronom; angażować się w nielegalne działania; brać lub nadużywać własności innych osób, w tym własności intelektualnej; zniesławiać lub pomawiać. Tabela 2.2 Poszanowanie według kodeksu etyki i postępowania zawodowego Wyjątki z kodeksu etyki PMI Należy: porozumiewać się bezpośrednio z osobami, z którymi mamy konflikty lub spory; negocjować w dobrej wierze; Nie należy: używać wpływów lub pozycji do wywierania wpływu na decyzje innych. Przykłady zastosowania Należy: zachowywać się w sposób profesjonalny, nawet gdy takie zachowanie nie jest odwzajemnione; unikać plotek i robienia negatywnych uwag w celu podważenia reputacji innych osób; słuchać wypowiedzi innych osób i starać się zrozumieć ich stanowisko; działać w dobrej wierze we wszystkich fazach kontraktu. Tabela 2.3 Bezstronność według kodeksu etyki i postępowania zawodowego Wyjątki z kodeksu etyki PMI Należy: wykazywać przejrzystość podejmowania decyzji; stale sprawdzać naszą bezstronność i obiektywizm; ujawniać konflikty interesów. Przykłady zastosowania Należy: konsekwentne postępować według zatwierdzonych polityk; ujawniać potencjalne konflikty interesów, zanim kierownictwo lub grupa robocza będzie omawiać taką sytuację; wiedzieć, że dostrzeganie konfliktu nie usuwa go; występowanie konfliktu jest dopuszczalne; nierozwiązanie konfliktu jest sytuacją niepożądaną; Nie należy: wykorzystywać swojej pozycji do celów osobistych lub korzyści biznesowych. 14

16 Tabela 2.4 Uczciwość według kodeksu etyki i postępowania zawodowego Wyjątki z kodeksu etyki PMI Należy: usiłować zrozumieć prawdę; tworzyć środowisko, w którym osoby czują się bezpiecznie, mówiąc prawdę. Nie należy: akceptować zachowania, które ma na celu wprowadzanie innych w błąd. Przykłady zastosowania Należy: raportować w sposób dokładny, prawdziwy i aktualny; może to dotyczyć np.: raportów projektów/programów, rocznych sprawozdań lub ich składowych; przeprowadzać spotkania w taki sposób, że: różne punkty widzenia są rozpatrywane i brane pod uwagę, złe wiadomości są traktowane jako wspólne i są rozpatrywane w sposób profesjonalny. Nie należy: składać oświadczenia wprowadzającego w błąd lub zawierającego półprawdziwe informacje; dostarczać informacji poza kontekstem lub zachowywać informacji dla siebie PMBOK rozwój i zasady Pierwsza edycja standardu PMBOK została opracowana w 1987, kolejna druga edycja została opublikowana w 1996 oraz 2000 na podstawie uwag członków PMI. Od tego czasu kolejne edycje powstają regularnie co cztery lata, w roku 2004 i W roku 1998 PMBOK został uznany za standard ANSI (American National Standards Institute). Począwszy od 1 stycznia 2009, PMI (Project Management Institute) wprowadził zaktualizowany standard zarządzania projektami zwany PMBOK (Project Management Body of Knowledge kompendium wiedzy o zarządzaniu projektami) będący czwartą edycją. Praktyczna znajomość standardów jest oceniana poprzez egzaminy organizowane przez PMI. Pierwszy egzamin z PMP został przeprowadzony w Egzamin ten należy do najbardziej popularnym i zarazem prestiżowych egzaminów z zakresu zarządzania projektami. Ze standardem PMBOK związane są dwa rodzaje egzaminów: Znany i ceniony egzamin PMP (Project Management Professional) wymagający wiedzy i doświadczenia zawodowego w zakresie zarządzania projektami. Konieczne jest wykazanie uczestnictwa w projektach, np. poprzez prowadzenie zadań w projektach. Zakres oraz sposób przeprowadzania egzaminu został opisany w [16]. Mniej popularny egzamin CAPM (Certified Associate in Project Managament) przeznaczony głównie dla osób nieposiadających dostatecznego doświadczenia, ale posiadających odpowiedni poziom wiedzy. Dostępnych jest wiele podręczników przygotowujących do egzaminu PMP, z których najbardziej popularnymi są pozycje [18, 19, 20, 22]. 15

17 W wyniku analizy standardu PMBOK można zdefiniować następujące zasady tej metodyki: Profesjonalizm działania i etyka zawodowa. Jednym z istotnych czynników sukcesu jest kompetentna kadra zarządzająca projektem oraz profesjonalne zachowanie w trakcie realizacji projektu. Charakter ogólny i globalny metodyki. Przedstawiona metodyka ma być ogólna, by można ją było użyć z powodzeniem w projektach z wielu branż i w wielu krajach świata. Skalowanie metodyki. Metodyka PMBOK ma charakter ogólny, ale zezwala na skalowanie metodyki do odpowiednich potrzeb. Decyzja o skalowaniu wysiłku związanego z zarządzaniem projektami zależy od jego wykonawców, czyli kierownika projektu i zespołu projektowego. Decyzja taka polega na doborze procesów i ich poziomu szczegółowości. Dostarczenie klientowi projektu dokładnie tego, czego wymagał (to i tylko to, czego wymagał klient). W trakcie zbierania wymagań dokonywane jest ich wartościowanie. Po dokonaniu takiego wartościowania definiowane jest we współpracy z klientem, które wymagania są w zakresie projektu, a które nie. Plan i proaktywne działanie. W celu dostarczenia klientowi tego, czego wymagał konieczne jest proaktywne działanie, bazujące na zarządzaniu interesariuszami oraz tworzeniu wiarygodnego planu projektu. Opracowany plan według standardu PMBOK-a nie musi mieć charakteru kaskadowego. Prace w projekcie związane z planowaniem, wykonaniem, kontrolą i monitorowaniem mogą się nakładać. Prace w projekcie mogą być podzielone na fazy sekwencyjne (model kaskadowy), nakładające się oraz iteracyjne. Planowanie kroczące i poprawa planów. Plan projektu nie musi być od razu planem szczegółowym. W miarę postępu prac projektu plan ten może być uszczegóławiany. Zintegrowane zarządzanie zmianą. W metodyce PMBOK dopuszcza się zmiany w planie i projekcie. Zmiany te powinny być przeprowadzone w sposób zintegrowany z uwzględnieniem wpływu zmiany na różne składowe projektu Zdarzenia grupowanie procesów według cyklu projektowego PMBOK uwzględnia ciągłą poprawę zarządzania projektem. Ta ciągła poprawa jest wzorowana na cyklu PDCA. Cykl PDCA został opracowany przez Waltera Shewharta, a następnie rozpropagowany przez Williama Edwarda Deminga, amerykańskiego statystyka. Cykl PDCA (zwany również kołem Deminga) polega na cyklicznym wykonywaniu powtarzających się kroków mających na celu ciągłe doskonalenie, nabieranie wiedzy i doświadczenia. Zazwyczaj przyjmuje się, że na początku planujemy rozwiązanie problemu (udoskonalenie), następnie przechodzimy do jego sprawdzenia, a jeżeli rozwiązanie sprawdziło się, to rozwiązanie wprowadzamy w całym obszarze działania. Cykl PDCA przedstawia się w formie koła podzielonego na cztery obszary (rys. 2.2). 16

18 Wykonaj (dlaczego?) Planuj (co, jak?) Sprawd Dzia aj Rys Ilustracja cyklu PDCA Cykl PDCA ma szerokie zastosowanie i może być użyty nie tylko w zarządzaniu projektami. W systemach zarządzania procesowego (np. ISO 9000) etapy koła Deminga mogą mieć następujące znaczenie: P opracuj plan realizacji procesu, D wykonaj plan, C sprawdź, czy uzyskano zamierzone rezultaty, A podejmij działania zapobiegawcze (po zidentyfikowaniu potencjalnych problemów) lub korygujące (jeżeli cele nie zostały w pełni osiągnięte). Bazując na cyklu PDCA, w PMBOK-u wydzielono następujące grupy procesów zarządzania, które są w następującej relacji z cyklem Deminga PDCA (rys. 2.3): inicjalizacji rozpoczęcie cyklu (fazy lub całego projektu), planowania opracowanie planu zakresu i planu jego realizacji, wykonania wykonanie prac według opracowanego planu, monitorowania i kontroli sprawdzenie zakresu prac i wyznaczenie możliwych zmian zakresu, zamknięcia zamknięcie cyklu (fazy lub całego projektu). W PMBOK planowanie odgrywa centralną rolę, prace które mają być wykonane są planowane, a potem przekazywane do wykonania (zaplanuj wykonaj zgodnie z planem). Kontrola wykonania projektu polega na sprawdzeniu postępu projektu w porównaniu z planem. W przypadku odchyłek opracowywane są zmiany (np. w postaci akcji naprawczych), a następnie plan projektu jest aktualizowany i przekazywany do wykonania. PMBOK nie jest rozwiązaniem kaskadowym, w którym po zakończeniu poprzedniego etapu może rozpocząć się następny etap. W PMBOK działania należące do różnych grup mogą się przenikać i być wykonywane w sposób równoległy, jak to przedstawiono na rysunku

19 Procesy inicjalizacji Procesy planowania Plan projektu Procesy monitorowania i kontroli Procesy wykonania Procesy zamkni cia Rys Odwzorowanie grup procesów metodyki PMBOK na cykl PDCA Rys Stopień zaangażowania zasobów procesów w trakcie realizacji projektu W PMBOK można wyróżnić dwa typy zdarzeń. Są to: fazy projektu oraz kamienie milowe. Sam projekt może się składać z różnych faz, w których mają miejsce czynności procesów rozpoczęcia, planowania, wykonania, monitorowania i kontroli, zamknięcia. Faza może 18

20 być traktowana jako podprojekt, w którym występuje rozpoczęcie i zakończenie. Typowe zastosowanie fazy może polegać na podziale projektu na różne etapy związane z wykonaniem prac przez różne zespoły projektowe. Kolejność wykonania faz może być różna, na przykład sekwencyjna. Wówczas warunkiem rozpoczęcia fazy jest zakończenie fazy poprzedzającej (rys. 2.5). Rys Sekwencyjna kolejność faz w trakcie realizacji projektu Rys Przykład nakładania się faz w trakcie realizacji projektu Rys Iteracyjne nakładanie się faz w trakcie realizacji projektu 19

21 Fazy mogą się nakładać w różny sposób (rys. 2.6). Szczególnym przypadkiem może być nakładanie iteracyjne (rys. 2.7), w którym w trakcie wykonywania aktualnej fazy dokonywane jest planowanie dla następnej fazy. Kamienie milowe W trakcie realizacji projektu mogą być definiowane kamienie milowe. Kamień milowy jest punktem w czasie reprezentującym ważne zdarzenie w życiu projektu. Osiągnięcie kamienia milowego powinno być możliwe do zweryfikowania przez interesariuszy. Kamień milowy jest zdarzeniem o zerowym czasie trwania, niewymagającym dodatkowych zasobów, reprezentującym punkt wydania produktu lub koniec etapu. Zazwyczaj kamień milowy jest punktem kontrolnym projektu w celu sprawdzenia stanu projektu i walidacji produktów projektu Artefakty W PMBOK-u artefakty projektu można zidentyfikować poprzez wyznaczenie przepływów pomiędzy procesami. Na podstawie analizy takich przepływów można wyróżnić pięć najbardziej popularnych oraz najważniejszych artefaktów: 1. Czynniki środowiskowe przedsiębiorstwa. Czynniki środowiskowe przedsiębiorstwa są to czynniki zewnętrzne i wewnętrzne, które wpływają na realizację projektu. Czynniki mogą zakłócić także realizację projektu oraz ograniczać możliwość wykonywania pewnych działań w projekcie. W PMBOK czynniki środowiskowe przedsiębiorstwa (EEFs Enterprise Environmental Factors) pojawiają się na wejściu wielu procesów, natomiast są wyjściem tylko dwóch procesów dotyczących wzrostu kompetencji podczas budowania zespołu projektowego oraz aktualizacji ocen tychże kompetencji w trakcie zarządzania zespołem projektowym. 2. Aktywa procesów organizacyjnych pojawiają się na wejściach wielu procesów oraz na wyjściu wielu procesów. W szczególności dotyczy to aktualizacji procesów i procedur organizacji dla prowadzonych prac oraz korporacyjnej bazy wiedzy. 3. Plan zarządzania projektem jest bardzo istotnym artefaktem i może być zdefiniowany na poziomie ogólnym albo szczegółowym. Plan zarządzania projektem składa się z wielu planów składowych oraz z ich zatwierdzonych wersji nazywanych referencjami bazowymi. Liczba planów składowych używanych w konkretnym projekcie może być różna i wynika ze złożoności i wymagań projektu. 4. Dokumenty projektu opisują wiele właściwości potrzebnych do realizacji projektu. Dokumenty te mają w przybliżeniu 40 składowych. Dokumenty projektu i ich składowe pojawiają się na wielu wejściach i wyjściach projektu. 5. Produkty projektu (produkty dostawy ang. deliverables) są artefaktami, które projekt ma dostarczyć odbiorcy. Artefakty te mogą być niepowtarzalnym i weryfikowalnym produktem, usługą lub wynikiem. Pojęcie produktu projektu jest głównie używane w odniesieniu do zewnętrznego produktu, który podlega akceptacji inwestora lub klienta. W PMBOK-u liczba możliwych artefaktów jest bardzo duża. W modelu PMBOK-a można wyróżnić ponad 300 przepływów [23, 24] pomiędzy procesami. Przepływy pomiędzy procesami będą się odnosić do artefaktów. Liczba takich artefaktów wynosi powyżej

22 Istotne jest zrozumienie znaczenia charakterystycznych artefaktów. Tabela 2.5 przedstawia taką listę. Artefakty można zidentyfikować poprzez wyznaczenie przepływów pomiędzy procesami. Na podstawie analizy takich przepływów wyróżniono pięć najbardziej popularnych oraz najważniejszych artefaktów. Tabela 2.5 Lista wybranych charakterystycznych artefaktów projektu Symbol artefaktu Opis artefaktu Produkty projektu (inaczej produkty dostawy ang. deliverables) są artefaktami, które projekt ma dostarczyć odbiorcy. Pojęcie produktu projektu jest głównie używane w odniesieniu do zewnętrznego produktu, który posiada wartość i podlega weryfikacji i akceptacji inwestora lub klienta przed odbiorem. W przypadku gdy projekt ma dostarczyć usługę, to również jest ona traktowana jako produkt dostawy. Sprawdzone produkty (ang. validated deliverables) dostarczane produkty muszą zostać sprawdzone ze względu na ich poprawność podczas kontroli jakości. Pozytywny wynik takiego sprawdzania zwykle umożliwia przekazanie produktu do akceptacji klienta. Zaakceptowany produkt (ang. product). W trakcie weryfikacji zakresu powinno się uzyskać formalną akceptację wytworzonego produktu. Pozwala to na formalne przekazanie produktu klientowi i zabezpiecza przed możliwymi skargami. Aktywa procesów organizacyjnych (ang. Organizational Process Assets) są zasobami wiedzy bazującymi głównie na procesach i procedurach organizacji dla prowadzonych prac oraz na korporacyjnej bazie wiedzy. Zespoły uczestniczące w projektach mają dużą wiedzę i doświadczenie, które powinny udostępnić i wykorzystać w innych projektach, wzbogacając tym samym aktywa procesów organizacyjnych. 21

23 Tabela 2.5. cd. Czynniki środowiskowe przedsiębiorstwa (EEFs Enterprise Environmental Factors) odnoszą się do czynników wewnętrznych (np. struktura organizacyjna i procesy przedsiębiorstwa, kultura i styl organizacyjny przedsiębiorstwa) i zewnętrznych (np. kultura organizacyjna klienta, standardy przemysłowe i rządowe regulacje), które mogą zakłócić lub mieć bezpośredni wpływ na realizację projektu. Czynniki te mają istotne znaczenie dla projektu, gdyż mogą ograniczać możliwość wykonania pewnych działań lub rozszerzać zakres projektu. Plan zarządzania projektem (ang. Project Managament Plan) jest strategią zarządzania projektem. Plan zarządzania określa, w jaki sposób będzie dokonywane planowanie, zarządzanie i kontrola zakresu, czasu i ryzyka. Plan ten ma powiązać ze sobą i skoordynować plany uzupełniające w postaci jednego planu zarządzania projektem. Ten plan jest skonstruowany na potrzeby projektu i jest używany na bieżąco do zarządzania projektem. Dokumenty projektu (ang. project documents) są dokumentami, które nie są planami projektu, ale wspomagają wykonanie i kontrolę projektu. Przykładami mogą być między innymi: rejestr spraw, rejestr zmian, oszacowania czasów i kosztów, metryki jakości, role i odpowiedzialności, repozytorium wyuczonych lekcji. Zakres projektu (ang. project scope) określa zakres prac do wykonania projektu. Wykonanie zakresu projektu jest mierzone względem tak zwanego zakresu bazowego. Zakres bazowy stanowi jedną z kluczowych składowych planu zarządzania projektem. W trakcie wykonania projektu powinno być zapewnione wykonanie prac należących do zakresu i tylko do zakresu, w celu zakończenia projektu z powodzeniem. Klient powinien uzyskać to, czego wymagał, nie mniej i nie więcej. Wersja bazowa nazywana także wersją referencyjną (ang. baseline) jest zachowaną i zatwierdzoną wersją planu lub dokumentu projektu. Wersja bazowa jest istotna, chociażby ze względu na konieczność porównania aktualnego stanu projektu właśnie z wersją bazową planu. 22

24 Tabela 2.5. cd. Aktualizacja (ang. updates) przedstawia aktualizacje artefaktów projektu w wyniku realizacji projektu. W wyniku tak zwanej zintegrowanej kontroli zmian może także dojść do zmian planu zarządzania projektem. Aktualizacja wiąże się przeważnie z aktualizacją tylko pewnej części artefaktu. Kluczową grupą artefaktów są produkty dostawy projektu (ang. deliverables). Na rysunku 2.8 przedstawiono diagram pokazujący przepływy produktów w projekcie. Produkty wytworzone w ramach wykonania projektu nazywamy produktami projektu. Produkty takie podlegają weryfikacji w procesach kontroli i monitorowania. W wyniku tych czynności otrzymamy sprawdzone produkty. W przypadku produktów sprawdzonych może być podjęta decyzja o akceptowalności produktu przez klienta. Jeżeli w projekcie jego produkty są akceptowalne, to może to umożliwić zakończenie projektu lub fazy. Kierowanie i zarządzanie wykonaniem projektu Rys Diagram przepływu produktów projektu W wyniku analizy metodyki PMBOK można wyróżnić wiele artefaktów, w tym dużą grupę artefaktów związanych z planem zarządzania projektem zawartą w tabeli 2.6. Na tej liście 14 pierwszych artefaktów traktuje się jako składowe planu zarządzania projektem. Prawie wszystkie pozycje od 1 do 14 są składowymi planu zarządzania projektem oraz są wejściami lub wyjściami innych procesów z wyjątkiem trzech: planu zarządzania zmianą (pozycja 1) jest to dokument opisujący, jakie zmiany będą monitorowane i kontrolowane; planu zarządzania konfiguracją (pozycja 3); planu zarządzania zakresem (pozycja 14) jest to dokument opisujący, jaki zakres będzie definiowany, weryfikowany, zarządzany i monitorowany. 23

25 Pozostałe pozycje, od 15 do 21, tworzą listę wejść i wyjść procesów planowania nieuwzględnionych jako składowe planu zarządzania projektem. Tabela 2.6 Lista artefaktów procesów planowania Lp. Nazwa przepływu (artefaktu) 1. Plan zarządzania zmianą (Change management plan) 2. Plan zarządzania komunikacją (Communication management plan) 3. Plan zarządzania konfiguracją (Confi guration management plan) 4. Plan zarządzania kosztami (Cost management plan) 5. Plan zasobów ludzkich (Human resource plan) 6. Plan poprawy procesów (Process improvement plan) 7. Plan zarządzania kontraktami (Procurement management plan) 8. Plan zarządzania jakością (Quality management plan) 9. Plan zarządzania wymaganiami (Requirements management plan) 10. Plan zarządzania ryzykiem (Risk management plan) 11. Harmonogram bazowy (Schedule baseline) 12. Plan zarządzania harmonogramem (Schedule management plan) 13. Zakres bazowy (Scope baseline): deklaracja zakresu (Scope statement) SPP (WBS) słownik SPP (WBS Dictionary) 14. Plan zarządzania zakresem (Scope management plan) 15. Dokumentacja wymagań (Requirement documentation) 16. Diagram sieciowy harmonogramu (Project schedule network diagram) 17. Harmonogram projektu (Project schedule) 18. Dane harmonogramu (Schedule data) 19. Bazowe wydajności kosztów (Cost performance baseline) 20. Plan zarządzania kontraktami (Risk related contract decisions) 21. Decyzja wykonania lub kupna (Make or buy decision) 24

26 W tabeli 2.6 dwie pozycje służą jako artefakty referencyjne, są to harmonogram i zakres bazowy. Artefakty referencyjne tym różnią się od pozostałych artefaktów, że ich kolejne aktualizacje muszą podlegać zatwierdzeniu i być wersjonowane. Ostatnia ważna wersja służy do porównania realizacji projektu z planami referencyjnymi. Następną ważną grupą są artefakty określane jako dokumenty projektu. Tabela 2.7 zawiera listę artefaktów związanych z dokumentami projektów. Zawiera ona 39 pozycji, z których 33 stanowią wejścia lub wyjścia innych procesów PMBOK-a, natomiast pozostałe stanowią wewnętrzne produkty procesu. Lista składowych dokumentów projektu, które nie są ani wejściami, ani wyjściami procesów: 1. Rejestr założeń (pozycja 4) może być częścią deklaracji zakresu lub oddzielnym rejestrem. 2. Struktura organizacyjna projektu (pozycja 17) występuje jako składowa planu zarządzania zasobami ludzkimi. 3. Macierz przydziału odpowiedzialności projektu (pozycja 21) występuje jako składowa planu zarządzania zasobami ludzkimi. 4. Role i odpowiedzialności projektu (pozycja 27) występują jako składowe planu zarządzania zasobami ludzkimi. 5. Macierz analizy interesariuszy (pozycja 30) jest częścią wejścia/wyjścia strategii zarządzania interesariuszami. 6. Wymagania interesariuszy (pozycja 33) opisane w planie zarządzania komunikacją. Tabela 2.7 Lista artefaktów dotyczących dokumentów projektów Lp. Dokumenty projektu 1. Parametry działania (Activity attributes) 2. Oszacowania kosztu działania (Activity cost estimates) 3. Lista działań (Activity list) 4. Rejestr założeń (Assumption log) 5. Podstawa oszacowań (Basis of estimates) 6. Rejestr zmian (Change log) 7. Karta projektu (Project charter) 8. Kontrakty (Contracts) 9. Oszacowania czasu trwania działania (Activity duration estimates) 10. Prognozy budżetowe (Budget forecasts) 11. Rejestr spraw (Issue log) 12. Lista kamieni milowych (Milestone list) 25

27 Tabela 2.7. cd. 13. Raporty wydajności (Performance reports) 14. Wymagania wobec funduszu projektu (Project funding requirements) 15. Oferty sprzedawców (Seller proposals) 16. Dokumenty kontraktu (Procurement documents) 17. Struktura organizacyjna procesu (Project organizational structure) 18. Pomiary kontroli jakości (Quality control measurements) 19. Listy kontrolne jakości (Quality checklists) 20. Metryki jakości (Quality metrics) 21. Macierz przydziału (Responsibility assignment) 22. Macierz powiązań wymagań (Requirements traceability matrix) 23. Struktura podziału zasobów (Resource breakdown structure) 24. Kalendarz zasobów (Resource calendar) 25. Wymagania wobec zasobów działania (Activity resource requirements) 26. Rejestr ryzyka (Risk register) 27. Role i odpowiedzialności (Roles and responsibilities) 28. Lista zakwalifikowanych sprzedawców (Qualifi ed sellers list) 29. Kryteria wyboru dostawcy (Source selection criteria) 30. Macierz analizy interesariuszy (Stakeholder analysis matrix) 31. Strategia zarządzania interesariuszami (Stakeholder management strategy) 32. Rejestr interesariuszy (Stakeholder register) 33. Wymagania interesariuszy (Stakeholder requirements) 34. Deklaracja prac projektu (Project statement of work) 35. Deklaracja zakresu prac kontraktu (Procurement statements of work) 36. Umowa o współpracy zespołowej (Teaming agreements) 37. Oceny wydajności zespołu (Team performance assessments) 38. Informacja o wydajności pracy (Work performance information) 39. Pomiary wydajności pracy (Work performance measurements) Rysunek 2.9 przedstawia diagram przepływu produktów projektu pomiędzy grupami procesów. Diagram ten przedstawia główne artefakty przepływające pomiędzy grupami procesów. W poszczególnych grupach procesów można wyróżnić podstawowe artefakty wejściowe i wyjściowe. 26

28 Grupa procesów inicjalizacji dotyczy prac niezbędnych do rozpoczęcia projektu. Artefaktami wejściowymi tej grupy procesów są przede wszystkim kontrakty (dokumenty kontraktów), deklaracja prac projektu, przypadek biznesowy, a także aktywa procesów organizacyjnych oraz czynniki środowiskowe przedsiębiorstwa. Wyjściami tej grupy procesów są karta projektu, rejestr interesariuszy i strategia zarządzania interesariuszami. Rys Diagram przepływu produktów projektu pomiędzy grupami procesów 27

29 Grupa procesów planowania dotyczy głównie prac związanych z tworzeniem planu zarządzania projektem i dokumentów projektu. Artefaktami wejściowymi tej grupy procesów są przede wszystkim artefakty będące wyjściami procesów inicjalizacji, a także aktywa procesów organizacyjnych i czynniki środowiskowe przedsiębiorstwa oraz ich aktualizacje. Wpływ na przebieg procesów planowania mają kalendarze zasobów oraz umowa o współpracy zespołowej. Wyjściami tej grupy procesów są plan zarządzania projektem, dokumenty projektu oraz kalendarz zasobów projektu. Grupa procesów wykonania jest odpowiedzialna za realizację projektu, w tym za powstawanie produktów projektu. Artefaktami wejściowymi tej grupy procesów są przede wszystkim artefakty będące wyjściami procesów planowania, a także aktywa procesów organizacyjnych i czynniki środowiskowe przedsiębiorstwa oraz ich aktualizacje. Wpływ na przebieg procesów planowania mają zatwierdzone żądania zmian, raporty wydajności, oferty sprzedawców oraz kryteria wyboru dostawcy. Wyjściami tej grupy procesów są produkty projektu, informacja o wydajności pracy, wybrani dostawcy oraz aktualizacje procesów organizacyjnych i czynników środowiskowych przedsiębiorstwa. Grupa procesów monitorowania i kontroli jest odpowiedzialna za śledzenie stanu projektu i utrzymania projektu na założonym kursie. Artefaktami wejściowymi tej grupy procesów są przede wszystkim artefakty będące wyjściami procesów planowania i wykonania, a także aktywa procesów organizacyjnych i czynniki środowiskowe przedsiębiorstwa oraz ich aktualizacje. Wyjściami tej grupy procesów są zatwierdzone żądania zmian, raporty wydajności pracy, zaakceptowane produkty, dokumenty kontraktu oraz aktualizacje procesów organizacyjnych i czynników środowiskowych przedsiębiorstwa. Grupa procesów zamknięcia odpowiada za prawidłowe zamknięcie projektu lub fazy. Artefaktami wejściowymi tej grupy procesów są zaakceptowane produkty, dokumenty kontraktu oraz aktualizacje procesów organizacyjnych i czynników środowiskowych przedsiębiorstwa. Wyjściami tej grupy procesów są produkt końcowy oraz aktualizacje procesów organizacyjnych i czynników środowiskowych przedsiębiorstwa Role W metodyce PMBOK występują role, które są opisane w różnym stopniu szczegółowości. Wszystkie role są objęte przez interesariuszy. W projekcie mogą występować role, które nie występują w standardzie. Zadaniem kierownika projektu i zespołu zarządzającego projektem jest identyfikacja takich ról. Tabela 2.8 zawiera role (zapisane pogrubioną czcionką), które zostały wspomniane w opisie standardu PMBOK. W tabeli 2.8 zawarto w celu pełniejszego określenia obrazu opis ról kierownika procesu i użytkownika końcowego, które nie występują bezpośrednio w opisie metodyki PMBOK. Do realizacji zadań określonych celów projektu tworzy się różne struktury organizacyjne projektów. W PMBOK nie ma opisu takiej struktury podanej w sposób jawny. Rysunek 2.10 przedstawia typową strukturę organizacyjną stosowaną w przypadku większych projektów. W strukturze tej wyróżniono role posiadające różne uprawnienia i odpowiedzialności. Odnośnie do większych projektów powoływany jest organ przeznaczony do kontroli projektu. Organ taki może w różnych metodykach może być różnie nazywany (np. rada projektu, komitet sterujący, rada kontroli zmian) i może posiadać różniące się funkcje. 28

30 Tabela 2.8 Role występujące w standardzie PMBOK Interesariusze (ang. stakeholders) to osoby lub organizacje, które są zainteresowane wynikami projektu. Mogą uczestniczyć w projekcie lub mogą mieć wpływ na projekt lub także projekt może wpływać na nie. Z każdym projektem są związani inni interesariusze. Kierownik projektu (ang. PM project manager) jest osobą reprezentującą projekt i osobą odpowiedzialną za osiągnięcie sukcesu projektu określonego poprzez wyznaczone cele. Kierownik projektu podejmuje decyzje taktyczne i operacyjne dotyczące: organizacji projektu, codziennego zarządzania projektem w obrębie zadanych ograniczeń, planowania, ustalania standardów i zasad, kontroli postępu i koordynacji prac i inne. Kierownik projektu jest odpowiedzialny za to, że zespół projektowy zrealizuje projekt. Inwestor (ang. sponsor) jest to osoba, grupa lub organizacja dostarczająca niezbędnych zasobów finansowych dla danego projektu. Sponsor ma znaczący wpływ na zakres projektu i można go określić jako właściciela projektu. Do zadań inwestora należy: zapewnienie poparcia dla projektu, dostarczenie uprawnień i zasobów dla projektu, akceptacja produktów projektu, wyrażenie zgody na przejście do następnej fazy. Zleceniodawca projektu (ang. project customer) jest typem inwestora, który zleca wykonanie projektu w formie kontraktu. Zakres współpracy ze zleceniodawcą zależy od zaangażowania przedstawicieli i od rodzaju zlecanego projektu. Klient, który zamawia projekt spoza firmy wykonującej projekt, nazywany jest klientem zewnętrznym (ang. external customer). Właściciel lub przedstawiciel właściciela biznesu jest inwestorem, który jest osobą odpowiedzialną przed firmą za osiągnięcie celów biznesowych projektu oraz inwestycje przeznaczone na projekt. Powinna to być osoba z szczebla kierowniczego, która jest istotnie zainteresowana pozytywnym wynikiem projektu. Wpływ na projekt ma tak zwane wyższe kierownictwo (ang. upper management) organizacji wykonującej projekt. 29

31 Tabela 2.8. cd. Kierownik funkcjonalny (ang. functional manager) ma uprawnienia do zarządzania jednostką organizacyjną. Zwykle taka jednostka specjalizuje się w pewnym obszarze odmiennym od pozostałych obszarów w ramach organizacji funkcjonalnej. Kierownik procesu jest odpowiedzialny za wyniki procesu (efektywność) procesu. Niekiedy kierownik procesu może być jednocześnie kierownikiem funkcjonalnym. Jednakże często procesy mogą być realizowane w obrębie wielu jednostek organizacyjnych. Ekspert dziedzinowy (ang. domain expert) jest osobą mająca dogłębną wiedzę z danego obszaru. Sporządza ocenę ekspercką (ang. expert judgment), inaczej ekspertyzę. Ekspert dziedzinowy sprzedaje ekspertyzę. Rada kontroli zmian (ang. Change Control Board) jest formalną grupą koncentrującą się głównie na kontroli zmian w projekcie. Grupa ta jest uprawniona do przeglądu, oceny oraz do akceptacji bądź odrzucenia zmian w projekcie. Rada taka dostarcza wskazówek związanych z przygotowaniem żądania zmian, oszacowania tych zmian i zarządzania implementacją zaakceptowanych zmian. Zazwyczaj jej członkami są przedstawiciele ważniejszych interesariuszy projektu. Zespół projektowy (ang. project team) w jego skład oprócz kadry zarządzającej wchodzą osoby wykonujące pracę nad właściwym produktem projektu. Grupa ta składa się z pracowników (ang. employees), ludzi o różnych kwalifikacjach i zadaniach w większości stanowiących załogę (ang. staff) organizacji wykonującej projekt. Zespół projektowy jest odpowiedzialny w ramach przydzielonych obowiązków za wykonanie zadań projektu i dostarczanie produktów zgodnie z planem projektu, wskazaniami kierownika projektu, poziomem wysiłku lub uczestnictwa dla nich zdefiniowanym. 30

32 Tabela 2.8. cd. Zespół zarządzania projektem (ang. Project management team) jest to zespół odpowiedzialny za zarządzanie projektem polegającym między innymi na planowaniu, kontroli i monitorowaniu projektu. Zespół ten nazywany jest również wsparciem (obsługą) projektu. Zespół ten wspomaga kierownika projektu w przygotowaniu planów i zbiera informację z monitorowania projektu. Biuro zarządzania projektem (ang. PMO Project Management Offi ce) jest oddziałem organizacji, w którym skoncentrowane jest zarządzanie projektami. Można wydzielić trzy typy biur zarządzania projektami: lekkie wspomagające wykonanie projektów poprzez dostarczanie polityk działań, metodyk i inne działania; treningowe wspierające właścicieli projektów poprzez dostarczanie porad oraz pomocy dotyczących sposobów zarządzania projektami; kierownicze dostarczające kierowników projektów do prowadzenia różnych projektów, zarządza zależnościami pomiędzy projektami. Klient lub kupujący w odniesieniu do produktu lub usługi (ang. (Customer (Client), Buyer) jest to osoba lub organizacja, która nabędzie produkty czy też usługi wytworzone przez projekt. W języku angielskim niekiedy rozróżnia się klienta, który nabywa produkty (ang. customer) od klienta nabywającego usługi (ang. client). Użytkownik końcowy (ang. end user) jest specjalnym rodzajem klienta, który używa produktu i nie musi być nabywcą produktu. Pojęcie użytkownik końcowy stosuje się po to, by odróżnić osobę, która korzysta z produktu lub usługi, od tych, którzy byli zaangażowani w rozwój, produkcję i dystrybucję produktu. Dostawca (ang. supplier) jest to osoba, organizacja lub przedsiębiorstwo dostarczające potrzebny produkt lub usługę. Zwykle taka dostawa jest traktowana jako część (zadanie) projektu. Zazwyczaj zakłada się, że dostawca tworzy produkt lub usługę w ramach działalności operacyjnej. 31

33 Tabela 2.8. cd. Sprzedawca lub handlowiec (ang. Seller, Vendor) jest to osoba, organizacja lub przedsiębiorstwo, która/które sprzedaje produkt lub usługę. Zwykle zakłada się, że sprzedawca lub handlowiec niekoniecznie tworzy produkt lub usługę. Wyróżnia się również sprzedawcę jako oferenta przetargu (ang. bidder). Wykonawca (ang. contractor) jest to osoba, organizacja lub przedsiębiorstwo odpowiedzialne za projekt, można powiedzieć sprzedające projekt. W ramach tego projektu wypełnia warunki kontraktu. Jest odpowiedzialne za codzienny nadzór, wykonanie, komunikację w projekcie. Jest zainteresowane odpowiednią jakością w projekcie. Stosowane jest pojęcie organizacji wykonującej (ang. performing organization), której załoga jest zaangażowana w wykonanie większości prac projektu. W tym przypadku taka organizacja jest głównym wykonawcą (ang. general contractor). W przypadku gdy wykonawca wykonuje tylko mniejszą część projektu, nazywany jest wtedy podwykonawcą (ang. subcontractor). Kierownik programu (ang. Program manager) kieruje programem. Kierownicy programów monitorują projekty i wykonywaną pracę poprzez struktury zarządzające. Kierownik programu odpowiada za to, by grupa powiązanych projektów była zarządzana w sposób skoordynowany w celu uzyskania korzyści niemożliwych do uzyskania przy oddzielnym prowadzeniu projektów. Należy określić, jakie korzyści ma program dostarczać i dbać, by te korzyści nie zostały utracone. Kierownik portfela (ang. Portfolio manager) stara się, by sumarycznie projekty przynosiły największe korzyści. Kierownik portfela monitoruje zagregowanie wydajności i wskaźniki wartościowe. Kierownik portfela koncentruje się na uzyskaniu wartości dodanej przy podejmowaniu decyzji dotyczących portfela. Rada kontroli portfela projektów (ang. Portfolio review board) odpowiada za analizę projektów i sporządzanie wniosków co do rozpoczęcia, zamknięcia, przerwania projektów. 32

34 Rys Struktura organizacyjna projektu Rada projektu (ang. Project Board) lub komitet sterujący (ang. Steering Committee) W skład rady projektu powinien wejść inwestor projektu. Brak w radzie inwestora projektu może sprowadzić radę do grupy dyskusyjnej, która musi prosić o decyzje inwestora projektu lub inne upoważnione osoby. W PMBOK nie ma takiego organu podanego w sposób jawny. Występuje rada kontroli zmian, która ma podobne uprawnienia. W innych metodykach i rozwiązaniach przyjmuje się, że rada projektu jest odpowiedzialna za: zatwierdzanie struktury i składu członków zespołu zarządzania projektem, sterowanie całością projektu najwyższa władza w projekcie, zapewnienie środków finansowych oraz zasobów ludzkich i rzeczowych, przyjmowanie produktów projektu, przydział zasobów i inicjowanie dalszych prac, podjęcie decyzji w przypadku spraw i zmian przekazanych do rozpatrzenia (eskalowanych) do rady projektu. Rada projektu zwykle składa się z przedstawicieli inwestora, klienta i dostawcy. Typowy skład rady dla większych projektów to: przewodzący radzie, przedstawiciel biznesowy klienta, właściciel uzasadnienia biznesowego projektu, 33

35 główny użytkownik reprezentujący interesy obszarów biznesowych objętych przez wytwarzany system, główny wykonawca reprezentujący wykonawców nowego systemu. Przewodniczący rady projektu jest odpowiedzialny za: określenie celów i zakresu projektu, uzasadnienie biznesowego przedsięwzięcia, określenie ogólnych parametrów (czas, budżet, forma realizacji), przyjmowanie produktów projektu, zatwierdzanie istotnych zmian w projekcie, mediacje, zapewnienie niezbędnych zmian w organizacji klienta. Główny użytkownik reprezentuje interesy użytkowników produktu projektu i wszystkich tych, którzy będą pod wpływem rezultatów i oddziaływania projektu. Do zakresu odpowiedzialności głównego użytkownika należą: specyfikacja potrzeb użytkownika, zapewnienie zasobów użytkownika, kontakt użytkownika z zespołem projektowym, monitorowanie zgodności produktu z wymaganiami. Rola ta pełniona jest w przypadku dużych projektów przez kilka osób. Główny wykonawca (dostawca) reprezentuje interesy dostawców produktów projektu, wytwarzających, zaopatrujących, wdrażających produkty projektu. Do zakresu odpowiedzialności głównego dostawcy należą: wiedza, umiejętności, doświadczenie w zakresie projektowania, wytwarzania, dostarczania i wdrażania produktów projektu, zapewnienie niezbędnego wyposażenia i zasobów dostawców. Rola ta pełniona jest w przypadku dużych projektów przez kilka osób. Przy większych projektach może być tworzony nadzór (zabezpieczenie projektu), który ma zapewnić, że projekt spełni cele biznesowe, potrzeby użytkownika oraz standardy techniczne zgodnie z założeniami jakościowymi. Przedstawione na rysunku 2.7 wsparcie projektu może być realizowane przez dedykowany zespół zarządzania projektem lub przez biuro zarządzania projektem. W procesach zarządzania istotną rolę pełnią interakcje pomiędzy rolami. Mogą one zostać zamodelowane poprzez użycie pasów pływackich (swimlanes) w modelu BPMN. Każdej roli wykonującej daną aktywność przypisany jest konkretny pas pływacki. Najczęściej takie interakcje mają miejsce w momencie podjęcia decyzji o akceptacji bądź odrzuceniu jakiegoś dokumentu czy też żądania zmian. Rysunek 2.11 przedstawia przykład zamodelowania interakcji pomiędzy rolami. Dolny pas dotyczy kierownika projektu, a górny rady kontroli zmian. Kierownik wysyła żądania zmian do rady kontroli, ta z kolei decyduje, które zmiany należy zaakceptować, a które odrzucić. Następnie rada odsyła decyzję zwrotną do kierownika. Ten po otrzymaniu informacji aktualizuje status żądań zmian. 34

36 Rys Wycinek z procesu przeprowadzania zintegrowanej kontroli zmian prezentujący interakcję pomiędzy rolami oraz powiązania danych z czynnościami 2.7. Procesy Jedną z podstawowych konstrukcji standardu PMBOK są procesy. Każdy proces jest opisany w sposób słowny (informacja o tym, co realizuje), a z każdym procesem zdefiniowane są wejścia i wyjścia. Do każdego procesu dołączona jest lista proponowanych narzędzi i technik pomocnych przy realizacji procesu. Standard PMBOK definiuje 42 procesy, dla każdego procesu definiowane są przepływy opisane w postaci wejść i wyjść procesów. Procesy te są przedstawione jako elementy z dobrze zdefiniowanym interfejsem, a w praktyce nakładają się one na siebie i współdziałają. Przedstawiona zostanie lista procesów wraz z numeracją procesów (podaną w nawiasach) zgodną z podziałem na pięć grup zarządzania projektem: 1. Grupa procesów inicjalizacji (Initiating process group). 2. Grupa procesów planowania (Planning process group). 3. Grupa procesów wykonania (Executing process group). 4. Grupa procesów monitorowania i kontroli (Monitoring and controlling process group). 5. Grupa procesów zamknięcia (Closing process group). Grupa procesów inicjalizacji składa się z procesów wykonywanych w celu zdefiniowania nowego projektu lub nowej fazy istniejącego projektu oraz uzyskania autoryzacji dla rozpoczęcia projektu lub fazy. Procesy inicjalizacji służą do zdefiniowania wysokopoziomowego zakresu i budżetu projektu oraz do zidentyfikowania najważniejszych 35

37 interesariuszy projektu. Wyniki procesów zawarte są w karcie projektu i w rejestrze interesariuszy. W chwili gdy karta projektu zostanie zatwierdzona, projekt może być wykonywany. W skład grupy procesów inicjalizacji wchodzą tylko dwa procesy: 1. (4.1) Tworzenie karty projektu (Develop Project Charter). 2. (10.1) Identyfikowanie interesariuszy (Identify Stakeholders). Grupa procesów planowania odpowiada za określenie i sprecyzowanie celów projektu oraz zaplanowanie sposobu działania pozwalającego zrealizować cele i zakres projektu. Głównym wynikiem procesów planowania jest stworzenie planu zarządzania projektem oraz dokumentów projektu niezbędnych do realizacji projektu. W miarę pozyskiwania bardziej dokładnych informacji związanych z projektem mogą powstawać kolejne plany. Zatem czynności planowania i dokumentowanie są czynnościami iteracyjnymi w cyklu życia projektu. W skład grupy procesów planowania wchodzi dwadzieścia procesów: 1. (4.2) Tworzenie planu zarządzania projektem (Develop Project Management Plan). 2. (5.1) Pozyskiwanie wymagań (Collect Requirements). 3. (5.2) Definiowanie zakresu (Defi ne Scope). 4. (5.3) Tworzenie SPP (Create WBS). 5. (6.1) Definiowanie działań (Defi ne Activities). 6. (6.2) Szeregowanie działań (Sequence Activities). 7. (6.3) Szacowanie zasobów działania (Estimate Activity Resources). 8. (6.4) Szacowanie czasu trwania działania (Estimate Activity Durations). 9. (6.5) Tworzenie harmonogramu (Develop Schedule). 10. (7.1) Szacowanie kosztów (Estimate Costs). 11. (7.2) Wyznaczenie budżetu (Determine Budget). 12. (8.1) Planowanie jakości (Plan Quality). 13. (9.1) Planowanie rozwoju zasobów ludzkich (Develop Human Resource Plan). 14. (10.2) Planowanie komunikacji (Plan Communications). 15. (11.1) Planowanie zarządzania ryzykiem (Plan Risk Management). 16. (11.2) Identyfikowanie ryzyka (Identify Risks). 17. (11.3) Przeprowadzanie jakościowej analizy ryzyka (Perform Qualitative Risk Analysis). 18. (11.4) Przeprowadzenie ilościowej analizy ryzyka (Perform Quantitative Risk Analysis). 19. (11.5) Planowanie reakcji na ryzyko (Plan Risk Responses). 20. (12.1) Planowanie kontraktów (Plan Procurements). Grupa procesów wykonania odpowiada za koordynację ludzi i innych zasobów w celu wykonania planu zarządzania projektem. W trakcie wykonywania projektu może wyniknąć potrzeba aktualizacji planów i założeń bazowych. Aktualizacje te dotyczą zmiany czasów trwania zadań, zmiany dostępności i produktywności zasobów ludzkich czy też niezidentyfikowanych wcześniej zagrożeń. Ze względu na to, że podane zmiany mają wpływ na plan zarządzania projektem i inne dokumenty projektu, zmiany powinny być przeprowadzone w sposób zintegrowany. W skład grupy procesów wykonania wchodzi osiem procesów: 36

38 1. (4.3) Kierowanie i zarządzanie wykonywaniem projektu (Direct and Manage Project Execution). 2. (8.2) Zapewnianie jakości (Perform Quality Assurance). 3. (9.2) Pozyskiwanie zespołu projektowego (Acquire Project Team). 4. (9.3) Budowanie zespołu projektowego (Develop Project Team). 5. (9.4) Zarządzanie zespołem projektowym (Manage Project Team). 6. (10.3) Rozprowadzanie informacji (Distribute Information). 7. (10.4) Zarządzanie oczekiwaniami interesariuszy (Manage Stakeholder Expectations). 8. (12.2) Realizowanie kontraktów (Conduct Procurements). Grupa procesów monitorowania odpowiada za systematyczny pomiar i monitorowanie postępu wykonania pozwalających wykryć odchylenia od planu projektu. Umożliwi to podjęcie w razie konieczności działań korygujących sprzyjających osiągnięciu celów projektu. Grupa procesów monitorowania i kontroli ma na celu bieżącą kontrolę postępu prac, wydajności projektu oraz monitorowanie wykonania projektu w celu określenia prognoz. W trakcie wykonywania tych procesów dokonywana jest identyfikacja obszarów, w których niezbędne są zmiany oraz dokonywana jest akceptacja bądź odrzucenie zmian. W skład grupy procesów monitorowania i kontroli wchodzi dziesięć procesów: 1. (4.4) Monitorowanie i kontrolowanie pracy projektu (Monitor and Control Project Work). 2. (4.5) Przeprowadzenie zintegrowanej kontroli zmian (Perform Integrated Change Control). 3. (5.4) Weryfikowanie zakresu (Verify Scope). 4. (5.5) Kontrolowanie zakresu (Control Scope). 5. (6.6) Kontrolowanie harmonogramu (Control Schedule). 6. (7.3) Kontrolowanie kosztów (Control Costs). 7. (8.3) Kontrolowanie jakości (Perform Quality Control). 8. (10.5) Raportowanie wydajności (Report Performance). 9. (11.6) Monitorowanie i kontrola ryzyka (Monitor and Control Risk). 10. (12.3) Administrowanie kontraktami (Administer Procurements). Grupa procesów zamknięcia odpowiada za formalną akceptację wyrobu, usługi lub rezultatu oraz za finalizację wszystkich czynności wykonywanych w trakcie trwania projektu czy też fazy projektu. Procesy zamknięcia weryfikują, czy wszystkie procesy we poszczególnych grupach procesów zostały pomyślnie ukończone. Ponadto w wyniku ich wykonania powinna zostać uzyskana formalna akceptacja zakończenia projektu lub fazy. W skład grupy procesów zamknięcia wchodzą tylko dwa procesy: 1. (4.6) Zamykanie projektu lub fazy (Close Project or Phase). 2. (12.4) Zamykanie kontraktów (Close Procurements). Głównym problemem przy modelowaniu procesów zawartych w PMBOK jest to, że czynności wewnątrz procesów nie są zdefiniowane w sposób jawny. Niezbędne było dokładne przeprowadzenie analizy standardu. W wyniku analizy standardu opisano czynności procesów. Należy pamiętać, że wydzielone w ten sposób czynności są subiektywną interpretacją standardu PMBOK dokonaną przez autorów niniejszej publikacji. 37

39 W zakresie modelowania istotnym etapem prac było wyznaczenie modelu metodyki i języków opisu tych modeli. Wybór metody opisu bazował głównie na następujących wskaźnikach [28]: Spójność i kompletność. Własności te będą niezbędne w celu weryfikacji poprawności modelu. Ekspresyjność. Z jednej strony powinniśmy przy użyciu modeli wystarczająco dokładnie opisać istniejące i proponowane rozwiązania, z drugiej strony niektóre metodyki nie są dokładnie opisane. Z tego wynika, że należy określić wymagany minimalny poziom dokładności modelu, a następnie decydować się na wybór języka modelowania. Zrozumiałość. Ponieważ modele będą prezentowane szerokiemu kręgowi osób, to proponowany język modelowania powinien być łatwo zrozumiały dla użytkowników modeli. Wydajność. Ze względu na tworzenie setek modeli procesów konieczne jest korzystanie z języków modelowania, które nie będą absorbować nadmiernie czasu osób tworzących modele. Na podobnej zasadzie był dokonywany wybór narzędzia do modelowania. Zamodelowanie metodyki PMBOK przy użyciu diagramów DFD pozwoliło na zwarty opis modelu zgodny z metodyką PMBOK. Jest to właściwy kierunek, a jego uzasadnieniem jest wykrycie w trakcie modelowania nieścisłości w standardzie PMBOK najnowszej edycji po jego zamodelowaniu przy użyciu tylko diagramów DFD. Przy tworzeniu modeli zakładano łatwą ich modyfikowalność [23, 24]. Zakładano, że modele powinny być również opisane strukturalnie przy użyciu plików Excela lub XML, a następnie wygenerowane do opisu przedstawionego na diagramach przepływu danych (DFD). Dla przykładu padano diagram DFD (rys. 2.12) ilustrujący proces tworzenia karty projektu zgodnie z standardem PMBOK (tab. 2.9). Tabela 2.9 Podstawowe własności procesu tworzenia karty projektu 4.1. Proces tworzenia karty projektu Wejścia Narzędzia i techniki Wyjścia Deklaracja prac projektu (Project statement of work) Przypadek biznesowy (Business case) Opinia eksperta (Expert judgment) Karta projektu (Project charter) Kontrakty (Contracts) Czynniki środowiskowe przedsiębiorstwa (Enterprise environmental factors) Aktywa procesów organizacyjnych (Organizational process assets) 38

40 Rys Ważniejsze przepływy pomiędzy procesami grupy zarządzania integracją projektu W celu zwiększenia dokładności opisu zostały opracowane modele bazujące na BPMN i SPEM. Problem wyboru modeli będzie polegał na możliwie dokładnym opisie rozwiązań przy minimalnej nadinterpretacji względem standardu PMBOK. Innym z napotkanych w trakcie modelowania problemów był fakt przenikania się ról w PMBOK. Wszystkie role w procesie zarządzenia projektem zaliczane są w poczet interesariuszy projektu. Z kolei osoba będąca kierownikiem projektu jest też członkiem zespołu projektowego. Oprócz tego istnieje jeszcze kilka sytuacji, w których następuje przenikanie się ról. Z kolei notacja BPMN wymusza oznaczenia pasów pływackich tylko dla jednej roli, a co za tym idzie, każdej czynności przypisana jest najbardziej adekwatna rola. Ponadto należy pamiętać, iż przypisanie do jakiejś czynności roli nie oznacza, że wykonuje ją jedna osoba. Takie powiązanie mówi o tym, że czynność tę wykonuje jedna osoba lub więcej osób posiadających odpowiednie funkcje w projekcie. W praktyce procesy PMBOK mogą być wykonywane równolegle. W celu uproszczenia stworzony model zakłada sekwencyjność wykonywania procesów [25, 26]. Każdy z procesów ma dokładnie określony start i koniec. Na rysunku 2.13 przedstawiono model pierwszego procesu w fazie rozpoczęcia, którym jest proces opracowania karty projektu. Notacja BPMN nie koncentruje się na tworzeniu powiązań pomiędzy obiektami danych tylko na opisie aktywności, które należy wykonać w celu pomyślnego ukończenie procesu. Jednak istnieje możliwość powiązania artefaktów z procesem. W modelu zastosowano do tego celu skierowane asocjacje. Rysunek 2.14 prezentuje zastosowane podejście do opisanego problemu w przypadku procesu opracowania karty projektu. 39

41 Rys Model procesu opracowania karty projektu z uwzględnieniem czynności procesu Rys Powiązanie danych z procesem tworzenia karty projektu 40

42 Zamieszczony na przykładzie proces ma pięć dokumentów wejściowych i produkuje jeden dokument wyjściowy. Dzięki możliwości wielokrotnego wykorzystania tego samego obiektu danych na kilku diagramach, możliwa jest analiza dotycząca tego, pomiędzy jakimi procesami przepływa konkretny artefakt. Kolejnym sposobem modelowania metodyki było wykorzystanie SPEM (Software Process Engineering Meta-Model) rozwijanego przez organizacje OMG. SPEM jest metamodelem przeznaczonym do definiowania procesów i ich komponentów, wykorzystując do tego notacje i mechanizmy wprowadzone w UML. SPEM został zdefiniowany jako profil UML. Procesy metodyki PMBOK zostały zamodelowane [27] na podstawie otwartego oprogramowania EPF (Eclipse Process Framework [29]) rozwijanego przez organizacje Eclipse i firmę IBM. Rysunek 2.16 przedstawia utworzony w EPF model procesu opracowania karty projektu w SPEM z uwzględnieniem czynności procesu, natomiast rysunek 2.15 przedstawia uproszczony model powiązania ról z czynnościami w procesie opracowania karty projektu. Rys Uproszczony model powiązania ról z czynnościami w procesie opracowania karty projektu 41

43 Rys Model procesu opracowania karty projektu w SPEM z uwzględnieniem czynności procesu 42

44 2.8. Dyscypliny PMBOK W PMBOK wyróżnia się dodatkowy sposób podziału procesów na tak zwane obszary wiedzy. Podział ten jest wykorzystywany do szybszego przyswajania wiedzy dotyczącej metodyki PMBOK. Wyróżniono dziewięć obszarów wiedzy numerowanych w standardzie od 4 do 12 (tab. 2.10): 1. Procesy zarządzania integracją projektu (Project integration management). 2. Procesy zarządzania zakresem projektu (Project scope management). 3. Procesy zarządzania czasem projektu (Project time management). 4. Procesy zarządzania kosztem projektu (Project cost management). 5. Procesy zarządzania jakością projektu (Project quality management). 6. Procesy zarządzania zasobami ludzkimi projektu (Project human resource management). 7. Procesy zarządzania komunikacją projektu (Project communications management). 8. Procesy zarządzania ryzykiem projektu (Project risk management). 9. Procesy zarządzania kontraktami projektu (Project procurement management). Takie pogrupowanie procesów ułatwia zrozumienie standardów ze względu na podobną tematykę oraz silniejsze wzajemne powiązanie procesów. Należy odróżniać grupowanie procesów w ramach obszarów wiedzy (dyscyplin) od grupowania procesów według pewnego porządku czasowego. Tabela 2.10 dobrze ilustruje takie powiązania pomiędzy grupami. Tabela 2.10 Procesy standardu PMBOK z podziałem na grupy Obszar wiedzy Grupy procesów zarządzania projektami inicjalizacji planowania wykonania monitorowania i kontroli zamknięcia 4. Zarządzanie integracją projektu 4.1. Tworzenie karty projektu 4.2. Tworzenie planu zarządzania projektem 4.3. Kierowanie i zarządzanie wykonaniem projektu 4.4. Monitorowanie i kontrolowanie wykonania projektu 4.5. Przeprowadzenie zintegrowanej kontroli zmian 4.6. Zamykanie projektu lub fazy 5. Zarządzanie zakresem projektu 5.1. Pozyskiwanie wymagań 5.2. Definiowanie zakresu 5.3. Tworzenie SPP 5.4. Weryfikowanie zakresu 5.5. Kontrola zakresu 43

45 Tabela cd. 6. Zarządzanie czasem projektu 6.1. Definiowanie działań 6.2. Szeregowanie działań 6.3. Szacowanie zasobów dla działania 6.4. Szacowanie czasów trwania działania 6.5. Tworzenie harmonogramu 6.6. Kontrolowanie harmonogramu 7. Zarządzanie kosztem projektu 7.1. Szacowanie kosztów 7.2. Wyznaczanie budżetu 7.3. Kontrolowanie kosztów 8. Zarządzanie jakością projektu 8.1. Zaplanowanie jakości 8.2. Zapewnienie jakości 8.3. Kontrolowanie jakości 9. Zarządzanie zasobami ludzkimi projektu 9.1. Planowanie rozwoju zasobów ludzkich 9.2. Rekrutacja do zespołu projektowego 9.3. Budowanie zespołu projektowego 9.4. Zarządzanie zespołem projektowym 10. Zarządzanie komunikacją w projekcie Identyfikowanie interesariuszy Zaplanowanie komunikacji Rozprowadzanie informacji Zarządzanie oczekiwaniami interesariuszy Raportowanie wydajności 11. Zarządzanie ryzykiem projektu Zaplanowanie zarządzania ryzykiem Identyfikowanie ryzyka Przeprowadzenie jakościowej analizy ryzyka Przeprowadzenie ilościowej analizy ryzyka Zaplanowanie reakcji na ryzyko Monitorowanie i kontrola ryzyka 12. Zarządzanie kontraktami projektu Planuj kontrakty Realizuj kontrakty Administruj kontraktami Zamykaj kontrakty 44

46 2.9. Narzędzia i techniki metodyki PMBOK Warsztat w PMBOK będzie tworzył zespół elementów, z których korzysta wykonawca procesu przy wykonywaniu działań. Elementami warsztatu są narzędzia i techniki (ang. tools and techniques). W standardzie PMBOK kładzie się mocny nacisk na zdefiniowanie zestawu sprawdzonych technik i narzędzi wspomagających pracę związaną z zarządzaniem projektem. Każdy proces opisany jest za pomocą zestawu szeroko rozumianych technik, które wykorzystywane są podczas jego realizowania. Wyróżnia się sześć podstawowych grup narzędzi i technik: 1. Analiza graficzna lub prezentacja danych np. diagram Ishikawy lub diagram Pareto. 2. Techniki i modele formalne np. analiza wrażliwości, symulacje. 3. Narzędzia komputerowe. 4. Narzędzia proceduralne np. system zarządzania zmianami. 5. Opis czynności koniecznych podczas realizacji procesu np. konferencje. 6. Ocena eksperta. W procesach PMBOK nie ma konieczności użycia wszystkich narzędzi i technik, dlatego podczas modelowania procesów zastosowano bramki decyzyjne, w których kierownik projektu lub zespół projektowy podejmuje decyzje, co powinno być użyte. Rysunek 2.17 prezentuje przykładowe rozwiązanie tego problemu. Rys Wycinek z procesu szacowania czasu trwania działań pokazujący przykład zamodelowania wyboru narzędzi i technik Ten fragment procesu polega na szacowaniu czasu trwania aktywności w projekcie. Do tego celu służą różne narzędzia i techniki, jednak w tym przypadku nie muszą być stosowane wszystkie z nich, stąd decyzja o użyciu bramek OR notacji BPMN. W standardzie PMBOK wyróżniono aż 129 technik i praktyk, co powoduje że dla jednego procesu proponuje się użycie warsztatu zawierającego średnio powyżej trzech technik i narzędzi. Tabela 2.11 zawiera alfabetyczną listę narzędzi i technik. Zestaw ten daje pogląd co do obszerności metodyki dotyczącej sugerowanych narzędzi i technik, natomiast od kierownika projektu i zespołu projektowego zależy, które z nich zostaną użyte. Metodyka ta zezwala oczywiście na użycie innych rozwiązań, niezdefiniowanych w jej opisie. 45

47 Tabela 2.11 Alfabetyczna lista technik i narzędzi dla wersji 4 standardu PMBOK Nr Narzędzia i techniki Liczba procesów Grupa procesów 1. Administrowanie skargami (Claims Administration) 1 MiK 2. Agregacja kosztów (Cost Agregation) 1 P 3. Analiza alternatyw (Alternatives Analysis) 1 P 4. Analiza harmonogramu sieciowego (Schedule Network Analysis) 1 P 5. Analiza interesariuszy (Stakeholders Analysis) 1 I 6. Analiza kosztów i zysków (Cost-Benefi t Anlaysis) 1 P 7. Analiza listy kontrolnej (Checklist Analysis) 1 P 8. Analiza ofert sprzedawców (Vendor Bid Analysis) 1 P 9. Analiza procesowa (Process Analysis) 1 P 10. Analiza produktu (Product Analysis) 1 P 11. Analiza rezerw (Reserve Analysis) 4 P, MiK 12. Analiza scenariuszy warunkowych (What-If Scenario Analysis) 2 P, MiK 13. Analiza SWOT (SWOT Analysis) 1 P 14. Analiza wariancji (Variance Analysis) 4 MiK 15. Analiza wariancji i trendów (Variance and Trend Analysis) 1 MiK 16. Analiza wykonania lub kupna (Make-or-Buy Analysis) 1 P 17. Analiza wymagań komunikacyjnych (Communication Requirements Analysis) 1 P 18. Analiza założeń (Assumptions Analysis) 1 P 19. Audyty jakości (Quality Audits) 1 W 20. Audyty kontraktów (Procurement Audits) 1 Z 21. Audyty ryzyka (Risk Audits) 1 MiK 22. Badania porównawcze (Benchmarking) 1 P 23. Dekompozycja (Decomposition) 2 P 24. Diagram rozrzutu (Scatter Diagram) 1 MiK 46

48 Tabela cd. 25. Diagramy organizacyjne i opisy stanowisk (Organization Charts and Position Description) 1 P 26. Diagramy Pareto (Pareto Chart) 1 MiK 27. Diagramy trendów (Run Chart) 1 MiK 28. Diagramy przepływów (Flowcharting) 2 MiK, P 29. Dodatkowe narzędzia do planowania jakości (Additional Quality Planning Tools) 30. Dostosowanie przyspieszenia lub opóźnienia działań (Adjusting Leads and Lags) 31. Dowody uznania i nagradzanie (Recognition and Rewards) 1 P 1 MiK 1 W 32. Działania budowy zespołu (Team-Building Activities) 1 W 33. Histogram (Histogram) 1 MiK 34. Identyfikacja alternatyw (Alternatives Identifi cation) 1 P 35. Inspekcje (Inspection) 2 MiK 36. Inspekcje i audyty (Inspections and Audits) 1 MiK 37. Integracja (Networking) 1 P 38. Karty kontroli jakości (Control Charts) 2 P, MiK 39. Kategoryzacja ryzyka (Risk Categorization) 1 P 40. Kolokacja (Co-location) 1 W 41. Kompresja harmonogramu (Schedule Compression) 2 P, MiK 42. Konferencje przetargowe (Bidder Conferences) 1 W 43. Koszty jakości (Cost of Quality (COQ)) 2 P 44. Kwestionariusz i przegląd (Questionnaires and Surveys) 1 P 45. Macierz prawdopodobieństwa i wpływów (Probability and Impact Matrix) 46. Metoda diagramów poprzedzania (Precedence Diagramming Method (PDM)) 1 P 1 P 47. Metoda łańcucha krytycznego (Critical Chain Method) 1 P 48. Metoda ścieżki krytycznej (Critical Path Method) 1 P 49. Metody komunikacji (Communication Methods) 4 P, W, MiK 50. Metody prognozowania (Forecasting Methods) 1 MiK 47

49 Tabela cd. 51. Modele komunikacji (Communication Models) 1 P 52. Nabór (Acquisition) 1 W 53. Narzędzia do rozprowadzania informacji (Information Distribution Tools) 1 W 54. Narzędzia harmonogramowania (Scheduling Tool) 2 P, MiK 55. Narzędzia i techniki planowania i kontroli jakości (Plan Quality and Perform Quality Control Tools and Techniques) 1 W 56. Negocjacje (Negotiation) 1 W 57. Negocjacje kontraktu (Procurement Negotiations) 1 W 58. Negocjowanie rozstrzygnięcia (Negotiated Settlements) 1 Z 59. Niezależne oszacowania (Independent Estimates) 1 W 60. Obserwacja i konwersacja (Observation and Conversation) 1 W 61. Obserwacje (Observations) 1 P 62. Ocena jakości danych dla ryzyka (Risk Data Quality Assessment) 1 P 63. Ocena pilności ryzyka (Risk Urgency Assessment) 1 P 64. Ocena prawdopodobieństwa i wpływu ryzyka (Risk Probability and Impact Assessment) 65. Ocena wydajności projektu (Project Performance Appraisals) 1 P 1 W 66. Opinia eksperta (Expert Judgment) 19 I, P, W, MiK, Z 67. Oprogramowanie do szacowania w zarządzaniu projektami (Project Management Estimating Software) 68. Oprogramowanie zarządzania projektem (Project Management Software) 1 P 3 P, MiK 69. Oszacowanie parametryczne (Parametric Estimating) 2 P 70. Oszacowanie przez analogię (Analogous Estimating) 2 P 71. Oszacowanie trójpunktowe (Three-Point Estimates) 2 P 72. Oszacowanie wstępujące (Bottom-Up Estimating) 2 P 73. Plan zapasowy (Contingent Response Startegies) 1 P 74. Planowanie kroczące (Rolling Wave Planning) 1 P 48

50 Tabela cd. 75. Planowanie spotkań i analiza (Planning Meeting and Analysis) 1 P 76. Podstawowe zasady (Ground Rules) 1 W 77. Pomiary technicznej wydajności (Techniccal Performance Measurment) 1 MiK 78. Ponowna ocena ryzyka (Risk Reassessment) 1 MiK 79. Powiązania historyczne (Historical Relatiionships) 1 MiK 80. Prognozowanie (Forecasting) 1 MiK 81. Projektowanie eksperymentów (Design of Experiments (DOE)) 1 P 82. Prototypy (Prototypes) 1 P 83. Próbkowanie statystyczne (Statistical Sampling) 2 P, MiK 84. Przeglądy dokumentacji (Documentation Reviews) 1 MiK 85. Przeglądy wydajności (Performance Reviews) 2 MiK 86. Przeglądy wydajności kontraktu (Procurement Performance Reviews) 87. Przeglądy zatwierdzonych żądań zmian (Approved Change Requests Review) 1 MiK 1 MiK 88. Przeprowadzenie wywiadu (Interviews) 1 P 89. Publikowanie oszacowania (Published Estimating Data) 1 P 90. Raportowanie wydajności (Performance Reporting) 1 MiK 91. Rejestr spraw (Issue Log) 1 W 92. Reklama (Advertising) 1 W 93. Specyficzne metodologie zarządzania jakością (Proprietary Quality Management Methodologies) 1 P 94. Spotkania kontroli zmian (Change Control Meetings) 1 MiK 95. Spotkania oceny stanu (Status Meetings) 1 MiK 96. Strategie reakcji na ryzyko mające negatywny skutek zagrożenia (Strategies for Negative Risk or Threats) 97. Strategie reakcji na ryzyko mające pozytywny skutek szanse (Startegies for Positive Risk Or Opportunities) 98. System kontroli zmian kontraktu (Contract Change Control System) 1 P 1 P 1 MiK 49

51 Tabela cd. 99. System zarządzania dokumentami (Records Management System) 2 MiK 100. Systemy płatności (Payment Systems) 1 MiK 101. Systemy raportujące (Reporting Systems) 1 MiK 102. Szablony (Templates) 1 P 103. Szablony harmonogramów sieciowych (Schedule Network Templates) 1 P 104. Szkolenia (Training) 1 W 105. Techniki analizy i modelowania ilościowego ryzyka (Quantitative Risk Analysis and Modeling Techniques) 1 P 106. Techniki diagramów (Diagramming Techniques) 1 P 107. Techniki kreatywności grupowej (Group Creativity Techniques) 108. Techniki oceny propozycji (Proposal Evaluation Techniques) 109. Techniki podejmowania decyzji grupowych (Group Decision Making Techniques) 110. Techniki zbierania i prezentowania danych (Data Gathering and Representation Techniques) 111. Techniki zbierania informacji (Information Gathering Techniques) 112. Technologia komunikacyjna (Communication Technology) 1 P 1 W 1 P 1 P 1 P 1 P 113. Teoria organizacji (Organizational Theory) 1 P 114. Typy kontraktów (Contract Types) 1 P 115. Umiejętności interpersonalne (Interpersonal Skills) 3 W 116. Umiejętności zarządzania (Management Skills) 1 W 117. Uzgodnienie limitów funduszy (Funding Limit Reconciliation) 1 P 118. Warsztaty wspomagające (Facilitated Workshops) 2 P 119. Wskaźnik wydajności do zakończenia projektu (To-Complete Performance Index) 1 MiK 120. Wstępny przydział zasobów (Pre-Assignment) 1 W 121. Wykresy przyczynowo-skutkowe (Cause and Effect Diagrams) 1 MiK 50

52 Tabela cd Wyrównanie obciążenia zasobów (Resource Leveling) 2 P, MiK 123. Wyszukiwanie internetowe (Internet Search) 1 W 124. Wyznaczanie zależności (Dependency Determination) 1 P 125. Zarządzanie konfliktem (Confl ict Management) 1 W 126. Zarządzanie wartością wypracowaną (EarnedValue Management) 127. Zastosowanie przyspieszenia lub opóźnienia działań (Applying Leads and Lags) 1 MiK 2 P 128. Zespoły wirtualne (Virtual Teams) 1 W 129. Zogniskowany wywiad grupowy (Focus groups) 1 P W standardzie PMBOK nie ma bezpośredniego odniesienia do praktyk. Natomiast w standardzie OPM3 [5] podawane są najlepsze praktyki (ang. best practices) opracowane przez PMI. Część z tych praktyk odnosi się bezpośrednio do zarządzania projektem Wnioski W opracowaniu przedstawiono systematyczny opis klasycznej metodyki zarządzania projektami PMBOK z podziałem na zasady, zdarzenia, artefakty, role, procesy, dyscypliny i warsztat. Na podstawie przedstawionego opisu opracowano kompletne modele metodyki w DPD, BPMN oraz SPEM. W wyniku tego stwierdzono istnienie wielu nieścisłości standardu [24, 26]. Literatura [1] A Guide to the Project Management Body of Knowledge, Fourth Edition (PMBOK Guide), Approved American National Standard ANSI/PMI , PMI, 2008 [2] A Guide to the Project Management Body of Knowledge, Fourth Edition (PMBOK Guide), Wydanie polskie Kompendium wiedzy o zarządzaniu projektami, MT&DC, 2009 [3] The Standard for Program Management, Second Edition, Approved American National Standard ANSI/PMI , PMI 2008 [4] The Standard for Portfolio Management, Second Edition, Approved American National Standard, Approved American National Standard ANSI/PMI , PMI, 2008 [5] Organizational Project Management Maturity Model (OPM3), Second Edition, Knowledge Foundation, An American National Standard ANSI/PMI , PMI,

53 [6] Practice Standard for Scheduling, PMI, 2011 [7] Practice Standard for Risk Management, PMI, 2009 [8] Practice Standard for Work Breakdown Struktures, PMI, 2006 [9] Practice Standard for Project Confi guration Management, PMI, 2007 [10] Practice Standard for Earned Value Management, PMI, 2004 [11] Practice Standard for Project Estimating, PMI, 2011 [12] Government Extension to the (PMBOK Guide), Third Edition, PMI, 2006 [13] Construction Extension to the (PMBOK Guide), Second Edition, PMI, 2007 [14] Project Manager Competency Development Framework, Second Edition, PMI, 2007 [15] Code of Ethics and Professional Conduct, Project Management Institute, About-Us/Ethics/~/media/PDF/Ethics/ap_pmicodeofethics.ashx [16] Project Management Professional (PMP ), Credential Handbook, PMP, [17] Certified Associate in Project Management (CAPM ), Credential Handbook, PMI, [18] Mulcahy R.: PMP Exam Prep, Sixth Edition Aligned with the PMBOK Guide Fourth Edition, RMC Publications, Inc, 2009 [19] Greene J., Stellman A.: Head First PMP : ABrain-friendly Guide to Passing Management Professional Exam, 2 nd Edition Covers Guide Fourth Edition, O Reilly 2009 [20] Crowe A.: The PMP Exam. How to pass on your fi rst try, Based on the 4 th Edition of the PMBOK Guide, Velocityteach 2009 [21] Heldman K.: PMP Project Management Professional Exam Study Guide, Fifth Edition, Updated for PMBOK Guide Fourth Edition, SYBEX 2009 [22] LeRoy Ward J., Levin G.: PMP Exam. Practice Test and Study Guide, ESI Int. Eight Edition, 2009 [23] Wrona A.: Zastosowanie DFD i BPMN do modelowania biznesowego procesów w oparciu o metodykę PMBOK, praca magisterska (promotor J. Werewka), AGH, Wydział EAEiI, Kraków 2009 [24] Werewka J., Wrona A.: Weryfikacja modelu procesowego standardu PMBOK przy użyciu diagramów DFD (ang. Verification of PMBOK process model with DFD diagrams), CSL R&D Report 4/0/2009, Laboratorium Informatyki, Katedra Automatyki, Wydział EAIiE, AGH Kraków [25] Krużel T., Modelowanie metodyki zarządzania projektami informatycznymi przy użyciu standardu BPMN, praca magisterska (promotor J. Werewka), AGH, Wydział EAEiI, Kraków 2011 [26] Krużel T., Werewka J.: Application of BPMN for the PMBOK standard modeling to scale project management efforts in IT enterprise, Information as the Intangible Assets and Company Value Source, Library of Informatics of University Level Schools, Wrocław 2011, s [27] Pytka D.: Zagadnienie konstrukcji bibliotek procesów wytwarzania oprogramowania, praca magisterska (promotor J. Werewka), AGH, Wydział EAEiI, Kraków 2012 [28] Hommes B.-J., van Reijswoud V.: Assessing the Quality of Business Process Modeling Techniques, 33rd Hawaii International Conference on System Sciences-Volume, IEEE, 2000 [29] Eclipse Process Framework Project (EPF),

54 3. Systematyczny opis metodyki Scrum dla zespołów projektowych 3.1. Zagadnienie konstrukcji systematycznego opisu metodyk wytwarzania i zarządzania Metodyki wytwarzania oprogramowania oraz zarządzania projektami opisywane są przeważnie nieformalnie i na różnorodne sposoby. Firmy informatyczne próbujące wykorzystać metodyki w praktyce często borykają się z ustaleniem istotnych informacji opisujących metodyki i różnice pomiędzy nimi. Nieprzerwanie rozwijane są metody i narzędzia do wiarygodnego opisu różnego typu systemów. Coraz większe znaczenie zdobywają modele ontologiczne uzupełnione o modele procesów np. w notacji BPMN (ang. Business Process Modeling Notation). Autorzy pracy obrali taki właśnie kierunek [14, 15]. Opracowane w ten sposób modele wymagają weryfikacji pod względem zgodności z pierwowzorem poprzez uzyskanie opinii ekspertów. W niniejszym opracowaniu w wyniku rozważań nad modelem ontologicznym [16] przedstawiono opis metodyki Scrum po wstępnej weryfikacji z ekspertami dziedzinowymi. W celu opisu różnych metodyk w obszarze zarządzania projektami i wytwarzania oprogramowania proponuje się użycie metamodelu. Metamodel będzie polegał na utworzeniu języka zdolnego do opisu różnych metodyk. Z jednej strony metamodel będzie służył do ograniczenia sposobu definiowania pojęć reprezentujących różne metodyki, zaś z drugiej strony model musi być na tyle ogólny, by nie ograniczał i nie zmieniał opisywanych metodyk. Zastosowany metamodel będzie polegał na konceptach oraz zbiorze konceptów o pewnej strukturze. Koncept jest jednostką myśli, która może być zdefiniowana lub opisana. Do opisu metodyk przyjęto zestaw podstawowych konceptów, przy czym w opracowaniu ograniczono się do pięciu podstawowych. Są to: Uniwersalne zasady (pryncypia). Zasady te są wytycznymi do tych działań w metodykach, które nie zostały dokładnie opisane. Działania takie powinny być zgodne z uniwersalnymi zasadami. Uniwersalne zasady postępowania mogą zależeć między innymi od tego, czym się kierujemy (np. wizji, norm które uznajemy oraz wyznawanych wartości) oraz od tego, co i jak robimy (np.: misji, postulatów, polityki). Artefakty. Wszystko to, co powstaje w trakcie wykonania prac projektu (np. wyroby, przedmioty, dokumenty, wzory zachowań). 53

55 Role. Rola oznacza wirtualną osobę, która jest w stanie wykonywać pewien zbiór czynności. Do tworzenia artefaktów potrzebne są osoby wykonujące pewne role. Procesy. Proces jest to zespół czynności, w wyniku którego powstają artefakty. Zdarzenia. Zjawiska, które występują w trakcie wykonania projektu. Konstruując opisy metodyk zarządzania projektami, wyszczególniono zdarzenia i procesy. Ważne jest zrozumienie różnicy obu pojęć. Zdarzenia są zdefiniowane poprzez relacje czasowe (czas wystąpienia, trwania itd.) oraz własności (uczestnicy, miejsce, przedmiot uwagi) i nie wytwarzają żadnych artefaktów. Procesy transformują wejścia w wyjścia i są uruchamiane podczas zdarzeń lub w wyniku pojawienia się zdarzenia. Zaproponowany metamodel zastosowano do opisu części metodyki Scrum dotyczącej spojrzenia na metodykę głównie z punktu widzenia zespołu i roli zwanej Scrum Masterem. Zaproponowany opis nie zmienia oraz nie poprawia metodyki. Opis ten ma za zadanie w sposób możliwie wierny opisać metodykę, nie powodując jej zmian. Przedstawiony opis zawiera procesy obejmujące około 90% prac zespołu. Zakłada się, że pozostała część metodyki przedstawiona zostanie w osobnym opracowaniu. Opracowanie takie będzie dotyczyć głównie spojrzenia na metodykę z punktu widzenia właściciela produktu i kierownictwa firmy. W opisie tym uwzględni się m.in. wizję produktu, wydania produktu, usuwanie blokad oraz pozostałe 10% prac zespołu przeznaczonych na wspomaganie prac właściciela produktu związanych z estymacją, definicją kryteriów gotowości i wykonania itp. Metodyki zarządzania projektami dzielimy na dwie podstawowe kategorie: klasyczne zorientowane na plan i zwinne zorientowane na zmiany produktu. Metodyki zwinne, określane w literaturze anglojęzycznej terminem agile (zwinny, sprawny, rzutki, zwrotny), w ostatnich kilku latach zdobywają coraz większą popularność przy produkcji oprogramowania różnej skali, w większości obszarów i domen. Znajdują one zastosowanie szczególnie w tworzeniu systemów i realizacji projektów, które obarczone są ryzykiem lub w ich przypadku istnieją pewne niewiadome. Podstawowymi argumentami za wykorzystaniem metodyk zwinnych są: zwiększona podatność na dokonywanie zmian (wymagań, technologii) w projekcie, lepsza kontrola ryzyka, a także osiąganie w warunkach zmian wysokiej zbieżności wytworzonego produktu z oczekiwaniami odbiorcy oprogramowania, przede wszystkim poprzez wczesne (w cyklu życia projektu) i nieprzerwane dostarczanie wysokiej jakości produktu. W literaturze polskiej czasami utożsamia się metodyki lekkie z metodykami zwinnymi. W tym opracowaniu metodykę lekką rozumie się jako metodykę, z której usunięto wszystko co nadmiarowe. Naszym zdaniem lekkość metodyki nie implikuje jej zwinności. Przykładowo można opracować lekką metodykę wykonywania pracy w pewnego typu urzędach. Metodyka taka może okazać się jednak mało elastyczna wobec konieczności wprowadzenia zmian w opisywanych przez nią procesach lub w przypadku zastosowania jej w innych instytucjach. Zakładamy jednak, że metodyka zwinna powinna być lekka, wymaga bowiem sprawnego reagowania na zachodzącą w projekcie zmianę. Zbyt duże obciążenie wymogami formalnymi (procesami, procedurami) ogranicza zwinność, nie tylko ze względu na nakład pracy potrzebny do osiągnięcia zgodności z regułami metodyki, ale również powoduje konieczność wykonania dodatkowych prac związanych z dostosowywaniem metodyki do nowej sytuacji. 54

56 3.2. Scrum geneza i rozwój Podstawowe założenia metodyki wywodzą się z prac prof. Hirotaka Takeuchi i Ikujiro Nonaka. Prace te są wynikiem studiów procesów wytwórczych przeprowadzonych w ponadnarodowych koncernach. W swojej publikacji pt. The New New Product Development [4], uważanej powszechnie za źródło inspiracji metodyki Scrum, wśród kilku opisywanych typów procesów autorzy opisali także tzw. podejście holistyczne (całościowe), najbardziej ich zdaniem efektywne w wytwarzaniu innowacyjnych produktów. Zdaniem autorów dopiero ujęcie holistyczne umożliwia uzyskanie oczekiwanej produktywności i elastyczności procesu. Planowanie w takim procesie z założenia jest planowaniem adaptacyjnym, a sam proces jest procesem empirycznym. Zainspirowani sportem w opisie procesu holistycznego przytaczają strategię gry w rugby, w szczególności formację młyna (ang. Scrum), jako dobrą metaforę odzwierciedlającą zestaw reguł obowiązujących zespoły realizujące podejście holistyczne. H. Takeuchi i I. Nonaka wyszczególnili sześć cech, którymi ich zdaniem powinien charakteryzować się proces holistyczny. Są to kolejno: Wbudowana niestabilność, rozumiana jako duża autonomia działania zespołu, którego zadaniem jest opracowanie innowacyjnego produktu o strategicznym znaczeniu, a co za tym idzie bez szczegółowych wytycznych co do postaci końcowej produktu. Nowy, innowacyjny produkt oznacza nowy proces, zatem wiedza z poprzednich projektów nie może zostać bezpośrednio zastosowana. Zespołowi, osobom najbardziej kompetentnym w kwestii doboru narzędzi i procedur, pozostawiana jest swoboda w wyborze szczegółowych rozwiązań oraz sposobu, w jaki cel strategiczny zostanie osiągnięty. Naczelne kierownictwo występuje w roli katalizatora, pełniąc rolę sponsora prac. Samoorganizacja zespołów, rozumiana jako rekonstrukcja struktury zespołu w kierunku zapewnienia jego autonomii, wypracowania kultury pracy zachęcającej do przekraczania ograniczeń i poszukiwania nowych wyzwań oraz wystąpienia elementu wzajemnej inspiracji pomiędzy członkami zespołu reprezentującymi odrębne doświadczenie, kwalifikacje i sposoby myślenia. Członkowie zespołu są zachęcani do podejmowania inicjatywy, ryzyka i odpowiedzialności za swoje działania, współpracy, koncentracji na rozwiązywaniu problemów i rozwijania zróżnicowanych umiejętności. Członkowie zespołu wypowiadają się we wszystkich niemal obszarach działalności, a procesy są przez nich definiowane i stosowane tam, gdzie rzeczywiście są potrzebne. Proces wytwórczy ulega zatem ciągłej rekonfiguracji dopasowaniu do rzeczywistych potrzeb. Zachodzące na siebie fazy (etapy) rozwoju produktu, pozwalające na ograniczenie liczby przekazań produktu pomiędzy grupami czy stanowiskami. Podejście takie skutkuje skróceniem całkowitego czasu realizacji projektu o około 30%. Możliwe jest to poprzez samoistne dopasowanie współpracujących ze sobą członków zespołu, a także podwykonawców i odbiorców. Takie zsynchronizowanie wzajemnych interesów nazwane zostało rytmem (pulsem) i określone jako cecha charakteryzująca dany zespół projektowy i tym samym nie może to stanowić stałego elementu procesu wytwórczego, a jedynie jego ogólną wytyczną. Dodatkowo, aby taki puls mógł się pojawić, istotne jest zapewnienie stabilności składu osobowego zespołu. 55

57 Nabywanie wszechstronnej wiedzy (multilearning), rozumiane jako kultywowanie procesu ciągłego nabywania nowych umiejętności i wiedzy przez członków zespołu, a także wykraczanie w tym procesie poza dotychczasową domenę ekspertyzy. Proces ten powinien zaistnieć przede wszystkim dzięki podejmowaniu kolejnych prób i wyciąganiu wniosków z popełnionych błędów, ale także dzięki wymianie wiedzy pomiędzy członkami multifunkcjonalnego zespołu. Bezpośredni kontakt ze specjalistami z różnych dziedzin powoduje, iż wszyscy członkowie zespołu nabywają szerokiej wiedzy wykraczającej poza ich początkowe kwalifikacje, dzięki czemu zespół jest w stanie pokonywać bariery i przełamywać status quo (eksperci, często kierując się rutyną, podążają utartymi ścieżkami, podczas gdy nowicjusze, nie wiedząc, że tak się nie da, osiągają cel). W procesie pozostawiono zatem znaczący margines na błędy i zarezerwowano czas na ich naprawę oraz samodoskonalenie. Subtelna kontrola, pojęcie to opisuje proces kontroli, który z jednej strony nie ogranicza kreatywności i spontaniczności jednostki, a z drugiej zabezpiecza zespół i co za tym idzie całą organizację przed popadnięciem w chaos. Element kontroli jest obecny w procesie holistycznym zarówno pod postacią punktów kontrolnych wyznaczanych przez naczelne kierownictwo, sprawdzające zgodność postępów prac z wyznaczonym celem strategicznym, jak również pod postacią presji utrzymywania wysokich standardów pracy płynącej ze strony współpracowników. H. Takeuchi i I. Nonaka zwracają uwagę na fakt, iż celem subtelnej kontroli jest wytworzenie kultury ciągłego doskonalenia, a nie wytykanie pomyłek. Pomocny w tym procesie jest wspólny dla wszystkich członków zespołu zestaw wartości. Niezakłócony transfer wiedzy, rozumiany jako swobodny przepływ informacji pomiędzy zainteresowanymi stronami, ale także transfer doświadczenia z jednego zespołu do innych w obrębie danej organizacji. Członkowie pierwotnego zespołu zakładając nowe komórki (zespoły), przekazują nie tyle wiedzę merytoryczną, ile kulturę pracy. Instytucjonalizacja procesów (przenoszenie rozwiązań z przeszłości do teraźniejszości) może być zagrożeniem dla uczenia się organizacji i przełamywania status quo [6]. Podejście H. Takeuchiego i I. Nonaki jednoznacznie wskazuje na korzyści zastosowania podejścia holistycznego w branżach wymagających innowacyjności i charakteryzujących się dużą zmiennością oczekiwań odbiorców a takimi przecież cechami niewątpliwie odznacza się branża IT. Wśród potencjalnych ograniczeń H. Takeuchi i I. Nonaka wskazują natomiast na trudności zastosowania tego podejścia w wytwarzaniu rozległych systemów, a także w silnie scentralizowanych organizacjach, których rozwój produktu realizowany jest pod dyktando wąskiego grona ekspertów. Zwracają oni także uwagę na trudności związane z restrukturyzacją przedsiębiorstw podczas przechodzenia na nowy sposób działania. Rozważania H. Takeuchiego i I. Nonaki, nawiązujące do formacji młyna jako metafory zespołu projektowego realizującego podejście holistyczne, były bezpośrednią inspiracją dla Kena Schwabera, Jeffa Sutherlanda i Mike a Beedle a do opracowania metodyki postępowania przy realizacji projektów informatycznych [8]. W metodyce Scrum zawartych jest wiele nawiązań do wyszczególnionych powyżej postulatów Manifestu Agile oraz cech procesu holistycznego. Z formalną definicją metodyki Scrum w zastosowaniu do projektów informatycznych wystąpił Ken Schwaber podczas konferencji OOPSLA w 1995 roku [1]. W chwili obecnej Scrum wydaje się najbardziej rozpowszechnioną wśród metodyk zwinnych zarządzania. Scrum skupia się na kwestiach zarządzania projektem oraz organiza- 56

58 cji pracy zespołu. Badanie stanu wykorzystania metodyk zwinnych przeprowadzone przez VersionOne Inc. w 2010 roku, w którym udział wzięło blisko pięć tysięcy respondentów, wskazało 58-procentowy udział Scrum i 17-procentowy udział hybrydy Scrum z programowaniem ekstremalnym (XP) [13]. Pozostałe metodyki, do których należą AgileUP, FDD, Lean Development, DSDM, OpenUP, Agile Modeling, Crystal, łącznie nie przekraczają progu 20%. Pozostałą część udziałów stanowią zwinne metodyki autorskie dostosowane i opracowane na potrzeby danego przedsiębiorstwa Postulaty metodyk zwinnych Metodyka Scrum nie jest opisana w dokumencie o charakterze standardu. Zwykle po opracowaniu nowego rozwiązania związanego z metodyką Scrum autor odwołuje się do wiodących prac uznanych autorytetów. Dokonując analiz opracowań zgromadzonych w dużej mierze wokół organizacji popularyzujących metodykę Scrum Scrum Alliance [11] i Scrum.org [12] autorzy pracy wydzielili sześć uniwersalnych zasad (rys. 3.1), które są uznawane w różnych opracowaniach związanych z metodyką Scrum. Są to: podejście holistyczne, zasady manifestu agile, samoorganizacja zespołu, wartości zespołu, empiryzm procesów metodyki, normatywny charakter metodyki. Rys Uniwersalne zasady Scrum Podejście holistyczne. Podejście całościowe przedstawione zostało przez H. Takeuchi i I. Nonaka [4, 6], którzy wyszczególnili sześć cech charakterystycznych poprawnego procesu holistycznego. W podejściu holistycznym na proces należy patrzeć jak na układ całościowy, a całości nie da się sprowadzić do sumy składników. Cechy procesu holistycznego zostały opisane dokładnie w poprzednim podrozdziale. 57

59 Zasady Manifestu Agile. Manifest Zwinnego Wytwarzania Oprogramowania [3] jest wykładnią postępowania, a zasady metodyki opierają się na jego pryncypiach. Wszyscy twórcy metodyki Scrum: Ken Schwaber, Jeff Sutherland i Mike Beedle są współautorami tego dokumentu. W roku 2001 reprezentanci nowego nurtu w sposobie wytwarzania oprogramowania wypracowali kilka uniwersalnych twierdzeń i wytycznych opisujących nowe podejście. Ogłoszono je pod postacią tzw. Manifestu zwinnego wytwarzania oprogramowania (ang. Manifesto for Agile Software Development) [3]. Manifest ten, nazywany w skrócie Manifestem Agile, deklaruje wspólne dla wszystkich metodyk zwinnych, postulaty wartościujące składowe procesu wytwarzania oprogramowania. W podejściu zwinnym przedkłada się: ludzi i współpracę ponad procesy i narzędzia, działające oprogramowanie ponad obszerną dokumentację, współpracę z klientem ponad negocjowanie kontraktu, reagowanie na zmiany ponad podążanie za planem. Dla wyjaśnienia w manifeście dodane jest zdanie: Oznacza to, że wprawdzie doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co jest po stronie lewej. Manifest Agile uzupełnia zbiór 12 zasad, nazywanych pryncypiami, do których stosowania nawołują autorzy manifestu: Najwyższym priorytetem jest zaspokajanie potrzeb klienta, dokonywane poprzez wczesne i częste dostarczanie wartościowego oprogramowania. Zmiany wymagań są przyjmowane z aprobatą, nawet jeśli występują późno w cyklu rozwoju. Procesy zwinne wykorzystują zmiany do uzyskania przez klienta przewagi konkurencyjnej. Działające oprogramowanie dostarczane jest często w odstępach od kilku tygodni do kilku miesięcy, z preferencją krótszych okresów. Osoby reprezentujące biznes muszą pracować razem z zespołem produkcyjnym dzień w dzień przez cały okres realizacji projektu. Projekty powstają na bazie motywacji osób biorących w nich udział. Udostępniane są im wszystkie niezbędne zasoby, ponadto osoby te obdarzane są zaufaniem, że ich praca zostanie wykonana. Najbardziej skutecznym i wydajnym sposobem przekazywania informacji do i w obrębie zespołu projektowego jest bezpośrednia rozmowa. Działające oprogramowanie jest głównym wskaźnikiem postępu. Procesy zwinne promują zrównoważone tempo rozwoju oprogramowania. Inwestorzy, zespół projektowy i użytkownicy powinni być w stanie utrzymywać stałe tempo bez końca. Ciągłe przywiązywanie wagi do technicznej doskonałości i architektury oprogramowania poprawia zwinność. Niezbędna jest prostota rozumiana jako sztuka maksymalizowania pracy, której nie trzeba wykonywać. Najlepsze możliwe: architektura, wymagania i projekty powstają w rezultacie pracy samoorganizujących się zespołów. W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć swoją efektywność, w efekcie czego dostraja i poprawia odpowiednio swoje zachowanie. 58

60 Punkt drugi powyższej listy postuluje, by procesy zwinne ujarzmiały zmiany w celu uzyskania przez klienta przewagi konkurencyjnej. Zdaniem autorów twierdzenie to może być również interpretowane jako wymóg wobec metodyki, by zmiany były ujarzmione. Oznacza to, że nie mogą one być w dowolny sposób przyjmowane. Sugerowana jest z jednej strony zwinność podejścia, z drugiej strony opracowanie zasad wprowadzania zmian w sposób kontrolowany. Przy tak dużym przyzwoleniu na wprowadzanie zmian w projekcie sprawne prowadzenie prac projektowych nie byłoby możliwe w sytuacji, gdy proces kontroli i adaptacji do zmian obejmowałby jedynie specyfikację wytwarzanego systemu. W związku z tym metodyki zwinne na równi z doskonaleniem produktu końcowego stawiają doskonalenie procesu wytwórczego. Takie podejście wymaga ustanowienia częstych punktów kontrolnych, które pozwolą nie tylko oceniać dotychczasowy przebieg przedsięwzięcia, ale także ustalać, jakie elementu procesu wytwórczego należy poddać modyfikacji w kolejnych etapach tak, aby osiągnąć najlepsze możliwe dopasowanie procesu do uwarunkowań budżetowych i terminowych realizowanego przedsięwzięcia. Samoorganizacja zespołu. Zespół Scrum jest z założenia zespołem samoorganizującym się, a więc powinien spełniać postulaty H. Takeuchiego i I. Nonaki, pod względem autonomii działania, międzyfunkcjonalności, wzajemnej kontroli służącej utrzymaniu wysokiej jakości pracy oraz kultury pracy promującej poszukiwanie nowych rozwiązań, a także przejmowania współodpowiedzialności za sukces przedsięwzięcia. Co równie istotne, organizacja wykorzystująca tę metodykę powinna zapewnić odpowiednie otoczenie i warunki sprzyjające istnieniu samoorganizacji (por. [6]). Wartości zespołu Scrum jako element również nawiązujący do postulatów H. Takeuchiego i I. Nonaki (subtelna kontrola) zostały zdefiniowane przez Kena Schwabera, Mike a Beedle a w następujący sposób [8]: Umiejętność podejmowania zobowiązania rozumiana jest jako silne poczucie związku z wyrażanymi opiniami i podejmowanymi działaniami oraz konsekwencja w ich realizacji. Przykładem może być podjęcie generalnego zobowiązania postępowania zgodnie z regułami metody Scrum zestawione z faktyczną determinacją w realizacji tego postanowienia wobec pojawiających się problemów. Koncentracja uwagi, bez której nie jest możliwe dogłębne rozumienie problemów i potrzeb, których rozwiązaniem ma być wytworzone oprogramowanie. Wobec dużej liczby dystraktorów obecnych w środowiskach dużych organizacji (zaangażowanie w poboczne projekty czy komunikacja ) łatwo o rozproszenie uwagi, co nie przyczynia się do uzyskania wysokiej efektywności i doskonałości technicznej wytwarzanego oprogramowania. Scrum wspomaga utrzymanie koncentracji poprzez wprowadzenie ograniczeń czasowych z jednoczesnym klarownym oznaczeniem celu. Otwartość wskazywana jest jako gotowość do dzielenia się informacją ze wszystkimi członkami zespołu, bez względu na charakter zgodny z oczekiwaniami czy nie tej informacji. Scrum wspomaga otwartość poprzez wbudowaną zasadę przejrzystości i klarowny rozdział odpowiedzialności. Wszystkie elementy metodyki Scrum w szczególności rejestry (backlogi), przyrost produktu, postęp prac są nie tylko jawne (dostępne dla wszystkich zainteresowanych), ale wręcz poddawane zespołowemu procesowi kontroli. Dodatkowo wyznacza się osobę stojącą na straży tej reguły. 59

61 Poszanowanie oznacza pozytywne odczucia jednej osoby względem drugiej i umiejętność budowania synergii przy uwzględnieniu silnych i słabych stron innych członków zespołu, różnic w doświadczeniu, wykształceniu i roli w zespole. Umiejętność budowania pozytywnych relacji zorientowanych na stawiany przed zespołem cel jest pożądaną cechą wspomagającą proces budowania zespołu. Cecha ta nie powinna ulegać wpływowi wzajemnych animozji, politykierstwa i innych negatywnych elementów codziennego życia każdej organizacji. Scrum funkcjonuje poprzez wykorzystanie samoorganizacji rozumianej jako powierzenie odpowiedzialności za realizację zadań zespołowi, a nie pojedynczym osobom. Zespół Scrum stanowi całość i jedność, więc tak jest postrzegany przez resztę organizacji, o czym wszyscy pracujący z zespołem Scrum powinni pamiętać. Odwaga jest elementem niezbędnym do istnienia i rozwoju metodyki Scrum. Jako nowa metoda pracy wymaga on zmiany dotychczasowego porządku, przełamywania zwyczajów i sposobów wykonywania pracy, co często wiąże się z dużym oporem. Odwaga wymagana jest zarówno w celu wyjawiania i wyjaśniania problemów, identyfikacji przeszkód, zwracania się o pomoc, udzielania lub przyjmowania tej pomocy. Scrum jako proces empiryczny wymaga ciągłego poszukiwania nowych, lepszych, bardziej efektywnych sposobów pracy i rozwiązywania problemów. Bez odwagi do eksplorowania niezbadanych dotąd obszarów nie jest to możliwe Scrum jako proces empiryczny filary procesu Podejście empiryczne (doświadczalne) właściwe jest dla zjawisk, których przebiegu nie można z góry przewidzieć i dokładnie opisać. Oprócz podejścia empirycznego wyróżnia się również podejście zdefiniowane (preskryptywne, teoretyczne). Scrum jest procesem empirycznym, którego podstawowymi założeniami są [1]: Przejrzystość (ang. transparency) każdy element procesu musi być jawny i zrozumiały dla wszystkich. Inspekcja (ang. inspection) każdy element procesu musi być cyklicznie poddawany przeglądowi pod kątem jego dopasowania do bieżących warunków. Przegląd ten wykonywany jest w celu zlokalizowania przeszkód, które powodują, iż proces ten nie jest optymalny. Adaptacja (ang. adaptation) po zlokalizowaniu przeszkody w procesie, należy tak szybko jak to możliwe, wyeliminować ją w celu usprawnienia procesu Scrum jako metodyka normatywna (szkielet pracy) W niektórych opracowaniach dotyczących Scrum występują stwierdzenia [1], że Scrum nie jest metodyką, lecz jest szkieletem pracy (ang. framework). By rozstrzygnąć tę kwestię należy wyjaśnić, jaki obszar obejmuje pojęcie metodyka, a jaki szkielet pracy. Istnieje podział na dwa podstawowe typy metodyk [2]: metodyka opisowa (descriptive) koncentruje się na opisie reguł, czynności i ich wytworów, metodyka normatywna (prescriptive) ustala reguły i normy poprawnego postępowania. 60

62 Większość metod klasycznej teorii decyzji ma charakter normatywny, tzn. polega na wyznaczeniu optymalnego rozwiązania przez idealnego decydenta, który całkowicie wykorzystuje dostępne mu informacje, wyznacza korzyści z perfekcyjną dokładnością i działa w pełni racjonalnie. Podejście deskryptywne opisuje typowe zachowania człowieka w danej sytuacji decyzyjnej. W takim podejściu dokonywany jest wybór działań spośród możliwych działań przy rozważeniu korzyści i strat związanych z wyborem działania. Metodyka normatywna jest rozumiana jako szkielet pracy, gdyż nie tylko opisuje, co powinno być zrobione, lecz dostarcza struktury implementacyjnej metodyki. W związku z powyższymi rozważaniami Scrum będzie traktowany jako metodyka normatywna utożsamiana z ramą pracy (framework). Ściślej rzecz ujmując Scrum stanowi ramę pracy, w obrębie której w sposób empiryczny powinien zostać wypracowany proces wytwórczy właściwy dla danej organizacji i realizowanego przez nią przedsięwzięcia [1] Zdarzenia metodyki Scrum W metodyce Scrum definiowanych jest wiele powtarzających się przedziałów czasowych, które mogą być interpretowane jako zdarzenia. Zastosowano w niej postulaty Manifestu Agile dotyczące dostaw produktu w krótkich (postulat 3), regularnych (postulat 12) odstępach oraz utrzymania zrównoważonego i stałego tempa rozwoju (postulat 8). Postulaty zrealizowano poprzez wyznaczenie szeregu powtarzalnych cykli. Podstawowy cykl metodyki zwany sprintem posiada stałą długość. Sprint jest zawarty w cyklu wydania, a ten w cyklu strategii. Z drugiej strony cykl sprintu zawiera w sobie cykl dnia, a ten cykle bieżące (ciągłe). Zaletą takiego rozwiązania jest regularność (rytm) i wynikająca z niego przewidywalność, ograniczenia czasowe stanowią także czynnik mobilizujący konieczność zdążenia z pracami przed zakończeniem się cyklu. W tym opracowaniu jako punkt wyjścia dla cykli czasowych przyjęto specyfikację Mike a Cohna [9], który opisał etapy zwinnego rozwoju projektu w postaci tzw. cebulki planowania. Warstwami cebulki są zawarte kolejno w sobie horyzonty czasowe, od ogólnych, długich cykli aż po cykle bieżące (ciągłe). Ta propozycja została następnie, przy jego pełnym wsparciu, zmodyfikowana przez firmę VersionOne [10] tak, aby lepiej przystawała do ogólnego opisu metodyk zwinnych. Modelując horyzonty planowania jako zdarzenia, wykorzystano pojęcia zaproponowane przez VersionOne (rys. 3.2). W opracowaniu dokonano nieznacznej modyfikacji uwzględniającej adaptacyjność metodyki oraz fakt, że Scrum nie musi być wykorzystywany tylko i wyłącznie przy wytwarzaniu oprogramowania. Cykle metodyki (horyzonty czasowe) zwane także przedziałami czasowymi (ang. timebox) są zdarzeniami ograniczonymi przez okresy, w których mogą być wykonywane różne procesy. W Scrum wyróżniamy następujące horyzonty czasowe: Strategii horyzont ten dotyczy całego cyklu życia produktu. Uruchomienie cyklu strategicznego wymaga określenia celów, wizji, karty produktu i decyzji uruchamiających rozwój produktu. Wydania horyzont ten obejmuje rozwój produktu związany z jednym wydaniem. W trakcie rozwoju produktu może pojawić się wiele wydań. Cykl wydania rozpoczynają: określenie potrzeb wobec produktu, opracowanie planu wydania i estymacja wymaganych prac. 61

63 Sprint jest to horyzont o stałej długości i dotyczy rozwoju produktu. Do wykonania sprintu potrzebny jest plan sprintu, a w jego trakcie uzyskiwany jest przyrost produktu. Cykl zamyka przegląd uzyskanego w trakcie sprintu przyrostu oraz retrospektywa. Horyzont dzienny każdego dnia kontrolowany i monitorowany jest stan postępu prac oraz dokonywana jest adaptacja, zmiana w obrębie sposobu wykonania pracy, prowadząca do zakończenia pracy w sprincie z sukcesem. Horyzont ciągłego wykonania obejmuje szereg prac wykonywanych na co dzień, do których zaliczyć można: rozwój produktu (projektowanie, programowanie), integrację, weryfikację, współpracę, komunikację. Rys Horyzonty planowania Scrum Każdy sprint jest samodzielnym, kompletnym cyklem wytwórczym, którego celem jest realizacja wydzielonego fragmentu funkcjonalności systemu (przyrost produktu). Pojedynczy sprint ma fundamentalne znaczenie, gdyż reguluje i zawiera wszelkie czynności związane z planowaniem i realizacją prac prowadzących do rozbudowy funkcjonalności systemu. Autorzy metodyki sugerują zastosowanie sprintów od dwóch- do czterotygodniowych. W celu ograniczenia ryzyka związanego z liczbą zmian w trakcie sprintu czas jego trwania nie powinien przekraczać miesiąca. W praktyce obserwuje się jednak również sprinty krótsze (tygodniowe) oraz dłuższe pięcio- i sześciotygodniowe. Należy pamiętać o utrzymaniu stałego czasu trwania sprintów, a także o tym, iż kolejne sprinty następują bezpośrednio po sobie, bez przerw pomiędzy nimi. Nie jest możliwe wydłużenie czasu trwania sprintu w jego trakcie, dopuszczalne jest natomiast, w sytuacjach wyjątkowych, jego skrócenie polegające na przedwczesnym zamknięciu i natychmiastowym uruchomieniu kolejnego sprintu bazującego na zmienionych założeniach. Utrzymanie dyscypliny czasowej sprintów jest niezbędne do zainicjowania i utrzymania procesu kontroli i adaptacji. 62

64 W trakcie każdego sprintu zachodzą stałe zdarzenia o charakterze spotkań zespołu Scrum (rys. 3.3): Spotkanie planistycznie dla sprintu, które przebiega dwuetapowo: część I dotyczy wyznaczania celu i zakresu sprintu, część II dotyczy planowania zadań sprintu. Spotkanie planistycznie dla sprintu miesięcznego trwa osiem godzin, w tym cztery godziny na planowanie celu sprintu oraz cztery godziny na planowanie zadań sprintu. Zgodnie z wytycznymi metodyki planowanie sprintu powinno obejmować około 5 10% czasu jego trwania. W ogólnym rozrachunku prace planistyczne w Scrumie pochłaniają nieco więcej wysiłku niż tradycyjne planowanie projektu [1]. Jest to jeszcze prawdziwsze twierdzenie, jeśli uwzględni się fakt, iż w planowaniu bierze udział cały zespół projektowy, w przeciwieństwie do planowania wykonywanego przez dedykowaną osobę, ewentualnie wspomaganą przez niewielkie grono ekspertów. Spotkanie codzienne (tzw. codzienny Scrum) jest 15-minutowym spotkaniem kontrolnym zespołu przeznaczonym na omówienie bieżącego stanu prac. Spotkanie przeglądu sprintu polega na przeglądzie i ocenie (walidacji) rezultatów (przyrostu produktu) osiągniętych w trakcie sprintu. Przegląd sprintu podlega ograniczeniu czasowemu (cztery godziny dla sprintu miesięcznego, nie więcej niż 5% trwania sprintu). Spotkanie retrospektywy sprintu wykorzystywane jest do sformułowania wniosków z przebiegu iteracji i zaleceń na przyszłość dotyczących poprawy pracy zespołu. Czas trwania spotkania retrospektywy sprintu jest ograniczony i wynosi trzy godziny. Część wykonawcza sprintu jest związana z rozwojem produktu. Jest to przedział czasowy sprintu bez spotkań planistycznych, przeglądu i retrospektywy sprintu. Na rysunku 3.3 zaznaczona jest jako wykonanie zadań sprintu. Rys Struktura czasowa sprintu dwutygodniowego (10-dniowego) 63

65 Strukturę sprintu wraz z występującymi stałymi fragmentami czasowymi przedstawiono na rysunku 3.4. Należy zwrócić uwagę, że metodyka Scrum kładzie nacisk na proces ciągłego dostarczania kolejnych przyrostów funkcjonalności, w postaci stabilnego produktu, w niewielkich okresach czasu. Rys Schemat przebiegu sprintu Planowanie sprintu realizowane jest na podstawie wymagań wobec produktu zawartych w rejestrze produktowym. Rejestr początkowo może zawierać jedynie tyle informacji, aby wypełnić zespołowi czas pracy w pojedynczym sprincie. W projektach o lepiej określonym zakresie prac horyzont ten może być bardziej odległy i może obejmować okres od kilku do kilkunastu sprintów. Odradza się jednak planowanie prac na odleglejsze okresy jako obarczone zbyt dużą niepewnością. W trakcie przebiegu sprintu wytwarzany jest przyrost produktu. Pod koniec sprintu dokonywana jest ocena produktu i produkt może być potencjalnie wydany na zewnątrz. Po wykonaniu przebiegu i przeglądu sprintu dokonywana jest ocena działań podejmowanych przez zespół projektowy. Ocena taka dokonywana jest w trakcie spotkania zwanego retrospektywą sprintu. Na rysunku 3.4 przedstawiono dwa strumienie rezultatów sprintu związane z: przyrostem wartości produktu postrzeganej przez jego odbiorcę (ang. potentially shippable product increment), przyrostem potencjalnych możliwości zespołu (ang. increased team capability). 64

66 3.5. Artefakty Kategoria artefakt (ang. artifact) grupuje klasy obiektów, które powstają w trakcie wykonywania procesów. W wyniku analizy opracowań dotyczącej metodyki Scrum autorzy publikacji postanowili wybrać i opisać zestaw artefaktów istotnych z punktu widzenia zespołu Scrum. Rejestr produktowy (ang. product backlog) zawiera wykaz wymagań przeznaczonych do wykonania w trakcie rozwoju produktu. Rejestr ten nazywany jest także zaległościami produktowymi w celu podkreślenia, jakie jeszcze prace związane z rozwojem produktu powinny być wykonane. Rejestr produktowy przyjmuje zazwyczaj postać listy uporządkowanej pod względem ważności jej elementów, determinującej kolejność ich realizacji. Metodyka nie specyfikuje natury poszczególnych wpisów, określając je ogólnym mianem elementów rejestru produktowego, wymagając jedynie, aby niosły one ze sobą wyczerpującą informację o cechach realizowanego systemu (mogą to być zarówno wymagania funkcjonalne, jak i niefunkcjonalne), koszcie ich realizacji (określenie złożoności lub pracochłonności) oraz aby były uporządkowane (wartościowane) pod względem oczekiwanej kolejności realizacji. Zawartość rejestru produktowego ewoluuje wraz z postępem prac i może być modyfikowana nie tylko na podstawie informacji zwrotnej od końcowego użytkownika oraz nowych informacji biznesowych czy technicznych, lecz także w wyniku dokonywania dekompozycji poszczególnych pozycji rejestru na bardziej szczegółowe. Ponadto kolejność realizowania poszczególnych wymagań (elementów rejestru produktowego) może ulegać zmianie ze sprintu na sprint. Elementy przeznaczone do realizacji w najbliższych sprintach opisane są w sposób precyzyjny i szczegółowy, natomiast te o odleglejszym czasie realizacji są zazwyczaj zarysowane jedynie ogólnie. Zdolności zespołu (ang. team capability) oznaczają ogólne możliwości zespołu do wykonania prac w sprintach. Zdolność zespołu jest scharakteryzowana między innymi przez następujące własności: Prędkość zespołu (ang. velocity) jest to prędkość produkcyjna zespołu wyrażana jako wartość liczbowa reprezentująca ilość wytwarzanej przez zespół funkcjonalności produktu w pojedynczej iteracji (sprincie). Wartość ta wyliczana jest jako suma początkowych estymat zespołu wszystkich oddawanych na koniec iteracji funkcjonalności. Na potrzeby planowania wykorzystywana jest średnia (lub średnia krocząca) tej wartości obejmująca poprzednio zrealizowane sprinty. Dostępność zespołu w sprincie (ang. team capacity) rozumiana zazwyczaj jako sumaryczna liczba godzin roboczych w sprincie, pomniejszona o liczbę godzin przeznaczonych na urlopy i inne prace członków zespołu. Kompetencje zespołu reprezentują one wiedzę i umiejętności dotyczące zarówno wytwarzanego produktu, jak i używanej w tym celu technologii, a także inne własności zespołu, jak na przykład jego interdyscyplinarność i samoorganizacja. Kryterium gotowości (ang. defi nition of ready) do rozpoczęcia sprintu określa warunki dotyczące opisów elementów rejestru produktowego, których spełnienie umożliwi rozpoczęcie sprintu. Kryterium gotowości określa zatem, czy stan rejestru produktowego zezwala na właściwe rozpoczęcie sprintu. Zwyczajowo mówi się, że rejestr produktowy jest dobrze 65

67 przygotowany, jeżeli liczba precyzyjnie opisanych wpisów w rejestrze wystarcza na wykonanie od dwóch do trzech sprintów. Kryterium ukończenia (ang. defi nition of done) może być rozumiane jako lista definicji opisujących, w jakim przypadku poszczególne elementy lub pewna grupa elementów rejestru produktowego mogą zostać uznane przez właściciela produktu za poprawnie wykonane. Kryterium to, szczególnie w procesie rozwoju oprogramowania, wyznacza oczekiwany poziom jakościowy. Przykładowo: Wykonane (done) zaimplementowane i wykonywalne w środowisku programisty. Wykonane wykonane (done done) ponadto pozytywnie zweryfikowane poprzez testy, przeglądy kodu źródłowego itp. Wykonane wykonane wykonane (done done done) dodatkowo pomyślna walidacja dokonana poprzez testy integracyjne, akceptacyjne, testy użyteczności itp. Kryterium ukończenia powinno zostać uzgodnione pomiędzy zespołem a właścicielem produktu przed rozpoczęciem sprintu, aby zespół projektowy zdawał sobie sprawę z oczekiwań właściciela produktu, a jednocześnie, by właściciel produktu rozumiał, co będzie podlegało walidacji na koniec sprintu i jakiego rodzaju prace zostaną w sprincie wykonane. Dobrze opisane kryterium ukończenia pomaga określić ilość pracy do wykonania w sprincie oraz właściwie przygotować rejestr zadaniowy. Kryterium ukończenia może dotyczyć pojedynczych elementów rejestru produktowego, ich grup, całego sprintu lub wydania. Cel sprintu (ang. sprint goal) przedstawia opisowy cel pojedynczego sprintu, wyznaczający kierunek prac przeznaczonych do wykonania w sprincie. Nadrzędny cel sprintu pomaga zespołowi utrzymać koncentrację podczas wykonywania prac w sprincie. Cel sprintu zazwyczaj przedstawiony jest lapidarnie jako odpowiednio dobrana nazwa sprintu lub metaforyczne zdanie podsumowujące zakres prac do wykonania w sprincie. Zakres sprintu (ang. sprint scope) stanowi grupę elementów rejestru produktowego wybraną do wykonania w sprincie. Grupa tych elementów nazywana jest także w środowisku Scrum rejestrem uzgodnionym (ang. comitted backlog). Rejestr zadaniowy (ang. sprint backlog) jest szczegółowym wykazem prac zaplanowanych do zrealizowania w obrębie pojedynczego sprintu. Rejestr zadaniowy uzyskiwany jest w wyniku dekompozycji elementów rejestru produktowego na bardziej szczegółowe zadania. Rejestr jest wykorzystywany przez zespół do skoordynowania jego własnych działań w sprincie. Zazwyczaj rejestr zawiera listę opisów zadań i informacje o ich przydziale do konkretnych wykonawców, statusie i szacowanym czasie wykonania. Rejestr zadaniowy odpowiadający przyjętemu do realizacji zakresowi sprintu nazywany jest bazowym zakresem sprintu (ang. sprint scope baseline). W trakcie wykonania sprintu rejestr zadaniowy może ulec zmianie, jeśli zespół zidentyfikuje nowe, niezbędne zadania lub uzna część zadań za niepotrzebne. Wykres wypalania dla sprintu (ang. sprint burndown chart) służy do przedstawienia na bieżąco wykonania zadań w trakcie sprintu. W trakcie wykonania sprintu zespół przedstawia postęp prac w postaci diagramu zwanego wykresem wypalania. Postęp prac jest podawany jako liczba godzin pracy (oś Y) zespołu pozostających do zrealizowania celu sprintu, dla każdego dnia roboczego (oś X) sprintu. Liczba godzin pozostałych do wykonania celu sprintu powinna zmniejszać się z każdym kolejnym dniem sprintu, może jednak ulec zwiększeniu w wyniku stwierdzenia, że czas potrzebny na wykonanie zadań jest dłuższy niż to początkowo szacowano lub w wyniku konieczności przeprowadzenia innych, nieprzewidzianych 66

68 prac. Warto pamiętać, że wykres wypalania (podobnie jak tablica) jest jedynie narzędziem wspomagającym pracę zespołu. Jego przygotowanie i prowadzenie nie powinno zatem stać się celem samym w sobie. Przyrost produktu (ang. product increment) jest identyfikowany zazwyczaj jako zbiór elementów z uzgodnionego rejestru produktowego, które pod koniec sprintu spełniają kryterium ukończenia. Warto jednak zauważyć, iż w trakcie sprintu zespół może zaproponować inne niż początkowo dyskutowane rozwiązanie, co powoduje, że przyrost identyfikowany i oceniany jest także pod kątem spełnienia (bądź nie) celu sprintu. Na podstawie zaimplementowanych własności produktu planowany jest jego dalszy rozwój. Produkt (ang. product) jest głównym obiektem dostarczanym przez zespół. Zazwyczaj w trakcie kolejnych sprintów rozwijany jest produkt, który na zakończenie powinien charakteryzować się potencjalną możliwością przekazania go odbiorcy. Wykonany w trakcie pojedynczego sprintu przyrost produktu powinien zostać zintegrowany w spójną całość z pracami wykonanymi w poprzednich sprintach bądź pracami wykonanymi przez inne zespoły współtworzące produkt i w takiej postaci przekazany odbiorcy. Rekomendacje rozwoju produktu (ang. recommendations of product development) opisują, jakie kroki związane z rozwojem produktu zostaną podjęte w kolejnym i następnych sprintach. Rekomendacje retrospektywy (ang. retrospective recommendations) przedstawiają zalecenie związane z ciągłym doskonaleniem działania zespołu. Rekomendacje te mogą dotyczyć działań bieżących (ang. short-term) i długoterminowych (ang. long-term), przekraczających długość pojedynczego sprintu Role W celu sprawnego rozwoju produktu wyróżniono tylko kilka podstawowych i ważnych ról. Role można podzielić na dwie kategorie: zespół Scrum i interesariusze. W metodyce Scrum wyróżnia się jedynie kilka ról. Są to (rys. 3.5): właściciel produktu (ang. product owner), scrum master (ang. scrum master), zespół scrum (ang. team), interesariusze (ang. stakeholders). Zespół Scrum (ang. scrum team) jest odpowiedzialny za dostarczenie produktu. Aby umożliwić identyfikację grupy odpowiedzialnej za wytworzenie danego produktu na tle całej organizacji, a także by ułatwić wprowadzenie i egzekwowanie reguł metodyki wobec i w obrębie tej grupy, wyróżnia się tak zwany zespół Scrum, w skład którego wchodzą: Scrum Master, właściciel produktu i zespół wykonawczy [1]. W praktyce często ta sama osoba pełni rolę Scrum Mastera i jest aktywnym członkiem zespołu rozwijającego produkt (np. programistą). Nie jest wskazane natomiast, by osoba pełniąca rolę właściciela produktu była jednocześnie członkiem zespołu rozwijającego produkt. Nie można również łączyć ról Scrum Mastera i właściciela produktu. 67

69 Rys Role w metodyce Scrum Właściciel produktu (ang. product owner) jest osobą odpowiedzialną za utrzymanie zestawu cech produktu przewidzianych do implementacji, zarządzanie kolejnością realizacji wymagań zgodnie z reprezentowaną przez nie wartością biznesową oraz za przejrzyste komunikowanie tych informacji. Właściciel produktu ma uprawnienia związane z wyznaczaniem celów zespołu Scrum i jest odpowiedzialny za jego sukces. Zespół Scrum może mieć tylko jednego właściciela produktu, jednak właściciel może kierować pracą jednego lub więcej zespołów. Lista obowiązków właściciela produktu może wyglądać następująco: Udział w przygotowaniu i rozwoju wizji produktu oraz przekazywanie jej zespołowi. Tworzenie i aktualizacja planów wydań w celu kierowania projektem w sposób proaktywny, angażujący w ten proces zespół Scrum i interesariuszy. Przygotowywanie zestawu cech, którymi charakteryzować ma się wytwarzany produkt oraz podejmowanie decyzji o kolejności ich wykonania przez zespół. Zapisywanie pożądanych cech produktu w rejestrze produktowym i współpraca z zespołem i interesariuszami w tym zakresie. Szacowanie zyskowności przedsięwzięcia związanego z tworzonym produktem. Koncentrowanie się na tworzeniu produktu o minimalnym zakresie funkcjonalności oraz na wydawaniu przyrostów produktu wcześnie i często. 68

70 Usuwanie elementów rejestru produktowego, które nie są kluczowe. Dobór celu sprintu. Ocena rezultatów pracy zespołu, w wyniku której następuje akceptacja lub odrzucenie zadań sprintu. Monitorowanie przebiegu prac i raportowanie stanu projektu przed interesariuszami. Codzienna współpraca z zespołem oraz udział w spotkaniach przewidzianych w metodyce Scrum. Postuluje się [1], aby rola właściciela produktu pełniona była wyłącznie przez jedną osobę, posiadającą odpowiednią moc sprawczą, a nie przez grupę osób. Nie oznacza to oczywiście, iż właściciel produktu nie może zasięgać opinii szerszego gremium i w praktyce bardzo często tak właśnie jest. Właściciela produktu wspiera zarówno zespół wykonawczy, jak i osoby spoza tego zespołu, np. dział marketingu. Właściciel produktu jest osobą oficjalnie odpowiedzialną za powodzenie projektu, każdy w organizacji powinien respektować podejmowane przez niego decyzje. Właściciel produktu reprezentuje przed zespołem stanowisko wszystkich interesariuszy realizowanego przedsięwzięcia. Nie jest dopuszczalne, by ktoś inny przekazywał zespołowi odmienne priorytety prac, natomiast zespół ze swojej strony musi podporządkować się wytycznym stawianym przez właściciela produktu [14]. Poważnym problemem dla rozwoju produktu są sytuacje, w których właściciel produktu: nie został formalnie zdefiniowany i przypisany do zespołu, nie posiadania odpowiednich pełnomocnictw (opóźnienia w podejmowaniu decyzji), nie posiada odpowiednich kwalifikacji lub wiedzy merytorycznej w zakresie realizowanego przedsięwzięcia, odznacza się brakiem zaangażowania w sukces przedsięwzięcia, odznacza się brakiem cech przywódczych (umiejętności kierowania, motywowania i podejmowania decyzji), nie jest w stanie wygospodarować odpowiedniej ilości czasu dla zespołu (np. brak przygotowania do sesji planistycznych, opóźnienia w reagowaniu na zapytania zespołu), nie został przeszkolony w zakresie metodyki Scrum i technik pomocniczych (np. strategia zarządzania rejestrem produktowym, historie użytkownika). Scrum Master (ang. scrum master) w polskiej nomenklaturze rola ta jest nazywana bardzo różnie, między innymi: młynarz, mistrz, strażnik młyna, scrum majster lub mistrz ceremonii. Ponieważ rola ta jest ściśle powiązana z metodyką Scrum postanowiono pozostać przy nazwie angielskiej. Scrum Master jest osobą odpowiedzialną za egzekwowanie praktyk i zasad metodyki Scrum. Jego podstawową rolą jest udzielanie wsparcia zespołowi i całej organizacji w zakresie efektywnego wykorzystania zasobów. W pewnym zakresie jest także odpowiedzialny za szkolenie zespołu i właściciela produktu, jeżeli nie posiadają wystarczającej wiedzy na temat swoich ról i obowiązków wynikających z metodyki. Scrum Master pomaga także zespołowi wykonywać pracę sprawnie, z zachowaniem zasad samoorganizacji, w środowisku, które nie jest w pełni przystosowane do wytwarzania złożonych produktów. Pomoc ta w nomenklaturze metodyki Scrum nazywana jest usuwaniem blokad (ang. impediments) [1]. Scrum Master przebywa z zespołem, dba o zespół i jego morale, stabilne tempo i postęp prac, nadzoruje zgodność praktyk projektowych z założeniami metodyki. Scrum Master nie zarządza zespołem nie definiuje i nie przypisuje 69

71 zadań zespół jest samoorganizujący się, a Scrum Master pełni funkcję katalizatora, który tę samoorganizację wspomaga. Lista obowiązków osoby pełniącej rolę Scrum Mastera może wyglądać następująco: Egzekwowanie od zespołu i reszty organizacji poszanowania reguł metodyki Scrum oraz edukowanie w tym zakresie i zachęcanie do wykorzystania jej mechanizmów w rozwiązywaniu codziennych problemów. Aktywne zachęcanie zespołu do poszukiwania alternatywnych rozwiązań napotkanych problemów. Sprawne i terminowe usuwanie wewnątrz- i pozazespołowych czynników, mogących negatywnie wpłynąć na rezultaty sprintu. Scrum Master nie musi rozwiązywać problemów samodzielnie, szczególnie, że mogą one wykraczać poza jego możliwości lub kompetencje, oczekuje się natomiast, iż wypracuje sposoby zaangażowania odpowiednich osób (w szczególności zespołu Scrum lub kierownictwa) do wypracowania i wdrożenia rozwiązania. Zapewnianie ścisłej współpracy pomiędzy reprezentantami wszystkich funkcji i ról oraz kontrola przebiegu tej współpracy. Zarządzanie zmianą zachodzącą w organizacji (każda zmiana powoduje stres ze względu na pojawiające się problemy, braki organizacji, kompetencji itp.). Zespół wykonawczy (ang. team), nazywany również zespołem projektowym lub krócej zespołem, to grupa osób zaangażowanych w realizację przedsięwzięcia. Grupa ta jest mało liczna, w celu minimalizacji narzutu komunikacyjnego, jednak na tyle duża, by mógł zachodzić efekt wzajemnego motywowania się przez jej członków. Zaleca się, by zespół wykonawczy liczył 7 ± 2 osoby (nie licząc właściciela produktu i Scrum Mastera) [1]. Kompetencje osób wchodzących w skład zespołu są tak dobrane, aby możliwe było wykonanie stawianych przed nimi zadań, prowadzących zazwyczaj do wytworzenia (kompletnego) produktu. W przypadku wytwarzania oprogramowania będą to więc zarówno programiści, projektanci, jak i analitycy i testerzy, a także, jeżeli projekt tego wymaga, administratorzy baz danych, administratorzy systemu, graficy itp. Pracują oni ze sobą na równych prawach, przy zachowaniu koleżeńskich relacji i wykonują wspólnie postawione przed nimi zadania, nawet jeśli wymagałoby to nabycia nowych kompetencji i związane było z przekraczaniem granic swojej podstawowej roli (analityka, projektanta, programisty, testera). Jak wspomniano wcześniej, wielokrotnie zespół jest samoogranizujący się. Członkowie zespołu powinni zatem dążyć do wykonania powierzonych im zadań we własnym gronie, organizując przebieg pracy we własnym zakresie. Każdy członek zespołu aktywnie uczestniczy w procesie podziału zadań i poszukiwaniu rozwiązań napotkanych problemów. Członkowie zespołu powinni w pełni poświęcić się (ang. commit) wykonaniu projektu i nie brać udziału w innych pracach. Nikt nie definiuje przebiegu pracy zespołu. Zespół zostanie oceniony na podstawie stopnia zrealizowania założonego celu sprintu. Interesariusze to osoby spoza zespołu Scrum zainteresowane lub zależne od przebiegu prac projektowych. Najbardziej typowymi interesariuszami są: inwestor, kierownictwo firmy, użytkownicy. Zakłada się, że interesariusze powinni być aktywnie zaangażowani w realizację projektu (ang. involved), w szczególności biorą udział w niektórych spotkaniach zespołu (pierwsza część planowania i przegląd sprintu), jednak przed zespołem wykonawczym ich reprezentantem jest właściciel produktu. 70

72 3.7. Procesy W wyniku analizy opracowań, związanych z metodyką Scrum, w systematycznym opisie metodyki wyróżniono zestawy podstawowych procesów. Warto zwrócić uwagę na uwidocznione w modelu (rys. 3.6 i rys. 3.7) ogólne powiązania procesów Scrum Planowanie sprintu Czynności związane z rozpoczęciem sprintu, określane wspólnym mianem planowania sprintu (ang. sprint planning), przebiegają dwuetapowo podczas dwóch następujących po sobie spotkań (rys. 3.6): spotkanie I planowanie celu i zakresu sprintu, spotkanie II planowanie zadań sprintu. Rys Schemat procesów planowania sprintu W trakcie I spotkania dokonywane jest planowanie celu i zakresu sprintu. Celem tej części spotkania planistycznego jest określenie tego, co ma zostać zrealizowane w rozpoczynanym właśnie sprincie. Właściciel produktu przedstawia elementy rejestru produktowego o najwyższych priorytetach, podając maksymalnie dużo informacji kontekstowej z czego wynika taka, a nie inna kolejność, co oznacza wykonanie danej funkcjonalność z perspektywy strategii produktu itp. W pierwszej kolejności z rejestru produktowego wybierany jest podzbiór elementów, których wykonanie w danym sprincie byłoby najbardziej zasadne. Podzbiór wyznaczany jest zgodne z celami wydania i ogólną wizją produktu. Przesłankami do dokonania tego wyboru może być wysokie znaczenie danej funkcjonalności dla końcowego odbiorcy, a także względnie wysokie ryzyko realizacji, które właściciel produktu w porozumieniu z zespołem chce obniżyć poprzez wczesne rozpoczęcie prac. 71

73 Tak wybrany zbiór elementów jest następnie dyskutowany z zespołem projektowym w celu zapewnienia wspólnego rozumienia zakresu prac i kryteriów, którymi kierować się będzie właściciel produktu, poddając ocenie dostarczony przez zespół produkt. Kryteria te odzwierciedlają oczekiwany przez właściciela produktu poziom jakościowy określany jako kryterium ukończenia (ang. defi nition of done). Warto zaznaczyć, że kryterium, a raczej kryteria ukończenia, mogą być podczas sesji planistycznej odświeżone, czyli znajdują się zarówno na wejściu, jak i na wyjściu procesu. Na tym etapie planowania dyskutowane jest również prawdopodobieństwo (stopień) wykonalności. Brane są pod uwagę zależności, ograniczenia, proponowane przez zespół rozwiązania, a także zdolności produkcyjne zespołu (historyczne oraz przewidywane). Ostatecznej decyzji co do zakresu, którego realizacji zespół podejmie się w kolejnym sprincie dokonuje wspólnie cały zespół wykonawczy. Wybrany w ten sposób podzbiór rejestru produktowego nazywany jest także rejestrem uzgodnionym (ang. committed backlog). Osiągnięty konsensus jest podsumowywany i zapisywany w formie celu sprintu, po czym zespół przechodzi do kolejnej, bardziej szczegółowej fazy planowania, obejmującej przygotowanie rejestru zadaniowego (ang. sprint backlog), czyli szczegółowego zestawienia prac, których wykonanie jest niezbędne, by osiągnąć cel sprintu. W trakcie II spotkania dokonywane jest planowanie zadań sprintu. Celem tej części jest określenie w sposób szczegółowy, jak praca ma być wykonana w sprincie. Wybrane w I części sesji planistycznej elementy rejestru produktowego zespół przekształca w zadania do wykonania w sprincie i zapisuje w postaci tak zwanego rejestru zadaniowego sprintu. Dzięki wspólnej pracy i wysiłkowi włożonemu w przygotowanie rejestru zadaniowego jego końcowa postać odzwierciedla realistyczny plan prac, a wszyscy członkowie zespołu poczuwając się do jego autorstwa, mają szansę być jednakowo zaangażowani w jego realizację. Rejestr zadaniowy jest narzędziem oraz przedmiotem pracy zespołu i jest w pełni widoczny dla wszystkich jego członków. W spotkaniu może uczestniczyć właściciel produktu w celu ewentualnego doprecyzowania zawartości rejestru produktowego, oczekiwań i oceny zależności (ang. trade-offs). Warto zwrócić uwagę, iż na tym etapie planowania, w razie zgłoszenia przez zespół wątpliwości, zakres prac w sprincie wciąż może ulegać zmianie, tak by było możliwe efektywne wykorzystanie czasu pracy całego zespołu. O poziomie szczegółowości tego etapu planowania może świadczyć fakt, iż zaleca się, by oszacowanie czasowe pojedynczego zadania mieściło się w granicach 10 godzin roboczych. Wytyczna ta związana jest z minimalizacją ryzyka, ale stanowi także element stymulujący pracę zespołową już na etapie planowania. Wysiłek włożony w dekompozycję zadań pozwala zespołowi lepiej zrozumieć pracę, a fakt wspólnego przygotowania planu pracy spaja zespół. Wybrany do realizacji zbiór elementów rejestru produktowego łącznie z celem sprintu oraz rejestrem sprintu reprezentują tzw. zobowiązanie zespołu do wykonania prac w sprincie. Od tego momentu zakres pracy zaplanowanej do realizacji w danym sprincie ulega zamrożeniu, ochrona poczynionych postanowień leży w gestii Scrum Mastera. Zadaniem zespołu staje się dążenie do dostarczenia tego, do czego się zobowiązał. Aby zobowiązanie to miało szanse być dotrzymane, skład zespołu pozostaje niezmienny podczas trwania sprintu. 72

74 Rozwój produktu (część wykonawcza sprintu) W ogólnym ujęciu celem zespołu Scrum jest dostarczenie, na podstawie wybranego przez właściciela produktu wycinka wymagań, w pełni działającego przyrostu produktu (rys. 3.7) w terminie przewidzianym jedną iteracją (sprintem). Tylko na jego podstawie może być dokonana korekta planu realizacji przedsięwzięcia oraz zmiana w obrębie procesu wytwórczego. Sprint nie może zostać skrócony lub wydłużony. W przypadku gdy prace sprintu mogą nie mieć sensu, sprint może zostać unieważniony przed jego zakończeniem. Tylko właściciel produktu może dokonać takiego unieważnienia [1]. W trakcie drugiego etapu planowania oraz wykonania sprintu zasada samoorganizacji zespołu jest najbardziej wyrazista. W praktycznym wymiarze objawia się ona tym, iż zadania nie są przygotowywane i przydzielane odgórnie członkom zespołu, nikt nie ingeruje w to, kto spośród jego członków i kiedy rozpocznie czy też zakończy realizowanie zadań. W szerszym ujęciu jest to przejaw zgodności metodyki z postulatami H. Takeuchiego i I. Nonaki. Zespół zachęcany jest do samodzielnego opracowania rozwiązania postawionego przed nim problemu (celu sprintu), wykorzystując wszystkie kompetencje, które członkowie zespołu posiadają, oraz empirycznie dobierając proces produkcji i narzędzia. Do dyspozycji zespołu pozostaje właściciel produktu będący głównym źródłem informacji odnośnie do nadrzędnego celu projektu oraz Scrum Master dbający o to, by zespół postępując zgodnie z regułami metodyki, dysponował wszystkim, co jest niezbędne do wytworzenia produktu. Ponadto odpowiedzialnością Scrum Mastera jest dbałość o to, by w trakcie sprintu nie były dokonywane żadne zmiany wpływające na zakres prac i cele sprintu. Rys Schemat procesu rozwoju produktu 73

75 Kontrola i monitorowanie sprintu Ulotna natura samoorganizacji wymaga dyscypliny i zaangażowania wszystkich osób uczestniczących w przedsięwzięciu. Wymaga także wprowadzenia mechanizmu subtelnej kontroli, aby ustrzec zespół przed popadnięciem w chaos. Autorzy metodyki opisują dwie stosunkowo proste techniki związane z kontrolowaniem i monitorowaniem (rys. 3.8), pozwalające uzyskać efekt pozytywnego wpływu presji grupy na zaangażowanie oraz utrzymanie wysokich standardów pracy przez wszystkich jej członków. W wyniku kontroli i monitorowania może być podjęta decyzja dotycząca zmian, nazwanych tutaj adaptacją sprintu (rys. 3.8). Rys Schemat procesów kontroli i adaptacji w części wykonawczej sprintu Kontrola sprintu Pierwszą z technik jest tzw. codzienny Scrum (ang. daily scrum) krótkie, maksymalnie 15-minutowe, spotkanie całego zespołu. Spotkanie to przeprowadzane jest w tym samym miejscu, o tym samym czasie, a obecność wszystkich członków zespołu jest obowiązkowa. Zespół jest odpowiedzialny za przeprowadzenie i efektywność spotkania. Scrum Master upewnia się, że zespół takie spotkania organizuje oraz dba o to, by przebiegały w założonym czasie dzięki wprowadzeniu reguł polegających na wypowiadaniu się członków zespołu w sposób treściwy i zwarty. Upewnia się także co do tego, czy osoby spoza zespołu Scrum nie przerywały jego przebiegu. W trakcie codziennych spotkań członkowie zespołu dyskutują o postępie prac w stosunku do dnia poprzedniego oraz przedstawiają napotkane przeszkody. Informacja ta pozwala na synchronizację zadań oraz dobór odpowiednich zachowań zespołu zapewniających uzyskanie celów sprintu. Codzienny Scrum nie jest spotkaniem omawiającym szczegółowo stan prac, a jedynie wglądem (inspekcją) w przebieg prac. Inspekcji tej dokonuje zespół i tylko zespół ocenia, czy wobec zaistniałych zdarzeń cele sprintu są zagrożone czy też nie. Sugeruje się trzy pytania, które, kierowane do każdego członka zespołu, pomagają skupić dyskusję na istotnych dla zespołu (pod kątem osiągnięcia celów sprintu) kwestiach [1]: 74

76 Co zostało wykonane od ostatniego spotkania? Czym dana osoba będzie się zajmować do kolejnego spotkania? Jakie przeszkody stanęły lub mogą stanąć na drodze? Tak zrealizowany proces kontroli usprawnia przepływ informacji w zespole, umożliwia wczesne wykrycie problemów czy sytuacji wymagających przeorganizowania przydziału prac w zespole. Jest także przejawem wzajemnej i subtelnej kontroli, gdyż omówienie przebiegu prac odbywa się wobec i przy aktywnym udziale wszystkich członków zespołu. Uzyskane podczas spotkania informacje mogą skutkować zmianą rejestru zadaniowego i przeplanowaniem przebiegu prac. Monitorowanie sprintu Drugą użyteczną techniką zaproponowaną przez twórców metodyki, pomagającą zaktywizować zespół, jest wizualizacja ilości pracy pozostałej do wykonania w sprincie. W tym celu niezbędne jest regularne określanie liczby godzin koniecznych do zakończenia rozpoczętych zadań i wizualizacja tej informacji w postaci tzw. wykresu wypalania (ang. burndown chart). Zespół samodzielnie wyznacza te dane, bazując na aktualnym stanie prac i zawartości rejestru zadaniowego oraz przedstawia je w postaci wykresu wypalania. Wykresy wypalania sprintu wykorzystywane są przez zespół do monitorowania wykonania sprintu, gdyż na ich podstawie można ocenić bieżący stan prac, a także prognozować osiągnięcie celu sprintu. Przykładowy wykres wypalania przedstawiony na rysunku 3.9 podaje dla poszczególnych dni sprintu liczbę godzin potrzebnych do wykonania zobowiązania podjętego w drugiej części spotkania planistycznego. Rys Wykres wypalania sprintu 75

77 Adaptacja sprintu Wyniki kontroli i monitorowania sprintu mogą powodować konieczność zmiany rejestru zadaniowego, co będzie wymagało przeplanowania przebiegu prac w sprincie. Jak wspomniano wcześniej, adaptacja sprintu ma również swój przejaw w bieżącej aktualizacji liczby godzin pozostałych do wykonania w sprincie. Rejestr zadaniowy i wykres wypalania są zatem na bieżąco aktualizowane w trakcie części wykonawczej sprintu Przegląd sprintu Zespół w trakcie sprintu uzyskuje ogromną swobodę co do sposobu wywiązania się z podjętego zobowiązania doboru zadań prowadzących do jego wypełnienia, wyboru technologii, kolejności wykonania prac, również kontrola przebiegu tego procesu w ogromnej mierze leży po stronie zespołu. Zarządzanie w ten sposób nie byłoby efektywne bez wprowadzenia do procesu elementu inspekcji i adaptacji następującego po wykonaniu sprintu. W metodyce Scrum te elementy cyklu produkcyjnego znajdują reprezentację w postaci przeglądu oraz retrospektywy sprintu. Przegląd sprintu (ang. sprint review) dokonywany jest pod koniec sprintu, zwykle w ostatnim jego dniu. Przegląd sprintu polega na sprawdzeniu, w jakim stopniu zrealizowany został cel sprintu, które z zadań postawionych w sesji planistycznej zostały wykonane i dyskusji dotyczącej tego, co proponowane przez zespół rozwiązania (lub ich brak) oznaczają dla produktu i dalszego przebiegu prac. Podczas przeglądu sprintu prezentowane są te cechy produktu, które udało się zrealizować w sposób kompletny, umożliwiający (potencjalne) przekazanie ich odbiorcy końcowemu (ang. potentially shippable product increment). Właściciel produktu, często w obecności interesariuszy, wspólnie z zespołem projektowym identyfikuje, co zostało wykonane, a co nie. W ocenie stopnia wykonalności poszczególnych cech produktu kierują się uzgodnionym wcześniej kryterium ukończenia. Zwykle substytuty (prototypy) oraz częściowo wykonana praca (na przykład dokumentacja projektowa bez towarzyszącego jej kodu źródłowego, niekompletny kod źródłowy, kod źródłowy pozbawiony dokumentacji, nieprzetestowany odpowiednio produkt) jako elementy z definicji niespełniające kryterium ukończenia nie podlegają prezentacji. Można zatem stwierdzić, że podstawową miarą oceny postępu prac oraz przesłanką do dokonywania jakiejkolwiek korekty planów projektu jest działające oprogramowanie (lub jego brak). Podczas spotkania następuje określenie stopnia, w jakim osiągnięto zaplanowany cel sprintu, cel wydania oraz cel nadrzędny przedsięwzięcia. Zespół otrzymuje od właściciela produktu informację zwrotną odnośnie do oceny wykonanej pracy oraz skuteczności pracy zespołu. Przegląd sprintu (rys. 3.10) dostarcza istotnych wiadomości potrzebnych do planowania kolejnych sprintów. Dyskutowane są kierunki rozwoju produktu w kolejnych sprintach i związane z tym zmiany w rejestrze produktowym. Właściciel produktu dokonuje oceny daty zakończenia projektu, wykorzystując w tym celu empirycznie wyznaczoną zdolność produkcyjną zespołu tzw. prędkość (ang. velocity) i dokonuje zmian w rejestrze produktowym. Obrazowo rzecz ujmując, rejestr produktowy po każdym zakończeniu sprintu jest redukowany poprzez usuwanie z niego elementów wykonanych w trakcie sprintu. Trzeba jednak pamiętać, że może on jednocześnie przyrastać, jeśli pojawi się potrzeba wprowadzenia nowych bądź zmodyfikowania już zaimplementowanych cech produktu. W szczególności może również zapaść decyzja o przerwaniu 76

78 projektu czy to na skutek wcześniejszej niż zakładana realizacji głównych założeń, czy przeciwnie z powodu braku oczekiwanych postępów. W przypadku metodyki Scrum mamy więc do czynienia nie tylko z przykładem iteracyjnego i przyrostowego procesu rozwoju oprogramowania, ale również z przykładem planowania adaptacyjnego, realizowanego iteracyjnie. Prezentacja wyników sprintu w postaci działającego oprogramowania ma na celu ocenę i ewentualne poszerzenie spektrum możliwości wykorzystania produktu przez odbiorcę (reprezentowanego przez właściciela produktu lub faktycznych odbiorców uczestniczących w przeglądzie sprintu), umożliwiając mu empiryczne zapoznanie się dokładnie z tym, co znajdzie się w przyszłym, eksploatowanym przez niego systemie. Przekazane przez niego uwagi mogą być w takim przypadku szczególnie trafne i zgodne z jego wyobrażeniem ewentualnych zmian. Przeglądu sprintu nie należy zatem traktować zbyt formalnie, raczej chodzi tutaj o rzetelną sesję roboczą, której celem jest uzyskanie przez obie strony użytecznej informacji zwrotnej i wypracowanie zasad postępowania w kolejnych etapach prac. Rys Schemat procesu przeglądu sprintu Retrospektywa sprintu Retrospektywa sprintu (ang. sprint retrospective) służy ocenie skuteczności działania zespołu i ustaleniu, jakie modyfikacje w kolejnych sprintach zwiększą jego produktywność (rys. 3.11). Scrum Master zachęca zespół do dokonania przeglądu funkcjonowania procesów i praktyk metodyki Scrum z szerszej perspektywy, w celu dokonania identyfikacji problemów i korekty w następnym lub kolejnych sprintach. Warto zwrócić uwagę na fakt, iż właściciel produktu zwykle nie uczestniczy w retrospektywie, podobnie jak wyższe kierownictwo, co daje okazję do przeprowadzenia swobodnej 77

79 i efektywnej dyskusji. Retrospektywa jest postrzegana jako faza adaptacyjna w pracy zespołu, znacznie poprawiająca komunikację w zespole i stymulująca jego samoświadomość i rozwój. Podczas retrospektywy zespół dokonuje podsumowania zadań, których realizacja powiodła się lub które sprawiały problemy, omawia skuteczność wykorzystanych narzędzi, technik i procedur. Dyskutuje ich skuteczność w kontekście osiągniętych rezultatów, kierując się informacją zwrotną przekazaną przez właściciela produktu podczas przeglądu sprintu. W wyniku spotkania powstają konkretne propozycje poprawy. W retrospektywie bierze udział cały zespół wykonawczy, więc ocena dokonywana jest z różnych perspektyw (analizy, projektowania, programowania, testowania). Uczestnicy zespołu dokonują analizy pod kątem: dotrzymania deklarowanych czasów realizacji; sprawności działania zespołu, w szczególności: relacji międzyludzkich, składu zespołu; procesu wytwórczego, organizacji i efektywności spotkań, metod komunikacji; adekwatności i efektywności wykorzystywanych narzędzi i technik; jakości produktu (na podstawie stanu faktycznego i pożądanej postaci wyrażonej poprzez kryterium ukończenia). Oprócz identyfikacji kwestii problematycznych zespół dyskutuje propozycje rozwiązań, których zastosowanie w kolejnych sprintach może zapobiec powtórzeniu się niepowodzeń. Rekomendacje te są następnie oceniane i porządkowane pod kątem możliwości i zasadności ich wdrożenia oraz kolejno i stopniowo wdrażane Realizacja rekomendacji retrospektywy Jak zostało to zasygnalizowane w poprzednim rozdziale, w trakcie retrospektywy definiowane są działania bieżące i długoterminowe dotyczące poprawy procesów oraz strategia ich realizacji w kolejnych sprintach. Rys Schemat procesów retrospektywy sprintu i realizacji rekomendacji retrospektywy 78

80 Częściowo mogą to być działania, których realizacji zespół może podjąć się już w kolejnym sprincie, częściowo osiągnięcie celów działań naprawczych może wymagać środków, do dysponowania którymi zespół nie jest upoważniony (na przykład zakup narzędzi). Wówczas do bieżących działań zespołu może należeć identyfikacja tych narzędzi, przeprowadzenie ich ewaluacji, dokonanie analizy kosztów wdrożenia czy przygotowanie zamówienia dla przełożonych. W wyniku realizacji działań wynikających z rekomendacji retrospektywy następuje zmiana potencjalnie na lepsze zdolności produkcyjnych zespołu (rys. 3.11) Zestawienie składowych i pojęć metodyki Scrum W literaturze polskiej stosowane są różne nazwy pojęć związanych z metodyką Scrum. Autorzy przeglądnęli słowniki, różne inne pozycje literaturowe i strony internetowe dotyczące rozważanych zagadnień. W wyniku takiego przeglądu wystąpiono z próbą uporządkowania nazewnictwa polskiego, którą zawarto w tabeli 3.1. Tabela 3.1 Słownik ważniejszych pojęć związanych z metodyką Scrum Nazwa angielska Universal principles Scrum agile agile manifesto normative methodology framework Events (time boxes) strategy timebox release timebox sprint timebox sprint planning meeting I part sprint planning meeting II part daily Scrum, daily Scrum meeting sprint review meeting Proponowana (zastępcza) nazwa polska Uniwersalne zasady Scrum (młyn) zwinny Manifest zwinnego wytwarzania oprogramowania, Manifest Agile metodyka normatywna szkielet pracy Zdarzenia horyzont czasowy strategii horyzont czasowy wydania horyzont czasowy sprintu spotkanie planistyczne sprintu część I spotkanie planistyczne sprintu część II Scrum codzienny, codzienne spotkanie zespołu Scrum spotkanie przeglądu sprintu 79

81 Tabela 3.1. cd. Nazwa angielska sprint retrospective meeting executing sprint part Artifacts product product backlog definition of ready team capabilities definition of done sprint goal sprint scope (committed backlog) sprint backlog sprint burndown chart product increment product development recommendations retrospective recommendations Roles Scrum master product owner stakeholders team team member Processes sprint goal and scope planning sprint task planning product development sprint control Proponowana (zastępcza) nazwa polska spotkanie retrospektywy sprintu, spotkanie retrospektywne sprintu wykonawcza część sprintu Artefakty produkt rejestr produktowy (zaległości produktowe) kryterium gotowości zdolności zespołu kryterium ukończenia cel sprintu zakres sprintu (uzgodniony rejestr) rejestr zadaniowy sprintu wykres wypalania sprintu przyrost produktu rekomendacje rozwoju produktu rekomendacje retrospektywy Role Scrum master (opiekun zespołu, trener zespołu, mistrz młyna, mistrz ceremonii, młynarz, mistrz, strażnik młyna) właściciel produktu interesariusze (osoby zainteresowane) zespół Scrum członek zespołu Procesy planowanie celu i zakresu sprintu planowanie zadań sprintu rozwój produktu kontrola sprintu 80

82 Tabela 3.1. cd. sprint monitoring sprint adaptation sprint review sprint retrospection retrospective recommendations realization Other vocabulary user story story points task board team velocity team capacity monitorowanie sprintu adaptacja sprintu przegląd sprintu retrospektywa sprintu realizacja rekomendacji retrospektywy Pozostałe słownictwo historyjka (historia, opowiadanie) użytkownika punkty historyjki tablica zadań prędkość zespołu zasobność zespołu 3.9. Podsumowanie W przedsiębiorstwach bazujących na zarządzaniu wiedzą dąży się do uzyskania wiedzy wartościowej na bazie posiadanej rozbudowanej i nieuporządkowanej informacji. W przypadku zarządzania projektami informatycznymi istotne jest, by można było oceniać różne metodyki i ich elementy w celu dostosowania ich do potrzeb firm. Rozwiązanie problemu wiarygodnego wyznaczenia własności metodyk polega na opracowaniu ontologii dla wybranych metodyk zarządzania bazującej na wspólnym metamodelu. W celu dokonania oceny przydatności ontologii metodyk przedstawiano uzyskane rozwiązania ekspertom dziedzinowym w formie opisowej przy zastosowaniu konceptów metamodelu. Głównym założeniem było opracowanie opisu niepowodującego zmiany samej metodyki. Autorzy dokonali szeregu wdrożeń metodyki Scrum w przedsiębiorstwach, przeprowadzili wiele dyskusji z praktykami z przedsiębiorstw informatycznych w trakcie prezentowania wyników na różnych seminariach. Weryfikacji opisu dokonywano w trakcie nauczania na studiach podyplomowych z zakresu zarządzania projektami oraz podczas szkoleń prowadzonych dla pracowników firm informatycznych. W wyniku tych dyskusji uzyskano w dużej mierze akceptację zaproponowanych rozwiązań. Autorzy stwierdzili, że podstawowym problemem jest brak wcześniejszego opisu metodyki Scrum o charakterze standardu. W związku z tym występują podzielone zdania co do kwestii, czy dane rozwiązanie jest elementem metodyki czy nie. 81

83 Podjęte badania i przeprowadzone kroki praktyczne wskazują na potrzebę systematyzacji opisu rozwiązań. Rozwiązania takie umożliwią szybszy dostęp do wartościowej wiedzy, umożliwią wiarygodne i łatwe porównanie metodyk. Niniejsze opracowanie zdaniem autorów stanowi systematyczny opis metodyki Scrum z uporządkowaniem jej niewyspecyfikowanych elementów. Literatura [1] Schwaber K., Sutherland J.: Scrum. Przewodnik po metodyce, 2010, [2] Decision Theory and Decision Behaviour, Normative and Descriptive Approaches, Springer, 1989 [3] Agile Manifesto, [4] Takeuchi H., Nonaka I.: The New New Product Development Game, Harvard Business Review, January February 1986 [5] Ćwiklicki M., Włodarek T.: Metodyka Scrum w Polsce w świetle badań, Nauka i Gospodarka 2010, nr 3 (6), s [6] Ćwiklicki M., Jabłoński M., Włodarek T.: Samoorganizacja w zarządzaniu projektami metodą Scrum, Wydawnictwo Mfiles.pl, Kraków 2010 [7] Schwaber K.: Agile Project Management with Scrum, Microsoft Professional, 2004 [8] Schwaber K., Beedle M.: Agile Software Development with Scrum, 2001 [9] Cohn M.: Agile estimating and planning, Pearson Education, 2006 [10] Agile Development Poster, [11] Scrum Alliance, [12] Scrum.org, [13] State of Agile Survey, 5th Annual State of Agile Software Development Survey, 2010, VersionOne Inc. [14] Werewka J., Szwed P., Rogus G.: Integration of classical and agile project management methodologies based on ontological models, w: Production engineering in making, ed. P. Łebkowski, Kraków, AGH University of Science and Technology Press, 2010, s [15] Szwed P., Werewka J., Rogus G.: Ontology based alignment of classic and agile project managment for an IT enterprise, Zeszyty Naukowe Wydziału ETI Politechniki Gdańskiej, Gdańsk, University of Technology Faculty of ETI Annals, t. 19, Seria: Technologie Informacyjne, 2010, nr 8, s [16] Szwed P., Rogus G., Werewka J.: Wykorzystanie ontologii do modelowania zwinnej metodyki zarządzania projektami Scrum, Zeszyty Naukowe Wydziału ETI Politechniki Gdańskiej, Gdansk University of Technology Faculty of ETI Annals, t. 19, Seria: Technologie Informacyjne, 2010, nr 8, s

84 4. Zarządzanie projektem w przedsiębiorstwie według metodyki Scrum 4.1. Wstęp Przesłaniem podstawowym metodyk zwinnych jest osiągnięcie zadowolenia klienta poprzez wczesne i nieprzerwane dostarczanie mu oprogramowania wysokiej jakości, spełniającego jego oczekiwania. To z kolei powinno być osiągane przez ścisłą współpracę zespołu z klientem oraz iteracyjne, przyrostowe podejście do procesu produkcji oprogramowania. Metoda przyrostowa z wielokrotną wymianą informacji dotyczących wymagań w trakcie realizacji projektu umożliwia lepszą przewidywalność i kontrolę ryzyka. Utrzymanie tych właściwości wymaga zastosowania wielu technik i usprawnień na wszystkich etapach procesu wytwarzania oprogramowania od pierwszych prac konceptualnych po testowanie i wdrażanie. W poprzednim rozdziale przedstawiono Scrum dla zespołów. Równie ważne jest umiejscowienie metodyki Scrum w organizacji rozwijającej produkt w postaci projektów. W opracowaniu zostanie przedstawiony systematyczny opis Scrum ze względu na zarządzanie projektem. Nie będą zawarte szczegóły dotyczące sprintów, gdyż zostały opisane w poprzednim rozdziale Zdarzenia metodyki Scrum w zarządzaniu projektem W rozwoju niepowtarzalnego produktu lub usługi celowe jest podejście projektowe. Jednym ze zweryfikowanych sposobów rozwoju produktu na podstawie metodyki Scrum jest propozycja potraktowania projektów jako kilka wydań produktu. Ostatnie wydanie produktu kończy projekt. W takim przypadku można zastosować propozycję zaproponowaną przez Dana Rawsthorne a w [11] zilustrowaną na rysunku 4.1. W takim podejściu występuje etap opracowania wizji projektu zawierający rozpoczęcie prac nad wizją produktu oraz zakończenie tych prac (kamień milowy). Zwykle właściciel biznesu lub inny interesariusz zgłasza ideę rozwoju produktu. Metodyka Scrum w zastosowaniu do projektów przewiduje kilka etapów planowania. Podstawowy z nich to planowanie harmonogramu wydań (Release plan). Pojedyncze wydanie 83

85 może zawierać jeden lub wiele sprintów i jest realizowane przez cały zespół pracujący pod przewodnictwem właściciela produktu. Planowanie harmonogramu powoduje uruchomienie kolejnych wydań: Wydanie początkowe. Pierwsze wydanie produktu. Pierwsze wydanie produktu zawiera pierwszy sprint składający się z czynności rozpoczęcia projektu i planowania wydania. Następnie wykonywane są (traktowane jako zdarzenia) kolejne sprinty rozwojowe produktu. Ostatni sprint w tym etapie to tzw. sprint wydaniowy, w którym następuje przekazanie produktu klientowi. W trakcie tego sprintu następuje planowanie następnego wydania. Wydania pośrednie. Kolejne wydania rozpoczynają się od planowania. Takie planowanie jest realizowane w trakcie sprintu wydaniowego poprzedniego wydania. Następnie występują kolejne sprinty rozwojowe produktu. Ostatni sprint w tym etapie to także sprint wydaniowy. Wydania końcowe. Wydanie końcowe różni się od wydań pośrednich czynnościami w sprincie wydaniowym, w którym zamiast planowania kolejnego wydania realizowane jest zamknięcie projektu. Rysunek 4.1 przedstawia zdarzenia związane z rozwojem produktu w ramach projektu. Rys Zdarzenia w rozwoju produktu w ramach projektu 4.3. Zestawienie procesów metodyki Scrum w zarządzaniu projektem W rozwoju produktu możemy wyróżnić dodatkowe procesy i artefakty, które nie występują w Scrumie dla zespołów przedstawionych w poprzednim rozdziale. Zestawienie tych nowych elementów zawiera tabela

86 Tabela 4.1 Zestawienie procesów Scrum dotyczących wydań i właściciela produktu Nazwa procesu Role wiodące Wejścia procesu Wyjścia (wyniki procesu) Opracowanie wizji projektu (project visioning) Właściciel biznesu, Właściciel produktu, Interesariusze Wizja produktu, Budżet rozwoju produktu, Plan rozwoju produktu, Rejestr produktowy dla projektu, Rozpoczęcie projektu (project startup activites) Właściciel produktu, Zespół, Scrum master Wizja produktu, Budżet rozwoju produktu, Plan rozwoju produktu, Rejestr produktowy (aktualny) Środowisko produkcyjne, Konsolidacja zespołu Planowanie wydania (release planing) Właściciel produktu, Zespół, Scrum master Wizja produktu, Budżet rozwoju produktu, Plan rozwoju produktu, Rejestr produktowy (aktualny) Cel wydania, Strategia wydania, Referencja bazowa wydania, Plan gry wydania, Rejestr produktowy dla wydania, Referencja bazowa wydania Wydanie produktu (product releasing) Właściciel produktu, Zespół, Klient Cel wydania, Strategia wydania, Referencja bazowa wydania, Plan gry wydania, Rejestr produktowy dla wydania Produkt (wydany) Zamknięcie projektu (project closeout activities) Właściciel produktu, Zespół, Scrum master Wizja produktu, Budżet rozwoju produktu, Plan rozwoju produktu Zarchiwizowane dane projektu, Końcowe rozliczenia projektu Monitorowanie wydania (monitoring the release) Zespół, Właściciel produktu Rejestr produktowy Wykresy wypalania dla wydania 85

87 Tabela 4.1. cd. Gromadzenie wymagań (requirements gathering) Właściciel produktu, Interesariusze Wizja produktu, Budżet rozwoju produktu, Plan rozwoju produktu, Rejestr produktowy (aktualny) Rejestr produktowy (aktualizacja) Pielęgnacja (utrzymanie) rejestru produktowego (product backlog grooming lub maitenance) Scrum master, Właściciel produktu, Zespół Wizja produktu, Budżet rozwoju produktu, Plan rozwoju produktu, Rejestr produktowy (aktualny) Rejestr produktowy (aktualizacja) Usuwanie przeszkód (impediments resolving) Scrum master, Właściciel produktu, Zespół Rejestr przeszkód, Lista rozwiązań blokad Rejestr przeszkód, Lista rozwiązań blokad Wyróżniamy następujące dodatkowe procesy: 1. Opracowanie wizji projektu (project visioning). 2. Rozpoczęcie projektu (project startup activites). 3. Planowanie wydania (release planing). 4. Wydanie produktu (product releasing). 5. Zamknięcie projektu (project closeout activities). 6. Monitorowanie wydania (release monitoring). 7. Gromadzenie wymagań (requirements gathering). 8. Pielęgnacja (utrzymanie) rejestru produktowego (product backlock grooming (maitenance)). 9. Usuwanie przeszkód (impediments resolving). Ostatnie trzy procesy z listy (7 9) to procesy ciągłe. Wykonywane są one z różnym nasileniem w trakcie rozwoju całego produktu Opracowanie wizji projektu Opis procesu W wyniku pomysłów dotyczących rozwoju produktu może powstać potrzeba realizacji prac objętych projektem. W związku z tym, że z projektem są związane koszty, należy dosyć dokładnie opisać zamierzenia projektu. Wysokopoziomowe cele, założenia i ograniczenia projektu opisywane są przez tak zwaną wizję projektu (Project Vision). Wizja projektu może 86

88 zawierać między innymi wizję biznesową, wizję produktu, budżet projektu, plan produktu (mapa drogowa produktu), może zawierać wydania i cele wydań, rejestr (własności) produktu. W wizji mogą być zdefiniowane długości sprintu. Role Przy opracowaniu wizji uczestniczą: właściciel biznesu, właściciel produktu, interesariusze, oraz zespół (estymacja wykonalności i pracochłonności). Artefakty wyjściowe Wizja produktu (product vision) przedstawia kierunki rozwoju produktu i wizję biznesową. Przy opracowaniu wizji należy odpowiedzieć na pytania: kto będzie kupował produkt, kto jest docelowym klientem, kto będzie użytkował produkt i kim są użytkownicy, jakie potrzeby klienta produkt spełnia i jaka jest wartość dodana produktu, jak wygląda porównanie produktu względem rozwiązań własnych i konkurencji; jaka jest docelowa cena produktu i możliwości sprzedaży produktu. Budżet rozwoju produktu (budget) opisuje kalkulacje budżetowe projektu, co może być potencjalnym źródłem zysku związanym z produktem, jaka jest opłacalność rozwoju produktu. Zwykle w celu określenia złożoności projektu właściciel projektu zaprasza zespół na sesję estymacji. Plan rozwoju produktu (product roadmap) zawiera opisy wielkości przyrostu produktu (wersje i warianty) oraz ograniczenia czasowe związane z rozwojem produktu. W planie powinna być podana liczba i cele kolejnych wydań, liczby i czasy trwania sprintów. Rejestr produktowy dla projektu (product backlog) stanowi wstępną wersję rejestru produktowego, w tym przygotowanie listy cech produktu, wstępne oszacowanie czasu ich realizacji oraz (wstępne) uporządkowanie listy pod kątem kolejności imple mentacji Rozpoczęcie projektu Opis procesu W trakcie tego procesu, po uzyskaniu zgody na realizację prac, powinny nastąpić czynności przygotowawcze do uruchomienia prac w projekcie. Do takich czynności należy integracja zespołu w celu wykonania prac w projekcie. W trakcie tego procesu powinna być objaśniona wszystkim członkom zespołu wizja projektu. Role Właściciel produktu objaśnia wizję projektu. Zespół współtworzy środowisko do uruchomienia prac w projekcie. Scrum master usuwa przeszkody związane z uruchomieniem projektu. Artefakty wyjściowe Środowisko produkcyjne. Przygotowywane są narzędzia oraz środowisko niezbędne do rozpoczęcia prac projektu. Konsolidacja zespołu. Wymagana jest konsolidacja zespołów w celu koncentracji nad pracami w projekcie. 87

89 Planowanie wydania Opis procesu Planowanie wydania polega przede wszystkim na wyznaczeniu planu zawierającego cel wydania (definicja sukcesu), strategię wydania, referencję bazową wydania (release baseline) i plan gry wydania (release game plan). Planowanie takie jest dokonywane głównie w trakcie spotkań planistycznych na potrzeby wydania. W trakcie tych spotkań definiowany jest cel wydania, wyznaczana jest wydajność zespołu, wybierane są historie wpływające na cel wydania. W trakcie tych spotkań zespół będzie miał możliwość zrozumienia historii użytkownika w dyskusji z właścicielem produktu i interesariuszami. Zespół dokonuje przeglądu już istniejących oszacowań historii oraz przeprowadza oszacowanie dla historii nieposiadających takich szacowań. Właściciel produktu powinien być przygotowany do podziału głównie tych historii użytkownika, które trudno zrozumieć lub oszacować. W spotkaniu mogą uczestniczyć interesariusze. Członkowie zespołu oceniają ryzyko dla każdej historii, podając je w skali kilkustopniowej. Właściciel produktu po ocenie wartości, oszacowań, kosztów i ryzyka wydania wybiera historie użytkownika, tworząc plan wydania. Celem spotkania wydania jest także to, aby zespół słownie zobowiązał się do dostarczenia opisanego wydania w zadanym terminie, a każdy członek zespołu to zobowiązanie rozumiał. Spotkanie planowania wydania jest ograniczone czasowo (timeboxed) i zawiera: cele wydania, rejestr produktowy z ustalonymi priorytetami, analizę ryzyka wydania, definicję własności i funkcjonalności, szacowany czas dostawy, analizę kosztów, plan inspekcji wydania, zmiany planu wydania ze sprintu na sprint, definiowanie ogólne celów i prawdopodobnych wyników. Przyjmuje się, że planowanie wydania zajmuje od 15 do 20% czasu wydania. Planowanie wydań Scrum może też być dokonywane na bieżąco podczas każdego przeglądu sprintu, dziennego spotkania Scrum. W planie wydania definiowane są kryteria wydania polegające na określeniu wielu warunków, artefaktów, czynności testowych, poziomu pokrycia testami, poziomu jakości, dopuszczalnych błędów, wyników oraz metryk. Określane są sposoby współpracy z innymi zespołami i poziomy zgodności (compliance level) z pracami tych zespołów. Spełnienie wszystkich tych kryteriów oznacza, że wydanie klientowi produktu może zostać przeprowadzone. Role Właściciel produktu objaśnia w miarę potrzeby historie, tworzy plan wydania (rys. 4.2). Zespół uczestniczy i współtworzy środowisko do uruchomienia prac w projekcie. Scrum master odpowiada za prawidłowy przebieg spotkań planistycznych. 88

90 Rys Przykład ilustracji planu wydania Artefakty wyjściowe Cel wydania (release goal) zawiera definicję sukcesu wydania oraz pogląd, co będzie zawarte w wydaniu. Strategia wydania (release strategy) określa, co stanie się z wydaniem, jakie są relatywne priorytety elementów zawartych w grze planistycznej (game plan), jakie wyważanie i kompromisy (tradeoffs) mogą być dokonane. Plan gry wydania (release game plan) zawiera: określenie, co się stanie, jeżeli wszystko pójdzie dobrze, braki wśród wbudowanych kompromisów (ale być może wbudowane ryzyka), określenie, co i kiedy dostarczymy, informacje o zwiększeniu się wydajności zespołu. Tworzy się rejestr produktowy dla wydania (który może się zmieniać dla sprintów). Referencja bazowa wydania (release baseline) to zapamiętanie planu gry wydania i rejestru produktowego w celu śledzenia zmian zakresu. 89

91 Wydanie produktu Opis procesu Wydanie polega na przekazaniu produktu przez zespół klientowi w sposób określony procedurą. Role Właściciel produktu uzgadnia procedurę wydania. Zespół przygotowuje produkt do wydania. Klient jest głównym odbiorcą wydania. Artefakty wyjściowe Produkt przekazywany jest w ramach wydania Zamknięcie projektu Opis procesu W trakcie tego procesu dokonywane jest formalne zamknięcie projektu. Role Właściciel produktu rozlicza projekt. Zespół archiwizuje dane dotyczące projektu, przekazuje środowisko do uruchomienia prac w projekcie. Scrum master dba o prawidłowy przebieg procesu zamknięcia projektu. Artefakty wyjściowe Następuje zarchiwizowanie danych projektu. Dokonuje się końcowego rozliczenia projektu Monitorowanie wydania Opis procesu Proces ma na celu monitorowanie prac nad wydaniem. Role Zespół aktualizuje wykres wypalania. Właściciel produktu sporządza raporty dotyczące wydania. Artefakty wyjściowe Wykres wypalania dla wydania (release burndown chart) aktualizowany jest pod koniec każdego sprintu. Proponowane jest tu wykorzystanie alternatywnego wykresu wypalania. 90

92 Gromadzenie wymagań Opis procesu W wyniku zbierania wymagań aktualizowany jest rejestr produktowy. Aktualizacja taka dokonywana jest głównie przez właściciela produktu kontaktującego się w tej sprawie z interesariuszami i zespołem. Właściciel produktu dokonuje przeglądu wymagań pod kątem ich poprawności, możliwości technicznych i wykonawczych. Wymagania są weryfikowane z kierownictwem organizacji rozwijającej produkt i z innymi interesariuszami. Aktualizacja rejestru produktowego polega na: dodaniu dodatkowych wymagań, uszczegółowieniu wymagań, określeniu wartości biznesowej wymagań, nadaniu priorytetów wymaganiom, wyznaczeniu kryterium gotowości dla wymagań. Mike Cohn [8] proponuje w procesie łowienia wymagań zastosowanie następujących technik przy tworzeniu zbioru historii: przeprowadzenie wywiadu (interview) z użytkownikami, tworzenie kwestionariuszy (questionnaires), wykorzystanie obserwacji w celu wyznaczenia sposobu postępowania użytkowników, przeprowadzenie warsztatów pisania historii użytkownika; warsztaty te polegają na spotkaniu członków zespołu, użytkowników i innych interesariuszy mogących wnieść wkład w tworzenie historii użytkownika; proponuje się organizowanie takich warsztatów przed rozpoczęciem wydania. W celu wyznaczania wymagań należy pracować z rzeczywistymi użytkownikami oraz z zespołami klienta. W przypadku gdy to nie jest możliwe, należy umiejętnie wykorzystywać przedstawicieli użytkownika (user proxies). W trakcie zbierania historii użytkownika pojawia się wiele szczegółów, które należy wykorzystać do pisania testów akceptacyjnych. Testy akceptacyjne należy pisać przed rozwinięciem tej części produktu, której dotyczą. Testy te są podstawowym kryterium sprawdzenia, że historie zostały w pełni zaimplementowane. Role Właściciel produktu jest odpowiedzialny za dostarczanie wymagań zapisanych w rejestrze produktowym na czas i z odpowiednim poziomem szczegółowości. Właściciel produktu jest ekspertem w domenie produktu i aktywnie tworzy wymagania. Interesariusze są potencjalnym źródłem wymagań. Właściciel produktu jest odpowiedzialny za pozyskiwanie wymagań od interesariuszy. Artefakty wyjściowe Zaktualizowany rejestr produktowy aktualizacja będzie polegała głównie na dodawaniu i precyzowaniu wymagań. 91

93 Pielęgnacja (utrzymanie) rejestru produktowego Opis procesu Utrzymanie rejestru produktowego (backlog maitenance) nazwane też upiększaniem rejestru produktowego (backlog grooming) nie jest formalnym procesem. Pielęgnowanie rejestru produktowego wykracza poza ustalenia określone wymaganiami i zmianami w tych wymaganiach. Dotyczy bowiem także planowania projektu, projektowania i architektury oraz rozwoju strategicznego projektu. Zagadnienia te dotyczą zarówno kwestii krótkoterminowych (np. sprintu) i długoterminowych (przykładowo strategii wydania). Według [1]: Pielęgnacja (grooming) rejestru produktowego jest działaniem polegającym na dodawaniu szczegółów, oszacowań i porządkowaniu elementów tego rejestru. Jest to proces ciągły, podczas którego właściciel produktu wraz zespołem deweloperskim pracuje nad szczegółami elementów rejestru produktowego. Podczas pielęgnacji rejestru jego elementy są przeglądane i korygowane. Nie zmienia to faktu, że elementy te mogą być uaktualnione w każdej chwili przez właściciela produktu lub według jego uznania. W przypadku gdy zespół poświęca mało czasu na utrzymanie rejestru produktowego, może dochodzić do: przedłużających się spotkań planowania sprintu, niskiej jakości planowania i wykonania, problemów związanych z projektowaniem, słabego prognozowania. Ken Schwaber [1] doradza przeznaczenie do 10% czasu na tę czynność. Proponowane jest przeprowadzenie spotkań związanych z utrzymaniem rejestru produktowego o stałym czasie trwania w stałym miejscu i stałych terminach. Niektóre źródła proponują takie spotkania dwa razy w tygodniu [12]. W spotkaniach powinien uczestniczyć cały zespół wraz z scrum masterem i właścicielem produktu. Szczególnie jest ważne przygotowanie rejestru przed spotkaniem planowania sprintu. Czynności utrzymania sprintu będą polegać na dodawaniu nowych historii użytkownika oraz powieści (epic), ekstrakcji historii z istniejących powieści i szacowaniu wysiłku dla istniejących historii. Role Scrum master jest odpowiedzialny za utrzymanie rejestru poprzez organizowanie spotkań pielęgnacji rejestru produktowego. Właściciel produktu podczas spotkań określa potrzeby biznesowe oraz co i kiedy ma dla niego wartość. Zespół uczestniczy w spotkaniu, traktując właściciela produktu jako partnera w interaktywnej pielęgnacji rejestru produktowego. Artefakty wyjściowe Zaktualizowany rejestr produktowy. Aktualizacja będzie polegała na poprawie oraz zwiększeniu jasności, szczegółowości i dokładności rejestru produktowego. 92

94 Usuwanie przeszkód Opis procesu Usuwanie przeszkód jest procesem, który jest wykonywany w sposób ciągły. Przeszkodą jest wszystko to, co przeszkadza w wykonaniu pracy członkom zespołu w sposób efektywny. Członkowie zespołu mogą zgłaszać informację o przeszkodach. Dokonują tego głównie w trakcie codziennych spotkań, które między innymi poprawiają komunikację, identyfikują i w efekcie usuwają przeszkody. Role Scrum master odpowiada za usuwanie przeszkód ograniczających postępy zespołu. Zespół informuje o występujących przeszkodach. Artefakty wyjściowe Rejestr przeszkód (impediments backlog) nazywany także rejestrem blokad jest w posiadaniu zespołu i jest dla niego widoczny. Lista rozwiązań blokad przedstawia opisy propozycji rozwiązań oraz identyfikuje rozwiązane przeszkody Warsztat Warsztat pracy w Scrum nie jest opisany w sposób jawny. Jednakże można wyróżnić zestaw zalecanych praktyk, technik i narzędzi. Praktyka zwykle polega na wyborze sposobu postępowania w wyniku zebranych pozytywnych doświadczeń. Praktyka jest zwyczajowym lub wypracowanym zachowaniem wskutek uzyskania doświadczenia związanego z wykonywaniem różnych czynności. Istnieje pojęcie najlepszych praktyk dotyczące wyboru najlepszych doświadczeń spośród wielu. Technika jest to systematyczna procedura, za pomocą której wykonywane są zadania wymagające pewnych umiejętności i polegające na ich doskonaleniu. Narzędzia mogą być dostarczone z zewnątrz lub być zbudowane przez zespół. Narzędzia wspomagają pracę i czynią ją bardziej efektywną Praktyki Praktyki Scrum, które warto wymienić, to: Samoorganizacja zespołu (self organizing team) nikt nie mówi zespołowi, jak powinien pracować. Przyjęcie reguły kolektywnego posiadania (collective ownership) wszelkie obiekty wytworzone przez zespół są znane wszystkim osobom należącym do zespołu. Każda z tych osób może podjąć się kontynuacji prac nad obiektem w ramach kolejnego zadania. Zespołowe przyjmowanie zobowiązań zobowiązanie definiowane w czasie planowania danego sprintu jest traktowane całościowo. Nie jest ono na tym etapie dystrybuowane pomiędzy poszczególne osoby w zespole. 93

95 Prowadzenie spotkań dziennych (stand up meeting) praktyka ta w oczywisty sposób stymuluje prowadzenie prac w ramach samoorganizującego się zespołu. Utrzymywanie ograniczenia czasowego dla sprintu sprint nie powinien trwać dłużej niż miesiąc. Przy dłuższych sprintach wystąpi duży nacisk na zmiany wymagań w trakcie sprintu. Ponadto planowanie dłuższego sprintu nie jest dokładne i walidacja produktu dokonywana jest zbyt późno. Członkowie zespołu nie ograniczają się do jednej specjalizacji każdy członek może wykonywać pracę innych i nie ma przypisanej jednej konkretnej funkcji. Komunikowanie zespołu poprzez kolokacje komunikacja jest utrzymywana poprzez umieszczenie zespołu w tym samym pomieszczeniu oraz przez system spotkań całego zespołu. Utrzymywanie wielkość zespołu na poziomie 7 (± 2) osób. W przypadku zespołu składającego się z mniej niż pięciu osób może występować brak pożądanych umiejętności, co może skutkować brakiem możliwości dostarczenia w sensownym czasie funkcjonalności produktu. Jeżeli zespół liczy więcej niż dziewięć osób, konieczna jest dodatkowa koordynacja. Oddzielenie estymacji od podejmowania zobowiązań przygotowanie rejestru produktowego wraz z oszacowaniem pracochłonności jego elementów jest oddzielnym procesem Narzędzia Do przykładowych i często wykorzystywanych narzędzi Scrum zaliczamy: wykresy wypalania monitorujące postęp prac, tablice zadań (task tables), narzędzia wspomagające wyznaczanie prędkości zespołu (stosowane do prognozowania wydania). Wykresy wypalania Wykresy wypalania przeznaczone są dla zespołu i mają w sposób obrazowy przedstawiać postęp prac. Właściwie wykresy wypalania przedstawiają zawsze ilość prac pozostałych do wykonania. Mogą być budowane dla: sprintu (oś X zawiera wówczas kolejne dni sprintu, oś Y liczbę godzin potrzebnych jeszcze do wykonania wszystkich zadań w sprincie), wydania (oś X zawiera kolejne numery sprintów, oś Y liczbę umownych punktów (zwykłych punktów historii) potrzebnych jeszcze do wykonania wszystkich wymagań w wydaniu), produktu (oś X zawiera wszystkie numery sprintów z wszystkich wydań, oś Y liczbę umownych punktów (zwykłych punktów historii) potrzebnych jeszcze do wykonania wszystkich wymagań w wydaniu). Wydawałoby się, że wykresy wypalania powinny posiadać stałą tendencję spadkową. Jednak tak zazwyczaj nie jest, gdyż: w trakcie rozwoju produktu może wyniknąć potrzeba wykonania dodatkowych prac mieszczących się w zakresie, oszacowania dotychczasowe były niedokładne. 94

96 Dodatkowo pomiędzy sprintami mogą się pojawiać nowe wymagania, które na wykresie wydania lub produktu będą podnosić wartości prac do wykonania. Wymagania takie definiuje właściciel produktu. Skutek powstawania nowych wymagań dobrze obrazuje alternatywny wykres wypalania (alternative release burndown chart). Ten wykres bazuje na reprezentacji słupkowej ze zmienną wysokością podstaw słupków. Przesunięcie podstawy to skutek dodania lub usunięcia wymagań przez właściciela produktu. Przesunięcie górnej części słupka obrazuje wyniki zmagań zespołu (wykonanie zadań). Taka notacja umożliwia wprowadzenie predykcji zmian także z uwzględnieniem tempa przyrostu funkcjonalności. Przykład konstrukcji graficznej umożliwiającej predykcję przedstawia rysunek 4.3. Przesunięta tam poniżej poziomu 0 dolna podstawa słupków przedstawia dodatkowe wymagania, które pojawiają się po kolejnych sprintach. Zakończenie bez uwzględnienia tempa wprowadzania nowych wymagań Zakończenie z uwzględnieniem tempa wprowadzania nowych wymagań Rys Alternatywny wykres wypalania bazujący na punktach historii Warto zauważyć, że możliwe jest nanoszenie linii trendu uwzględniającej dalszy przyrost wymagań określanych przez właściciela produktu oraz bez uwzględnienia przyrostu. W tym drugim przypadku będziemy mieli do czynienia z linią poziomą (jak na rysunku 4.3) nanoszoną w chwili zakończenia danego sprintu. Tablica zadań Interesującym przykładem narzędzia wspomagającego pracę w konkretnym sprincie może być graficzna prezentacja postępu prac, prowadzona na specjalnie do tego celu opracowanej tablicy ściennej. Tablica ta (task board) towarzyszy realizacji sprintu i jest jego mapą reprezentującą status wykonania wszystkich zadań (rys. 4.4). Ponieważ sprint może trwać wiele dni, treść tablicy przekazuje bardzo istotną informację kontrolną porządkującą pracę zespołu. 95

97 Historie do wykonania ( ródłowe) w sprincie Zadania do wykonania Zadania wykonywane Zadania do weryfikacji Liczba godzin Zadania wykonane Rys Scrum tablica zadań Poszczególne kolumny widocznej na rysunku 4.4 tablicy zawierają następującą treść: Historie do wykonania (story) opis historii: Jako użytkownik, chciałbym, aby.... Zadania do wykonania (to do) zadania niezrealizowane (lub do rozważenia). Zadania wykonywane (in progress) aktualnie przetwarzane (programista, wybierając zadanie, przemieszcza jego kartę tutaj). Podobnie, gdy uczestnik zespołu rezerwuje zadanie w czasie spotkania dziennego. Zadania do weryfikacji (to verify) oczekujące na przygotowanie testów ich wykonania (opisanych jako inne zadania) lub samoprzetestowanie. Liczby godzin (hours) bieżąca wartość licznika przepracowanych godzin. Zadania wykonane (done) gotowe, będące składnikiem historii, z której wykonania zespół musi się wywiązać. Każde zadanie na tablicy przedstawia karta przemieszczająca się od (w uproszczeniu) strony lewej do prawej reprezentując swoim położeniem kolejne stadia realizacji zadania. Tego typu rozwiązania nie tylko umożliwiają lepszą organizację pracy, lecz także dodatkowo integrują zespół, usprawniając komunikację przy uzgadnianiu przydziału zadań do realizacji czy podejmowaniu jakichkolwiek decyzji planistycznych. Narzędzia do wyznaczania prędkości zespołu Do planowania wydań i sprintów konieczna jest znajomość prędkości zespołu. Zazwyczaj prędkość zespołu przedstawiana jest jako liczba punktów (zazwyczaj punktów historii użytkownika) wykonywanych przez zespół w trakcie jednego sprintu. W trakcie spotkania 96

98 planistycznego sprintu zespół określa liczbę punktów, którą będzie w stanie wykonać w trakcie sprintu. Prędkość zespołu jest weryfikowana po zakończeniu każdego sprintu. Przy wyznaczaniu prędkości zespołu uwzględniane są tylko elementy rejestru produktowego, które zostały uznane przez właściciela produktu za wykonane (zgodnie z Definition of Done, DoD). Rysunek 4.5 przedstawia omawianą sytuację. Wyznaczenie prędkości zespołu jest konieczne do planowania wydań. Zazwyczaj właściciel produktu wykorzystuje trzy rodzaje prędkości zespołu: minimalną, przeciętną, maksymalną, w celu szacowania możliwych wariantów rozwoju produktu. Rys Przykład wyznaczania szacowanej i aktualnej prędkości zespołu Zdolność produkcyjna zespołu wyrażana jako wartość liczbowa reprezentująca ilość funkcjonalności wytwarzanej przez zespół w pojedynczej iteracji nosi w nomenklaturze lekkich metodyk nazwę prędkości zespołu (velocity). Wartość ta wyliczana jest na koniec iteracji jako suma początkowych estymat wszystkich wykonanych w iteracji funkcjonalności. Na potrzeby planowania wykorzystywana jest średnia (lub średnia krocząca) tej wartości. Duży problem stanowi oszacowanie prędkości pierwszej iteracji. Początkowo jakiekolwiek estymacje będą tu bardzo niedokładne. Istnieją trzy sposoby ulepszenia tego szacowania. Pierwszy z nich polega na przeprowadzeniu eksperymentu w postaci uruchomienia niewielkiej ilości testowych iteracji (dwóch lub trzech). Liczba zadań w sprintach będzie wówczas celowo zawyżona, a przedmiotem pomiaru będzie liczba punktów historii faktycznie zrealizowanych zadań. Wynik obserwacji będzie dość dokładny. 97

99 Kolejnym sposobem jest analiza wartości historycznych. Ta metoda ma powodzenie w sytuacji, gdy posiadamy już wstępną wiedzą o zespole i jego wcześniejszych pracach. Naturalnie zbieżność wiedzy historycznej z obecnie zastanymi okolicznościami, w jakich będzie pracował zespół, trzeba zweryfikować. Pomocne tu będzie ustalenie odpowiedzi na następujące pytania: czy zespół ma taki sam skład, czy właściciel produktu to ta sama osoba, czy technologia realizacji projektu jest ta podobna, czy planowane jest wykorzystanie tych samych narzędzi, czy estymacja elementów rejestru produktowego jest wykonywana przez te same osoby, czy dziedzina projektu jest taka sama, czy warunki pracy (środowisko) są takie same. Pozytywne odpowiedzi będą świadczyć o celowości wykorzystywania danych historycznych. Trzecia metoda to prognozowanie możliwych do wykorzystania roboczogodzin. Szacujemy tu liczbę godzin, które są przez daną osobę przeznaczane na pracę każdego dnia. Naturalnie odosobniona od innych danych liczba możliwych do wykorzystania roboczogodzin nie jest precyzyjnym wskaźnikiem, więc trzecią metodę stosuje się najczęściej, gdy dwie pierwsze nie są możliwe do zastosowania. W procesie konsultowania oszacowanej prędkości zespołu z właścicielem produktu konieczne jest jasne określenie stopnia niepewności tej estymacji. Pomocna staje się tu konstrukcja zwana stożkiem niepewności. Jest to uniwersalna konstrukcja graficzna, obrazująca postęp trafności prognozy w kolejnych iteracjach, próbach czy po kolejnych eksperymentach. W przypadku Scrum stożek niepewności będzie odnosił się do kolejnych iteracji, a nanoszona na nim wartość wyrażona będzie w punktach historii i umożliwi określenie przedziału potencjalnie popełnionego błędu Techniki Mianem technik określamy różnego typu wzorce i wytyczne stosowane jako rozwiązania usprawniające pracę w ramach Scrum. Wśród technik można także wyliczyć zwyczajowe normy postępowania przy realizowaniu czynności dyktowanych metodyką. Przykładowe techniki opisane zostaną w bieżącym podrozdziale. Będą to: technika definiowania wymagań na podstawie historii użytkownika, technika estymacji grupowej pracochłonności (planning poker), technika klasyfikacji rejestru produktowego pod kątem priorytetów, technika utrzymywania właściwej granulacji rejestru produktowego. Definiowanie wymagań na podstawie historii użytkownika Metodyka Scrum nie określa precyzyjnie sposobu definiowania wymagań. Można rozważać zastosowanie w tym celu historii użytkownika (user stories) [20], formalnego zapisu wymagań [10] czy prostych równoważników zdań. Zapisy te mogą być uzupełniane przez dodatkowe scenariusze, przypadki użycia, diagramy (np. UML), regulacje prawne lub biznesowe. 98

100 Największą popularnością cieszy się zbieranie wymagań na podstawie historii użytkownika. Zwykle zbieranie wymagań podlega na ich doprecyzowaniu w kolejnych etapach rozwoju produktu. Rysunek 4.6 przedstawia możliwy przykład uszczegółowiania. Temat Powie 1 Powie 2 Historia 1 Historia 2 Historia 3 Historia 4 Zadanie 1 Zadanie 2 Zadanie 4 Zadanie 6 Zadanie 3 Zadanie 5 Zadanie 7 Rys Uszczegółowianie wymagań w metodyce Scrum Rejestr produktowy może zawierać elementy opisujące wymagania wobec produktu na różnym poziomie ogólności. Charakterystykę poszczególnych elementów z rysunku można określić następująco [8]: Temat (theme) jest celem najwyższego poziomu przyjmowanym przy wytwarzaniu danego produktu. Tematy mogą być wykorzystywane zarówno na etapie planowania, jak i implementacji. Powieść (epic) jest wymaganiem zdefiniowanym w sposób bardzo ogólny, obejmującym przynajmniej jedną historię użytkownika. Powieść jest na tyle duża, złożona lub nieokreślona, że zespół projektowy musi konsultować wymagania z nią związane. Zwykle przy uściślaniu powstaje z powieści wiele historii użytkownika. Historia użytkownika (user story) najważniejsza postać wymagania wobec zespołu, która posiada wartość. Opisane wymaganie można zaprezentować, przetestować i zweryfikować. Historie użytkownika, zwane także skrótowo po prostu historiami, muszą być na tyle małe, by w trakcie iteracji zespół mógł ich wykonać co najmniej kilka. Zwykle historie są małymi częściami funkcjonalności rozumianej przez właściciela produktu. Mogą one także dotyczyć naprawy błędów, refaktoryzacji kodu itp. Wymagane jest, aby przed rozpoczęciem sprintu elementy rejestru produktowego o najwyższym priorytecie były wystarczająco małe, by kilka z nich mogło się zmieścić w sprincie. Pracochłonność historii jest szacowana przez zespół w postaci tak zwanych punktów historii 99

101 (story points). Punkty historii są umownymi jednostkami pracochłonności przyjętymi przez zespół. Jest to jednostka relatywna oszacowanie punktowe zadania jest realizowane względem innych zadań, bez odniesienie do skali czasu czy innych zasobów. Należy pamiętać, że punkty historii nie są określane według sztywnego wzorca. W praktyce ich wartość jest uzależniana także od ryzyka, złożoności i innych czynników potencjalnie skutkujących wydłużeniem lub skróceniem okresu realizacji punktowanego zadania. W trakcie planowania sprintu zespół dzieli historie na zadania w celu łatwego zarządzania ich realizacją w trakcie sprintu. Zadania są zapisywane do tak zwanego rejestru zadaniowego. Dopiero pracochłonność zadania jest określona liczbą roboczogodzin potrzebnych do jego wykonania. Estymowanie grupowe pracochłonności na bazie planning poker Właściciel produktu otrzymuje od zespołu oszacowania poszczególnych historii użytkownika. Dokonanie w zespole dobrego oszacowania pracochłonności nie jest rzeczą łatwą. Istnieją jednak techniki usprawniające takie procesy. Jedną z nich jest bazująca na estymacji kolektywnej oraz iteracyjnej wymianie opinii metoda o nazwie planning poker. Etymologia metody nie jest przypadkowa. Metoda bazuje na współpracy całego zespołu Scrum i użyciu kart, które są wielokrotnie rozdawane członkom zespołu. Głównym celem jest optymalizowanie oceny pracochłonności. Każdy z członków szacuje pracochłonność realizacji postawionych zadań poprzez wytypowanie karty. Otrzymuje on wcześniej zestaw kart o nominałach: 0, 1/2, 1, 2, 5, 8, 13, 20, 40, 100 i opcjonalnie karty określające niepewność (oznaczona symbolem? lub unsure) oraz zmęczenie (oznaczone przez symbol lub napis coffee cup albo need a break). Jedna z nich (wybrana) jest odsłaniana na komendę scrum mastera w tym samym momencie przez każdego z członków zespołu (synchronicznie) co otwiera dyskusję. W pierwszej kolejności głos zabierają osoby, które wytypowały najwyższą i najniższą estymatę wyjaśniając przyczyny swoich decyzji. Po ewentualnej dalszej dyskusji proces estymowania jest ponawiany. Tym razem członkowie zespołu dysponują jednak wiedzą o pobudkach, którymi inne osoby kierowały się podczas prowadzenia analizy. Wyniki estymowania są już bardziej zbliżone (co zbliża także do celu całego procesu). Finalnie zespół powinien wybrać jedną estymatę dla danego zadania, stanowiącą wynik. Dyskusja na poszczególnych etapach estymowania zadania jest limitowana czasowo limit czasu ustala scrum master. Zalety techniki planning poker to przede wszystkim zaangażowanie w procesie estymowania wielu osób jednocześnie, wspomaganie szacowania pracochłonności dyskusją prowadzoną na bieżąco oraz uzyskiwanie opinii osób będących specjalistami w różnych dziedzinach (grafik, programista, tester itp.). Wtórnie polepszenie komunikacyjności zespołu i wypracowanie poczucia poprawności i akceptacji wprowadzonego planu działania (wśród wszystkich członów zespołu). Nie jest określone, jakimi pobudkami powinien się kierować członek zespołu Scrum, dokonując wyboru karty. Zasadniczo można się tutaj posłużyć dowolną techniką. Przykładowo estymacją przez analogię lub techniką dekompozycji. W pierwszym przypadku zakładamy, że obecnie rozważane zadanie jest podobne do zadania realizowanego w przeszłości (naturalnie pod warunkiem odnalezienia takiego zadania). Technika dekompozycji będzie polegała na poszukiwaniu czynności elementarnych, koniecznych do zrealizowania zadania i szacowaniu na bazie zliczenia ich pracochłonności. 100

102 Szacowanie często rozpoczynamy od poszukiwania tzw. punktu odniesienia. Dostarcza go estymata jednej z opowieści. Często poszukuje się tu (w przybliżeniu) opowieści najkrótszej i ustala wartość punktową jej oszacowania na 1. Drugi sposób to wybranie opowieści o średniej złożoności i wytypowanie oszacowania jako wartości środkowej z przedziału możliwych wartości na skali punktowej. W przypadku procesu planowania wydania dopuszcza się naturalnie estymowanie poszczególnych elementów rejestru produktowego w celu określenia przybliżonego terminu zakończenia projektu wydaniem. Domeną metodyki zwinnej jest szybka adaptacja i reagowanie na zmiany wymagań, więc jakiekolwiek estymowanie terminu zakończenia prac będzie bardzo pobieżne (wymagania będą się zmieniać zgodnie z wolą właściciela produktu). Przybliżona estymacja często jest jednak przez właściciela produktu pożądana (chce on posiadać wiedzę o możliwym terminie wdrożenia, jeśli wymagania nie będą się zmieniały). W takiej sytuacji stosuje się estymację z wykorzystaniem tzw. dni idealnych (ideal days) [10]. Dzień idealny oznacza okres (najczęściej, choć niekoniecznie, jeden dzień roboczy), w którym praca trwa bez przerwy i zakłóceń. Posłużenie się jednostką dnia idealnego umożliwia określenie pracochłonności z wyrażeniem jej na skali czasu (w przeciwieństwie do jedynie relatywnie ujętej skali punktów historii) Klasyfikacja rejestru produktowego pod kątem priorytetów Klasyfikacja rejestru produktowego dla małych projektów dokonywana jest przez właściciela produktu. Określa on priorytety powieści, a w konsekwencji opowieści użytkownika (powstałych po zdekomponowaniu powieści) [2]. Zamiennie możliwe jest zastosowanie techniki priority poker bardzo zbliżonej do planning poker. Priority poker również bazuje na systemie punktowym, określając dla każdej opowieści tak zwane priority points. Skala punktowa na kartach jest tu jednak skrócona. Liczba punktów przyznawanych historiom jest wartością łączoną oszacowania złożoności danego zadania i jego wartości biznesowej. Granulacja rejestru produktowego Przed zaplanowaniem iteracji konieczne jest posiadanie dobrze przygotowanego rejestru produktowego. Kolejna z technik dotyczy zarządzania tym rejestrem. Jak wiadomo, wymagane jest, by przed rozpoczęciem sprintu elementy rejestru produktowego o najwyższym priorytecie były dostatecznie małe. Kilka z nich powinno zmieścić się jednocześnie w sprincie. Pracochłonność historii jest szacowana przez zespół w postaci punktów historii (story points). Punkty historii są umownymi jednostkami pracochłonności. Poszczególne posortowane wpisy rejestru podlegają dekompozycji sukcesywnej (wraz z kolejnymi iteracjami i zależnie od pozycji na liście związanej z priorytetem). Technika zakłada, że progresywne dekomponowanie rejestru produktowego zgodne jest z tzw. regułą 20/30/50. Według tej reguły tylko 20% wpisów powinny stanowić historie użytkownika gotowe do przeniesienia do sprintu. Przedwczesna dekompozycja rejestru nie jest więc wskazana. Kolejne 30% stanowić powinny powieści, stanowiące jednostki zbyt duże do przetworzenia w sprincie oraz takie, których wyspecyfikowanie wymaga dalszych rozważań i konsultacji. Ostatnie 50% to tematy szeroko ujęte zagadnienia przewidziane do opracowania w przyszłości (długoterminowe). Interpretując podział z punktu widzenia jego znaczenia, można powiedzieć, iż pierwsze 20% pełni rolę materiału gotowego do wykorzystania i potwierdza dojrzałość rejestru produktowego do rozpoczęcia sprintu, kolejne 30% określa rzeczy, które są dopiero klarowane, ostatnie 50% to zarys bliżej nieokreślonej przyszłości. 101

103 4.5. Skalowanie Scrum Metodyka Scrum jest dedykowana do prowadzenia projektów małych. Istnieją jednak techniki umożliwiające realizację projektu na tyle dużego, iż szczegółowe wymagania nie mogą już być kontrolowane przez jedną osobę właściciela produktu. Podstawowym założeniem jest tu wprowadzenie wielu zespołów Scrum pracujących równolegle nad dużym projektem. Współpraca ta, analogicznie do zwykłego Scrum, powinna być wspierana filarami przejrzystości, kontroli i adaptacji. Początkowy etap realizacji dużego projektu wymaga określenia wspólnych ograniczeń czasowych dla zespołów. Uzgadniane są także wyróżnione role osób zaangażowanych w prace, sposoby wymiany informacji czy narzędzia wykorzystywane podczas pracy. Właściciel produktu i właściciel biznesowy Skalowanie procesu wytwarzania oprogramowania wymaga innowacyjnego systemu weryfikowania wymagań. Są różne podejścia do tego problemu. Jednym z rozwiązań stosowanych w przypadku skalowania Scrum jest wprowadzenie osoby właściciela biznesowego (business owner). Koordynuje ona pracę aktorów będących właścicielami produktu. Produktem będzie teraz jedynie komponent lub inny wycinek systemu. Właściciele produktu są przypisani do poszczególnych zespołów Scrum. Właściciel biznesowy bierze odpowiedzialność za powodzenie biznesowe projektu i stawia wytyczne w tym kierunku. W sytuacji gdy właściciel produktu zajmuje się interakcją tylko z jednym zespołem, zmieniają się nieco jego zadania. Znika problem zyskowności przedsięwzięcia jako całości. Wizja produktu i sposób przekazywania jej zespołowi nadal stoi w centrum uwagi właściciela produktu, jednak obecnie jej kształt musi być efektem kompromisu z produktami pracy innych zespołów. Bez zmian pozostaje kwestia oceny rezultatów pracy zespołu, autonomii decyzji o kolejności wykonania definiowanych przez siebie zadań i zarządzania rejestrem produktowym [5]. Podział pracy pomiędzy zespoły tworzenie rejestrów produktowych Materiały stanowiące wymagania przekazywane są przez właściciela biznesowego. W przypadku skalowanego Scrum często nazywa się je zleceniami (żądaniami) rozszerzenia funkcjonalności (enhancement requests). Są one podstawą do formułowania poszczególnych powieści przez właścicieli produktu. Warto tu zaznaczyć, że jedno zlecenie może wpływać jednocześnie na wiele powieści. Przy okazji prac konceptualnych nad wstępnymi wymaganiami dla systemu tworzy się dodatkowo tak zwany dokument wizji (vision document). Umożliwia on odnotowanie zgłoszonych przez właściciela biznesowego zleceń. Dzięki temu nie ma konieczności natychmiastowego tworzenia wymagań szczegółowych dla wszystkich zleceń i rozpraszania ich w formie powieści pomiędzy zespołami Scrum. Dokument wizji umożliwia dodatkowo kontrolę kształtu przyszłego systemu w wymiarze długoterminowym [7]. Sam podział zleceń dostarczanych przez właściciela biznesowego może przebiegać według jednej z dwóch technik, przyjmowanych w czasie trwania projektu: Pierwsza z nich to podział strukturalny (najczęściej warstwowy lub komponentowy); poszczególne zespoły są wówczas wyspecjalizowane w rozwijaniu określonych komponentów lub warstw systemu, a w przypadku pojawienia się nowych zleceń dotyczących warstw lub już istniejących komponentów stosowny właściciel produktu przygotowuje nową powieść dla swojego zespołu. 102

104 Druga technika to podejście całościowe, zwane inaczej end-to-end; zgodnie z nim zespół będzie otrzymywał zadanie polegające na dodaniu do całego systemu określonej funkcji tak, aby uzyskać gotową wartość biznesową w postaci nowej funkcjonalności. W przypadku drugiego podejścia uzyskuje się pełną zgodność z metodyką Scrum, w której działania zespołu powinny bezpośrednio zmierzać do powiększenia wartości biznesowej produktu. Stwarza ono jednak więcej problemów przy podziale zespołów Scrum do pracy przy dużych projektach. Dzielenie zespołów i podział kompetencji Gdy rozproszenie geograficzne zespołów Scrum nie ma miejsca i istnieje dowolność podziału zespołu, celowe są rozważania nad optymalizacją tego procesu. Tworzenie zespołów jak najlepiej odpowiadających wymaganiom powinno przebiegać zgodnie z kilkoma istotnymi wytycznymi: Pierwsza z nich wymaga dzielenia zespołów o liczebności osobowej przekraczającej 10 na mniejsze i równoliczne. Dzięki niej zespół będzie najlepiej spełniał wymagania zadane metodyką Scrum [7]. Następna wymaga, aby liczba osób o szerokich zainteresowaniach i liczba ekspertów w wąskich dziedzinach były w zespole wyważone. Stymuluje to samoorganizację i polepsza proces samouczenia się zespołu. Kolejna wytyczna postuluje tzw. podwojenie specjalizacji, wymagając, aby w każdym zespole istniały przynajmniej dwie osoby o danej specjalizacji (zwłaszcza w wariancie end-to-end). Jeśli w projekcie występują komponenty mające kluczowe znaczenie dla realizacji projektu, praktykuje się też znaczne zróżnicowanie specjalizacji osób w zespole. Komponent taki to przeważnie jądro systemu, do którego prowadzą liczne interfejsy. Posiadanie wiedzy o zasadach funkcjonowania innych komponentów, łączonych przy użyciu tych interfejsów, jest zatem wskazane [3]. Scrum of Scrums Każdy z zespołów deleguje osobę uczestniczącą w spotkaniach koordynacyjnych. Osobą tą powinien być szeregowy członek zespołu. Spotkania umożliwiające komunikowanie zespołów noszą nazwę Scrum of Scrums. Są one analogią do spotkań dziennych realizowanych w ramach jednego zespołu Scrum. Nie muszą jednak odbywać się codziennie. W czasie spotkań jest przetwarzana specjalna forma rejestru produktowego, nosząca nazwę Scrum of Scrums backlog. Rejestr ten zawiera wszelkie dane o sprawach (issues) przenoszonych na następne spotkania Scrum of Scrums. Spotkanie Scrum of Scrums jest prowadzone przez wyznaczoną osobę, nazwaną Scrum master of scrum masters. W przypadku rozproszenia geograficznego zespołów możliwe jest prowadzenie spotkania Scrum of Scrums za pomocą multimediów [2, 7]. Agenda spotkania Scrum of Scrums odbywa się analogicznie do spotkanie dziennego. Poszczególne jej elementy dotyczą jednak całego zespołu, a nie indywidualnych członków zespołów. Na spotkaniach można utrzymywać system 15-minutowego raportowania o postępach, zgodnie z następującą serią pytań: Co zrobiliście od ostatniego spotkania? Co zrobicie, zanim znów się spotkamy? 103

105 Co spowodowało spowalnienie waszej pracy? Czy chcecie przekazać coś do zrobienia innemu zespołowi? Szczególnym przypadkiem występującym podczas organizacji Scrum of Scrums jest sytuacja, gdy rozproszenie geograficzne zespołów spowoduje dodatkowo występowanie przesunięć czasowych. W tej sytuacji szuka się najlepszego możliwego terminu spotkania, pilnując, aby spotkanie dla jak największej liczby zespołów odbywało na początku dnia (rys. 4.7). Pozostałe zespoły muszą delegować na spotkanie wyznaczoną osobę podczas czasu swojej pracy lub interakcja oparta jest na raportach pisemnych (zgodnie z agendą), gdy spotkanie wypada dla nich w godzinach nocnych [4]. Rys Problemy z przesunięciami stref czasowych w przypadku zespołów rozproszonych geograficznie występujące przy organizowaniu spotkania Scrum of Scrums Proces skalowania Scrum jest regulowany serią technik i praktyk wychodzących poza ramy metodyki Scrum. W podrozdziale przedstawiono tylko niektóre z nich. Obranie innych dróg przy organizowaniu pracy dużego zespołu jest jak najbardziej możliwe. Celowość wyboru takiego czy innego rozwiązania w związku z różnorodnością stawianych zadań i okoliczności nie jest jednoznacznie określona Podsumowanie Włączanie przyszłych użytkowników w proces wytwórczy ma dla nich kluczowe znaczenie. Osoby te traktują powstający produkt jak własny już we wczesnych fazach jego powstawania, stale podnosząc swoją świadomość co do sposobu jego działania i odnosząc tę wiedzę do swojej znajomości środowiska, w którym system docelowo ma działać. Dostarczając na tej podstawie informacji o dopasowaniu bądź jego braku, znacznie przyspieszają implementację poszczególnych funkcjonalności systemu. Podobnie duża autonomia zespołu projektowego ma sprzyjać zaangażowaniu pracowników w realizowane przedsięwzięcie, a także wpływać na ich kreatywność i chęć poszukiwania nowych, przełomowych rozwiązań. 104

106 Literatura [1] Schwaber K., Sutherland J.: Scrum. Przewodnik po metodyce, 2010, [2] Molokken-Ostvold K.: Combining estimates with planning poker an empirical study, Software Engineering Conference, ASWEC ieeexplore.ieee.org, 2007, s [3] Sutherland S., Viktorov A., Blount J., Puntikov N.: Distributed Scrum: Agile Project Management with Outsourced Development Teams, System Sciences, 2007 [4] Jensen B., Zilmer A.: Cross-continent development using Scrum and XP, Extreme Programming and Agile Processes in Software Engineering, Lecture Notes in Computer Science, 2003, Volume 2675/2003, Springer [5] Eckstein V.: Agile software development in the large, Dorset House, 2004 [6] Agile Manifesto, [7] Schwaber K.: Agile Project Management with Scrum, 2004 [8] Cohn M.: User Stories Applied: For Agile Software Development, 2004 [9] Scrum Alliance, [10] Scrum.org, [11] Rawsthorne D.: Release Planning and Monitoring, Collabnet 2010, media/pdfs/sbu_releaseplanning.pdf [12] Galen R.: Grooming your Agile Backlogs for Success, grooming-your-agile-backlogs-for-success.html

107 5. Programowanie ekstremalne (XP) 5.1. Wprowadzenie Obok metodyki Scrum, której podstawowymi obiektami zainteresowania są organizacja pracy zespołu i zarządzanie projektem, wykorzystuje się metodyki zwinne określające czynności i praktyki związane z iteracyjnym wytwarzaniem oprogramowania. Jedna z nich identyfikowana jest pod nazwą programowanie ekstremalne (lub Extreme programming, XP). Bazując na tych samych co Scrum przesłankach [5], metodyka ta promuje wysokie standardy inżynierskie realizowanych przy jej użyciu przedsięwzięć. Paradygmat programowania ekstremalnego niesie ze sobą liczne wskazówki dotyczące projektowania, programowania, zarządzania konfiguracją czy testowania oprogramowania wytwarzanego przez samoorganizujący się zespół. Przez swoich twórców (Kenta Becka i Rona Jeffriesa) programowanie ekstremalne jest określane mianem systemu wartości, którymi powinien kierować się każdy profesjonalny twórca oprogramowania, niezależnie od zakresu swoich kompetencji [8, 9]. XP zakłada silne zintegrowanie zespołu tworzącego oprogramowanie z klientem. Wszystkie osoby, począwszy od klienta zamawiającego oprogramowanie poprzez analityków, projektantów, programistów aż po testerów, powinny komunikować się na podstawie wykorzystywanych na co dzień i postulowanych przez XP praktyk. Powinny także honorować wspólny zbiór wartości: dbałość o efektywną komunikację pomiędzy zaangażowanymi w przedsięwzięcie osobami; częste przekazywanie informacji i wiedzy na różnych poziomach i w różnym kontekście; śmiałość przy poszukiwaniu nowych rozwiązań technologicznych; odpowiedzialność za wspólnie realizowaną pracę; wzajemny szacunek. Metodyka XP oparta jest na spostrzeżeniach jej twórców [9], iż żaden odgórnie zdefiniowany proces produkcji nie umożliwia osiągnięcia sukcesu w tak szybko zmieniającym się środowisku, jakim jest produkcja oprogramowania. Zbyt wiele czynników ulega ciągłej zmianie od otoczenia biznesowego i potrzeb klienta, po wykorzystywane do wytworzenia produktu końcowego narzędzia i technologie. Tylko umiejętność ciągłego dostosowywania się (adaptacji) do nowych okoliczności pozwala na osiągnięcie satysfakcjonującego wszystkie strony sukcesu. Zastosowany metamodel będzie polegał na konceptach oraz zbiorze konceptów o pewnej strukturze. Koncept jest jednostką myśli, która może być zdefiniowana lub opisana. 106

108 Do opisu metodyki, podobnie jak w poprzednich podrozdziałach, przyjęto zestaw podstawowych konceptów wymagających szerszego omówienia w ramach metodyki. W przypadku XP wyróżniono: uniwersalne zasady (pryncypia), artefakty, role, procesy. Dokonano także szybkiej analizy porównawczej XP oraz wcześniej opisywanej metodyki Scrum z uwzględnieniem różnic w klasyfikacji tych dwóch metodyk XP a Scrum Jak wspomniano, w odróżnieniu od metodyki Scrum, XP traktuje w głównej mierze o inżynierskim aspekcie wytwarzania oprogramowania. Warto jednak wspomnieć, iż istnieje pewien zestaw cech wspólnych z metodyką Scrum, który w wymiarze praktycznym pozwala łączyć je obydwie. Takimi cechami są: uznanie autorytetu i samodzielności zespołu; zaangażowanie klienta końcowego w prace zespołu (tu promowana jest idea on-site customer, czyli idea posiadania klienta przebywającego z zespołem na co dzień, w miejscu, w którym realizowany jest zamawiany przez niego produkt); iteracyjne planowanie twórcy programowania ekstremalnego podkreślają, iż sformułowanie iteracyjne planowanie lepiej oddaje naturę postulowanego podejścia niż iteracyjne wytwarzanie [12]; ciągłe (regularne) dostarczanie działającego oprogramowania jako jedynej wiarygodnej miary postępów prac; dążenie do doskonałości poprzez szczerą i otwartą analizę popełnionych błędów. Metodyka XP przeznaczona jest głównie dla małych zespołów. Nie umożliwia skalowania jak w przypadku Scrum. W zakresie zainteresowania XP leżą metody pracy takiego zespołu programistycznego, kiedy Scrum dostarcza ogólniejszych szablonów postępowania przy zarządzaniu całym projektem. Poszczególne pozycje z powyższej listy mają jednak zastosowanie w obydwu tych aspektach. Tworzenie oprogramowania w ramach metodyki XP jest prowadzone iteracyjnie. Podobnie jak w metodyce Scrum, bazującej na kilkutygodniowych sprintach, iteracja w XP zajmuje od jednego do trzech tygodni. Wydania produktu mogą przebiegać na przykład w cyklu kwartalnym. Rozpoczęcie pracy nad kolejnymi wydaniami produktu jest poprzedzane krótką fazą planowania przeprowadzaną przed rozpoczęciem każdej nowej iteracji. Zasady planowania iteracji oraz ogólne wytyczne postulowane metodyką XP z planowaniem powiązane zostaną omówione w kolejnych podrozdziałach Uniwersalne zasady (pryncypia) Twórcy metodyki proponując wiele praktyk, których wykorzystanie może pomóc w osiągnięciu sukcesu, podkreślają, że kluczowym elementem jest zmiana wyznawanego systemu wartości i przyjęcie określonego zestawu reguł, bez których nawet pedantyczne (bez rozumienia celu) stosowanie poszczególnych praktyk nie przyniesie oczekiwanych rezultatów. 107

109 Nie jest przy tym istotne, czy wykorzystywane są wszystkie praktyki jednocześnie, czy jedynie ich podzbiór. Decyzję o tym, które z proponowanych praktyk przystają do realizowanego projektu, pozostawia się w gestii zespołu. W literaturze przewija się od kilkunastu do kilkudziesięciu promowanych przez programowanie ekstremalne praktyk; wśród nich najczęściej wymienia się następujące [12, 14]: Jedność zespołu (whole team) Zespół pracuje wspólnie, o ile to możliwe, przebywając w jednym pomieszczeniu (sit together), zachowując ciągłość składu osobowego (team continuity); w skład zespołu jako jego pełnoprawny (pod względem zarówno przywilejów, jak i obowiązków) członek wchodzi klient (on-site customer). Kondycja zespołu W celu zapewnienia dobrej kondycji zespołu projektowego oraz jego wysokiej produktywności postuluje się brak nadgodzin (40-hour week), zezwolenie na pewną swobodę wykorzystania czasu pracy (slack) oraz stałe tempo pracy (sustainable pace). Informatywne miejsce pracy (informative workplace) Informacje istotne dla zespołu lub przebiegu projektu uwidocznione są bezpośrednio w miejscu pracy zespołu, w sposób umożliwiający wszystkim zainteresowanym nieograniczony do nich dostęp. Wartość odczuwalna dla klienta (customer visible functionality) Zadowolenie klienta jest przedmiotem najwyższego zainteresowania zespołu zarówno podczas planowania, jak i analizy dostarczonego oprogramowania. Aby ułatwić przyjęcie tej optyki, postuluje się szerokie wykorzystanie historyjek użytkownika (user stories), które rozważa się z perspektywy wartości biznesowej, ryzyka i kosztów wytworzenia, uzupełnionych o testy akceptacyjne (acceptance testing). Iteracyjne planowanie (planning game) Planowanie, jako czynność wykonywana zespołowo, otwiera cykl produkcyjny wydania oprogramowania (release) dyskutowane i estymowane są historyjki oraz każda z wchodzących w skład wydania iteracji (iteration). Tu dyskutowany jest podzbiór historyjek, przygotowywane są listy zadań, następuje także podjęcie zobowiązania przez programistów (sign-up); z zagadnieniem tym związany jest także postulat negocjowalnego zakresu kontraktu (negotiated scope contract) przy jednoczesnym zamrożeniu jego budżetu i czasu trwania (fi xed time, fi xed cost, fi xed quality, fl exible scope). Szybkie prototypowanie (spike) Niewiadome i ryzyka w projekcie rozwiązuje się za pomocą szybkiego, najwyżej kilkudniowego prototypowania (spike), podejście takie jest uważane za lepsze niż teoretyczne rozważania. Prostota projektu (simple design) Dbałość o prostotę projektu systemu i kodu źródłowego przejawia się zarówno w szybkich (15 30-minutowych) sesjach projektowych przy użyciu narzędzi takich jak karty CRC czy odręczne, proste diagramy UML, przez wykorzystanie metafor (system metaphor) jako narzędzia przekazu istoty działania systemu oraz, na poziomie kodu źródłowego, w staraniu o czytelność, przejrzystość, osiąganą za pomocą technik refaktoryzacji (refactoring) i wykorzystania wzorców projektowych (design patterns). 108

110 Programowanie w parach (pair programming) W odróżnieniu od formalnych sesji przeglądowych (review) w XP proponuje się pracę w dwuosobowych i często rekonfigurowanych zespołach, w których jedna osoba aktywnie wykorzystuje klawiaturę (driver), zapisując kod źródłowy, natomiast druga (pilot) dba o zgodność z projektem, przejrzystość i spójność tworzonego fragmentu oprogramowania. Wspólna własność kodu źródłowego (collective code ownership) W XP nastąpiło odejście od modelu wyłączności, w którym prawo modyfikacji poszczególnych fragmentów oprogramowania mieli tylko specjalizujący się w tym fragmencie programiści. Prawa do modyfikowania całego kodu źródłowego utrzymywanego przez zespół mają wszyscy jego członkowie, a dzięki szerokiemu wykorzystaniu standardów kodowania (coding standard), testów jednostkowych (unit test) oraz refaktoryzacji (refactoring) zapewnia się nie tylko przejrzystość samego kodu źródłowego, ale również równomierny rozkład wiedzy o jego funkcjonowaniu wśród członków zespołu. Pojedyncza linia oprogramowania (single code base) Ta praktyka bazuje na obserwacji, że wprowadzanie tej samej poprawki lub nowej funkcjonalności do wielu utrzymywanych równolegle linii produktu jest nie tylko pracochłonne, ale również powodujące błędy. Postuluje się zatem utrzymywanie pojedynczej bazy kodu źródłowego, wspólnej dla wszystkich linii produktu. Odmienną funkcjonalność osiąga się poprzez rozwiązania architektoniczne systemu (np. konfigurowalne włączanie/wyłączanie funkcjonalności w zależności od odbiorcy końcowego lub platformy docelowej). Wysoka jakość wytwarzanego oprogramowania Jakość powstającego produktu podnosi nie tylko szerokie wykorzystanie testów jednostkowych i akceptacyjnych. Ważnym elementem jest tu także spostrzeżenie, że tylko aktywna, częsta konsolidacja całego produktu (continuous integration), jego testowe wdrażanie i uruchamianie (deployment) w środowiskach zbliżonych do środowisk produkcyjnych są w stanie wychwycić problemy, które inaczej mogłyby zostać wykryte dopiero w środowisku produkcyjnym. Aby to zapewnić, budowanie systemu nie powinno zabierać więcej niż kilka minut (10-minutes build), instalacja systemu oraz testowe uruchamianie powinny być wykonywanie automatycznie [19] Artefakty Materiały powstające w ramach poszczególnych iteracji to oczywiście wersje tworzonego systemu. Zanim dojdzie do wytworzenia i zaprezentowania wersji oprogramowania (tzw. małego wydania small release) wytwarzany jest cały szereg materiałów pośrednich. Proces rozpoczynany jest wytwarzaniem przez klienta tzw. historii użytkownika (user stories). Są one archiwizowane na kartkach. Typowa historia może zawierać pola: referencja do konkretnego projektu, flagi typu historii (poprawka, rozszerzenie funkcjonalności, nowa historia itp.), określenie priorytetu, oszacowanie ryzyka (jeśli klient jest władny tego dokonać), szczegółowy opis historii. Na bazie historii użytkownika zespół jest w stanie określić podstawowe wytyczne ograniczające najbliższą iterację. Tworzony jest wówczas tzw. architectual spike. Dzięki niemu możliwa jest wstępna redukcja ryzyka projektowego poprzez ogólne określenie rozwiązań 109

111 technologicznych (środowisko, narzędzia), użytych przy wytwarzaniu systemu. W kolejnym kroku tworzony jest tzw. spike solution. Zawiera on opracowany przez zespół (przy wsparciu wiedzy eksperckiej, konsultacji z klientem i pomocy trenera) zestaw szczegółowych rozwiązań problemów technicznych oraz rozwiązań zagadnień merytorycznych, dotyczących powstającej w iteracji nowej funkcjonalności systemu. Po osiągnięciu spike solution rozpoczyna się wytwarzanie nowej funkcjonalności systemu. Procesowi temu towarzyszy realizowany w parze mechanizm kontrolny bazujący na wytwarzaniu i aplikowaniu testów. Jest on bardzo rozbudowanym składnikiem metodyki XP. Podejście test najpierw (test-fi rst) oraz określanie funkcjonalności poprzez planowanie testów (test driven development, TDD) stały się technikami promującymi sprawne wykonywanie wysokiej jakości kodu, jego spójność i prostotę [18]. Oprócz testów akceptacyjnych to podejście określa także elementarne testy funkcjonalności systemu. Te drugie użytkowane są rutynowo w procesie ciągłej walidacji oprogramowania, są także stosowane przez klienta w celu dokonania oceny dostarczonego mu produktu. Te testy mają zasadniczo dwa zadania: wykazanie, iż nowo powstały kod funkcjonuje poprawnie, wykazanie, iż kod modyfikowany (np. w procesie refaktoryzacji czy rozszerzania funkcjonalności) nie został przez te modyfikacje uszkodzony (nadal funkcjonuje poprawnie). Metodyka XP przewiduje istnienie trzech rodzajów testów: testy jednostkowe (unit tests), testy akceptacyjne (acceptance tests), testy interaktywne lub wizualne (visual tests). Pierwsze z nich (testy jednostkowe) tworzone są przez programistów. Są automatyczne co przeważnie oznacza, iż uruchamiane są w serii za pośrednictwem dodatkowego oprogramowania zarządzającego testami. Testy jednostkowe są tworzone w zbiorach i dotyczą każdego elementu oprogramowania, z którym można nawiązać jakąkolwiek komunikację (przekazać dane i sprawdzić wyniki przetwarzania). Programista jeszcze przed napisaniem konkretnej procedury powinien stworzyć test, który będzie ją sprawdzał. Pisanie procedury testowej nie powinno jednak zabierać zbyt dużej ilości czasu. Dodatkowo procedury testujące powinny przewidywać spójny dla wszystkich przypadków system przekazywania raportów o wynikach. Umożliwia to tworzenie narzędzi automatyzujących procesy testowania oprogramowania. Dążenie do automatyzowania procedur testowych jest istotne, gdyż są one uruchamiane po każdorazowym łączeniu kodu oraz po przerabianiu jego treści (np. refaktoryzacji). Wspomniana konieczność automatyzacji procesu testowania wyznaczyła drogę rozwoju wielu dedykowanych narzędzi testujących (potocznie zwanych unitami). Narzędzia typu Maven, Gump, Junit czy Python PyUnit wspierają tworzenie testów oraz automatyzują procedury testujące. Narzędzia takie umożliwiają rejestrowanie jednostek testujących, a następnie uruchomienie testowanego modułu jako systemu osadzonego. Wynik testów stabilizowany jest automatycznie, gwarantując względną pewność tego, iż nowy kod działa poprawnie, a kod utworzony wcześniej nie został uszkodzony podczas dodawania nowej funkcjonalności czy refaktoryzacji. Najczęściej użycie narzędzia do wspomagania testów polega na skorzystaniu z dostarczanego przez nie API. Wyprowadzamy wtedy z klasy w zasobach API własną klasę testującą. W klasie tej definiujemy 110

112 testy, polegające na sekwencyjnym wywoływaniu asercji testujących. Każde wywołanie asercji polega na wywołaniu funkcji testowanego systemu z podaniem do niej określonych w asercji parametrów i skontrolowaniu zwracanego przez nią wyniku. Tak przygotowane testy możemy agregować w serie (służy do tego funkcjonalność wspomnianego API narzędzia testującego) i następnie uruchamiać w takich seriach. Uzyskujemy wówczas test zautomatyzowany. Wspomniana wielokrotnie powyżej refaktoryzacja to modyfikacja istniejącego kodu w celu jego strukturalnego polepszenia. Modyfikacja ta nie może zmieniać zewnętrznego zachowania programu. Refaktoryzacja realizowana jest głównie w celu poprawienia wydajności działania kodu, zwiększenia jego przejrzystości (co jest szczególnie istotne w sytuacjach, kiedy kod jest współtworzony przez wielu programistów) czy uzyskania zmian w strukturze (projekcie) systemu. Literatura źródłowa podaje wiele technik i sposobów przeprowadzania takich modyfikacji [4], istnieją także katalogi zunifikowanych rozwiązań projektowych (architektonicznych), których konsekwentne stosowanie poprawia czytelność kodu źródłowego. Prowadzenie testów po refaktoryzacji jest szczególnie istotne. Testy jednostkowe często są przypisywane do klas definiowanych przez kod języka programowania. Funkcjonalność migrująca pomiędzy klasami (w konsekwencji procesu refaktoryzacji) musi być kompleksowo poddana poprawnie prowadzonym testom. Zestaw testów jednostkowych musi przewidywać taką sytuację. Testy akceptacyjne są projektowane przez klienta. Gdy klient nie jest w stanie samodzielnie ich zapisać, wytwarzane są przez programistę. Opisują one oczekiwania klienta wobec powstającego produktu. Nazywane są też czasami testami funkcjonalnymi (functional tests) [13], gdyż przedmiotem testowania jest tu zaimplementowana funkcjonalność systemu opisywana wcześniej w historiach użytkownika. Naturalnie testy akceptacyjne powinny być dokładniej określone niż same historie użytkownika. Kryteria tych testów powinny brać pod uwagę oprócz walidacji wartości typowego zwracanego wyniku także warunki brzegowe czy wyrażenia typu jeżeli to. Komplet testów akceptacyjnych nie jest jednak specyfikacją wymagań. Pomyślne przejście takich testów satysfakcjonuje klienta, ale nadal nie ma wymiaru formalnej specyfikacji. Testy wizualne to komplet wytycznych (zapisanych na przykład w formie listy pozycji do sprawdzenia) umożliwiający sekwencyjne przeprowadzenie wizualnej kontroli funkcjonowania systemu. Kontrola ta prowadzana jest głównie z punktu widzenia aktorów (użytkowników systemu) i dotyczy oceny interfejsów systemu. W praktyce sprowadza się ona do kontroli ergonomii interfejsów graficznych lub estetyki prezentowanych za ich pośrednictwem treści. Pośrednio możliwe jest kontrolowanie wyników generowanych przez system i prezentowanych za pomocą graficznych interfejsów lecz tym powinny zajmować się wcześniej omówione testy. W czasie iteracyjnej rozbudowy systemu testy są ciągle aktualizowane. Każdy przyrost funkcjonalności, nowe wymaganie klienta czy zmiana struktury systemu będzie w konsekwencji wpływać na zbiór testów. Testy są rozbudowywane także w przypadku przypadkowego wykrycia błędów wcześniej testami nieprzewidzianych zabezpieczając przed powtórzeniami takich samych błędów w przyszłości. Iteracja kończy się wytworzeniem wydania (small release), będącego sprawnym modułem nowo powstającego systemu, za pomocą którego możliwe jest skontrolowanie nowo wytworzonej funkcjonalności. 111

113 5.5. Role Zespół XP to grupa ludzi, mająca dążyć do wytworzenia oprogramowania wysokiej jakości oraz takiego, które będzie satysfakcjonowało klienta. Zespół ten nie składa się jednak wyłącznie z wytwórców samego kodu oprogramowania (programistów), lecz w jego ramach znajdują się także osoby zarządzające, wspomagające procesy wytwórcze od strony merytorycznej czy walidujące wyniki; w ramach metodyki definiowane są osoby: programista, tester, konsultant w dziedzinie (specjalista), zarządca, klient oraz trener. Programista W przypadku metodyki XP programista podobnie jak w innych metodykach zajmuje się wytwarzaniem konkretnego kodu realizującego funkcjonalność. Jest jednak współodpowiedzialny za całość wytwarzanego kodu, więc zakres jego kompetencji jest większy. Wiąże się on przede wszystkim z koniecznością posiadania umiejętności w zakresie sprawnego komunikowania się w zespole. Ponadto metodyka XP zakłada periodyczne prowadzenie czynności dodatkowych, związanych z wytwarzaniem kodu, takich jak jego refaktoryzacja czy prowadzenie testów. W XP programista może ingerować w dowolne fragmenty kodu, gdyż posiada wiedzę o tym kodzie. Zmienia to sposób patrzenia na wytwarzany kod, obligując do wytwarzania kodu maksymalnie uproszczonego i przejrzystego. Tester Osoba testera nie jest jedynie postrzegana jako przeciwwaga dla programisty, wydająca opinie o jakości jego produktów. Tester w zespole dostarcza szeroko pojętą informację o wynikach prowadzonych periodycznie testów i stanowi ważne ogniwo wspierające programistów w kolejnych czynnościach związanych z wytwarzaniem oprogramowania w ramach iteracji. Należy pamiętać, iż testy wytwarzane są w kooperacji z klientem. Stanowią one zatem informację uzupełniającą o wymaganiach klienta, które innymi kanałami (na skutek przeoczeń, zmiany zdania itp.) nie zostały zgłoszone. Klient Klient jest naturalnie rolą kluczową. Tworząc historie dostarcza on podstawowej informacji o wymaganiach. Współpracuje także z testerem w dziedzinie formułowania testów akceptacyjnych (lub nawet wytwarza je osobiście). W czasie realizacji iteracji rozstrzyga wszelkie napotkane wątpliwości, posiadając autorytatywną wiedzą o zasadach funkcjonowania przyszłego systemu. Klient dokonuje także oględzin gotowych wersji produktu, dzieląc się ich wynikami z zespołem. Konsultant Realizacja jakiegokolwiek systemu informatycznego wymaga dostępu do bardziej lub mniej rozbudowanej wiedzy dziedzinowej (o dziedzinie, branży, której system dotyczy). Taka wiedza specjalistyczna pozyskiwana jest od konsultanta. Może dotyczyć przykładowo przebiegu procesu produkcyjnego, będącego przedmiotem przetwarzania przez tworzony system czy choćby obiegu dokumentów, który ma być przez system informatyczny wspierany. Konsultant nie śledzi całego procesu wytwarzania oprogramowania w zespole, lecz zespół zwraca się do niego z konkretnym, jasno przedstawionym problemem do rozwiązania. 112

114 Zarządca Zarządca to rola porządkowa, do której wyłaniany jest jeden z członków zespołu. Zarządca archiwizuje przebieg prac, przykładając szczególną wagę do powodzenia testów w poszczególnych iteracjach. Dodatkowo analizuje obłożenie pracą w ramach poszczególnych iteracji, oszacowując możliwości ukończenia prac na czas. Dostarcza informację kontrolną i doradczą dla zespołu. Trener Trener to doświadczona osoba, potrafiąca stymulować zespół do podejmowania odpowiednich zadań. Odbywa się to przeważnie poprzez przedstawianie przypadków użycia, wymagających specjalnej uwagi, a przez zespół niedostrzeganych. Trener nie narzuca jednak konkretnych rozwiązań, gdyż decyzje dotyczące rozwiązywania problemów podejmuje zespół. Trener jest też partnerem do programowania. Rozpatrując pojedyncze role w zespole XP trzeba cały czas pamiętać, iż ich wyróżnienie ma na celu wprowadzenie wszelkich możliwych udogodnień umożliwiających sprawne rozwiązanie problemów merytorycznych, technicznych oraz maksymalizację jakości wytwarzanego oprogramowania. Przy podziale zadań w ramach ról XP ten cel przewodni nie może zejść na dalszy plan Procesy Esencją metodyki XP są cztery procesy regulujące wszelkie procedury i praktyki dyktowane lub proponowane przez tę metodykę. Postuluje się istnienie etapów planowania, projektowanie, implementację i testowanie. W następnych rozdziałach poświęcono sporo uwagi poszczególnym problemom z nimi związanym. Wstępną i pobieżną ich charakterystykę można przedstawić następująco: Planowanie Prowadzone jest w ramach iteracyjnego systemu tworzenia oprogramowania, z wyodrębnieniem wielu etapów jego rozwijania (zwanych fazami, przyrostami lub właśnie iteracjami). Planowanie ma na celu wyodrębnienie zadań do realizacji w danej iteracji (wskutek kolektywnie podejmowanych decyzji w zespole). Zadania muszą być uproszczone, czyli na tyle małe, aby w iteracji się zmieściły. Oszacowania czasowe zawsze ujmuje się z dołu, czyli zakładając, iż realizacja zadania potrwa na pewno nie krócej, niż założono w planie. Planując realizację projektu, zakłada się także, że projekt powinien być prowadzony tak, aby każdy z członków zespołu posiadał wiedzę o wszystkich jego elementach. Dotyczy to także implementacji, szczególnie zasad funkcjonowania poszczególnych komponentów tworzonego systemu. Tym samym członkowie zespołu pozyskują praktyczną wiedzę o elementach projektu także w zakresie rozwiązań i technologii, w których się nie specjalizują. Kolejnym problemem branym pod uwagę przy planowaniu jest ciągła ocena skuteczności stosowania metodyki XP. Gdy okazuje się, że określone reguły XP się nie sprawdzają, można z nich swobodnie rezygnować. Projektowanie Projekt funkcjonalności przyszłego systemu zakłada maksymalną prostotę jeśli w ogóle istnieje. W czasie realizacji poszczególnych iteracji nie dodaje się żadnej zbędnej 113

115 funkcjonalności. Dodatkową funkcjonalność dodawać będzie można w przyszłości dopiero wtedy, gdy zajdzie taka potrzeba. Także kod posiadający funkcjonalność nadmiarową, na skutek wycofania się klienta z wcześniej stawianych wymagań, winien być z niej oczyszczony. Implementacja Metodyka XP ingeruje także w kwestie tworzenia kodu implementowanego systemu. Definiuje wiele wytycznych, postulujących utrzymywanie ściśle określonej konwencji kodowania, ciągłe definiowanie testów tworzonego kodu (jeszcze przed jego utworzeniem), często prowadzoną integrację kodu, programowanie w parach, współdzielenie kodu przez wszystkich członków zespołu i wiele innych. Testowanie System testowania tworzonego kodu jest sztandarowym atrybutem programowania ekstremalnego, odróżniającym tę metodykę od innych. Nacisk jest postawiony na testowanie. Testy są definiowane nawet zanim powstanie kod, swoją treścią przybliżając zakres przyszłej funkcjonalności systemu. Kod jest umieszczany w ogólnodostępnym dla zespołu repozytorium dopiero po przejściu testów. Te same testy są prowadzone po zintegrowaniu kodu, jego rozszerzeniu funkcjonalnym czy refaktoryzacji. Testy są również środkiem zapobiegającym powtórkom już wykrytych i usuniętych błędów. Po usunięciu błędu tworzony jest test wykrywający występowanie objawów w zachowaniu wykonywanego kodu analogicznych do powodowanych wcześniej przez usunięty błąd. Od tego momentu będzie on uruchamiany rutynowo po dalszych modyfikacjach kodu. Ograniczenia, które nakłada swoimi postulatami metodyka programowania ekstremalnego, nie są, jak widać, duże. Redukcja ryzyka podejmowanego przy realizacji projektu z jej użyciem oraz możliwość produkowania kodu wysokiej jakości dają przy tym sporo korzyści. Programowanie ekstremalne wyróżnia czynności prowadzące do oszacowania ryzyka i oceny koniecznych nakładów czasowych. Przed rozpoczęciem iteracji jest analizowany tak zwany architectural spike, a w jego konsekwencji spike solution. Pod tym terminem występuje wstępna redukcja ryzyka projektowego, tworzona poprzez ogólne określenie rozwiązań technologicznych (środowisko, narzędzia) użytych przy wytwarzaniu systemu. Ważne ogniwo w komunikacji z klientem stanowi zunifikowany system opisu pojęć dotyczących wszelkich zagadnień związanych z procesem wytwarzania oprogramowania, występujący pod nazwą metafory systemu. Metafora systemu (system metaphor) to wstępna koncepcja architektury i zarys funkcjonalności systemu, powstałe po analizie architectural spike. Przy rozwijaniu opisów różnorodnych elementów metafory systemu konieczne jest opracowanie słownika używanych pojęć zrozumiałego zarówno dla klienta, jak i zespołu realizującego projekt. Zbieżność znaczenia tych pojęć jest kluczowa dla poprawnej interpretacji historii opisywanych przez klienta. Klient, niezaznajomiony z technologiami informatycznymi, nie będzie w stanie operować terminologią techniczną. Nie będzie także poprawnie interpretował znaczenia wielu zależności i procesów występujących w systemie. W ramach metafory systemu tworzone jest zatem coś w rodzaju zestawu filtrów konwertujących, które w górnej warstwie systemu dokonają zamiany informacji technicznej (zarówno danych, jak i tej służącej do specyfikowania wymagań) na postać zrozumiałą dla klienta. 114

116 Jednym z ważniejszych procesów realizowanych w ramach iteracyjnego trybu wytwarzania oprogramowania jest naturalnie planowanie samej iteracji. Konieczne jest tu oszacowanie pracochłonności dla każdej pojedynczej historii użytkownika (user story) [20], powstałej na podstawie opisów słownych przedstawionych przez klienta. Do szacowania używa się jednostek zwanych idealnymi osobotygodniami (jednostka określa tygodniowy czas pracy jednej osoby bez absorbowania uwagi czymkolwiek innym). Klient dostarcza zespołowi wiedzę o stawianych wymaganiach w formie powieści. Gdy klient określi, które historie są dla niego najważniejsze, można rozpoczynać pierwszą iterację. Iteracja kończy się osiągnięciem działającej wersji systemu (po zakończeniu kodowania), złączeniu i przetestowaniu nowo powstałej wersji systemu. Proces wytwarzania wersji można zobrazować schematycznie (rys. 5.1) w postaci tzw. mapy programowania ekstremalnego (the XP-map). User Architectural Spike Release Planning Test Acceptance Test Stand up Meeting Development Versio I T E R Bug A C J Unit Tests A Rys The XP-Map (stworzono na bazie [12]) User Approval Small Celem głównym czynności naniesionych na powyższą mapę jest doprowadzenie do wydania nowej wersji tworzonego systemu najczęściej wersji o powiększonej funkcjonalności. Wersja taka wymaga akceptacji klienta, a ponieważ jest jedynie tworem przejściowym nadano jej nazwę tzw. małego wydania (small release). Tym samym do osiągnięcia finalnej wersji systemu podąża się (w trybie iteracyjnym) małymi krokami, dokładając każdorazowo łatwy do przetestowania, niewielki, lecz kompletny pod względem funkcjonalnym, zakres cech. Wymaga to częstego łączenia kodu napisanego przez programistów oraz wprowadzenia sprawnego systemu testowania dodanej funkcjonalności. Niewielkie historie użytkownika ułatwiają ten proces. Przy takim podejściu zawsze istnieje sprawnie działająca wersja systemu, a klient nie musi długo czekać na kolejną. Na znaczne uproszczenie stopnia skomplikowania pojedynczych zadań ma wpływ jeszcze jeden czynnik. Jak wiadomo, metodyka XP zakłada operowanie w bardzo zmiennym i nieprzewidywalnym środowisku, w którym wymagania dla systemu w nim osadzonego ciągle mogą się zmieniać, dlatego nie ma sensu planowanie kompleksowych, rozbudowanych i uniwersalnych rozwiązań, o których nie wiadomo nawet, czy zostaną kiedykolwiek wykorzystane funkcjonalnie. Dostarczenie oprogramowania spełniającego aktualnie postawione 115

117 wymagania bez rozwijania wątków pobocznych znacznie upraszcza procedurę wytwarzania nowej wersji. Programista, realizując czynności związane z implementacją danej historii użytkownika, stara się jak najszybciej usatysfakcjonować klienta. Z każdą iteracją klient określa tak zwane testy akceptacyjne (acceptance tests), które powinny zostać zaliczone pomyślnie. Kwestia testowania funkcjonalności systemu zostanie przedstawiona w kolejnych podrozdziałach XP wytwarzanie kodu Jak wspomniano, kod dostarczający funkcjonalność przyszłego systemu jest wytwarzany kolektywnie przez wielu programistów. Współdzielenie kodu i jego ciągła reedycja, dokonywana przez różnych członków zespołu, wymaga wprowadzenia do metodyki XP licznych technik wspomagających zarządzanie tym kodem. W niniejszym podrozdziale najważniejsze z nich zostaną zaprezentowane Programowanie w parach Współtworzenie kodu jest osiągane w ramach praktyki zwanej programowaniem w parach (pair programming). Polega ona na rozwijaniu poszczególnych składowych funkcjonalnych systemu w podzespołach dwuosobowych. Jedna z osób rozwija kod, pracując w edytorze tekstu. Druga wspiera proces wytwarzania rozmaitymi materiałami i czynnościami od elementarnych rozwiązań technicznych (jak np. nazewnictwo metod angażowanych w kodzie), przez korekty składniowe, po rozwiązania konceptualne dotyczące kodowanych właśnie algorytmów. Programowanie w parach wymaga dobrego zgrania zespołu, lecz przynosi znaczny wzrost wydajności. Osoby w parach powinny się regularnie zamieniać rolami. Wskazane są częste roszady pomiędzy parami co wspomaga lepsze zorientowanie programistów w całości wspólnego kodu (collective code ownership). Intensywne propagowanie wiedzy o różnych fragmentach programu w całej grupie osób pracujących przy systemie przynosi wymierne korzyści w postaci lepiej funkcjonującego, szybciej wyprodukowanego i bardziej uporządkowanego kodu. Podstawą funkcjonowania w parze jest skłonność do dzielenia się wiedzą i spostrzeżeniami z inną osoba w parze. Skład par często się zmienia, więc wiedza posiadana pierwotnie tylko przez wyselekcjonowane osoby migruje do osób pozostałych Standaryzacja kodu źródłowego Uporządkowanie kodu źródłowego jest dodatkowo wymuszane wprowadzaniem ścisłych standardów kodowania (coding standards). Narzuca się wszystkim programistom wymóg zgodności tworzonego kodu źródłowego z uzgodnionym w zespole standardem kodowania i dokumentowania kodu. Sam standard nie jest szczegółowo specyfikowany metodologią, powinien być natomiast ustalony i zaakceptowany przez całą grupę. Specyfikacja standardu powinna być dokumentem krótkim, niezawierającym zbędnych szczegółów, lecz jednocześnie niepozostawiającym niedomówień w dziedzinie utrzymywanej konwencji nazewnictwa, formatowania bloków czy komentowania kodu. Preferowane jest wyrażanie znaczenia terminu 116

118 (lub obiektu) poprzez jego nazwę. Dotyczy to szczególnie klas przeznaczenie poszczególnych metod powinno być jasne, a ich działanie oczywiste. Informacja ta jest uzupełniana przez bloki komentarza, przy tworzeniu którego nacisk kładzie się właśnie na dokładny opis deklaracji klas. Posiadanie wspólnego i zrozumiałego dla wszystkich kodu źródłowego ujawnia swoje zalety w razie wystąpienia konieczności jego reedycji (wnoszenie poprawek po testach, rozwijanie funkcjonalności) Ciągła integracja Korekty kodu mogą wprowadzać dowolne osoby z zespołu programistów, co znacznie ułatwia zarządzanie zasobami ludzkimi w projekcie preferowana jest wspomniana wcześniej samoorganizacja. W celu zapewnienia spójności i poprawności wielokrotnie w ciągu dnia modyfikowanego kodu wymagana jest regularna konsolidacja i uruchamianie zestawu testów (continuous integration). Programista po wykonaniu każdego nowego fragmentu programu łączy go z systemem i kontroluje jego zachowanie. Czynności związane z konsolidacją i testowaniem są na tyle częste (postuluje się kilkukrotne w ciągu godziny konsolidowanie nowo utworzonego kodu z już istniejącym), iż do ich realizacji dedykuje się zwykle oddzielną maszynę i (często) także osobę przeprowadzającą łączenie oraz testy. Z oczywistych względów dąży się tutaj do pełnej automatyzacji wymienionych czynności. Przyjmuje się, że intensywność procesu ciągłej integracji powinna być tak silna, aby system mógł być budowany w całości ze swoich zmodyfikowanych właśnie źródeł przynajmniej raz dziennie. W celu uporządkowania tego procesu zakłada się, że tylko jedna para dokonuje integracji. Czynności integracyjne często automatyzuje się poprzez połączenie z wykonywaniem testów. Często prowadzona integracja wymaga precyzyjnego określenia interfejsów łączących poszczególne komponenty tworzonego systemu. Skutki niedoskonałości tych interfejsów są bardzo kosztowne czasowo, gdyż integracja zachodzi często. Niedoskonałości powinny być korygowane natychmiast po wychwyceniu Współwłasność kodu Zakłada się, że poszczególne elementy kodu źródłowego nie mają swoich konkretnych właścicieli. Kod jest własnością całego zespołu, a zespół posiada wiedzę na temat całego kodu. Rozproszenie wiedzy niweluje skutki ewentualnej utraty osoby z zespołu. Współwłasność tworzonego kodu upoważnia każdą z par do czynności integracyjnych i edycyjnych z zachowaniem kontroli wersji. Współwłasność kodu leży u podstaw kolejnego mechanizmu, zwanego mechanizmem komunikacji poprzez kod. Programiści analizują kod obcy, śledząc podejście innych osób do implementacji określonych komponentów i przejmując opracowane przez nie rozwiązania. Tym samym wiedza na temat technik programistycznych jednej osoby migruje do innych. Nie typuje się jawnie autora określonego fragmentu kodu, zakładając, iż indywidualni autorzy są anonimowi, a kod jest produktem całego zespołu Refaktoryzacja Projekt tworzony zgodnie z metodyką XP musi być ciągle otwarty na nowe funkcje. Jego kod jest także ciągle modyfikowany przez różne osoby. Konieczne są zatem zabiegi umożliwiające utrzymanie czytelnej struktury kodu. Proces porządkowania kodu źródłowego 117

119 nazywamy tu refaktoryzacją. Polega on przede wszystkim na usuwaniu redundancji w kodzie, porządkowaniu struktury klas i metod pokrywających zadaną funkcjonalność, porządkowaniu kodu przez adaptowanie go do wymogów przyjętej konwencji kodowania i komentowania tego kodu. Po przeprowadzeniu refaktoryzacji obowiązkową czynnością jest przeprowadzenie kompletu testów zrefaktoryzowanego systemu godzinny tydzień pracy Zespoły programistów, zorganizowane w dwójki, powinny być przyzwyczajone do stałej wydajności i stałego obciążenia. Ułatwia to planowanie iteracji, a tym samym zarządzanie procesem rozwijania systemu. Jedną z charakterystycznych cech programowania ekstremalnego jest definiowanie sztywnej marszruty czasowej dla programisty, będącej konkretną, nienaruszalną granicą obciążenia grupy. Zwyczajowo nazywamy ją 40-godzinnym tygodniem pracy (40-hour week). Nie jest ważne, ile godzin w tygodniu pracy programisty faktycznie zostało przyjęte jako owa norma. Ważne jest, aby norma po wyznaczeniu była utrzymywana ściśle i konsekwentnie. Jednokrotne jej naruszenie dezorganizuje pracę zespołu, ponowne stanowi już poważne zagrożenie dla powodzenia iteracji. W XP odrzucana jest także możliwość realizacji zadań w ramach nadgodzin Współpraca z klientem Iteracyjny tryb realizacji projektu wymaga, jak wiadomo, częstego kontaktu z klientem. W praktyce programowania ekstremalnego ta ciągłość oznacza praktycznie codzienny kontakt klienta z zespołem. W przypadku braku możliwości zapewnienia stałego i bezpośredniego kontaktu z klientem konieczne jest wprowadzanie rozwiązań zastępczych, polegających głównie na utrzymywaniu zdalnych form komunikacji z klientem. Praktyka pokazuje jednak, iż brak klienta mogącego poświęcić wystarczająco wiele czasu dla nowo powstającego systemu wpływa bardzo negatywnie na tempo prac i, co warte podkreślenia, morale zespołu. Rutynowa realizacja projektu wymaga organizowania spotkań codziennych zespołu, identyfikowanych pod nazwą Stand-up Meeting. To robocze spotkanie rozpoczyna dzień pracy. Ma głównie na celu: określenie postępu prac (każda para przedstawia tu raport), wykrycie trudnych (wymagających czasu) problemów, koordynację wysiłków w celu rozwiązania trudnych problemów. Przy okazji tych spotkań budzi się najwięcej wątpliwości, skutkujących koniecznością kierowania pytań do klienta. Utworzenie nowego wydania (tzw. single release) także w oczywisty sposób wymaga interakcji z klientem. Po wykonaniu testów (acceptance tests) jego aprobata jest sygnałem do zakwalifikowania danej funkcjonalności jako dostarczonej i przejścia do kolejnej iteracji prac nad rozwijanym systemem. Częste prezentacje kolejnych wersji oprogramowania przed klientem mają dwie podstawowe zalety. Pierwsza to wymuszone takimi prezentacjami ciągłe integrowanie systemu, redukujące ryzyko zaistnienia kosztownych w skutkach błędów związanych z niekompatybilnością komponentów oraz dające zespołowi poczucie ciągłej kontroli nad postępem prac 118

120 w projekcie. Druga to częsta walidacja biznesowa powstającej funkcjonalności, dokonywana przez klienta. Na podstawie wniosków z oględzin prezentowanej wersji i wiedzy zdobytej pomiędzy wydaniami podejmuje on decyzje o kierunku dalszych prac Zarządzanie ryzykiem w projektach XP Ryzyko związane z realizacją systemów informatycznych ma różnorodne źródła. Metodyka XP posiada wiele zalet mogących skutecznie to ryzyko redukować. Niżej zostały opisane typowe zjawiska stanowiące zagrożenie; skomentowano także techniki redukcji skutków tych zjawisk oraz opisano cechy metodyki XP powodujące ich samoczynne zanikanie: Opóźnienia w realizacji Opóźnienie realizacji komponentów systemu jest problemem szczególnie kłopotliwym przy wykonywaniu zadań dużych, odgórnie szacowanych czasowo. W XP zakłada się krótkie cykle realizacji wersji oprogramowania. Nowa wersja oprogramowania często trafia do klienta, podlegając jego ocenie. Rozmowy na temat terminów realizacji zadań następnych są zatem dużo łatwiejsze. Wcześniej przeprowadzone cykle dostarczają ponadto wiedzy na temat przebiegu realizacji komponentów podobnych, co pomaga przy tworzeniu oszacowań czasowych. Dodatkowo nowy cykl będzie krótkoterminowy, co siłą rzeczy zmniejsza zakres możliwego do popełnienia błędu przy szacowaniu nakładów czasowych na realizację komponentu do oprogramowania w cyklu. Anulowanie projektu Różne przesłanki mogą prowadzić do anulowania realizacji projektu, zanim oprogramowanie osiągnie postać gotowego produktu. Metodyka XP wymaga od klienta, aby typował jak najmniejsze wydania, posiadające wartość biznesową. Tym samym wystąpi mniej problemów związanych z realizacją wersji nieprodukcyjnych oprogramowania i ryzyko anulowania jest dużo mniejsze. Jeśli anulowanie mimo wszystko nastąpi (z niezależnych od przebiegu realizacji powodów), to nakłady pracy, które mogą zostać zmarnowane (funkcjonalność wykonana niepotrzebnie), są znacznie mniejsze. Problem rozszerzalności wersji Gdy system zostanie wyprodukowany i pomyślnie wdrożony, może się okazać, iż z powodu chaotycznego zakodowania jego funkcjonalności dalsza rozbudowa systemu będzie niemożliwa lub bardzo kosztowna. Wówczas po kilku latach eksploatacji system z powodów biznesowych może wymagać wymiany. Metodologia XP wprowadza ścisłe procedury kontroli jakości oprogramowania poprzez wykorzystanie testów jednostkowych. Ważne jest, iż jednostki te prowadzą kompleksową kontrolę systemu weryfikując także, czy implementacja funkcji niebędących przedmiotem bieżącej iteracji nie uległa przypadkowemu uszkodzeniu w konsekwencji wprowadzanych zmian. Umożliwia uwzględnianie w testach zależności funkcjonalnych pomiędzy różnymi komponentami systemu. Rozbudowa systemu jest ułatwiona. Jakość kodu Niska jakość samego oprogramowania to ogólnie znany problem. Testowanie powstającego produktu jest oczywistą domeną każdej metodyki wytwarzania oprogramowania. 119

121 W przypadku XP nacisk na testowanie jest niezmiernie silny. Po pierwsze testy definiowane są przez zespół, który realizuje je z procedury na procedurę. Innymi słowy każda nowa procedura dodawana do systemu jest utożsamiana z serią testów, które weryfikując jej funkcjonowanie, są uruchamiane po każdej modyfikacji. Po drugie testy dookreśla sam użytkownik (klient), tym razem w trybie z cechy na cechę funkcjonalną systemu. Ten rodzaj testu polega na każdorazowym sprawdzaniu poprawności funkcjonowania dodanej właśnie nowej cechy systemu przez interpretowanie jej z punktu widzenia użytkownika. Zagadnienia związane z metodyką testowania oprogramowania w XP zostają poruszone w następnych podrozdziałach. Nieporozumienia biznesowe Oczywiste jest, iż powstająca specyfikacja wymagań systemu informatycznego musi mieć swoje źródła w materiale przekazywanym przez klienta. Taki materiał, mając często werbalny i nieformalny kształt, jest potencjalnym nośnikiem nieporozumień. W przypadku metodologii XP klient traktowany jest jako integralna część zespołu. W związku z tym nie istnieje specyfikacja, która określa kompletne wymagania dla systemu przed rozpoczęciem realizacji. Wszelka informacja dotycząca wymagań może być także przekazana przez klienta bezpośrednio przed implementacją. Specyfikacja jest ciągle ulepszana także na podstawie wiedzy pozyskanej przez klienta dopiero w trakcie implementacji (na przykład wiedzy pochodzącej z oględzin wypuszczonej właśnie wersji). Zmiany biznesowe W trakcie realizacji mogą także ulegać zmianom wymagania biznesowe, na podstawie których utworzono specyfikację wymagań. Długi okres realizacji w naturalny sposób potęguje takie zagrożenie. W przypadku XP po raz kolejny krótki cykl realizacji redukuje skutki tego zjawiska. W trakcie prac klient przedstawia kontroluje i modyfikuje listy prac zrealizowanych i prac jeszcze koniecznych do zrealizowania. Osoby realizujące zadania nie będą musiały nawet wiedzieć, czy wykonują w cyklu zadanie zdefiniowane przed chwilą, czy rok temu. Niska wartość biznesowa produktu Powyższy problem pojawia się, gdy powstał system, który posiada wiele zaawansowanych i interesujących funkcji, lecz nie przedstawiają one wielkiej wartości dla konkretnego klienta (zrealizowano coś, co jest klientowi niepotrzebne). W przypadku XP zjawisko jest redukowane przez przestrzeganie postulatu, mówiącego o przenoszeniu do realizacji wyłącznie zadań najwyższego priorytetu. O priorytetach decyduje klient. Rotacje kadrowe Przy długotrwałych i przeciągających się realizacjach może dojść do znużenia członków zespołu wykonywaniem ciągle tego samego monotonnie przebiegającego zadania. Odchodzą oni wówczas często z zespołu. W XP estymaty czasowe podejmowanych zadań i możliwość realizowania zadań różnorodnych podnoszą atrakcyjność wykonywanej pracy. Ponadto XP wzmacnia współpracę w zespole, redukując ewentualne skutki samotnej realizacji długich, odseparowanych i rozbudowanych komponentów. Widać, iż metodyka XP formułuje sensowne odpowiedzi na większość problemów związanych z ryzykiem podejmowanym przy realizacji projektów informatycznych. Iteracyjny 120

122 tryb realizowania projektu i łatwość adaptacji do wszelkich zmian to główne jej atuty. Jest typową metodyką zwinną, przeznaczoną do stosowania w sytuacjach, gdy stawiane wymagania funkcjonalne są nieprecyzyjne, a ryzyko wprowadzenia w nich zmian duże Podsumowanie Programowanie ekstremalne (XP) jest niewątpliwie zbiorem bardzo ciekawych rozwiązań metodycznych. XP to nie tylko zbiór wytycznych wspomagających zarządzanie projektami informatycznymi. XP należy interpretować szerzej jako metodykę zwinną planowania i realizowania projektów informatycznych. Realizacja projektów w XP wymaga od programistów wyrobienia u siebie pewnych niestandardowych nawyków, związanych głównie ze specyficznym trybem współpracy pomiędzy członkami zespołu. Pośród wytycznych metodyki pojawiają się elementy kontrowersyjne. Pierwszy z nich to samoprogramowanie w parach, gdzie jedno zadanie wykonywane jest przez dwie osoby. Teoretycznie może to oznaczać marnotrawienie zasobów, lecz w praktyce daje się zaobserwować wzrost prędkości realizowania takich zadań nawet o 80% [7]. Słabo mierzalny wzrost jakości wytworzonego produktu oraz zysk płynący z wymiany wiedzy i doświadczeń podczas pracy także trzeba wziąć pod uwagę. Innym kontrowersyjnym elementem jest niemal całkowity brak dokumentacji projektu. Wszelkie dane o projekcie, utrzymywane jedynie przez programistów, mogą być potrzebne na etapie wdrożenia systemu. Fakt ten trzeba wziąć pod uwagę. Z drugiej strony główne zalety XP to szybka adaptacja programistów niewyspecjalizowanych do realizacji określonych zadań, silna migracja wiedzy w zespole czy szybkość reakcji na zmiany wymagań funkcjonalnych. Dochodzi tu także możliwość silnego zredukowania ryzyka w projekcie i osiągania produktów dobrze przetestowanych, więc wysokiej jakości. W przypadku małych projektów, gdzie klient osobiście ingeruje w wymagania i regularnie żąda wyniku prac, metodykę XP na pewno warto wypróbować. Literatura [1] Jeffries R.: Programowanie ekstremalne w C#, APM PROMISE, 2006 [2] Shore J., Warden S.: Agile Development. Filozofia programowania zwinnego, Helion, Gliwice 2008 [3] Diaz T.A.: Extreme Programming Pocket Guide, O Reilly Media, 2003 [4] Fowler M., Beck K., Brant J., Opdyke W.: Refactoring: Improving the Design of Existing Code, Addison-Wesley 1999 [5] Beck K.: Implementation Patterns, Addison-Wesley, 2007 [6] Beck K., Andres C.: Extreme Programming Explained: Embrace Change, Addison-Wesley, Boston 2005 [7] Jeffries R., Anderson A., Hendrickson C.: Extreme Programming Installed, Addison-Wesley, Boston 2001 [8] IEEE Recommended Practice for Software Requirements Specifi cations, IEEE Computer Society, New York

123 [9] Williams L., Kessler R.: Pair Programming Illuminated, Pearson Education, Boston 2003 [10] Beck K.: Test Driven Development: By Example, Pearson Education, Boston 2003 [11] Duvall P.: Continuous Integration: Improving Software Quality and Reducing Risk, Addison- -Wesley, 2007 [12] [13] [14]

124 6. Zarządzanie jakością oprogramowania: wprowadzenie do testowania * 6.1. Podstawy testowania Wstęp Obecnie systemy informatyczne otaczają nas ze wszystkich stron. Znajdują się w miejscach gdzie jeszcze kilka lat temu trudno było to sobie wyobrazić, począwszy od rozwiązań dla biznesu aż do urządzeń konsumenckich. Większość użytkowników zetknęła się z systemami, które nie działały tak jak powinny. Wadliwie działające oprogramowanie może wywołać wiele problemów stratę pieniędzy, czasu, reputacji, a nawet zdrowia. Rodzaj i skala problemu jest uzależniona od tego, gdzie niepoprawnie działający system się znajduje oraz jakiego typu ma usterkę. Głównymi źródłami usterek jest błąd człowieka. Może on zostać popełniony na różnych poziomach i etapach projektowania systemu: na poziomie kodu źródłowego, dokumentacji, specyfikacji itp. Efektem jest defekt (usterka, pluskwa), który w momencie wywołania może powodować awarię. Człowiek popełnia błędy z różnych przyczyn, w szczególności mogą nimi być działanie pod presją czasu, stres, zmęczenie, a także duży poziom skomplikowania kodu, infrastruktury, zmieniających się technologii oraz wielu interakcji wewnątrz systemu. Innymi źródłami awarii mogą być także czynniki środowiska zewnętrznego: promieniowanie, magnetyzm, pole elektryczne. Wszystko to może powodować awarię oprogramowania poprzez zmianę warunków działania systemu. Niniejszy rozdział opisuje wybrane istotne zagadnienia związane z testowaniem. Z racji tego, że ma on pomagać czytelnikowi w przygotowaniu do egzaminu ISTQB Certyfikowany tester, powstał on głównie na podstawie opracowania [3]. W wybranych miejscach wskazano reprezentatywne pytania za [4]. Definicje niektórych pojęć pochodzą ze słownika [5]. Zagadnienia prezentowane w rozdziale są podstawą do zarządzania jakością w procesie wytwarzania oprogramowania [1, 2]. Testowanie systemu ma za zadanie zredukowanie prawdopodobieństwa wystąpienia awarii w środowisku produkcyjnym i przyczynienie się do zwiększenia jakości i zaufania do systemu. Ważne jest, aby wszystkie znalezione defekty zostały poprawione przed dopuszczeniem systemu do działania w środowisku produkcyjnym, co często może być wymagane w zapisach kontraktowych, prawnych lub * Rozdział zredagowano głównie na podstawie syllabusa Stowarzyszenia Jakości Systemów Informatycznych, Certyfi kowany tester. Plan poziomu podstawowego. Wersja 1.0,

125 definiowane przez standardy przemysłowe. Za pomocą testowania można zmierzyć jakość oprogramowania, którą rozumie się jako ilość znalezionych błędów w stosunku do liczby wymagań funkcjonalnych i niefunkcjonalnych oraz cech systemu (niezawodność, wydajność, użyteczność, utrzymywalność) [6]. Testowanie oprogramowania można zintegrować z innymi etapami, metodami wytwarzania oprogramowania (kodowanie, analiza błędów, szkolenia), a także z fazą końcową, w której podsumowując przeprowadzone testy, wyciąga się wnioski i doskonali proces wytwarzania, w taki sposób, aby zminimalizować ponowne wystąpienie wykrytych defektów w przyszłych projektach. Ważne jest, aby określić czas trwania testowania, który może zależeć od wielu czynników, w tym od poziomu ryzyka (biznesowego, technicznego, projektowego) wystąpienia awarii systemu, dostępnego przedziału czasu przeznaczonego na przeprowadzenie testowania czy od dostępnych zasobów finansowych. W każdym jednak wypadku testowanie winno być tak przeprowadzone, aby dostarczyć interesantom wystarczającej ilości informacji potrzebnej do przekazania systemu do dalszej fazy produkcji bądź do przekazania go klientowi. Testowanie opiera się na pewnych podstawowych zasadach opisanych w kolejnych podrozdziałach Zasady testowania Od wielu lat powstają ogólne zasady, które należy brać pod uwagę w przypadku testowania dowolnego rodzaju systemu; poniżej przedstawiono wybrane z nich za [3]: Testowanie ujawnia błędy testowanie może pokazać że w oprogramowaniu znajdują się usterki, jednak testując nie jesteśmy w stanie dowieść że ich tam nie ma. Pomyślne przeprowadzenie testów nie daje gwarancji niezawodności oprogramowania. Testowanie gruntowne nie jest możliwe przetestowanie wszystkich kombinacji wejść i wyjść jest możliwe tylko w przypadku bardzo prostych systemów. W przypadkach bardziej skomplikowanych należy się skupić na informacjach o ryzyku i priorytetach. Wczesne testowanie przeprowadzanie testów powinno się rozpocząć na jak najwcześniejszym etapie cyklu wytwarzania oprogramowania. Kumulowanie się błędów większość defektów znalezionych przed wypuszczeniem oprogramowania znajduje się w stosunkowo małej liczbie modułów. Paradoks pestycydów przeprowadzanie ciągle tych samych testów powoduje, że nie są znajdowane żadne nowe błędy. Aby przezwyciężyć ten paradoks, należy regularnie przeglądać, korygować, a także tworzyć nowe przypadki testowe. Pozwoli to potencjalnie na sprawdzenie większej części systemu oraz wykrycie nowych defektów. Testowanie jest zależne od kontekstu testowanie jest wykonywane w różny sposób w zależności od rodzaju systemu (systemy bezpieczeństwa, systemy typu e-commerce). Mylne przekonanie o bezbłędności znalezienie i usunięcie błędów nie pomaga, jeżeli system nie nadaje się do użytku i nie spełnia potrzeb oraz oczekiwań użytkownika. Zasady te wpływają na przedstawiony poniżej proces testowy oprogramowania. 124

126 Proces testowy Głównym etapem procesu testowania jest etap, w którym przeprowadzane są testy. Jednak aby ten etap dawał możliwie najlepsze wyniki, należy dodatkowo wykonać wiele zadań. Według ISTQB podstawowy proces testowy składa się z następujących etapów (za [3]): planowanie i nadzór testów, analiza i projektowanie, implementacja i wykonanie, ocena stopnia spełnienia warunków zakończenia testów i raportowanie wyników, czynności zmykające test. Powyższe czynności mogą być wykonywane jedna po drugiej, jednak równie dobrze mogą zachodzić na siebie lub nawet być wykonywane jednocześnie. Planowanie testów definiuje cele testowania oraz sposób ich osiągnięcia, podczas gdy nadzór nad testami to powtarzająca się czynność porównywania rzeczywistego postępu prac z planem i raportowanie wraz z informacją o odchyleniach od założeń. Informacje te powinny być wykorzystywane podczas planowania kolejnych testów. Głównym zadaniem w planowaniu jest między innymi ocena zakresu ryzyka oraz identyfikacja celów testowania. Kolejnym jest ocena metodyki testowania i wymaganych zasobów. Planowanie służy też do wdrożenia polityki testów i harmonogramowania ich wykonania oraz oceny, a także do określania kryteriów zakończenia. Natomiast nadzór nad testami obejmuje analizę rezultatów, monitorowanie i dokumentowanie postępu prac, pokrycia testowego i kryteriów zakończenia oraz rozpoczęcie prac naprawczych. Analiza i projektowanie stanowią bardzo ważny krok w całym procesie testowym. W ramach tych czynności ogólne cele zostają przekształcone w konkretne warunki testowe i projekty testów. Krok ten wymaga przeglądania podstawy testów (wymagania, architektura, projekt, interfejsy), a następnie identyfikacji warunków testowych lub wymagań testowych oraz potrzebnych danych testowych na podstawie analizy przedmiotów testu, specyfikacji, zachowania i struktury, zaś w końcu projektowania testów i oceny testowalności wymagań i systemu. Projektowaniu podlega też środowisko testowe, co wymaga określenia infrastruktury oraz narzędzi. Po kroku analizy i projektowania testów można przejść do fazy implementacji i wykonywania testów. Tutaj warunki testowe są przekształcane w przypadki testowe, testalia (ang. testware) oraz tworzone jest środowisko testowe. Ważnymi elementami tego etapu jest wytwarzanie i określanie priorytetów przypadków testowych oraz utworzenie scenariusza testowania, który ma na celu zwiększenie efektywności wykonywania testu. Wykonanie przypadków testowych (ręcznie lub za pomocą narzędzi) może odbyć się po weryfikacji poprawności utworzonego środowiska testowego. Podczas wykonywania przypadków testowych należy logować wszystkie wyniki wykonywania testów, aby móc je następnie porównać z rzeczywistymi oczekiwaniami. Wszystkie rozbieżności powinny być raportowane w celu dalszej analizy, która ma na celu określenie przyczyny rozbieżności (defektu). Wszystkie czynności testowe powinny zostać powtórzone w celu potwierdzenia usunięcia znalezionego defektu i sprawdzenia, czy naprawa nie spowodowała innych usterek (testowanie regresywne poszukiwanie niezamierzonych zmian). O tym, kiedy można zakończyć testy, decyduje procedura oceny kryteriów zakończenia. W trakcie tej procedury sprawdzany jest dziennik testów w odniesieniu do warunków zakończenia określonych podczas planowania. Na tej podstawie można określić, czy wymagana 125

127 jest większa liczba testów lub też zmiana warunków testowania. W momencie kiedy zostanie podjęta decyzja o zakończeniu procedury testowania, powinien powstać raport końcowy z testowania przeznaczony dla interesariuszy. Finalne zamknięcie procesu testowania powinno obejmować zebranie danych z zakończonych czynności testowych, w celu gromadzenia doświadczenia na potrzeby przyszłych projektów i środowisk testowych Psychologia testowania Nie wymaga komentarza fakt, iż cele podczas fazy testowania i przeglądania są znacznie inne niż te podczas fazy analizowania i wytwarzania; toteż testowanie swojego kodu przez programistę wymaga od niego odpowiedniego nastawienia. Zwykle rozdzielenie odpowiedzialności pomiędzy twórcami kodu a testerami ma na celu zwiększenie nacisku na testy i dostarczenie dodatkowych korzyści takich jak niezależne spojrzenie wyszkolonego i profesjonalnego zespołu testowego. Pewien stopień niezależności (dzięki któremu unika się autorskiego spojrzenia na produkt) pozwala zwykle na większą skuteczność w znajdowaniu defektów i awarii. Z drugiej jednak strony pewne typy defektów są skuteczniej odnajdywane przez autorów. Szukanie awarii podczas testowania może być postrzegane jako krytyka pod adresem produktu lub jego autora. Powoduje to, że testowanie jest często traktowane jako czynność destrukcyjna. Jednak przeprowadzone prawidłowo staje się niezmiernie konstruktywnym elementem w aspekcie zarządzania ryzykiem całego projektu. Wyszukiwanie awarii w systemie wymaga ciekawości, profesjonalnego pesymizmu, krytycznego spojrzenia, przywiązywania wagi do szczegółów i dobrej komunikacji z programistami. Aby uniknąć spięć pomiędzy testerami i programistami, komunikaty o znalezionych defektach powinny być przekazywane w konstruktywny sposób. Z tego powodu testerzy i kierownik potrzebują dobrych umiejętności interpersonalnych. Przynosi to wtedy korzyści obu stronom. Dla autorów oprogramowania lub dokumentu informacja o awarii może okazać się pomocna w doskonaleniu umiejętności, a wnioski wyciągnięte z popełnionego błędu mogą zaoszczędzić czas i środki w przyszłości, a przede wszystkim zmniejszają ryzyko projektów. Problemy w komunikacji mogą się pojawić wtedy, gdy testerzy będą postrzegani jako osoby przekazujące informację wyłącznie o awariach. Istnieje kilka sposobów, aby zachować dobrą komunikację i relację pomiędzy testerami a pracownikami. Należy raczej współpracować niż walczyć wspólnym celem jest podniesienie jakości produktów. Warto informować o nieprawidłowościach w neutralny sposób, zorientowany na fakty, bez krytykowania osoby. Należy próbować zrozumieć, co czuje druga osoba i dlaczego reaguje w określony sposób oraz upewnić się, że przekazana informacja została poprawnie zrozumiana. Do omawianej w tym punkcie grupy zagadnień odnoszą się między innymi pytania 24, 26, 32 z zestawu [4]. Pytanie 26 brzmi: Która czynność w podstawowym procesie testowania zawiera szacowanie testowalności wymagań i systemu? A. Analiza i projektowanie testów. B. Implementacja i wykonanie testów. C. Zamknięcie testów. D. Planowanie i kontrola testów. W tym przypadku poprawna odpowiedź to A. 126

128 6.2. Testowanie w procesie wytwarzanie oprogramowania Proces wytwarzania oprogramowania jest ściśle związany z procesem testowania. W zależności od modelu wytwarzania oprogramowania planuje się i wykonuje różne warianty procesu. Z punktu widzenia testowania optymalny dla integracji procesu jest tak zwany model V pokazany na rysunku 6.1. Istnieją rozmaite warianty modelu V, jednak do każdego wykorzystuje się podejście wprowadzające cztery poziomy testów, do których zalicza się testowanie modułowe (jednostkowe, unit testing), integracyjne, systemowe i akceptacyjne. W rzeczywistości model V może mieć różne definicje poziomów wytwarzania i testowania oprogramowania, w zależności od projektu lub rodzaju produktu. Na przykład po testowaniu modułowym może występować testowanie integracyjne modułów lub po testowaniu systemowym testowanie integracyjne systemów. Rysunek przedstawia przykładowe zależności modelu V. Rys Model V wytwarzania oprogramowania (za 127

129 Powstające w procesie wytwarzania oprogramowania produkty stanowią podstawę na jednym lub kilku poziomach testów. Produkty te definiowane są m.in. w modelu CMMI (Capability Maturity Model Integration) oraz w normie IEEE/IEC (Software Life Cycle Process). Tak zwane iteracyjne modele wytwarzania odgrywają istotną rolę w rozwoju oprogramowania. W wytwarzaniu iteracyjnym cały proces dzieli się na kilka mniejszych podprocesów, w których każdorazowo odbywa się: określenie wymagań, projektowanie, programowanie i testowanie. W trakcie trwania każdego podprocesu tworzona jest kolejna część systemu, która może być przetestowana na kilku poziomach. Następnie przetestowana (nowa) część systemu jest scalana z resztą systemu, tworząc w ten sposób nowy (większy) system, który także powinien zostać poddany testowaniu. W każdej kolejnej iteracji na znaczeniu zyskują testy regresywne. Właściwy cykl życia systemu ma cechy charakterystyczne dobrego testowania. Każdej czynności wytwarzania systemu odpowiada jej właściwa czynność testowa. Każdy poziom testów ma specyficzne dla siebie cele. Analiza i projektowanie testów w przypadku danego poziomu powinny rozpoczynać się już podczas odpowiadającej jej fazy wytwarzania. Testerzy powinni uczestniczyć w przeglądach wczesnych wersji dokumentacji tworzonej podczas wytwarzania. Do omawianej w tym punkcie grupy zagadnień odnosi się między innymi pytanie 7 w [4], które brzmi: Które z poniższych zdań charakteryzuje dobre podejście do testowania w całym cyklu życia oprogramowania? A. Analiza i tworzenie testów rozpoczyna się tuż po zakończeniu prac wytwórczych. B. Niektóre, ale nie wszystkie, czynności związane z przygotowaniem aplikacji są wspierane odpowiednimi testami. C. Każdy poziom testów ma specyficzne dla siebie cele. D. Wszystkie przeglądy dokumentów angażują cały zespół programistów. W tym przypadku poprawna odpowiedź to C Poziomy testów Dla każdego poziomu testów w cyklu życia można określić następujące parametry: ogólne cele, produkty procesu wytwarzania, z których wywodzą się przypadki testowe (podstawa testów), przedmiot testowania, znajdowane typowe defekty i awarie, metodologie testowania oraz odpowiedzialności [3]. Celem testów modułowych jest poszukiwanie defektów w takich elementach oprogramowania jak np. moduły, programy, obiekty, klasy itd. Testowana może być zarówno funkcjonalność modułu, jak też i jego właściwości niefunkcjonalne, np. wykorzystanie zasobów (czy nie powoduje wycieków pamięci itp.). Ponadto można także wykonać testy odporności modułu oraz testowanie strukturalne w celu osiągnięcia pokrycia rozgałęzień. Przypadki testowe projektuje się na podstawie specyfikacji modułów, specyfikacji projektu oprogramowania lub modelu danych. Zwykle aby móc przeprowadzić testowanie modułowe, niezbędny jest dostęp do kodu źródłowego, środowiska deweloperskiego, oprogramowania 128

130 wspomagającego testowanie lub też debuggera. Zazwyczaj w testach uczestniczy sam autor, a odnalezione defekty są naprawiane bez ich formalnego zgłaszania. Testowanie integracyjne polega na sprawdzeniu interfejsów pomiędzy różnymi modułami systemu (system operacyjny, pliki, sprzęt) oraz interfejsów do innych systemów. Od razu można zauważyć, że testy integracyjne mogą być wykonywane na różnych poziomach, etapach powstawania systemu, a ich przedmiotem mogą być części o bardzo zróżnicowanym rozmiarze, np. testy integracyjne modułów mogą być przeprowadzane tuż po testowaniu modułowym, natomiast testy integracyjne systemów po testowaniu systemowym. Im większy jest zakres integracji, tym trudniejsze może być określenie, który moduł lub system jest przyczyną wykrytej awarii to powoduje zwiększone ryzyko. Aby ograniczyć ryzyko spowodowane zbyt późnym pojawieniem się awarii, zaleca się raczej integrację przyrostową niż skokową. Niezależnie od poziomu integracji, testowanie integracyjne powinno dotyczyć samej integracji (a nie np. funkcjonalności). Testowanie systemowe dotyczy testowania całego programu, systemu, produktu, zgodnie z zakresem projektu. Bardzo ważne jest, aby środowisko służące do testowania było jak najbliższe środowisku produkcyjnemu, w którym produkt ma znaleźć zastosowanie. Pozwoli to na zminimalizowanie pojawienia się awarii zależnych od specyfiki środowiska produkcyjnego. Przypadki testowe wykorzystywane w testowaniu systemowym można projektować na podstawie: oceny ryzyka, specyfikacji wymagań, procesu biznesowego, przypadków użycia oraz interakcji systemu z systemem operacyjnym i jego zasobami. Testowanie systemowe powinno brać pod uwagę zarówno wymaganie funkcjonalne, jak i niefunkcjonalne. Projektowanie funkcjonalne należy rozpocząć od projektowania przypadków testowych za pomocą najstosowniejszej dla danego systemu techniki czarnoskrzynkowej (na podstawie specyfikacji). Można także stosować techniki testowania strukturalnego (białoskrzynkowe), aby ocenić staranność testowania w odniesieniu do pokrycia wybranych elementów, np. struktury menu, nawigacji pomiędzy stronami www. Celem testowania akceptacyjnego jest osiągnięcie zaufania do systemu, jego części lub określonych wymagań niefunkcjonalnych. Testy akceptacyjne mogą służyć do oceny gotowości systemu do wdrożenia lub użytkowania, choć niekoniecznie są ostatnią fazą testowania. Odpowiedzialność za ten poziom testowania spoczywa najczęściej na klientach lub użytkownikach, chociaż mogą mieć w niej udział także inni interesariusze. Najczęściej spotyka się następujące formy testów akceptacyjnych [3]: Testowanie akceptacyjne przez użytkownika celem jest weryfikacja dostosowania do użycia dokonywana przez użytkowników biznesowych. Operacyjne testy akceptacyjne akceptacja systemu przez osoby administrujące. Testy akceptacyjne zgodności z umową (odbiorcze) wykonuje się na podstawie określonych w kontrakcie kryteriów odbioru. Testy zgodności legislacyjnej wykonuje się na podstawie zgodności z obowiązującymi przepisami prawnymi, branżowymi itp. Testy alfa i beta wykonywane są przez potencjalnych odbiorców z odpowiedniego sektora rynkowego jeszcze przed wypuszczeniem produktu do sprzedaży. Różnica pomiędzy tymi testami polega na tym, że testy alfa są przeprowadzane w siedzibie producenta, natomiast testy beta w środowisku produkcyjnym. 129

131 Typy i cele testów Wszystkie rodzaje testów można podzielić według tego, jakie są powody lub przyczyny wykonywania danej grupy testów. Cechą wspólną wszystkich testów należących do jednej kategorii jest określony, wspólny cel, np. przetestowanie danej funkcjonalności, przetestowanie właściwości (niezawodność, użyteczność itp.), nabranie zaufania do oprogramowania. Testy funkcjonalne wykonuje się zwykle na wszystkich poziomach testów. Funkcje określają, co robi system. Funkcje danego systemu, podsystemu, modułu, programu są zwykle opisywane w formie przypadków użycia lub w formie specyfikacji funkcjonalnej. Warunki i przypadki testowe projektuje się na podstawie dostępnej specyfikacji oprogramowania, modułu (tzw. testowanie czarnoskrzynkowe). Testowanie niefunkcjonalne (właściwości) określa, jak działa system. Testowanie tego typu odwołuje się do modelu jakości takiego jak np. ISO 9126 Software Engineering Software Product Quality. W skład testów niefunkcjonalnych wchodzi między innymi testowanie wydajności, obciążeniowe, przeciążające, użyteczności, współdziałania, utrzymywalności, niezawodności oraz przenaszalności. Podobnie jak testowanie funkcjonalne testowanie niefunkcjonalne może zostać przeprowadzone na wszystkich poziomach testów. Testy niefunkcjonalne są niezbędne do wyznaczenia charakterystyk systemu, które dają się skwantyfikować na skali, np. czas odpowiedzi. Testowanie strukturalne przeprowadza się także na wszystkich poziomach testów i służy ono do testowania struktury bądź też architektury danego systemu. Zazwyczaj stosuje się je dopiero po testowaniu opartym na specyfikacji (czarnoskrzynkowym), aby zmierzyć staranność testowania poprzez ocenę pokrycia wybranego rodzaju struktur (np. w przypadku testowania na poziomie modułowym lub testowania integracyjnego modułów stosuje się pomiar pokrycia takich elementów jak instrukcje lub decyzje). Jeżeli pokrycie nie jest pełne, wtedy można zaprojektować dodatkowe przypadki testowe. W testowaniu związanym ze zmianami można wyróżnić dwie podkategorie. Są nimi testowanie potwierdzające i regresywne. Obie podkategorie dotyczą testowania oprogramowania po naprawieniu defektu odnalezionego w innej fazie testowania. Za pomocą testowania potwierdzającego weryfikowana (potwierdzana) jest poprawność naprawy wykrytego defektu, tzn. sprawdzane jest, czy dany defekt już nie występuje. Nieco inną semantykę ma testowanie regresywne, za pomocą którego sprawdzane jest, czy po wprowadzeniu modyfikacji służących naprawie danego defektu nie pojawiły się defekty w innych miejscach systemu. Nowe defekty mogą występować albo w testowanym oprogramowaniu, albo też w innym mającym lub nie związek z przedmiotem testów module oprogramowania. Zakres testów regresywnych powinien być warunkowany wielkością ryzyka znalezienia usterki w oprogramowaniu, które wcześniej działało poprawnie. Testowanie regresywne można przeprowadzać na wszystkich poziomach testów. W skład testów regresywnych mogą wchodzić wszelkie typy testów (funkcjonalne, właściwości, strukturalne). Ważnym wymogiem w przypadku tych dwóch rodzajów testów jest, aby były one powtarzalne, gdyż powinny być wykonywane po każdej zmianie oprogramowania. Do omawianej w tym punkcie grupy zagadnień odnoszą się między innymi pytania 17, 21 i 35 z zestawu [4]. Pytanie 17 brzmi: Które z następujących wymagań mogą być testowane poprzez funkcjonalne testy systemu? 130

132 A. System musi uwzględniać nowych klientów na rok. B. System musi pozwolić użytkownikowi na zmianę adresu klienta. C. System musi działać sprawnie, obsługując do 30 użytkowników. D. System musi wykonywać swoje funkcje średnio przez 23 godziny i 10 minut na dobę. W tym przypadku poprawna odpowiedź to B. Pytanie 35 brzmi: Które z poniższych twierdzeń na temat testowania regresywnego jest fałszywe? A. Testowanie regresywne powinno być wykonywane po każdej zmianie w aplikacji. B. Należy dokonywać przeglądów testów regresywnych, w celu zapewnienia ich zgodności z wymaganiami biznesowymi. C. Zautomatyzowane testowanie regresywne jest zawsze bardziej efektywne od manualnego. D. Testy regresywne mogą być uruchamiane wiele razy. W tym przypadku poprawna odpowiedź to C Testowanie w fazie utrzymania Po wdrożeniu wiele systemów jest używanych przez długi okres. Zazwyczaj przez ten czas środowisko produkcyjne poddawane jest wielu naprawom, modyfikacjom, a także niejednokrotnie jest rozbudowywane lub wymieniane na nowsze. Testowanie w fazie utrzymania wykonywane jest na systemie produkcyjnym, a powodem testów są m.in.: modyfikacje, migracje czy wycofanie systemu bądź oprogramowania [3]. Modyfikacje środowiska produkcyjnego mają wiele przyczyn. Co za tym idzie, testowanie w fazie utrzymania ma na celu sprawdzenie poprawności współpracy oprogramowania w nowym (zmienionym) środowisku produkcyjnym. Testowanie w fazie utrzymania wykonywane w trakcie migracji powinno dotyczyć zarówno testów zdolności operacyjnej nowego środowiska, jak i testów zmodyfikowanego oprogramowania. Natomiast testowanie wykonywane w związku z wycofaniem systemu może obejmować testy migracji lub archiwizacji danych. Oprócz testowania wykonywanych zmian testy w fazie utrzymania obejmują także pełne testy regresywne niezmienionych części systemu. Zakres testów regresywnych zależy od ryzyka zmiany, wielkości systemu oraz zakresu zmiany. Analiza wpływu polega na określeniu, w jakim stopniu zmiany mogą wpłynąć na system, a jej wynik określa, jak obszerne testy powinny zostać wykonane. Do omawianej w tym punkcie grupy zagadnień odnoszą się między innymi pytanie 28 z zestawu [4], które brzmi: Które z poniższych stwierdzeń definiuje zakres testów w fazie utrzymania: A. Czas, w którym dokonano ostatniej zmiany w systemie. B. Pokrycie aktualnego zbioru testów regresywnych. C. Rozmiar i ryzyko zmian w systemie. D. Błędy znalezione podczas przeprowadzania ostatnich testów regresywnych. W tym przypadku poprawna odpowiedź to C. 131

133 6.3. Testowanie statyczne Statyczne techniki testowania nie uruchamiają testowanego programu, gdyż są to techniki ręczne (przeglądy) lub zautomatyzowane (analiza statyczna). Przeglądy, analiza statyczna oraz testowanie dynamiczne mają jeden wspólny cel zidentyfikowanie defektów. Są to czynności uzupełniające się, a każda z nich umożliwia odnalezienie różnych rodzajów defektów. W przeciwieństwie do testowania dynamicznego, testowanie statyczne znajduje raczej defekty niż awarie. Typowymi defektami, łatwiejszymi do odnalezienia za pomocą przeglądów niż testowania dynamicznego, są odchylenia od standardów, błędy wymagań lub projektu, niewystarczająca zdolność do konserwacji lub nieprawidłowe specyfikacje interfejsów. Testowanie statyczne powinno być wykonywane przed testowaniem dynamicznym. Defekty wykryte podczas testów statycznych na wczesnym etapie życia produktu są często dużo tańsze i łatwiejsze do usunięcia niż defekty wykryte podczas wykonywania późniejszych testów (np. defekty znalezione w wymaganiach). Do zalet przeglądów wlicza się również wczesne wykrycie i naprawę defektu, poprawę produktywności oprogramowania oraz skrócony czas tworzenia oprogramowania i testowania, a także zmniejszenie defektów i polepszoną komunikację. Przeglądy mogą być prowadzone na bardzo różnym poziomie sformalizowania. Sposób, w jaki przegląd jest prowadzony, zależy od uzgodnionego celu. Planując przegląd formalny, należy wziąć pod uwagę wszystkie niezbędne fazy takiego przeglądu oraz odpowiednio zdefiniować role i odpowiedzialności. Wśród faz formalnego przeglądu należy uwzględnić: Fazę planowania, w której należy wybrać osoby wykonujące przegląd oraz przypisać im role. Należy także jasno określić, co jest na wejściu przeglądu i jakie są warunki wyjścia. Fazę rozpoczęcia, w której dokonywana jest dystrybucja dokumentów do przejrzenia oraz wyjaśnienie uczestnikom celów, procesu i dokumentów. Fazę indywidualnego przygotowania, która jest wykonywana samodzielnie przez wybrane osoby. W tej fazie przed przystąpieniem do spotkania przeglądowego uczestnicy robią notatki na temat uwag, potencjalnych defektów, komentarzy. Fazę spotkania przeglądowego, podczas którego odbywa się dyskusja lub zapis z udokumentowanymi wynikami lub protokołami (dla bardziej formalnych typów przeglądu). Fazę obróbki, podczas której następuje ustalenie znalezionych defektów najczęściej wykonywane przez autora. Dalsze części formalnego przeglądu, które mogą polegać na weryfikacji, czy defekty zostały zaadresowane, czy metryki zostały zebrane oraz czy spełnione są warunki wyjścia. Aby cały proces mógł przebiegać sprawnie należy zdefiniować odpowiednie role: Menedżer decyduje o wykonaniu przeglądu, przydziela czas w harmonogramach projektów i określa, czy zostały uwzględnione cele przeglądu. Moderator jest osobą, na której spoczywa odpowiedzialność za sukces przeglądu. Prowadzi przegląd dokumentów, wliczając w to planowanie przeglądu, przebieg spotkania 132

134 i dalszą część po spotkaniu. Jeżeli to konieczne, może prowadzić mediacje pomiędzy osobami o różnych poglądach. Autor osoba odpowiedzialna za przeglądane dokumenty. Przeglądający osoby ze specyficznym technicznym lub biznesowym przygotowaniem, które identyfikują i opisują wyniki badań przeglądanego produktu. Przeglądający powinni być tak wybrani, aby reprezentowali różne perspektywy i role. Protokolant dokumentuje wszystkie kwestie pojawiające się podczas spotkania. Pojedynczy dokument może być przedmiotem więcej niż jednego rodzaju przeglądu, które mogą być wykonywane w różnej kolejności. Oprócz przeglądu formalnego można wyróżnić kilka innych rodzajów przeglądów [3]: przegląd nieformalny, którego głównymi cechami są: brak formalnego procesu, możliwość jego zastosowania przy programowaniu parami lub do przeglądów projektu i kodu przez kierownika zespołu, opcjonalność: może być udokumentowany, różnica w przydatności w zależności od przeglądającego, osiągnięcie głównego celu: niedrogi sposób uzyskania pewnej korzyści; przejrzenie, którego kluczowymi elementami są: spotkanie prowadzone przez autora, scenariusze, przeglądy kodu, grupa koleżeńska, otwarte dyskusje, opcjonalnie przygotowanie przeglądających przed spotkaniem, raport z przeglądu, lista wykrytych rzeczy i protokolant (nie autor), brak zróżnicowania od zupełnie nieformalnego do bardzo formalnego, osiągnięcie głównego celu: nauka, zrozumienie, znalezienie defektu; przegląd techniczny, którego głównymi elementami są: udokumentowany, nastawiony na wykrycie błędów proces, w którym biorą udział koledzy i eksperci techniczni, przegląd koleżeński bez uczestnictwa zarządu, wstępne przygotowanie przed spotkaniem, opcjonalnie: użycie list kontrolnych, raportu przeglądu, list wykrytych rzeczy oraz uczestnictwo zarządu, osiągnięcie głównego celu: przedyskutować, podjąć decyzję, ocenić alternatywy, znaleźć defekty, rozwiązać problemy techniczne oraz sprawdzić zgodność ze specyfikacjami i standardami; inspekcja, która charakteryzuje się tym, że: prowadzona jest przez wyszkolonego moderatora (nie autora), zwykle wykonywana jest przez osoby o podobnych kompetencjach jak autor, są w niej określone role, zawiera miary, formalny proces oparty jest na regułach oraz na listach kontrolnych z kryteriami wejściowymi i warunkami wyjścia, wstępne przygotowanie dokonywane jest przed spotkaniem, 133

135 sporządza się raport z inspekcji, listę wykrytych rzeczy, formalny proces kontroli wykonywany jest po wykonaniu napraw, opcjonalnie: następuje ulepszenie procesu, główny cel to znalezienie defektów. Niezależnie od rodzaju przeglądu można zdefiniować ogólne czynniki stanowiące o powodzeniu przeglądu: Każdy przegląd musi mieć jasno określony cel. Do realizacji celów przeglądu angażuje się właściwe osoby. Znalezione błędy są przyjmowane z zadowoleniem i mówi się o nich obiektywnie. Stosuje się techniki przeglądowe, które są odpowiednie dla typu i poziomu produktów pracy programowej oraz osób przeglądających. Jeśli stosowne jest zwiększenie efektywności identyfikacji defektu, korzysta się z list kontrolnych i ról. Stosuje się szkolenia w technikach przeglądowych, szczególnie w tych bardziej formalnych jak inspekcja. Zarząd popiera dobry proces przeglądu (np. poprzez uwzględnienie odpowiedniego czasu na czynności przeglądu w harmonogramie projektu). Kładzie się nacisk na naukę i ulepszanie procesu przeglądu. Analiza statyczna może zlokalizować defekty trudne do wykrycia za pomocą innych technik testowania. Tak jak przeglądy, analiza statyczna wykrywa raczej defekty niż awarie. Do typowych defektów wykrywanych za pomocą analizy statycznej należą: odwołanie się do zmiennej z nieokreśloną wartością, niespójny interfejs pomiędzy modułami, zmienne, których nigdy nie użyto, nieosiągalny (martwy) kod, naruszenie standardów programowania, słabe punkty bezpieczeństwa, błędy składni kodu i modeli oprogramowania. Narzędzia do analizy statycznej są używane głównie przez programistów przed testowaniem modułowym i integracyjnym i podczas niego oraz przez projektantów podczas modelowania oprogramowania. Narzędzia do analizy statycznej mogą generować ogromne ilości komunikatów, dlatego wymagane jest umiejętne zarządzenie nimi, aby korzystanie było maksymalnie efektywne. Do omawianej w tym punkcie grupy zagadnień odnoszą się między innymi pytania 20, 22 i 27 z zestawu [4]. W szczególności pytanie 20 brzmi: Jaka zwykle kolejność poszczególnych faz dotyczy przeglądów formalnych? A. Planowanie, rozpoczęcie, przygotowanie, spotkanie, obróbka, sprawdzenie. B. Rozpoczęcie, planowanie, przygotowanie, spotkanie, obróbka, sprawdzenie. C. Przygotowanie, planowanie, rozpoczęcie, spotkanie, obróbka, sprawdzenie. D. Planowanie, przygotowanie, rozpoczęcie, spotkanie, obróbka, sprawdzenie. W tym przypadku poprawna odpowiedź to A. 134

136 6.4. Projektowanie testów Proces identyfikowania warunków testowych oraz projektowania testów składa się z kilku podstawowych kroków. Pierwszy z nich to projektowanie testów przez identyfikowanie warunków testowych. Następnie ma miejsce specyfikacja przypadków i procedur testowych. Proces może zostać wykonany w różnoraki sposób: od zupełnie nieformalnego z małą ilością dokumentacji do zupełnie formalnego. Poziom sformalizowania zależy od kontekstu testowania. Podczas projektowania analizie poddawane zostają podstawy testów w celu określenia, co testować i w celu identyfikacji warunków testowych, przy czym warunek testowy jest definiowany jako element lub zdarzenie, które powinno być zweryfikowane przez jeden lub więcej przypadków testowych. Podczas projektowania testów szczegółowe podejście testowe jest budowane na podstawie zidentyfikowanego ryzyka. W czasie specyfikacji przypadków testowych dane i przypadki testowe są szczegółowo budowane i opisywane z wykorzystaniem technik projektowania testów. Przypadek testowy jest zestawem danych wejściowych, warunków początkowych, oczekiwanych wyników i warunków końcowych zaprojektowanych w celu pokrycia pewnych warunków testowych. Specyfikacja procedury testowej obejmuje definiowanie kolejności wykonywania przypadków testowych. Jeżeli testy są przeprowadzane przy użyciu narzędzia wspierającego, to kolejność działań powinna zostać określona w skrypcie testowym (który jest zautomatyzowaną procedurą testową). W kolejnym kroku różne procedury testowe są wstawiane w harmonogram wykonania testu, który określa kolejność ich wykonywania. W harmonogramie należy wziąć pod uwagę takie czynniki jak testy regresywne, priorytety, zależności techniczne i logiczne. Celem technik projektowania testów jest zidentyfikowanie warunków testowych i przypadków testowych. Klasycznym podziałem technik testowych jest podział na technikę czarnoskrzynkową i technikę białoskrzynkową. Pewne techniki jednak mieszczą się wyraźnie w jednej kategorii, inne maję cechy więcej niż jednej kategorii Techniki czarnoskrzynkowe Techniki czarnoskrzynkowe (zwane również technikami opartymi na specyfikacji) znajdują i wybierają warunki i przypadki testowe na podstawie analizy dokumentacji (podstawy testów) zarówno funkcjonalnej, jak i niefunkcjonalnej bez odwoływania się do wewnętrznej struktury testowanego obiektu. Podstawowymi cechami tych technik są: modele formalne lub nieformalne, które są wykorzystywane do specyfikowania rozwiązywanych problemów, systemu lub jego modułów; przypadki testowe, które mogą być wytwarzane systematycznie na podstawie modeli. Do technik testowania czarnoskrzynkowego zaliczamy: Podział na klasy równoważności technika w której tak projektuje się testy, aby pokryć wszystkie klasy równoważności. Klasy równoważności są to takie grupy elementów wejściowych systemu, które są przetwarzane przez system, w ten sam sposób. Tę technikę można stosować, aby osiągnąć pokrycie dla danych wejściowych i wyjściowych. 135

137 Analiza wartości brzegowych jest to technika, która jest często uwzględniana jako rozszerzenie techniki klas równoważności. Projektując przypadki testowe, należy wybierać wszystkie wartości minimalne oraz maksymalnie zdefiniowanych klas równoważności. Technika ta jest łatwa w stosowaniu i ma dużą efektywność wykrywania błędów, ponieważ bardzo często zdarza się, że właśnie dla wartości brzegowych zachowanie systemu jest nieprawidłowe. Stosowanie tej techniki wymaga dostępu do szczegółowej, a czasami nawet do dodatkowej, dokumentacji, specyfikacji. Technikę tę można stosować na wszystkich poziomach testów. Testowanie na podstawie tablicy decyzyjnej jest bardzo dobrym sposobem przetestowania wymagań zawierających warunki logiczne. Warunki wejściowe i akcje ustawia się w taki sposób, aby mogły odzwierciedlać prawdę lub fałsz. Tworzy się tablicę decyzyjną, która zawiera warunki przełączania, często kombinację prawdy i fałszu, dla wszystkich warunków wejściowych oraz wynikających z nich akcji. Każda kolumna odpowiada pojedynczej regule biznesowej, która określa unikalną kombinację warunków, dając w sumie wykonanie wszystkich akcji związanych z tą regułą. Podstawowym pokryciem w tej technice jest co najmniej jeden test dla każdej z kolumn, który pokrywa wszystkie kombinacje warunków wyzwalających. Technika ta minimalizuje ryzyko nieprzetestowania wszystkich kombinacji warunków wejściowych i powinna być stosowana tam, gdzie działanie oprogramowania zależy od decyzji logicznych. Testowanie przejść pomiędzy stanami jest techniką stosowaną w przypadku systemów, których odpowiedź zależy od bieżących warunków, historii wejść, bieżących wartości zmiennych w systemie. W tym podejściu system jest reprezentowany przez tablicę stanów, na której zaznaczone są wszystkie możliwe stany, wszystkie możliwe przejścia oraz przejścia niedozwolone. Testy powinny zostać tak zaprojektowane, aby pokryć wszystkie stany, przejścia oraz sprawdzić przejścia niedozwolone. Testowanie na podstawie przypadków użycia jest techniką bazującą na scenariuszach biznesowych lub przypadkach użycia, które opisują interakcję pomiędzy użytkownikiem a systemem, produkującą wartość wynikową dla użytkownika. Opisują one przepływ procesów przez system, co powoduje, że są one niezastąpione w wykrywaniu defektów w rzeczywistych przepływach danych w systemie. Przypadki użycia mające związek ze scenariuszami są bardzo pomocne przy projektowaniu testów akceptacyjnych z udziałem klienta/użytkownika Techniki białoskrzynkowe Techniki białoskrzynkowe, zwane również technikami strukturalnymi lub opartymi na strukturze, oparte są na analizie wewnętrznej struktury modułu lub systemu np.: Poziomu modułu: strukturą jest kod, tzn. instrukcje, decyzje i rozgałęzienia. Poziomu integracji: strukturą może być drzewo wywołań. Poziomu systemu: strukturą może być struktura menu, proces biznesowy. W [3] przedstawione są dwie techniki stosowane do pokrycia kodu bazujące na instrukcjach i decyzjach: Testowanie instrukcji i pokrycie w testowaniu modułowym pokrycie kodu jest procentową częścią instrukcji, które zostały wykonane przez zestaw przypadków testowych. 136

138 W testowaniu instrukcji przypadki testowe projektuje się tak, aby zmaksymalizować pokrycie instrukcji kodu. Testowanie decyzyjne i pokrycie pokrycie decyzji w odniesieniu do testowania rozgałęzień jest procentową oceną rezultatów decyzyjnych, które zostały wykonane przez zestaw przypadków testowych. W testowaniu decyzyjnym przypadki testowe projektuje się tak, aby zmaksymalizować pokrycie decyzji. Pokrycie decyzji jest silniejsze od pokrycia instrukcji: 100% pokrycia decyzji gwarantuje 100% pokrycia kodu, ale nie odwrotnie Techniki oparte na doświadczeniu Rozpowszechniona i bardzo popularna jest technika zgadywania błędów. Testy tworzone są na podstawie umiejętności, intuicji i doświadczenia testerów z podobnymi aplikacjami. Skuteczność tej techniki może być bardzo zróżnicowana i zależy głównie od doświadczenia testerów. Stosowana jest w przypadkach, kiedy brak jest zupełnej specyfikacji, nacisków na skrócenie czasu testowania lub jako sprawdzenie całego procesu testowego w celu upewnienia się, że najpoważniejsze defekty zostały wykryte. Do omawianej w tym punkcie grupy zagadnień odnoszą się między innymi pytania 13, 34, 36, 37, 38 i 40 z zestawu [4]. W szczególności pytanie 38 brzmi: Poniższe czynności są podstawami do tworzenia przypadków testowych przy użyciu technik zarówno czarno-, jak i białoskrzynkowych. 1. Posiadanie informacji o tym, jak aplikacja jest skonstruowana. 2. Poznanie modelu systemu, aplikacji lub jej modułów. 3. Analiza dokumentacji, będącej podstawą do testów. 4. Analiza wewnętrznej struktury modułów. Wybierz te wszystkie, które odnoszą się tylko do technik czarnoskrzynkowych. A. 1. oraz 4. B. 1. oraz 3. C. 2. oraz 3. D. 2. oraz 4. W tym przypadku poprawna odpowiedź to C. Pytanie 40 brzmi: Na podstawie danej specyfikacji, które z poniższych wartości wieku są w tym samym przedziale równoważności: 1. Jeżeli masz poniżej 18 lat, jesteś zbyt młody, aby być ubezpieczonym. 2. Pomiędzy 18 a 30 rokiem życia włącznie, otrzymasz 20% zniżkę. 3. Jeżeli masz powyżej 30 lat, nie przysługuje ci żadna zniżka. A. 29, 30, 31. B. 17, 29, 31. C. 18, 29, 30. D. 17, 18, 19. W tym przypadku poprawna odpowiedź to C. 137

139 6.5. Zarządzanie procesem testowym Niezależność testowania Skuteczność odnajdywania błędów drogą testowania i przeglądów można podnieść, wykorzystując niezależnych testerów. Mogą to być testerzy w zespołach programistycznych, grupa testowa w organizacji, testerzy z działu biznesowego, przedstawiciele użytkowników końcowych czy w końcu niezależni specjaliści testowi. W przypadku dużych, złożonych projektów lub w zespołach wytwarzających produkty, krytyczne pod względem bezpieczeństwa, zwykle najkorzystniejsze jest testowanie na wielu poziomach. Wybrane poziomy testowania są wykonywane przez niezależnych testerów. Deweloperzy mogą uczestniczyć w testowaniu, zwłaszcza na niższych poziomach, ale ich brak obiektywności ogranicza ich skuteczność. Z niezależności płyną liczne korzyści. Niezależni testerzy dostrzegają często inne błędy niż te znalezione przez konstruktorów, a ponadto podchodzą do testowanego produktu bez żadnych oczekiwań i uprzedzeń. Mogą oni także zweryfikować poprawność założeń, które przyjęto na etapie specyfikacji i implementacji. Niezależność testowania ma też swoje wady. W przypadku niezależności zupełnej może prowadzić do odizolowania testerów od deweloperów. Problemem jest to, że niezależni testerzy mogą stać się wąskim gardłem projektu, gdyż spoczywa na nich odpowiedzialność za ostateczną kontrolę projektu. Ponadto deweloperzy mogą utracić współodpowiedzialność za jakość produktu. Osoby, które pracują przy analizie testów, projektowaniu testów, testach specyficznych typów lub automatyzacji testów, powinny być specjalistami w swych rolach. W zależności od poziomu testów i ryzyka związanego z produktem lub projektem różni ludzie mogą pracować jako testerzy, zachowując pewien stopień niezależności np. na poziomie modułów i integracji, testerami mogą być deweloperzy, przy testach akceptacyjnych mogą to być eksperci biznesowi lub użytkownicy, natomiast przy akceptacji operacyjnej powinni to być operatorzy systemu. Do omawianej w tym punkcie grupy zagadnień odnosi się między innymi pytanie 39 z zestawu [4], które brzmi: Które z poniższych stwierdzeń opisują korzyści niezależnego testowania: A. Nowy kod nie może być wdrożony do produkcji, dopóki nie zostaną ukończone testy niezależne. B. Testy są odizolowane od wytwarzania. C. Niezależni testerzy są bezstronni i dostrzegają inne, nowe defekty. D. Programiści nie muszą brać tak dużej odpowiedzialności za jakość. W tym przypadku poprawna odpowiedź to C Planowanie testowania Najważniejszym celem głównego planu testów jest wyjaśnienie, jak będzie przebiegało testowanie. Planowanie może być udokumentowane w planie testów projektu lub głównym planie testów, a także w odrębnych planach testów dla poszczególnych poziomów. Istnieją 138

140 standardy określające wzorce dokumentacji planów testów np. Standard for Software Test Documentation (IEEE 829). Standard ten określa formę zbioru ośmiu dokumentów potrzebnych w każdej z faz testowania oprogramowania: Test Plan dokument planowania zarządzania projektem, który składa się z informacji o tym, w jaki sposób będą prowadzone testy, kto będzie je przeprowadzał, co będzie testowane, jak długo potrwa cały proces oraz jaki będzie zakres testów. Test Design Specifi cation szczegóły na temat warunków testowania, oczekiwanych wyników, a także kryteriach przejścia testu. Test Case Specifi cation specyfikuje dane testowe do użycia podczas wdrażania warunków testowania określonych w Test Design Specifi cation. Test Procedure Specifi cation zawiera szczegóły na temat przeprowadzenia każdego testu, włączając w to założenia oraz poszczególne kroki testów. Test Item Transmittal Report zawiera raporty na temat czasu przejścia testowanych fragmentów oprogramowania między etapami. Test Log zawiera informacje o tym, które przypadki testowania zostały użyte, kto je użył i w jakim porządku oraz informacje o ich powodzeniu. Test Incident Report zawiera informacje o testach zakończonych niepowodzeniem, informacje o wynikach oraz dlaczego dany test nie powiódł się. Test Summary Report raport ten zawiera wszystkie istotne informacje ujawnione podczas zakończonych testów oraz wyceny jakości procesów testowania, jakości oprogramowania poddanego testowi, a także statystyki uzyskane z Incident Report. Raport odnosi się również do typów i czasu trwania wykonanych testów w celu usprawnienia wszelkich planów związanych z testami w przyszłości. Ostateczna forma dokumentu jest wykorzystywana do weryfikacji poprawności testowanego systemu względem wymagań zdefiniowanych przez zleceniodawców. Na planowanie wpływa polityka testów w organizacji, cele i zakres testowania, zagrożenia, ograniczenia, krytyczność i łatwość testowania oraz dostępność zasobów. Im dalej posuwa się planowanie projektu i testowania, tym więcej informacji jest do dyspozycji i tym bardziej szczegółowy staje się plan. Planowanie jest czynnością stałą i wykonuje się je we wszystkich procesach i fazach cyklu życiowego oprogramowania. Informacja zwrotna z realizacji planu testów umożliwia identyfikację zmieniającego się ryzyka, co pozwala na dostosowanie planu. W trakcie planowania testów mogą być wykonywane następujące czynności: Określenie ogólnej metodyki testowej, w tym poziomów testowania oraz kryteriów wejścia i wyjścia. Zintegrowanie i skoordynowanie procesu testowania z fazami cyklu życia oprogramowania. Podjęcie decyzji o tym, co będzie testowane, jakie role będą przypisane jakim zadaniom, kiedy i w jaki sposób będą wykonywane zadania testowe, jak będą oceniane wyniki testów oraz kiedy testy powinny zostać zakończone. Przydzielenie zasobów do zadań. Określenie formatu dokumentacji testowej. 139

141 Wybór miar służących do monitorowania i nadzoru nad przygotowaniem i wykonywaniem testów, rozwiązywania zgłoszeń błędów oraz problemów związanych z ryzykiem. Określenie szczegółowości procedur testowych. Kryteria wyjścia określają, kiedy można zakończyć testowanie. Przykładami powszechnie stosowanych kryteriów zakończenia są miary staranności takie jak pokrycie kodu, funkcjonalności lub ryzyka, koszty testowania, projektu itp. Inne kryteria to oszacowanie miary zagęszczenia błędów lub miary niezawodności czy istniejące zagrożenia takie jak nienaprawione błędy lub brak pokrycia pewnych obszarów oraz harmonogramy projektu. W jednym ze sposobów kategoryzacji podejścia lub strategii testowych jest użycie kryterium czasu. Odnosi się to do przedziałów czasu, podczas których odbywa się większość pracy związanej z testowaniem. W szczególności wyróżnia się metody: prewencyjne, w których testy projektuje się tak wcześnie, jak to tylko możliwe, reaktywne, w których projektowanie testów następuje dopiero po wyprodukowaniu oprogramowania lub systemu. Typowymi strategiami testowymi są metody [3]: analityczne, np. testowanie na podstawie ryzyka, w których testowanie jest skupione na obszarach o największym zagrożeniu, modelowania, np. metody stochastyczne na podstawie danych statystycznych dotyczących częstotliwości awarii lub zastosowania, systematyczne, takie jak testowanie na podstawie danych o awariach, na podstawie list kontrolnych oraz na podstawie atrybutów jakości, zgodne z procesem, standardem lub normą określoną np. przez standard branżowy lub metodyki zwinne, dynamiczne i heurystyczne, w których testowanie polega bardziej na reagowaniu na zdarzenia niż na planowaniu. Inne strategie obejmują podejścia konsultatywne, w których projektowanie testów jest w dużej części zadaniem ekspertów w dziedzinie technologii lub zastosowania biznesowego, oraz mające na celu ograniczenie pracochłonności testów regresji poprzez ponowne użycie artefaktów testowych, rozbudowaną automatyzację oraz wykorzystanie standardowych zestawów testów. Różne metody mogą być łączone pomiędzy sobą. Wybierając metody, należy uwzględnić różne aspekty, w tym ryzyko niepowodzenia projektu, wszelkie zagrożenia spowodowane awarią produktu, umiejętności i doświadczenie ludzi pracujących w ramach projektu, cel przedsięwzięcia testowego oraz misję zespołu testowego, przepisy dotyczące procesu wytwarzania oraz rodzaj i specyfikację produktu lub przedsięwzięcia. Do omawianej w tym punkcie grupy zagadnień odnoszą się między innymi pytania 10 i 33 z zestawu [4]. W szczególności pytanie 33 brzmi: Które z poniższych zadań jest głównym zadaniem planowania testów: A. Szacowanie kryteriów zakończenia oraz raportowanie. B. Określenie metody testów. C. Przygotowanie specyfikacji testów. D. Pomiary i analiza wyników. W tym przypadku poprawna odpowiedź to B. 140

142 Nadzór testowania Zadaniem monitorowania testów jest wygenerowanie informacji zwrotnej z ich przebiegu. Informacje mogą być zbierane ręcznie lub automatycznie i mogą służyć do określenia, w jakim stopniu kryteria wyjścia zostały spełnione, sprawdzeniu postępu prac z harmonogramem i budżetem. Przykładami często stosowanych miar mogą być [3]: ustalenie, jaka część prac została wykonana, a jaką część wykonano, przygotowując środowisko testowe; przebieg wykonania testów i analiza danych o błędach; stopień realizacji wymagań, pokrycia kodu; subiektywne poczucie testerów o niezawodności produktu; daty testowych kamieni milowych czy koszty projektu. Celem raportowania jest podanie podsumowujących danych dotyczących przebiegu przedsięwzięcia testowego. Przykładowe wzorce końcowego raportu znajdują się w normie IEEE 829 Standard for Software Test Documentation. W trakcie i pod koniec każdego poziomu testowania należy wykonać pomiary, aby móc ocenić właściwy wybór celów testowania dla danego poziomu, na ile przyjęta metodyka testowania jest odpowiednia oraz na ile testowanie jest skuteczne w porównaniu z przyjętymi celami. Nadzór nad testowaniem obejmuje wszelkie czynności związane z testowaniem. Dzięki zebranym danym umożliwia poprawę jakości testowania poprzez nadanie procesowi nowego kierunku. Przykładami typowych czynności nadzorczych są zmiana wag testów po wystąpieniu jakiegoś ryzyka czy zmiana harmonogramu. Wszystkie czynności i decyzje związane z nadzorem testowania mogą mieć wpływ na proces rozwoju oprogramowania w jego cyklu życia. Do omawianej w tym punkcie grupy zagadnień odnosi się między innymi pytanie 30 z zestawu [4], które brzmi: Która z poniższych miar jest poprawną miarą postępu testów: A. Całkowita liczba błędów w produkcie. B. Pracochłonność poprawy wszystkich błędów. C. Liczba niewykonanych przypadków testowych. D. Liczba niewykrytych błędów. W tym przypadku poprawna odpowiedź to C Zarządzanie incydentami Jednym z celów testowania jest odnalezienie defektów. Konieczny jest mechanizm pozwalający na zarządzanie odnalezionymi defektami. Każdy defekt powinien być nadzorowany od momentu jego odkrycia poprzez zaklasyfikowanie, naprawienie i potwierdzenie jego usunięcia. Incydenty mogą być zgłaszane na każdym etapie projektu i mogą dotyczyć wszelkich spraw z nim związanych (kod źródłowy, specyfikacja wymagań, instrukcja obsługi itp.). Podstawowymi celami zgłaszania incydentów są dostarczenie informacji o wystąpieniu incydentu i jakości systemu oraz przebiegu procesu testowania, a także generowanie propozycji udoskonalenia procesu testowania. 141

143 Tester lub osoba wykonująca przegląd zwykle notuje następujące dane na temat incydentu [3]: datę zgłoszenia, organizację zgłaszającą, autora, zatwierdzenie i status; informację dotyczącą zgłoszenia, jego wagę i priorytet; odnośniki, w tym identyfikator przypadku testowego, który ujawnił problem. Zgłoszenie incydentu może też zawierać szczegółowe informacje [3]. Wyżej wspominany standard określa treść i strukturę zgłoszenia incydentu, nazywanego w normie zgłoszeniem niezgodności. Do omawianej w tym punkcie grupy zagadnień odnosi się między innymi pytanie 12 z zestawu [4], które brzmi: Co najprawdopodobniej nie znajdzie się w zgłoszeniu incydentu? A. Faza cyklu życia, w którym wystąpił incydent. B. Sugestie dotyczące naprawy problemu. C. Data wystąpienia incydentu. D. Stopień wpływu incydentu na interesy interesariuszy. W tym przypadku poprawna odpowiedź to B Klasy narzędzi testowych Dostępnych jest wiele narzędzi wspomagających różne typy i fazy testowania. Niektóre z nich wspierają tylko jedną czynność, inne potrafią wspierać testera w całej gamie czynności. Ich korzystne działanie polega głównie na zautomatyzowaniu wielokrotnie wykonywanych czynności testowych. Mogą one także poprawić niezawodność testowania dzięki automatyzacji porównywania dużych ilości danych lub symulowania określonych zachowań środowiska testowanego systemu. Niektóre narzędzia są inwazyjne, inne nie, toteż wyniki tych samych pomiarów dokonywanych za pomocą różnych narzędzi mogą się od siebie różnić. Skutek inwazyjności narzędzia jest nazywany efektem próbnika. Większość faz, obszarów związanych z testowaniem, jest wspierana przez różnorodne narzędzia. Do zarządzania testowaniem także powstało wiele narzędzi. Można wśród nich wyróżnić narzędzia do zarządzania testami, wymaganiami, incydentami i konfiguracją Narzędziowe wsparcie testowania statycznego Kwestia ważności testowania statycznego była już poruszana wcześniej. Wśród narzędzi wspierających testowanie statyczne możemy wyróżnić narzędzia wspierające: Proces przeglądu mogą przechowywać dane na temat proces przeglądu, raportować znalezione defekty oraz pracochłonność, śledzić powiązania pomiędzy dokumentacją a kodem źródłowym. Mogą także pozwolić na wykonywanie przeglądów on-line, co może mieć duże znaczenia dla projektów rozproszonych geograficznie. Analizę statyczną umożliwiają programistom, testerom i specjalistom od zapewniania jakości znajdowanie defektów przed rozpoczęciem testowania dynamicznego. Mogą 142

144 one być pomocne w wyliczaniu miar, a ich podstawowymi celami są nadzorowanie przestrzegania standardów kodowania, analiza struktur i zależności oraz ułatwienie zrozumienia kodu. Modelowanie pomagają dokonywać walidacji modeli oprogramowania (niespójności modelu, błędy w przejściach pomiędzy stanami projektowanego systemu), a czasami także umożliwiają wygenerowanie przypadków testowych. Podstawową korzyścią płynącą z zastosowania narzędzi do testowania statycznego jest oszczędność wynikająca ze znajdowania błędów we wcześniejszych fazach procesu wytwarzania oprogramowania. Dzięki temu proces może odbywać się szybciej i sprawniej, gdyż ogranicza się liczbę przeróbek Narzędziowe wsparcie tworzenia specyfikacji testów Pierwszą podgrupę stanowią narzędzia wspierające projektowanie testów. Generują one wejściowe dane testowe lub testy z wymagań, z graficznego interfejsu użytkownika, z modeli projektowych lub też z kodu źródłowego. Potrafią także generować oczekiwane wyniki. Testy wygenerowane z modelu automatu skończonego lub modelu obiektowego są przydatne do weryfikacji poprawności implementacji modelu w kodzie, ale z reguły nie są wystarczające do zweryfikowania wszystkich aspektów oprogramowania. Pozwalają przede wszystkim zaoszczędzić czas i zapewnić większą staranność, gdyż testy wygenerowane przez narzędzia są kompletne i dotyczą wszystkich obszarów funkcjonalności systemu. Drugą podgrupę stanowią narzędzia do przygotowania danych testowych. Generują dane testowe wykorzystywane przy wykonywaniu testów z baz danych, plików lub zarejestrowanych przekazów danych. Zaletą tych narzędzi jest zabezpieczenie poufnych danych wykorzystanych w środowisku testowym Narzędziowe wsparcie wykonywania testów Narzędzia wspomagające wykonywanie testów umożliwiają automatyczne lub półautomatyczne wykonywanie testów sterowanych językiem skryptowym. Zwykle narzędzia tego typu pozwalają na porównywanie wyników oraz tworzenie logu dla każdego wykonania testu. Narzędzia wspierające wykonanie testów mogą być też stosowane do rejestrowania testów. Rejestrowanie danych testowych może być przydatne do odtworzenia lub udokumentowania testów w przypadku awarii. Komparatory testowe są inną klasą narzędzi wspierających proces wykonywania testów. Służą one do porównywania plików, baz danych lub wyników testów. W skład narzędzi do wykonywania testów wchodzą głównie komparatory dynamiczne, ale niekiedy porównania wykonuje się dopiero po zakończeniu testów za pomocą odrębnego narzędzia do porównywania wyników. Narzędzia wykonujące pomiar pokrycia mogą działać inwazyjnie lub nie i zależy to od techniki wykonywania pomiaru, rodzaju miary pokrycia oraz języka programowania. Narzędzia te mierzą odsetek określonych konstrukcji w kodzie (instrukcje, decyzje, wywołań funkcji itp.), które zostały sprawdzone podczas procesu testowania. Miary pokrycia wykazują, w jakim stopniu konstrukcje będące przedmiotem pomiaru są testowane przez dany zestaw testów. 143

145 Narzędzia do testowania zabezpieczeń wyszukują wirusy oraz identyfikują ataki mające na celu przeciążenie serwerów. Identyfikują także miejsca braku odporności na nieautoryzowany dostęp do systemu Narzędziowe wsparcie testowania wydajności W tej grupie narzędzi można wyróżnić trzy podkategorie: Narzędzia do analizy dynamicznej odnajdują defekty dające się zaobserwować wyłącznie podczas działania programu takie jak zależności czasowe, wycieki pamięci. Używane są zwykle do testowania modułowego, integracji modułów oraz do testowania oprogramowania pośredniego. Narzędzia do testów wydajności, obciążenia i przeciążających symulują obciążenie aplikacji, bazy danych albo komponentów środowiska systemu takich jak sieć czy serwer oraz monitorują zachowanie się testowanego systemu w symulowanych warunkach. Narzędzia do monitorowania nie są typowymi narzędziami testowymi, ale dostarczają informacji niedostępnej w inny sposób, która następnie jest wykorzystywana w celach testowania. Analizują, weryfikują i raportują wykorzystanie określonych zasobów systemowych oraz ostrzegają o zagrożeniach systemu. Ponadto przechowują dane dotyczące wersji i tzw. buildów oprogramowania, testaliów, a także umożliwiają śledzenie powiązań Narzędzia wspierające testowanie w określonych dziedzinach Niektóre narzędzia należące do opisanych wcześniej typów mogą być wyspecjalizowane do testowania specjalnego rodzaju oprogramowania. Na przykład istnieją specjalne narzędzia do testów wydajności aplikacji internetowych, narzędzia do analizy statycznej dedykowane poszczególnym platformom programistycznym lub narzędzia do analizy dynamicznej wykonywanej przede wszystkim pod kątem zabezpieczeń systemu. Do omawianej w tym punkcie grupy zagadnień odnoszą się między innymi pytania 4, 11, 31 z zestawu [4]. W szczególności pytanie 11 brzmi: Które z poniższych narzędzi najprawdopodobniej zawiera komparator? A. Narzędzie do analizy dynamicznej. B. Narzędzie do wykonywania testów. C. Narzędzie do analizy statycznej. D. Narzędzie do testowania bezpieczeństwa. W tym przypadku poprawna odpowiedź to B Wybrane otwarte narzędzia wspomagające testowanie Istotną grupę narzędzi testujących używanych przez deweloperów i testerów stanowią narzędzia do testów jednostkowych. W tej grupie istnieje wiele dojrzałych rozwiązań otwartych [1]. JUnit jest narzędziem służącym do tworzenia powtarzalnych testów jednostkowych oprogramowania pisanego w języku Java. Autorami programu są Kent Beck, Erich Gamma, 144

146 David Saff, a narzędzie jest rozpowszechniane na licencji Common Public License przez stronę JUnit umożliwia tworzenie zarówno testów bardzo prostych, jak i bardzo skomplikowanych. Do jego zalet należy to, że metoda języka programowania jest najmniejszą jednostką testowania, wspiera tworzenie przypadków testowych. Pozwala również na oddzielenie testów od kodu i wspiera wiele mechanizmów uruchamiania, oraz budowanie raportów. Obecnie narzędzie jest ściśle zintegrowane z różnymi IDE, w tym Eclipse i NetBeans. Powstały również wersje JUnit dla innych języków programowania, w tym Ada (Aunit), C# (Nunit), JavaScript (JSUnit), Objective-C (OCUnit), PHP (PHPUnit), Python (PyUnit) czy Haskell (Hunit). CppUnit jest frameworkiem do testów dla języka C++, opisywany jako wersja JUnit dla C++. Biblioteka jest udostępniana na licencji GNU Lesser General Public License przez stronę Może być uruchamiana na każdym systemie typu POSIX, co oznacza ze może być wykorzystywana również dla języka C przy minimalnych zmianach w kodzie. Biblioteka posiada wbudowany UI do uruchamiania scenariuszy testowych. W podstawowym trybie pracy wyjście przesyłane jest do filtra, który wyświetla podstawową informację na temat powodzenia (lub nie) testu. Narzędzie udostępnia makra do tworzenia scenariuszy testowych i wspiera hierarchiczne wywoływanie testów. Mniej typową, ale coraz ważniejszą grupę stanowią narzędzia do testowania aplikacji webowych, które tworzą znaczny odsetek wytwarzanego obecnie oprogramowania. Często funkcjonalność i niezawodność tych aplikacji jest sprawą krytyczną (systemy rezerwacji biletów, internetowe konta bankowe, programy lojalnościowe itp). Co za tym idzie, istnieje silna potrzeba testowania. Bogactwo technologii internetowych (HTML, PHP, JSP, JS, AJAX) oraz środowisk (mnogość przeglądarek, różne standardy) znacznie utrudnia przeprowadzenie kompleksowych testów automatycznych. Niestety często aplikacje muszą być testowane ręcznie. Na szczęście część pracy można zautomatyzować poprzez istniejące gotowe rozwiązania. Selenium ( jest napisanym w Javie przenośnym oprogramowaniem do testowania aplikacji webowych autorstwa Jasona Hugginsa (ThoughtWorks) udostępnionym na licencji Apache License 2.0. Zapewnia interfejs do nagrywania i przeprowadzania testów bez potrzeby poznawania języków skryptowych. Aplikacja dostarcza dedykowany język domain specifi c language (DSL) do pisania testów w wielu popularnych językach z uwzględnieniem takich języków, jak Java, Ruby, Groovy, Python, PHP i Perl. Odtwarzanie testów jest możliwe w większość nowych przeglądarek na wszystkich popularnych systemach operacyjnych (Windows, Linux, Macintosh). Narzędzie pozwala na nagrywanie testów, inteligentny wybór zawartości strony, uzupełnianie dla wszystkich wbudowanych komend, podgląd testów, debugowanie oraz zapisywanie testów jako HTML, skrypt Ruby i inne. Pozwala też na automatyczne sprawdzanie tytułów stron. Apache JMeter (jakarta.apache.org/jmeter) jest kompleksowym narzędziem do testowania oprogramowania i mierzenia wydajności udostępnianym przez Apache Software Foundation. Pozwala na testowanie nie tylko kodu aplikacji, ale też m.in. zapytań bazodanowych, FTP, Servletów, skryptów Perl, serwerów , obiektów Java i wiele więcej. Skupia się na testach wydajnościowych serwisów webowych. Narzędzie pracuje wielowątkowo i udostępnia graficzny interfejs użytkownika. Jest również rozszerzalne przez mechanizm wtyczek. 145

147 6.7. Podsumowanie Testowanie oprogramowania jest jednym z podstawowych środków służących do zapewniania jakości oprogramowania. Obecnie proces testowy jest standaryzowany i silnie wspierany narzędziowo. Organizacje takie jak ISTQ dbają o wyszkolenie fachowców zajmujących się testowaniem. Niniejszy rozdział został zredagowany na podstawie syllabusa [3], pytań [4] i innych źródeł [1, 2] w celu podsumowania najistotniejszych informacji związanych z testowaniem oprogramowania z perspektywy ISTQB. Ma on stanowić pomoc dydaktyczną dla osób przygotowujących się do egzaminu dla certyfikowanych testerów. Szersze informacje na temat podstaw testowania można znaleźć w skrypcie [6]. Literatura [1] Nalepa G.J.: Zarządzanie jakością oprogramowania, wykład dla studiów podyplomowych ZPI, AGH, 2011 [2] Werewka J.: Inżynieria wytwarzania oprogramowania: podstawy testowania, wykład, AGH, 2010 [3] Stowarzyszenie Jakości Systemów Informatycznych, Certyfi kowany tester. Plan poziomu podstawowego. Wersja 1.0, 2006 [4] Stowarzyszenie Jakości Systemów Informatycznych, Certyfi kowany tester. Pytania przykładowe do poziomu podstawowego. Wersja dokumentu 2.0. Wersja syllabusu 1.00, 2007 [5] International Software Testing Qualifications Board, Słownik wyrażeń związanych z testowaniem, wersja 2.0. [6] Wiszniewski B., Bereza-Jarociński B.: Teoria i praktyka testowania, PWN, 2006

148 7. Środowiska wytwarzania programowania: wybrane narzędzia 7.1. Wstęp Niniejszy rozdział jest poświęcony wybranym narzędziom stanowiącym współczesne środowisko wspomagania wytwarzania czy utrzymywania oprogramowania. Cechą wspólną wybranych rozwiązań jest to, że są swobodnie dostępne na licencjach opensource lub jako wolnodostępne oprogramowanie (ang. free software). Przedstawione zostały przykłady narzędzi z czterech wybranych klas narzędzi wspomagających. Są to odpowiednio: zintegrowane środowiska programistyczne, systemy wersjonowania kodu, automatyczne generatory dokumentacji oraz systemy do śledzenia zdarzeń i błędów [1] Zintegrowane środowiska programistyczne Zintegrowane środowisko programistyczne to aplikacja lub pakiet zintegrowanych aplikacji służących do wspomagania tworzenia, modyfikowania, testowania i konserwacji oprogramowania. Nazwa IDE pochodzi od angielskiego określenia Integrated Development Environment. IDE oferują zazwyczaj złożoną funkcjonalność, w tym przede wszystkim wsparcie dla edycji kodu źródłowego w wielu językach programowania oraz kompilowanie, debugowanie i uruchamianie kodu źródłowego. Ponadto często wspomagają tworzenie różnorodnych zasobów programu, w tym elementów graficznego interfejsu użytkownika. Niejednokrotnie pomagają w integracji oprogramowania bazowego z innymi aplikacjami, np. systemami baz danych. W dalszej części rozdziału zaprezentowano trzy popularne swobodnie dostępne rozwiązania tego typu NetBeans Pakiet NetBeans IDE ( jest uniwersalnym zintegrowanym środowiskiem programistycznym. Został stworzony przez firmę Sun, a aktualnie jest wspierany i rozwijany przez firmę Oracle. Choć pakiet tworzony był z myślą o wspieraniu oprogramowania w języku Java, to z czasem powstało wiele dodatków, które udostępniają wsparcie dla innych popularnych języków programowania w tym C/C++, PHP, JavaScript, Ruby czy Groovy. 147

149 Architektura NetBeans IDE jest silnie zmodularyzowana. Każda nowa funkcjonalność może zostać dołączona do środowiska w postaci tzw. wtyczki (ang. plugin). Dzięki temu NetBeans wspiera w pełni zintegrowany proces wytwarzania oprogramowania na każdym jego etapie, począwszy od projektowania dzięki wtyczce umożliwiającej tworzenie diagramów UML i automatyczne generowanie kodu na ich podstawie, aż po konserwację i rozwijanie gotowego oprogramowania dzięki integracji z systemami wersjonowania kodu, a także systemami śledzenia błędów. W skład dodatkowych funkcjonalności pakietu NetBeans IDE wchodzą m.in.: projektowanie oprogramowania w UML, projektowanie i tworzenie GUI w Swing Builder czy narzędzia do testowania oprogramowania. Samo środowisko NetBeans IDE zostało stworzone na podstawie tzw. platformy (ang. framework) NetBeans wykorzystującej technologię Java Swing. Oprócz NetBeans IDE istnieje wiele innych aplikacji bazujących na platformie NetBeans. W związku z tym, że platforma napisana została w Javie, ona sama oraz wszystkie produkty na niej bazujące są w pełni przenośne pomiędzy wszystkimi popularnymi systemami operacyjnymi Eclipse Eclipse ( to platforma (framework) napisana w Javie do tworzenia aplikacji typu Rich Client. Na bazie Eclipse powstało IDE do tworzenia programów w Javie, które jest razem z tą platformą rozpowszechniane. Projekt został stworzony przez koncern IBM, a potem udostępniony na zasadach wolnego oprogramowania. Obecnie jest wspierany przez Fundację Eclipse [2]. Podobnie jak NetBeans sama platforma Eclipse nie dostarcza konkretnych narzędzi pomocnych przy projektowaniu aplikacji czy tworzeniu kodu, jednak jej otwarta konstrukcja zapewnia obsługę pluginów wtyczek realizujących różne zadania. Eclipse jest aktualnie jednym z najbardziej rozbudowanych i jednocześnie najpopularniejszych otwartych środowisk wspierających tworzenie oprogramowania (rys. 7.1). Ilość wtyczek do Eclipse jest ogromna i pokrywa większość narzędzi developerskich. Oficjalnie udostępnionych jest ponad tysiąc wtyczek. Wśród wielu funkcjonalności oferowanych przez platformę znajdują się między innymi: tworzenie kodu oprogramowania, projektowanie baz danych, budowanie interfejsów i dokumentacji. Na bazie platformy Eclipse zbudowano kilka innych (poza IDE) środowisk, w tym: Enterprise Java pakiet zawiera zestaw narzędzi przeznaczonych do modelowania, tworzenia, raportowania, testowania i profilingu kodu dla aplikacji w języku Java z naciskiem na wytwarzanie oprogramowania sieciowego i web serwisów. Eclipse RT zbiór środowisk uruchomieniowych i frameworków bazujących na OSGi, umożliwiający tworzenie aplikacji komponentowych o architekturze silnie zmodularyzowanej. Eclipse SOA zbiór pakietów i narzędzi do tworzenia aplikacji o architekturze SOA. Pulsar pakiet oferujący narzędzia do tworzenia aplikacji na urządzenia mobilne. Głównym elementem projektu jest Mobile Tools for Java (MTJ). Modeling pakiet umożliwiający generowanie kodu dla aplikacji Java na podstawie modelu formalnego (na przykład diagramów UML). Poza otwartymi środowiskami stworzonymi ze wsparciem korporacyjnym powstały również środowiska IDE tworzone przez społeczność programistów ochotników na zasadach free software. Dobrym przykładem takiego środowiska jest pakiet KDevelop. 148

150 Rys Architektura platformy Eclipse [2] KDevelop Z początku KDevelop ( było pakietem IDE dla środowiska desktopowego KDE ( do tworzenia oprogramowania w języku C++. Obecnie platformy, na których można uruchomić KDevelop, a także wspierane przez samo IDE języki programowania, zostały rozszerzone. W skład funkcjonalności środowiska KDevelop wchodzi m.in. zarządzanie projektami różnych typów, włączając te bazujące na narzędziach GNU Autotools, QT qmake, CMake oraz Ant. Pakiet obsługuje kompilatory z zestawu GNU Compiler Collection i debugera GNU Debugger. Wspiera również projektowanie GUI. Obsługiwane jest wiele języków programowania w tym Ada, Bash, C/C++, Fortran, Haskell, Java, Pascal, Perl, PHP, Python, Ruby i SQL. Pakiet ma wbudowaną obsługę generatora dokumentacji Doxygen i systemów kontroli wersji: Subversion, CVS, ClearCase i Perforce [3]. Zintegrowane środowiska programistyczne posiadają wbudowane edytory kontekstowe pozwalające na edycję kodu źródłowego i innych plików tekstowych. Jedną z najistotniejszych kwestii w trakcie rozwoju projektu informatycznego jest zarządzanie zmianami tych plików. 149

151 7.3. Systemy wersjonowania i zarządzania zmianami kodu Systemy wersjonowania czy też zarządzania zmianami (ang. revision control systems) funkcjonują pod różnymi postaciami wszędzie tam, gdzie istnieje potrzeba archiwizowania wprowadzonych zmian w plikach. Inny istotny obszar dotyczy wspomagania pracy grupowej, gdy nad plikami pracuje jednocześnie kilka osób. Dotyczy to najczęściej kodu źródłowego i dokumentacji oprogramowania, lecz również systemów zarządzania treścią (CMS), w tym stron typu wiki. W ogólnym przypadku zarządzaniem mogą zostać również objęte pliki aplikacji biurowych. Sposoby na zarządzanie kodem silnie ewoluowały przez ostatnie 20 lat. Obecnie podstawowe funkcjonalności systemów wersjonowania kodu obejmują: archiwizację, wersjonowanie, cofanie zmian, dokumentowanie zmian, udostępnianie, synchronizację, powiadamianie o konfliktach, śledzenie aktywności oraz łączenie i uzgadnianie różnych wariantów (ang. branching & merging). Podstawowym podziałem systemów wersjonowania jest podział ze względu na architekturę. Wyróżnia się dwa podstawowe modele: 1. Scentralizowany (architektura klient-server), np. w systemach CVS, SVN. 2. Rozproszony (architektura peer-to-peer), np. w systemach Mercurial czy GIT. Dalej zaprezentowane są podstawowe przykłady systemów z obu grup RCS protoplasta systemów wersjonowania System RCS Revision Control System jest pakietem poleceń pracujących w środowisku Unix/GNU/Linux, realizującym kontrolę wersji w plikach tekstowych. Autorem RCS jest Walter F. Tichy. System powstał na znanym wydziale informatyki Uniwersytetu Purdue w Indianie [4]. RCS zarządza grupami wydań (edycji) (ang. revision) plików. Przez grupę wydań rozumie się pewien zbiór dokumentów tekstowych powiązanych ze sobą w ten sposób, że kolejne pliki powstawały przez modyfikacje poprzednich. System RCS organizuje tak rozumiane wydania w drzewo, przedstawiające historię zmian wydań. W praktyce wydanie można nazywać wersją w szerszym rozumieniu tego słowa. System automatyzuje proces tworzenia i przechowywania kolejnych wersji projektu. Zapewnia również mechanizmy pozwalające na dokładne określanie różnic pomiędzy wersjami oraz scalanie różnych wersji. Wszystkie zmiany w kolejnych wersjach są rejestrowane i dokumentowane, co umożliwia w każdej chwili uzyskanie opisu historii zmian. Wprawdzie RCS był tworzony głównie z myślą o zarządzaniu wersjami kodu źródłowego programów, lecz w praktyce pracuje z dowolnymi plikami tekstowymi. Oznacza to, że może być stosowany do dowolnych zmieniających się plików tekstowych, takich jak kody źródłowe w językach programowania czy skryptowych, dokumenty tekstowe, dokumenty w językach opisu tekstu takich jak LaTEX, a także HTML czy XML. Oznacza to, iż RCS jest w stanie zarządzać nie tylko wersjami kodu programów, lecz również dokumentacją w różnych formatach [5]. Aktualnie RCS jest rzadko wykorzystywany w praktyce, stał się jednak bazą dla innych systemów kontroli wersji, takich jak CVS czy SVN. 150

152 Scentralizowane systemy wersjonowania Pierwsza wersja CVS, autorstwa Dicka Grune a, miała postać skryptu shella i pojawiła się w grudniu 1986 na liście comp.sources.unix. Choć w dzisiejszym CVS, Concurrent Versions System, nie ma już wiele z tamtego kodu, to pozostały algorytmy rozwiązywania konfliktów opracowane przez Grune a. Głównymi autorami aktualnej wersji CVS są Brian Berliner i Jeff Polk. Poza nimi system udoskonalało wielu innych programistów i należy go dziś uznać za dojrzały i stabilny [5]. System CVS ( jest oparty na RCS. Realizuje wszystkie funkcje RCS oraz wykorzystuje go do rejestrowania modyfikacji w poszczególnych plikach, którymi zarządza. Repozytorium CVS przechowuje informacje na temat wielu drzew katalogów zawierających pliki objęte kontrolą wersji. Drzewa mogą być organizowane w osobne moduły czy projekty. W przeciwieństwie do RCS, który składa się z szeregu krótkich programów realizujących poszczególne funkcje, CVS składa się z jednego programu o nazwie cvs udostępniającego polecenia uruchamiające wszystkie funkcje systemu. Najważniejsze z nich to: init dokonuje inicjalizacji nowego repozytorium CVS, checkout udostępnia wskazany moduł projektu (drzewo plików) z repozytorium w postaci kopii roboczej (odpowiednik co w RCS), import pozwala na dodanie do kopii roboczej projektu całego drzewa plików, add pozwala na dodanie do kopii roboczej projektu pliku lub katalogu, remove umożliwia usunięcie z kopii roboczej projektu pliku lub katalogu, update dokonuje uaktualnienia kopii roboczej z repozytorium projektu, commit przeprowadza synchronizację kopii roboczej z repozytorium, umieszczając w nim zmiany wprowadzone w kopii roboczej (odpowiednik ci w RCS), diff pokazuje zmiany pomiędzy różnymi wersjami plików lub całych drzew projektu (odpowiednik rcsdiff w RCS), log wyświetla historię i opisy zmian plików lub całych drzew projektu (odpowiednik rlog w RCS). System CVS nie blokuje dostępu do wersjonowanych plików (jak to ma miejsce w przypadku RCS), lecz zawsze po operacji checkout tworzy nową kopię roboczą dla konkretnego użytkownika. W związku z tym w tym samym czasie może pracować wielu autorów nad własnymi egzemplarzami kodu. W trakcie pracy każdy autor może porównać swoją kopię roboczą ze stanem repozytorium, aby sprawdzić, czy inne osoby nie wprowadziły jakichś zmian do projektu. Po wprowadzeniu modyfikacji autor umieszcza swoją kopię roboczą w repozytorium. Jest to złożony proces, ponieważ CVS musi porównać tę kopię ze stanem repozytorium, które od czasu utworzenia kopii roboczej mogło być wielokrotnie zmieniane przez innych autorów. W czasie tego porównywania CVS rozwiązuje ewentualne konflikty w modyfikacjach. W razie potrzeby autor jest proszony o potwierdzenie odpowiednich zmian. SVN (Subversion) jest rozszerzeniem systemu CVS ( bazującym na nieco innej koncepcji przechowywania danych i bardziej zaawansowanym zarządzaniu dostępem do repozytoriów, dzięki czemu system lepiej nadaje się do projektów większej skali, nad którymi pracuje wielu programistów [6]. Obecnie projekt jest rozwijany w ramach Apache Foundation. 151

153 Najważniejsze cechy wyróżniające system SVN można opisać następująco: numery wersji dotyczą zawsze całego (repozytorium) katalogu, nie pojedynczych plików, SVN zawsze pracuje na katalogach, które są wersjonowane, co pociąga za sobą konieczność wykonania update, SVN przechowuje lokalnie ostatnią wersję katalogu z repozytorium, co pozwala na lokalną pracę z status/diff/revert, SVN umożliwia pracę bezpołączeniową i spójną prezentację zdarzeń, rozgałęzienia (ang. branches/tags) w SVN są osobnymi katalogami, rozwiązywanie konfliktów ma wsparcie dla trybu interaktywnego, SVN używa diff (delta) dla plików binarnych oraz obsługuje standard MIME. System został zbudowany z założeniem pełnego sieciowego dostępu deweloperów do repozytorium, co za tym idzie, wspiera wiele metod transportu sieciowego i autoryzacji użytkowników. Obecnie SVN stał się dominującym standardem wśród scentralizowanych systemów wersjonowania, stopniowo wypierając CVS Podejście rozproszone do wersjonowania Główną ideą podejścia rozproszonego jest wyeliminowanie lub ograniczenie roli centralnego repozytorium. W podejściu tym każdy użytkownik systemu posiada pełną lokalną kopię repozytorium. Taka redundancja pozwala na zagwarantowanie bezpieczeństwa (safety) danych w rozumieniu uniknięcia utraty danych lub dostępu do nich z powodów awarii centralnego serwera lub połączenia internetowego. Na rysunkach przedstawione zostały najistotniejsze różnice pomiędzy podejściem scentralizowanym (rys. 7.2) a wariantami podejścia peer-to-peer (rys. 7.3 i 7.4). Rys Przepływ danych w podejściu scentralizowanym [7] Git ( jest rozproszonym systemem kontroli wersji, napisanym przez Linusa Torvaldsa w celu wspomagania rozwoju jądra Linux. Pierwsza wersja Git została opracowana w roku Git jest projektem opensource. System jest zaprojektowany pod kątem intensywnego branchingu, gdzie każdy deweloper posiada pełną kopię lokalną repozytorium. 152

154 Prawie każda operacja jest wykonywana lokalnie, co znacząco poprawia wydajność, a samo repozytorium opiera się na snapshotach, a nie diffach. Dopuszcza się różne modele zarządzania przepływem informacji, a preferowanym modelem jest Dictator and Lieutenants Workfl ow. System obsługuje też kilka protokołów sieciowych w tym Git, ssh i http(s). Obecnie Git stał się popularnym rozwiązaniem rozproszonym w projektach opensource i komercyjnych. Rys Przepływ danych w podejściu rozproszonym z wykorzystaniem menagera integrującego (Integration Manager) [7] Rys Przepływ danych w podejściu rozproszonym z wykorzystaniem dyktatora i poruczników (Dictator and Lieutenants Workfl ow) [7] Bazaar ( jest opensource owym, rozproszonym systemem kontroli wersji zaimplementowanym w języku Python. W przeciwieństwie do systemu Git, działa z wieloma systemami operacyjnymi (GNU/Linux, FreeBSD, MS Windows, Mac OS X). 153

155 Obecnie jest wykorzystywany jako system zarządzania dystrybucją Ubuntu Linux. Podstawową cechą różniącą Bazaar od innych rozproszonych systemów kontroli wersji jest to, że oferuje on możliwość użycia centralnego serwera repozytorium. Bazaar udostępnia również mechanizm automatycznego mergowania plików, który charakteryzuje się dużą elastycznością, pozwalając na bardzo skuteczne zarządzanie konfliktami. Mercurial (znany również jako Hg) jest rozproszonym systemem kontroli wersji udostępnionym na licencji GPL ( Przeznaczony jest dla systemów operacyjnych Linux, Windows oraz Mac OS X. Mercurial jest jednym z najdojrzalszych narzędzi tego typu. Cechują go między innymi wysoka wydajność, łatwość obsługi, łatwa rozszerzalność dzięki dodatkowym modułom, dobra przenośność (istotne części są napisane w języku Python) i solidne wsparcie. Cechy te sprawiły, że jest on chętnie wykorzystywany w wielu projektach otwartych i komercyjnych w tym Google Code, NetBeans, Mozilla, OpenOffice, Python i wielu innych. Udostępnianie systemu wersjonowania dla zespołu deweloperów wymaga użycia właściwego środowiska serwerowego. Ten proces można znaczenie uprościć i obniżyć koszty poprzez skorzystanie z gotowych i swobodnie dostępnych on-line serwisów hostingowych dla projektów Systemy wersjonowania dostępne on-line Rozproszone i scentralizowane systemy zarządzania projektem oferują zazwyczaj tylko system kontroli wersji. System typu on-line (rys. 7.5) udostępnia grupę współpracujących programów praktycznie bez konieczności ich konfigurowania. Najpopularniejsze systemy zarządzania projektami on-line to Sourceforge, Bitbucket, GitHub i XP-Dev. Rys Architektura narzędzi do zarządzania projektem on-line Zalet webowych systemów zarządzania projektem jest co najmniej kilka: Nie trzeba samodzielnie konfigurować narzędzi (CVS, Issue Tracker, Bug tracker itp.). 154

156 Nie ma konieczności inwestowania w serwer. Strona projektu jest subdomeną na wysoko pozycjonowanym serwerze (np. sf.net). Hosting, utrzymanie i wszystkie czynności związane z konserwacją sprzętu i oprogramowania zostają po stronie firmy dostarczającej zintegrowany system. W tabeli 7.1 zostało przedstawione porównanie wybranych zintegrowanych systemów wspierających wytwarzanie oprogramowania, bazujących na podejściu on-line. Tab. 7.1 Porównanie systemów typu on-line do zarządzania projektami Cecha Sourceforge Bitbucket GitHub XP-Dev Strony dla projektów Tak Tak Tak Tak Dostępna subdomena Tak Nie Nie Nie Issue tracker Tak Tak Tak Tak Bug tracker Tak Tak Tak Tak Wsparcie dla Git Tak Nie Tak Nie Wsparcie dla Mercurial Tak Nie Nie Tak Wsparcie dla CVS/SVN Tak Tak Tak Tak 7.4. Systemy wspomagające dokumentowanie kodu Generator dokumentacji to narzędzie programistyczne umożliwiające tworzenie dokumentacji zarówno dla programistów (API), jak i dla użytkowników (End-User Guide) ze specjalnie skomentowanego kodu źródłowego, a w niektórych przypadkach także z już skompilowanych programów. Działanie generatora zostało zilustrowane na rysunku 7.6. Rys Schemat działania dokumentacji 155

157 JavaDoc JavaDoc jest konsolowym narzędziem przeznaczonym do dokumentowania kodu napisanego w Javie, które wchodzi w skład Java SDK. Umożliwia generowanie kodu na podstawie umieszczonych w nim w postaci komentarzy tzw. tagów. JavaDoc udostępnia także API pozwalające na modyfikowanie standardowego działania JavaDoc i dodawanie własnych tagów (tzw. doclety i taglety). Wyjściem z generatora jest dokumentacja w formacie HTML w konwencji Java API. W JavaDoc wszystkie tagi muszą być umieszczane w komentarzach. Dobrym zwyczajem jest rozpoczynanie komentarza, w którym zawarte są elementy dokumentacji znakiem /**. W opisach metod można bezpośrednio wykorzystywać kod HTML. Dobrym zwyczajem jest oddzielanie paragrafów w większych opisach za pomocą znacznika <p>. W komentowaniu kodu istnieje wiele niepisanych zasad. Narzędzie DocCheck może pomóc w tworzeniu lepszych dokumentacji. Jest ono jednak obecnie (rok 2011) dostępne wyłącznie w wersji Beta. Poniżej przedstawiony został prosty program w Javie z umieszczonymi tagami dla narzędzi JavaDoc. Dokumentacja dla metody printmessage została przedstawiona na rysunku 7.7. /** * Klasa implementująca zaawansowany mechanizm wyświetlania * transcendentalnego komunikatu Witaj świecie. GEIST 1.0 */ public class HelloWorld{ /** * Metoda wyświetlajaca komuniakta standardowym wyjściu message komunikat który ma zostać wyświetlony Exception w przypadku gdy komunikat jest równy null, * wyrzucany jest wyjątek {@link Exception}. #getdefaultmessage() */ public void printmessage(string message) throws Exception{ } /** * Metoda zwracająca domyślny komunikat do wyświetlenia domyślny komunikat */ public String getdefaultmessage(){ } } Przykład 1. Dokumentacja kodu w konwencji JavaDoc 156

158 Rys Przykład dokumentacji wygenerowanej za pomocą JavaDoc Doclety to programy napisane w języku Java, które umożliwiają zmianę działania narzędzia JavaDoc na poziomie interpretacji tagów i generowania na ich podstawie dokumentu wyjściowego. Oznacza to, że istnieje możliwość stworzenia docletu, który będzie generował na wyjściu dokument w formacie LaTeX, a nie standardowy HTML, a także będzie interpretował zdefiniowane przez programistę tagi, które nie istnieją w standardowej wersji JavaDoc. Rys Umiejscowienie docletu w architekturze JavaDoc 157

159 Taglety są pluginami do docletów JavaDoc. Są odpowiedzialne za modyfikowanie zachowania narzędzia JavaDoc na poziomie interpretacji konkretnego, jednego znacznika. Możliwa jest redefinicja formatowania istniejącego znacznika lub dodanie nowego. Podstawową różnicą pomiędzy docletem a tagletem jest to, że doclet jest autonomicznym programem, który korzysta z API JavaDoc do tworzenia dokumentacji na podstawie zamieszczonych w kodzie komentarzy, a taglet jest jedynie pluginem do istniejącego docletu, który modyfikuje jego działanie dla określonych tagów (rys. 7.8). Szersze możliwości od JavaDoc ma bardziej uniwersalny Doxygen Doxygen Doxygen, to narzędzie do generowania dokumentacji, działające na podobnej zasadzie jak JavaDoc, ale dużo bardziej uniwersalne, wspierające wiele języków programistycznych oraz wiele konwencji dokumentowania kodu. Do języków standardowo wspieranych przez narzędzie zalicza się: C++, C, C#, Java, Objective-C, Python, PHP, IDL (Corba i wersje Microsoftu), Fortran, VHDL oraz częściowo D. Doxygen dostarcza standardowo wiele formatów, do których można eksportować dokumentację. W skład udostępnianych formatów wchodzą: HTML, LaTeX, RTF (MS-Word), PostScript, Hyperlinked PDF, Unix Man Pages W celu wygenerowania dokumentacji za pomocą Doxygena należy wykonać trzy podstawowe kroki: przygotować odpowiednio ukomentowany kod, stworzyć plik konfiguracyjny dla narzędzia Doxygen, a następnie je uruchomić. Składnia Doxygen jest bardzo bogata. Podczas dokumentowania kodu można stosować dwa style komentowania (poza specjalnymi wyjątkami jak Python czy VHDL). Style można mieszać, ale dobrym zwyczajem jest trzymanie się jednego w całej dokumentacji. Poniżej przedstawione zostały przykłady wspomnianych dwóch konwencji dokumentowania kodu: /** * Opis Metody message wiadomosc do wyswietlenie */ public void print(string param){} /*! Opis Metody \param message wiadomosc do wyswietlenie */ public void print(string param){} 158

160 Poza szczególnymi przypadkami każde tagowanie klasy lub metody dzieli się na trzy części: 1. Krótkie streszczenie rozpoczynające się znacznikiem \brief, a kończące nową linią lub znakiem kropki i spacji. 2. Szczegółowy opis występujący po krótkim streszczeniu. 3. Tak zwana dokumentacja in-body składająca się z połączenia wszystkich bloków komentarzy wewnątrz dokumentowanej metody. Plik konfiguracyjny dla Doxygen musi być tworzony w przypadku każdej nowej dokumentacji, w nim określa się między innymi język programistyczny, format i katalog wyjściowy dokumentacji. W przypadku niestworzenia takiego pliku do wygenerowania dokumentacji zostanie użyta domyślna konfiguracja Doxygen. Plik konfiguracyjny jest zwykłym plikiem tekstowym zbudowanym według formatu OPCJA = wartość. Poniżej przedstawiony został przykład zastosowania narzędzia Doxygen ukazujący funkcjonalność rysowania diagramu wywołań funkcji na podstawie kodu z przykładu poniżej. Po uruchomieniu narzędzia otrzymano dokumentację przedstawioną na rysunku 7.9. Rys Przykład dokumentacji wygenerowanej za pomocą Doxygen 159

161 /** Krótki opis. * * Dokładny opis danej metody */ String getmessage(){ /** Opis in-body */ return null; } /** Klasa wywołująca */ class Caller{ public: /** * Funkcja foo */ void bar(){} /** * Funkcja wołajaca funkcje foo */ void foo(){ bar(); } }; /** Klasa posiadająca pole typu Caller*/ class Owner{ private: Caller c; /**< Pole typu Caller */ public: /** * Funkcja wywołująca wszystkie funkcje */ void callemall(){ c.foo(); } }; 160

162 Integralną częścią środowiska narzędziowego do wspomagania rozwijania oprogramowania są systemy śledzenia błędów i zdarzeń, praktycznie niezbędne na etapie testowania i w fazie utrzymania projektu Systemy kontroli i śledzenia błędów Zarządzanie problemami (ang. Issue management) to zagadnienie obejmujące działania mające na celu rozwiązywane problematycznych kwestii pojawiających się w trakcie realizowania projektów informatycznych, biznesowych czy naukowych. Polega na zbieraniu uwag i opinii oraz klasyfikowaniu ich w taki sposób, aby zawsze rozwiązywać kwestie w danej chwili najistotniejsze. Tak zwana kwestia (ang. issue) to problem lub sprawa, które muszą zostać załatwione w odpowiednim czasie, aby przedsięwzięcie się powiodło. Może to być na przykład naprawienie błędu, dodanie nowej funkcjonalności czy rozwiązanie problemu klienta. Systemy śledzenia biletów (ang. issue tracking systems, ticket tracking systems) to aplikacje zarządzające listą kwestii dotyczących danego przedsięwzięcia. Umożliwiają one dodawanie nowych kwestii oraz zmianę statusu istniejących już w systemie. Nie umożliwiają usuwania kwestii, gdyż nawet po ich rozwiązaniu wiedza na temat tego, co się stało i jak zostało to obsłużone, jest istotna. Reprezentację kwestii w systemie stanowi bilet (ang. ticket). Jest on nadawany każdej sprawie i zawiera m.in.: identyfikator, priorytet, opis, aktualny stan postępu, historię postępowania, identyfikatory osób pracujących nad kwestią i zainteresowanych postępami. Zastosowanie biletów znacznie ułatwia zarządzanie kwestiami, upraszczając wyszukiwanie i filtrowanie. Podstawowe funkcjonalności systemów śledzenia biletów to: dodawanie kwestii/ biletów, przypisywanie osób odpowiedzialnych za dany bilet, przypisywanie grupom osób zainteresowanych postępami w danej kwestii, śledzenie zmian w biletach, informowanie o zmianach osób zainteresowanych, inicjowanie czynności na podstawie statusów lub priorytetów biletów, raportowanie o stanie biletów szczegółowo i zbiorczo i zamykanie biletów. Kluczową częścią każdego systemu śledzenia biletów jest baza danych, zawierająca wszystkie informacje na temat zgłaszanych kwestii. Dane te są zarządzane przez wyższe warstwy aplikacji, które muszą gwarantować: dostępność, możliwość jednoczesnego dostępu do danych wielu osób, możliwość śledzenia historii, trwałość zapisów, kontrolę dostępu i możliwość definiowania zależności między zadaniami. Systemy śledzenia biletów mają szczególne zastosowanie w procesie wytwarzania i wspierania oprogramowania. Systemy tego typu przeznaczone do nadzoru nad kodem nazywamy systemami kontroli błędów (ang. bug tracking systems). Ich zadaniem jest ułatwienie programistom dostępu do błędów zgłaszanych w tworzonym przez nich oprogramowaniu oraz pomoc w kontrolowaniu jakości rozwiązań. Systemy kontroli błędów mają zastosowanie także dla użytkowników oprogramowania. Wiele projektów typu opensource posiada ogólnie dostępne bazy odnotowanych błędów, gdzie można sprawdzić, czy napotkany problem jest powiązany z którymś z nich oraz czy deweloper oprogramowania zaproponował już jakieś 161

163 rozwiązanie. Dodatkowo takie rozwiązanie ogranicza w pewnym stopniu ilość zgłoszeń tego samego błędu. W przypadku systemów śledzenia błędów szczególnie ważną informacją, która musi zostać podana w zgłoszeniu, jest opis, jak i kiedy do błędu dochodzi. Osoby rozwiązujące daną kwestię muszą potrafić ponownie wywołać wystąpienie błędu. Bez ustalenia przyczyn powstawania nie jest możliwe wypracowanie dobrego rozwiązania. W systemach śledzenia błędów problemy są zazwyczaj dzielone na klasy ważności (ang. severity levels). W każdym bugtrackerze definiowane są stany, które mogą być przypisane do błędu, oraz możliwe przejścia między nimi. Powstały w ten sposób graf nazywa się cyklem życia błędu. Najczęściej spotykane stany to: niepotwierdzony, nowy, przydzielony, otwarty, rozwiązany, weryfikowany, odroczony, zamknięty. Poniżej omówione są trzy popularne i otwarte systemy śledzenia błędów. Bugzilla ( jest jednym z najbardziej znanych i otwartych systemów śledzenia błędów. Program napisał Terry Weissman dla Fundacji Mozilla w 1998 roku do zarządzania jej projektami. Bugzilla jest zazwyczaj instalowana w środowisku typu Unix lub Linux. Program jest napisany w Perlu i wykorzystuje bazę danych (np. MySQL, Oracle lub PostgreSQL). Bugzilla jest systemem złożonym, o bogatej funkcjonalności. Do jej zalet należą m.in. możliwość prowadzenia wielu projektów, duża elastyczność, wprowadzenia wielu statusów ułatwiających śledzenie błędu, możliwość generowania różnych raportów, zarządzanie uprawnieniami użytkowników, moduł do rejestracji przypadków testowych. Cechą charakterystyczną systemu jest to, że posiada wiele interfejsów, w tym liniowy, owy, webowy i desktopowy. Złożoność Bugzilli jest niejednokrotnie uznawana za jej ograniczenie, gdyż utrudnia i wydłuża wdrożenie. Trac ( jest bugtrackerem napisanym w języku Python i udostępnionym na licencji GPL. System posiada architekturę typu klient server i został zaimplementowany w języku Python. Współpracuje z wieloma bazami danych, w tym MySQL, SQLite i PostgreSQL. Oferuje również możliwość elastycznego dostosowania schematu przepływu błędów. System posiada podstawowy interfejs sieciowy dostępny przez przeglądarkę www. Track udostępnia możliwość integracji z wieloma systemami wersjonowania kodu, w tym CVS, SVN, Git, Mercurial. Poza tym system posiada elementy narzędzia do zarządzania projektem, w tym jego harmonogramem (ang. roadmap), zadaniami oraz etapami (ang. milestones). W porównaniu do Bugzilli jest szybszy, prostszy we wdrożeniu i eksploatacji. Oferuje za to nieco skromniejszą funkcjonalność. Redmine ( jest stosunkowo młodym, lecz dynamicznie rozwijanym i zyskującym dużą popularność systemem do zarządzania błędami i monitorowania postępów projektów. System został zaimplementowany w języku Ruby i cechuje się wysoką wydajnością. Jest zorientowany na pracę w rozproszonym środowisku webowym, a jako podstawowego interfejsu używa przeglądarki www. Redmine pozwala na zarządzanie wieloma projektami i (podobnie jak Trac) udostępnia wbudowany system wiki pozwalający na tworzenie opisów i dokumentacji. Współpracuje z wszystkimi podstawowymi systemami wersjonowania kodu oraz wspiera kilka różnych implementacji systemów bazodanowych do przechowywania informacji. System jest silnie zorientowany na pracę rozproszoną, udostępniając również fora dyskusyjne związane z konkretnymi projektami oraz interfejs użytkownika w wielu językach narodowych. Do jego zalet należą prostota obsługi i elastyczność konfiguracji. 162

164 7.6. Podsumowanie W niniejszym rozdziale omówiono wybrane narzędzia składające się na środowisko wspomagania wytwarzania i utrzymywania oprogramowania [1]. Skupiono się na swobodnie dostępnych narzędziach typu opensource i free software. W ostatnich latach zyskały one na znaczeniu i zdobyły dużą popularność. Powodem tego jest nie tylko ich niska cena (najczęściej koszty są związane tylko z wdrożeniem), lecz przede wszystkim dobra jakość i szybki rozwój. Poza tym ich otwarty charakter często nie wyklucza dostępności komercyjnego wsparcia. Co za tym idzie, są one często wybierane do budowania własnych środowisk programistycznych nie tylko w małych firmach, lecz również w dojrzalszych przedsiębiorstwach z branży IT. Literatura [1] Nalepa G.J.: Środowiska wytwarzania oprogramowania, wykład dla studiów podyplomowych ZPI, AGH, 2011 [2] Eclipse Indigo Documentation System ( The Eclipse Foundation, [3] KDevelop4/Manual ( KDE project, 2011 [4] Tichy W.F.: RCS A System for Version Control, Department of Computer Sciences Purdue University, 1995 [5] Nalepa G.J.: Wprowadzenie do systemów kontroli wersji RCS i CVS, opracowanie własne, 2001 [6] Collins-Sussman B., Fitzpatrick B.W., Pilato C.M.: Version Control with Subversion, O Reilly, 2004 [7] Chacon S.: Why Git is Better than X?,

165