Praca dyplomowa - magisterska

Transkrypt

1 Wydział Informatyki i Zarządzania kierunek studiów: Zarządzanie specjalność: Projekty, Innowacje i Przedsiębiorczość Praca dyplomowa - magisterska WDRAŻANIE METOD ZWINNYCH NA PRZYKŁADZIE ŚREDNIEGO PRZEDSIĘBIORSTWA INFORMATYCZNEGO Aneta Ozierańska krótkie streszczenie: Praca podejmuje tematykę wdrażania metodyki Scrum do zarządzania projektem informatycznym. słowa kluczowe: zarządzanie projektami metody zwinne metodyka Scrum opiekun pracy dyplomowej Prof. Dr Hab. Inż. Dorota Kuchta Tytuł/stopień naukowy/imię i nazwisko ocena podpis Do celów archiwalnych pracę dyplomową zakwalifikowano do:* a) kategorii A (akta wieczyste) b) kategorii BE 50 (po 50 latach podlegające ekspertyzie) * niepotrzebne skreślić Wrocław 2015 pieczątka wydziałowa

2

3 Spis treści WSTĘP Kontekst teoretyczny pracy Wstęp Podejście zwinne Źródła i geneza powstania podejścia O podejściu zwinnym Scrum przykładem metodyki zwinnej Pojęcie Scrum Źródła i historia powstania Filozofia Scrum Proces Role Zdarzenia Artefakty Scrum a podejście zwinne Problematyka implementacji metod zwinnych Implementacja metodyk zwinnych w literaturze Klasyfikacja czynników mających wpływ na wdrażanie metod zwinnych Zakończenie Studium przypadku wdrażania Scrum Wstęp Charakterystyka przedsiębiorstwa Informacje ogólne Charakterystyka otoczenia Ewolucja struktury i metod zarządzania Charakterystyka zespołu Sieci Wstęp Cele i technologia Struktura i ludzie Otoczenie Dziennik wdrażania metodyki Scrum w zespole Sieci Wstęp Sprint 0 początki zespołu Sprint 1 pierwsze tygodnie Scruma... 43

4 2.4.4 Sprint 2 początki zmian Sprint 3 etap dojrzewania Sprint 4 poważne zmiany Czynniki mające wpływ na wdrażanie metodyki Scrum - analiza Wstęp Kategoria 1: Organizacja Zespołu Projektowego Kategoria 2: Aspekty Psychologiczne i Kulturowe Kategoria 3: Proces oraz Metoda Kategoria 4: Otoczenie Kategoria 5: Technologia Zakończenie Rekomendacje dotyczące wdrażania Scrum Wstęp Problemy wdrożeniowe Wstęp Utworzenie zespołu Scrumowego Prawidłowe wdrożenie procesu Korzystanie z narzędzi metodyki Techniki wdrożeniowe ZAKOŃCZENIE BIBLIOGRAFIA SPIS TABEL SPIS ILUSTRACJI ZAŁĄCZNIKI Załącznik Tabela 1. Czynniki mające wpływ na wdrażanie metodyki Scrum Tabela 2. Problemy wdrożeniowe Tabela 3. Wpływ czynników na pojawienie się problemów wdrożeniowych Tabela 4. Rekomendacje wdrożeniowe Załącznik Rysunek 1. Schemat struktury organizacyjnej Numergy

5 STRESZCZENIE Dynamiczny rozwój sektora IT powoduje, że tradycyjne metody zarządzania okazują się niewystarczające, aby nadążyć za innowacyjnymi technologiami i burzliwymi zmianami w otoczeniu. Metody zwinne zarządzania projektami zostały zaprojektowane tak, aby odpowiedzieć na wysokie wymagania sektora. Niniejsza praca podejmuje tematykę wdrażania metod zwinnych do zarządzania projektem informatycznym. Jej zasadniczym celem było sformułowanie rekomendacji dotyczących wdrażania tych metod. Zostały przeprowadzone badania literaturowe oraz terenowe (obserwacje i wywiady w przedsiębiorstwie). Wynikiem badań było wskazanie czynników mających wpływ na wdrażanie metodyki zwinnej Scrum. Analiza tych czynników doprowadziła do sformułowania problemów wdrożeniowych. Zasadniczym wnioskiem z tej analizy było stwierdzenie, że każdy z problemów wdrożeniowych powstaje przez oddziaływanie wielu czynników. Na koniec pracy zostały przedstawione techniki i praktyki wdrożeniowe mające na celu eliminowanie wpływu tych czynników, a w rezultacie unikanie problemów implementacyjnych. ABSTRACT Due to the dynamic growth of the IT sector the performance of traditional management methods cease to be sufficient to make up with the rapid changes in the technology and organizational environment. The Agile methods were designed to respond to the challenges of the IT sector. This paper concentrates on Agile methods implementation in IT project. The aim of the study was to formulate the recommendations to effectively implement these methods. Based on existing literature and the case study (observations and interviews in an enterprise), a list of factors having impact on Scrum (one of the agile methods) implementation was identified. The analysis of the above factors made it possible to formulate a list of problems that may happen when Scrum is implemented. The results revealed that each problem has multiple possible sources. The list of recommendations aims to associate each factor influencing Scrum implementation with the technique to avoid it. As a result, the set of recommendations was proposed in order to evade the problems.

6 WSTĘP Niniejsza praca podejmuje tematykę wdrażania metod zwinnych zarządzania projektami informatycznymi. Temat odnosi się przede wszystkim do nauk o zarządzaniu, ale nawiązuje również do inżynierii oprogramowania (zagadnienie przedsięwzięcia informatycznego) oraz psychologii (opory przed wdrażaniem). U źródeł powstania pracy leży zainteresowanie jej autora podejściem zwinnym do zarządzania. Idee oraz wartości propagowane przez twórców i praktyków tego podejścia spowodowały rewolucję w myśleniu o zarządzaniu [6]. Entuzjazm przedstawicieli środowisk naukowych [25, s.327] oraz praktyków zarządzania [5] przyczynił się do rozprzestrzenienia się zwinnych metod zarządzania we wszystkich typach przedsiębiorstw. Wraz ze wzrostem złożoności otoczenia biznesu oraz dynamicznym rozwojem technologii, klasyczne metody zarządzania stały się coraz mniej przydatne, a wdrożenie innowacyjnych metod zwinnych okazało się niezbędne po to, aby uzyskać przewagę konkurencyjną. 1 Fenomen podejścia zwinnego polega również na jego niesłabnącej popularności już od ponad czterdziestu lat. Uwagę autora niniejszej pracy przyciągnęło pytanie, skąd tak zaskakująca aktualność tego pojęcia w tak długim czasie od jego powstania. Sam wybór metody zarządzania nie jest wystarczający do osiągnięcia sukcesu menedżerskiego. Niezbędne jest również jej sprawne wdrożenie w przedsiębiorstwie. Implementacja metod zwinnych wymaga spojrzenia na wiele aspektów [25, s.556]. Na powodzenie wdrażania mają wpływ zarówno czynniki techniczne, dotyczące procesu oraz narzędzi projektowych, jak i psychologiczno-kulturowe, takie jak opory przed wdrażaniem oraz dotyczące kultury organizacyjnej oraz stylu menedżerskiego [4]. Dodatkowym elementem stanowiącym o atrakcyjności tematu dla autora tej pracy jest znaczenie projektu informatycznego we współczesnym świecie biznesu. Podczas gdy rola sektora technologii informacyjnych dla gospodarki na świecie rośnie, jego wydajność słabnie [13]. Aby zapewnić warunki dla rozwoju sektora IT, potrzebne są szybkie innowacje w dziedzinie zarządzania w informatyce [13]. W powyżej przedstawionym kontekście sprawne wdrożenie innowacyjnych metod zarządzania, takich jak zwinne, może się przyczynić do zwiększenia wydajności przedsiębiorstw mających kluczowe znaczenie dla gospodarki. Pytanie, jak powinno się wdrażać metody zwinne w najefektywniejszy sposób, przyczyniło się do sformułowania celu niniejszej pracy: Celem pracy jest sformułowanie rekomendacji dotyczących wdrażania metod zwinnych do zarządzania projektem informatycznym. Zastosowana metoda badań w tej pracy to obserwacje oraz wywiady przeprowadzone w przedsiębiorstwie. Okres obserwacji obejmuje cztery miesiące (od czerwca do września 2014 roku). Obiektem badań jest przedsiębiorstwo informatyczne należące do sektora małych i średnich przedsiębiorstw. W sposób szczegółowy badaniom został poddany zespół architektury i bezpieczeństwa sieci. Praca składa się z trzech głównych etapów, tak jak zostało to zaprezentowane na Rysunku 1 oraz opisane poniżej. Pierwszy rozdział pracy przedstawia aktualny stan wiedzy na temat metod zwinnych zarządzania oraz zagadnień implementacyjnych tych metod. Badania literaturowe, będące 1 Dla ponad 70% projektów zwinne metody zarządzania są najlepszym rozwiązaniem, według [25] 1

7 podstawą do powstania rozdziału, dotyczyły publikacji zwartych i ciągłych. Na koniec rozdziału zostało przedstawione narzędzie stworzone na potrzeby późniejszej analizy czynników wpływających na implementację metod zwinnych. Część praktyczna pracy została zawarta w rozdziale drugim. Opis przedsiębiorstwa wraz z najważniejszymi elementami jego otoczenia, a także szczegółowa analiza jednego z zespołów z wybranej firmy stanowią wstęp do studium przypadku. Następnie rozdział zawiera wyniki badań, czyli dziennik obserwacji w przedsiębiorstwie oraz informacje uzyskane poprzez wywiady. Rozdział ma na celu zidentyfikowanie czynników wpływających na powodzenie implementacji metod zwinnych. W ostatnim etapie został zrealizowany właściwy cel pracy. Rozdział trzeci zawiera listę zaleceń dotyczących technik i praktyk implementacyjnych metod zwinnych zarządzania w projekcie informatycznym. Rekomendacje zostały sformułowane na podstawie wyników analizy z końca rozdziału drugiego.. Analiza teoretyczna: Stan wiedzy na temat: - podejścia zwinnego; - konkretnej metodyki; - wdrażania metodyk zwinnych. Studium przypadku: Obserwacje i wywiady w przedsiębiorstwie informatycznym Analiza wyników Synteza: Sformułowanie: - problemów wdrożeniowych; - rekomendacji dotyczących wdrażania metod zwinnych w przedsiębiorstwie informatycznym. Rysunek 1. Schemat metody badań w niniejszej pracy Źródło: Opracowanie własne 2

8 1 Kontekst teoretyczny pracy 1.1 Wstęp Aby zrozumieć istotę zagadnień poruszanych w tej pracy, niezbędne jest wprowadzenie kluczowych dla tematyki pojęć. W niniejszym rozdziale został przedstawiony kontekst teoretyczny metod zwinnych ogólnie, metodyki implementowanej w badanym przedsiębiorstwie, a także zagadnienia dotyczące wdrażania zarządzania zwinnego. W pierwszej kolejności został nakreślony kontekst powstania podejścia zwinnego, filozofia, z której się wywodzi, a także jego główne założenia. Dalsza część zawiera szczegółowy opis metodyki Scrum. To właśnie ta metodyka została wdrożona w badanym przedsiębiorstwie (Rozdział 2). Zapoznanie się z elementami charakterystycznymi Scruma, specyficznym żargonem z nim związanym oraz wartościami, do których się odwołuje pozwolą Czytelnikowi na zrozumienie zagadnień opisywanych w części praktycznej. Rozdział zakończy przegląd stanu wiedzy na temat implementacji metod zwinnych. W szczególności zostaną przedstawione narzędzia służące do analizy czynników wpływających na powodzenie wdrażania metod zwinnych. 1.2 Podejście zwinne Źródła i geneza powstania podejścia Chociaż wiele metod zarządzania projektami dziś jest uważanych za uniwersalne, nie należy zapominać, że pierwotnie były dedykowane jedynie środowiskom programistycznym. W odpowiedzi na dynamiczny rozwój technologii komputerowej, w latach 60-tych powstała dziedzina zajmująca się procesami wytwarzania produktów i usług informatycznych 2. Inżynieria oprogramowania zrodziła się z przekonania o niemożności stosowania cyklów życia projektu znanych z innych dziedzin na potrzeby tworzenia oprogramowania [30, s.11]. Cykl życia projektu (lub cykl wytwarzania) to nic innego, jak zbiór procesów prowadzących do produkcji danego produktu lub usługi, począwszy od określenia zakresu projektu, przez procesy planowania i rozpoczęcia prac produkcyjnych, monitorowanie, aż do wdrożenia i ewolucji produktu powstałego w cyklu projektowym [25, s.40]. Z cyklem życia projektu w sposób ścisły jest związana metoda zarządzania. Modele zarządzania projektu różnią się przede wszystkim szkieletem procesu wytwarzania. Tradycyjne modele zarządzania projektami opierają się na liniowym cyklu wytwarzania, natomiast podejście zwinne zakłada cykl adaptacyjny i iteracyjny [25, s.40]. Tradycyjnie cykl wytwarzania produktu był podzielony na następujące po sobie i zależne od siebie fazy. Liniowość procesu polega na istnieniu zależnościach sekwencyjnych pomiędzy fazami. Schemat oraz typowe etapy cyklu wytwarzania w podejściu linowym (wraz ze stanowiskami za nie odpowiedzialnymi) zostały przedstawione na Rysunku 2. 2 Pojęcie inżynierii oprogramowania pojawiło się po raz pierwszy na konferencji w 1968 roku [30]. 3

9 Faza koncepcji Testy wykonalności Projektowanie produktu Pilotowanie produkcji Ostateczna produkcja Marketing Specjaliści funkcjonalni Inżynierowie B&R Inżynierowie produkcji Inzynierowie produkcji Rysunek 2. Tworzenie produktu: podejście liniowe Źródło: Takeuchi H., Nonaka I., The New New Product Development Game, Harvard Business Review 1986, nr 1. Zaletą podejścia liniowego jest przewidywalność procesu, a tym samym dat zakończenia projektu. Wraz z rozpoczęciem cyklu znane są specyfikacje projektu, a ich zmiana nie jest możliwa aż do jego zakończenia. Dzięki temu przy zatwierdzaniu specyfikacji projektu można w sposób dokładny przewidzieć szczegóły oraz datę dostarczenia produktu. W latach 70-tych zauważono, że w dynamicznie zmieniającym się otoczeniu przedsiębiorstw podejście liniowe przestaje być efektywne [6]. Spośród warunków, w których zrodziła się potrzeba poszukiwania alternatywnej metody zarządzania, można wymienić najważniejsze [9, 12, 16]: rozprzestrzeniający się rynek masowy oraz indywidualizacja potrzeb klienta masowego; dynamiczny rozwój technologii informacyjnych; globalizacja procesów produkcji oraz tworzenie globalnych sieci dystrybucji; rosnąca konkurencja (także w związku z globalizacją rynków); powstanie pojęcia produktu informatycznego (na granicy klasycznie zdefiniowanego produktu i usługi); pojawienie się mody menedżerskiej na partycypacyjne zarządzanie ludźmi. Wymienione elementy mają dwa zasadnicze skutki: otoczenie przedsiębiorstwa staje się coraz bardziej złożone a specyfikacje dotyczące produktu oczekiwanego przez rynek stają się niemożliwe do ustalenia we wczesnych fazach projektu. Wobec powyższych zjawisk, przedsiębiorstwa chcące uzyskać przewagę konkurencyjną muszą przystosować procesy wytwarzania produktu, aby można było szybko i elastycznie reagować na zmiany w otoczeniu oraz umożliwić wprowadzanie zmian w specyfikacjach produktowych [16]. Tradycyjna metoda zarządzania projektami nie jest dostosowana do tego, aby spełnić wyżej sformułowane wymagania. Niezbędne okazało się zaprojektowanie alternatywnego cyklu życia projektu, opartego na procesach adaptacyjnych oraz iteracjach. Metody opierające się na tak zdefiniowanym cyklu należą do podejścia zwinnego. 4

10 1.2.2 O podejściu zwinnym Podejście zwinne powstawało w sposób ewolucyjny, a jego tematyką zajmowało się jednocześnie wiele osób. Jego ścisłe zdefiniowanie nie jest możliwe 3. Zamiast definicji, w poniższych akapitach zostaną nakreślone podstawowe założenia oraz wartości, do których odwołuje się koncepcja zarządzania zwinnego. Jednym z pierwszych źródeł formalizujących podejście zwinne (wtedy znane jako holistyczne) jest artykuł The New New Product Development Game [23]. Jego autorzy wskazują na niedoskonałości podejścia liniowego, tym samym proponując alternatywną metodę zarządzania. W przeciwieństwie do tradycyjnego modelu zarządzania projektami (Rysunek 2), nowa metoda polega na wykluczeniu zależności sekwencyjnych pomiędzy etapami i połączeniu wszystkich faz w jeden proces trwający przez cały okres projektu (Rysunek 3). Cykl życia projektu zostaje podzielony na części, zwane iteracjami. To pojęcie wywodzi się z języka programistycznego i oznacza wielokrotne powtarzanie tego samego procesu. Przełożone na język zarządzania projektami, określa krótkie okresy kończące się dostarczeniem działającej części produktu. adaptacja adaptacja iteracja iteracja iteracja Rysunek 3. Tworzenie produktu: podejście holistyczne Źródło: Opracowanie własne na podstawie Takeuchi H., Nonaka I., The New New Product Development Game, Harvard Business Review 1986, nr 1. Kiedy artykuł pojawił się w Harvard Business Review (1986), koncepcje zwinne zarządzania były już stosowane w praktyce. NEC, Epson, Brother, 3M, Xerox i Hewlett- Packard to przedsiębiorstwa, które mogły się pochwalić implementacją metod zwinnych już od 1976 roku [23]. Oprócz powyżej cytowanych teoretyków oraz przedsiębiorstw, tematyką podejścia zwinnego zajmowało się jednocześnie wiele innych osób. W literaturze spotykamy się z wieloma pozycjami, które opisują cykl życia projektu charakterystyczny dla podejścia zwinnego. 3 A także podjęcie próby zamknięcia koncepcji zwinnych w sztywnych ramach definicji pozostawałoby w sprzeczności z filozofią, z której się wywodzą. 5

11 Zasady, do których większość autorów się odwołuje to [23, 16, 12, s.xi]: proces projektowy umożliwiający zmiany w produkcie na każdym etapie cyklu wytwarzania oraz dający częste okazje do kontaktu z klientem projektu, kultura organizacyjna oparta na zaufaniu i współpracy. Według takiego podejścia cykl wytwarzania musi być dostosowany do wprowadzania zmian w specyfikacjach projektu. Oznacza to, że wygląd lub funkcjonalności dostarczonego produktu mogą się różnić w stosunku do założeń. Dzieje się tak, ponieważ w czasie trwania prac nad produktem wymagania otoczenia mogą się zmienić. Również zespół projektowy ma zdolność uczenia się, a więc może odkryć w trakcie projektu, że niektóre elementy specyfikacji nie są adekwatne do wymagań klienta lub technologii. Aby umożliwić procesy adaptacyjne, niezbędne jest zbudowanie procesu opartego na częstym kontakcie z klientem. Dzięki iteracjom, na koniec których dostarcza się działającą wersję produktu, zespół ma okazję skonfrontować dotychczasowy wynik prac z faktycznymi oczekiwaniami klienta. Łatwo zauważyć, że w tak skonstruowanym cyklu życia projektu nie jest możliwe precyzyjne ustalenie w początkowych fazach projektu, jak będzie wyglądał produkt końcowy. Podejście zwinne charakteryzuje się również innym niż w podejściu tradycyjnym stylem zarządzania ludźmi. Elementem kluczowym dla powodzenia projektu zwinnego jest stworzenie zespołu projektowego, który jest w dużym stopniu samodzielny. Zespół tworzy własny plan działania i organizacji pracy, ma prawo do inicjatyw, ma wpływ na wygląd produktu oraz ponosi odpowiedzialność za swoje działania. Oprócz tego, powinien składać się z członków o różnorodnych kompetencjach, a także współpracować z przedstawicielami innych działów przedsiębiorstwa na każdym etapie rozwoju produktu. Styl zarządzania preferowany w podejściu zwinnym jest oparty na zaufaniu i minimalnej interwencji w pracę zespołu. Sformalizowanie podejścia zwinnego jako grupy metod zarządzania, miało miejsce wiele lat po rozpoczęciu rozważań na jego temat, bo dopiero w roku 2001 [19]. Wtedy został sformułowany Manifest Zwinnego Tworzenia Oprogramowania [28]. Manifest (Rysunek 4) w sposób syntetyczny podsumowuje wartości, do których odwołuje się siedemnaście metodyk, których autorzy podpisali się pod dokumentem: Programowanie Ekstremalne (Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries), Scrum (Ken Schwaber, Jeff Sutherland, Mike Beedle), Metoda DSDM (Arie van Bennekum), Crystal (Alistair Cockburn), Adaptive Software Development (Jim Highsmith), Feature-Driven Development (Jon Kern), Booch Method (Robert C. Martin), Pragmatic Programming (Dave Thomas, Andrew Hunt), Inne (Brian Marick, James Grenning, Steve Mellor) [28]. Powyższe metodyki różnią się na poziomie konkretnych technik oraz narzędzi. Jednak, niezależnie od stosowanych praktyk, wszystkie bazują na kilku założeniach charakterystycznych dla podejścia zwinnego. Manifest jest wyrazem filozofii, wspólnej dla wszystkich powyższych autorów. Podsumowuje już wcześniej omawiane wartości, do których odwołuje się podejście zwinne. Według manifestu, w projektach programistycznych istotniejsze jest budowanie relacji i dobrych stosunków pomiędzy ludźmi niż skupianie się na wytycznych dotyczących procesów i narzędzi zarządzania. Oprócz tego, priorytetem jest dostarczanie działającego oprogramowania ponad tworzenie dokumentacji. Kolejny postulat 6

12 manifestu podkreśla potrzebę współpracy pomiędzy zespołem a klientem, zamiast opierać relację pomiędzy nimi jedynie na formalnych ustaleniach, takich jak umowy, czy kontrakty. Ostatni punkt odnosi się do podstawowej wartości podejścia zwinnego, jaką jest adaptacyjność. Manifest podkreśla, że zmianę należy niejako wpisać w plan projektu. Manifest Zwinnego Tworzenia Oprogramowania Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy: Ludzi i interakcje ponad procesy i narzędzia. Działające oprogramowanie ponad obszerną dokumentację. Współpracę z klientem ponad formalne ustalenia. Reagowanie na zmiany ponad podążanie za planem. Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej. Rysunek 4 Manifest Zwinnego Tworzenia Oprogramowania Źródło: Manifesto for Agile Software Development, [ dostęp W celu podsumowania rozważań na temat, czym jest podejście zwinne, w poniższej tabeli zostało przedstawione porównanie kluczowych elementów koncepcji zarządzania zwinnego w kontekście tradycyjnego podejścia do zarządzania projektami. Tabela 1. Porównanie podejścia tradycyjnego i zwinnego Podejście tradycyjne Podejście zwinne Cykl życia projektu: Liniowy Iteracyjny Zakres projektu: Kontakt z klientem: Możliwość adaptacji: Zespół: Ustalony na początku projektu pozostaje niezmienny do jego końca Przed i po zakończeniu projektu Brak Na każdym etapie projektu interweniują specjaliści z innych dziedzin 7 Ewoluuje wraz z projektem Po każdej iteracji w ciągu całego cyklu projektu Po każdej iteracji w ciągu całego cyklu projektu Niewielki, samoorganizujący się i autonomiczny

13 Styl zarządzania: Rozkaz i kontrola Zaufanie i minimalna interwencja Źródło: Opracowanie własne na podstawie Wysocki R.K., Effective Project Management. Traditional, Agile, Extreme. John Wiley & Sons, Inc., 2014, s Scrum przykładem metodyki zwinnej Pojęcie Scrum 4 Przed rozpoczęciem opisywania genezy oraz struktury Scruma, warto byłoby przybliżyć, czym właściwie jest Scrum. Autorzy tej koncepcji, praktycy oraz środowiska naukowe nie są zgodni już na poziomie samego zdefiniowania, do jakiej kategorii należy. Według różnych autorów, Scrum jest: środowiskiem [12]; ramami postępowania [21, s.3]; procesem [22]. Niechęć autorów do przypisania Scruma do kategorii metod zarządzania (metodologii, metodyki lub techniki) jest spowodowana unikaniem porównań do tradycyjnych metod, opartych na sztywnych zasadach [12, s.xi]. Wciąż podkreślając źródła oraz wartości, na których oparta jest idea metodyk zwinnych, w literaturze preferuje się określenia mniej precyzyjne, czyli Scruma jako środowiska zawierającego praktyki i techniki zarządzania, (które jednak nie wyznacza sztywnych ram postępowania). Pomimo powyżej opisanego sporu, Scrum spełnia definicję metodyki zarządzania projektami i tworzenia oprogramowania [24, s.75]. Określa rekomendowane praktyki, zasady postępowania oraz techniki, których zastosowanie w środowisku programistycznym albo projektowym może potencjalnie dostarczyć korzyści. Jeden z teoretyków Scruma, Jim Highsmith, podkreśla, że o ile określanie Scruma metodyką jest poprawne, o tyle ciekawsze z punktu widzenia koncepcji zwinnych jest unikanie prób zamykania jej w ścisłych definicjach. Scrum oznacza zmianę kultury organizacyjnej oraz przedefiniowanie relacji międzyludzkich oraz przywództwa w przedsiębiorstwie. Bez zmian w mentalności organizacji nie można mówić o Scrumie, nawet jeżeli przestrzega się wszystkich jego zasad [12, s.xi]. Z tego punktu widzenia, nazwanie go metodyką byłoby błędne. Niniejsza praca nie ma jednak na celu wzięcia udziału w sporze dotyczącym definicji Scruma, a zatem w kolejnych rozdziałach, pomimo powyżej przedstawionych niejasności, określenie metodyka będzie używane w sposób umowny, w kontekście Scruma Źródła i historia powstania Pierwsze wzmianki o podejściu do zarządzania projektami, mającym cechy charakterystyczne metodyki dziś znanej pod nazwą Scrum, zaczęły pojawiać się w latach osiemdziesiątych. W już cytowanym artykule, The New New Development Game [23], został opisany szkielet oraz elementy charakterystyczne dla tej metodyki. Autorzy odnieśli te elementy do jednej z figur gry sportowej rugby, której nazwa dziś jest kojarzona z jedną z najpopularniejszych metodyk zwinnych (scrum, z ang. młyn) [19, s.5]. W latach dziewięćdziesiątych metodyka Scrum została sformalizowana. Ken Schwaber oraz Jeff Sutherland wspólnie ją zaprezentowali w roku 1995 [20]. Pierwotnym źródłem 4 W niniejszej pracy słowo Scrum będzie odmieniane według form używanych w oficjalnym Przewodniku po Scrumie [21]. 8

14 wiedzy o Scrumie jest przewodnik napisany przez nich. Krótki, bo 16-stronicowy dokument zawiera definicję metodyki lub reguły gry, jak sugeruje podtytuł (ang. The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game) [21]. Według przytoczonego dokumentu Scrum nie jest techniką ani procesem zarządzania samymi w sobie, ale strukturą wyznaczającą ramy, w których można stosować różne procesy lub techniki po to, aby tworzyć produkty. Można je stosować w projektach o różnej wielkości, specyfice oraz wymaganiach jakościowych. Są jednak rekomendowane w szczególności dla projektów o wysokim stopniu skomplikowania i warunkach dużej niepewności. W podręczniku znajdują się rekomendowane zasady oraz praktyki związane z metodyką. Twórcy podkreślają jednak, że konkretne techniki są zależne od projektu, a zatem implementacje Scruma różnią się od siebie w zależności od specyfiki zespołu. Szczegółowe opisy metodyki znajdują się w kilku dokumentach źródłowych opublikowanych przez jej autorów w różnych okresach. 5 Przewodnik po Scrumie pozostaje jednak dokumentem podstawowym i to właśnie on posłużył jako podstawowe źródło informacji w poniższych podrozdziałach (oraz częściowo podręcznik Kena Schwabera [22]) Filozofia Scrum Przed opisaniem i zdefiniowaniem wszystkich elementów struktury Scruma, należy przede wszystkim podkreślić, na jakich wartościach opiera się ta metodyka. Wszystkie elementy procesu, które zostaną przedstawione później w tym rozdziale, są podporządkowane tym wartościom. Filarem Scruma jest empiryzm. Metodyka opiera się na empirycznej kontroli procesu. W tym podejściu zakłada się, że wiedza pochodzi z doświadczenia, a decyzje powinno podejmować się na podstawie tego, co się wie [21, s.3]. Proces empiryczny jest koncepcją przeciwstawną do procesu zdefiniowanego. Jak twierdzi jeden z autorów metodyki (Ken Schwaber), jednym z podstawowych powodów porażki niektórych projektów jest filozofia, która leży u podstaw systemów zarządzania [12, s.132]. W warunkach kompleksowego otoczenia wielu rzeczy nie jest się w stanie przewidzieć, zatem błędne jest założenie, że wszystkie parametry projektu powinny zostać zdefiniowane przed jego rozpoczęciem. s.4]: Proces kontroli empirycznej jest zdefiniowany przez trzy podstawowe wartości [21, przejrzystość; inspekcję; adaptację. Pierwsza z nich odnosi się do przekonania, że kluczowe elementy procesu powinny być łatwo dostępne dla osób odpowiedzialnych za proces. Dostępność jest rozumiana zarówno w aspekcie fizycznym, jak również przez tożsame zrozumienie elementów przez wszystkie zainteresowane podmioty. Przejrzystość umożliwia proces inspekcji, który ma za zadanie wykrycie ewentualnych anomalii, mogących zagrażać osiągnięciu celu danej części projektu. Istotne jest, aby odchylenia były identyfikowane już na jak najwcześniejszych etapach projektu. Bezpośredni związek z inspekcją ma adaptacja. Jeśli zostanie zidentyfikowany problem lub punkt wymagający ulepszeń, należy natychmiast podjąć działania naprawcze i adaptacyjne. 5 Przede wszystkim [21, 22] 9

15 Aby zapewnić sprawne działanie powyższych funkcji procesu empirycznego, niezbędne jest umieszczenie w procesie wytwarzania produktu narzędzi ich umożliwiających. Narzędzia te zostały opisane w kolejnych podrozdziałach. Trzeba sobie jednak uświadomić, że o ile zasady Scruma są łatwe w zrozumieniu, o tyle ich implementacja stawia wysokie wymagania zespołowi, w którym metodyka jest wdrażana oraz jego otoczeniu. Wszystko wynika z faktu, że wdrożenie metodyki nie jest możliwe bez zrozumienia filozofii za nią stojącej oraz bez dokonania fundamentalnych zmian w kulturze organizacyjnej przedsiębiorstwa [22] Proces Szkielet procesu tworzenia produktu w Scrumie jest oparty na iteracjach i przyroście inkrementalnym produktu [22, s.15]. Te dwie cechy mają na celu umożliwienie procesów adaptacji. Liczba okazji, w których można otrzymać istotną informację zwrotną od klienta, jest maksymalizowana. Można mówić o istotności tej informacji w przypadku, gdy użytkownik ma szansę manipulować funkcjonalnością produktu, dlatego niezbędne jest ich stopniowe narastanie podczas całego czasu trwania projektu. Stąd pojęcie przyrostu inkrementalnego, który oznacza, że na koniec każdej iteracji produkt powinien być działający 6. Feedback (z ang. informacja zwrotna) użytkownika jest podstawą do wprowadzania zmian. Iteracje w Scrumie są to krótkie (do 30 dni) okresy o stałej długości, na które podzielony jest projekt. W słowniku metodyki nazywają się one Sprintami. Zakłada się powtarzalność ogólnej struktury każdego Sprintu (Rysunek 5). Mechanizm procesu tworzenia produktu w Sprincie można opisać w następujący sposób. Dane wejściowe projektu (wymagania projektu) są zawarte w Product Backlogu (z ang. lista rzeczy do zrobienia, dotyczących produktu). Elementy w nim zawarte zasilają Sprint Backlog (z ang. lista rzeczy do zrobienia w Sprincie), według ustalonego celu Sprintu. Podczas iteracji zespół wykonuje zadania ze Sprint Backlogu. Suma skompletowanych zadań ze Sprint Backlogu tworzy przyrost (z ang. increment; nowa, działającą funkcjonalność) produktu (dane wyjściowe procesu). W strukturę Sprintu wpisane są małe iteracje (trwające jeden dzień), rozpoczynane zdarzeniem Daily Scrum (z ang. codzienny Scrum) [22, s.15]. 6 Innymi słowy powinien być dostarczony w takiej formie, aby klient mógł go w jakiś sposób obsłużyć. 10

16 Rysunek 5. Schemat procesu Scrum Źródło: Opracowanie własne na podstawie: Schwaber, K., Sutherland, J., The Scrum Guide. The Definitive Guide to Scrum: The Rules of Game, 2013, s.4. 11

17 Proces Scrum jest ciągły, a jego silnikiem jest Product Backlog. Proces trwa do momentu, kiedy jest zasilany przez elementy zawarte w Product Backlogu. W procesie Scruma, otrzymuje się wiele okazji do inspekcji i adaptacji. Na koniec każdego ze Sprintów można przeprowadzić analizę pracy, która została wykonana, jej jakości oraz produktywności zespołu (inspekcja). Działający element produktu, dostarczany na koniec każdej iteracji, może zostać zaprezentowany klientowi po to, aby uzyskać informację zwrotną (inspekcja). Na początku każdego ze Sprintów dokonuje się uaktualnienia zawartości oraz priorytetów Product Backlogu (adaptacja). Raz dziennie zespół zbiera się podczas Daily Scrum w celu wykrycia ewentualnych anomalii zagrażających osiągnięcie celu Sprintu (inspekcja i adaptacja). W tak sformułowanym procesie niezbędne jest wprowadzenie zdarzeń, ról oraz narzędzi umożliwiających jego funkcjonowanie Role Zespół Scrumowy Zespół Scrumowy składa się z Product Ownera (z ang. właściciel produktu), Scrum Mastera (z ang. mistrz młyna) i Development Teamu (z ang. zespół deweloperski) 7. Celem nadrzędnym zespołu jest zapewnienie, że działająca wersja produktu jest zawsze dostępna do wglądu dla klienta. Organizacja pracy wewnątrz zespołu jest pozostawiona jego członkom, na których spoczywa odpowiedzialność decyzji, w jaki sposób osiągnąć założenia projektu (zdolność samoorganizowania się). Zespół jest samowystarczalny, czyli posiada wszystkie umiejętności niezbędne do wykonania zadań z Product Backlogu (autonomiczność) Product Owner Pierwszą z omawianych ról w zespole Scrumowym jest Product Owner, czyli właściciel produktu. Jego głównym zadaniem jest zarządzanie Product Backlogiem (patrz ), według poniższych zasad. Elementy Product Backlogu muszą być jasno i precyzyjnie wyrażone. Priorytety powinny być wyznaczone tak, aby cel i misja projektu zostały osiągnięte w jak najefektywniejszy sposób. Wartość pracy zespołu (jakość i liczba wykonanych zadań) powinna być jak najwyższa. Product Backlog powinien być dostępny, zawsze aktualny oraz zrozumiały dla wszystkich stron zainteresowanych. Rola Product Ownera jest kluczowa dla wymagań funkcjonalnych projektu. Wszystkie sugestie zmiany lub aktualizacji elementów specyfikacji produktowych muszą zostać zweryfikowane przez Product Ownera i to on ma całkowitą władzę nad tym, co i w jakiej formie znajdzie się w Product Backlogu. 7 Ponieważ przewodnik zaleca korzystać z oryginalnego nazewnictwa, przyjęło się nie tłumaczyć angielskich nazw elementów metodyki. 12

18 Scrum Master Drugą z ról określonych w Scrumie jest Scrum Master. Ma on za zadanie zapewnienie, że cały zespół utożsamia się z teorią, praktykami i zasadami Scruma oraz że wartości i zasady metodyki są jasne dla wszystkich osób z zespołu. Rola Scrum Mastera polega przede wszystkim na maksymalizowaniu wartości ze stosowania metodyki Scrum. Można by pokusić się o przyrównanie tej roli do managera projektu. Autorzy metodyki Scrum woleli jednak podkreślić fundamentalne różnice w postrzeganiu lidera w podejściu zwinnym w porównaniu z tradycyjnym zarządzaniem: autorytet Scrum Mastera wynika z jego umiejętności ułatwiania procesu wytwarzania produktu, a nie pozycji hierarchicznej w przedsiębiorstwie, Scrum Master stwarza warunki do autonomicznej pracy zespołu, zamiast stosować zasadę rozkazu i kontroli, jego relacje z zespołem opierają się na zasadach współpracy i zaufania, a nie formalnego kontraktu [22, s.31]. Scrum Master pozostaje liderem zespołu, jednak w kontekście innej filozofii przywództwa, niż klasyczny manager projektu Development Team Zespół techniczny ma za zadanie tworzenie przyrostu funkcjonalności produktu i jego regularne dostarczanie na koniec każdej iteracji. Development Team funkcjonuje w sposób autonomiczny (w sensie organizacji i zarządzania) i jest odpowiedzialny za wynik swojej pracy jako zespół (indywidualni członkowie nie są rozliczani z wykonanych zadań osobno). Nie jest możliwe tworzenie podgrup w Development Teamie, a jej członkowie tracą indywidualne tytuły (określające domeny ich specjalizacji), zyskując prosty przydomek dewelopera. 8 Optymalna wielkość zespołu to od 3 (minimum, aby uzyskać korzyści z interakcji) do 9 osób (maksimum, po którym koordynacja procesu empirycznego staje się zbyt skomplikowana). Zespół sam ustala sposób organizacji pracy (rozdzielenie zadań, rozplanowanie zadań w czasie, etc.), a także jest odpowiedzialny za ustalenie ile zadań z Product Backlogu jest w stanie wykonać podczas Sprintu, (jeżeli Development Team nie zgodzi się na wykonanie pewnych elementów z Product Backlogu podczas Sprintu, nikt nie ma nad nim władzy, aby go do tego zmusić) [22, s.89] Zdarzenia Sprint Zdarzenia w Scrumie mają na celu stworzenie wrażenia pozytywnej rutyny. To właśnie te elementy sprawiają, że proces Scruma, choć nieprzewidywalny i niepowtarzalny, posiada minimum struktury, która chroni zespół przed chaosem. Ramą dla wszystkich zdarzeń jest Sprint, czyli iteracja w Scrumie. Sprint jest skończonym okresem, podczas którego pewne elementy pozostają niezmienne (głównie cel Sprintu). Warunkiem istnienia Sprintu jest zdefiniowanie jego celu, struktury oraz elastycznego planu, który jest linią przewodnią do osiągnięcia celu. 8 W języku angielskim developer oznacza nie tylko programistę, ale każdą osobę, która coś tworzy. 13

19 Czas trwania Sprintu musi być ograniczony do maksymalnie 30 dni, aby umożliwić procesy inspekcji i adaptacji przynajmniej raz w miesiącu. Krótki czas trwania iteracji oswaja nieprzewidywalność i kompleksowość tworzenia produktu. Podstawową strukturę Sprintu wyznaczają cztery zdarzenia: Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective. Przed rozpoczęciem Sprintu parametry wszystkich zdarzeń muszą zostać jasno określone. W szczególności czasy ich trwania, które nie mogą zostać zmienione w trakcie iteracji. Kolejność oraz umiejscowienie powyższych zdarzeń w Sprincie są ściśle określone. Proces z zaznaczonymi zdarzeniami został przedstawiony na Rysunku 6. Rysunek 6. Zdarzenia w procesie Scrum. Źródło: Opracowanie własne na podstawie: Schwaber, K., Sutherland, J., The Scrum Guide. The Definitive Guide to Scrum: The Rules of Game, Sprint Planning Przed rozpoczęciem Sprintu odbywa się Sprint Planning (z ang. planowanie Sprintu), który ma na celu wyznaczenie zakresu pracy do wykonania podczas iteracji. Podczas zdarzenia wybierane są elementy z Product Backlogu, których wykonanie zagwarantuje stworzenie danej funkcjonalności (przyrostu produktu). Wszyscy członkowie zespołu muszą być obecni podczas planowania Sprintu. Rezultatem spotkania powinna być decyzja, co może zostać dostarczone na koniec Sprintu oraz w jaki sposób zostanie wykonana niezbędna do tego praca. Odpowiedź na powyższe pytania uzyskuje się w wyniku negocjacji pomiędzy Product Ownerem i Development Teamem. Product Owner dostarcza informacji o priorytetach stron zainteresowanym projektem (klient, akcjonariusze), natomiast członkowie Development Team decydują (na podstawie szybkości swojej pracy w poprzednich Sprintach oraz własnej prognozowanej produktywności), jak wiele z tego są w stanie wykonać. Na koniec cały zespół formułuje cel Sprintu, a Development Team wyjaśnia reszcie zespołu, w jaki sposób dostarczy wymagane funkcjonalności. Planowanie w Scrumie zostało ograniczone do minimum, które jest niezbędne dla użytkowników ostatecznego produktu oraz innych akcjonariuszy projektu. Planować 14

20 w rozumieniu zwinnym oznacza nakreślić wizję, czyli przesłanki, dla których projekt został powołany oraz pożądany stan produktu po iteracji [22, s.65] Daily Scrum To codzienne spotkanie Development Teamu ma na celu synchronizację pracy zespołu oraz ustalenie planu pracy na następne 24 godziny. Trwa maksymalnie 15 minut. Aby maksymalnie usprawnić przebieg tego zdarzenia, należy zdefiniować stałą godzinę rozpoczęcia oraz miejsce jego odbywania się. Podczas spotkań każdy z uczestników odpowiada na trzy pytania. Co zrobiłem w ciągu ostatnich 24 godzin, aby osiągnąć cel Sprintu? Co mam zamiar zrobić przez kolejne 24 godziny, aby zbliżyć się do celu? Czy widzę jakiekolwiek bariery, które uniemożliwią mi lub całemu zespołowi osiągnięcie celu Sprintu? Spotkanie jest kluczowym narzędziem inspekcji oraz adaptacji. Wzmacnia komunikację w zespole, minimalizuje (lub eliminuje) pojawianie się innych, niezaplanowanych zebrań, promuje szybkie podejmowanie decyzji, zwiększa poziom wiedzy członków zespołu oraz pozwala na szybką i niezawodną identyfikację problemów Sprint Review Sprint Review (z ang. przegląd Sprintu) jest jednym z dwóch spotkań zwieńczających pracę zespołu podczas iteracji. Służy do inspekcji dostarczonego przyrostu funkcjonalności. Uczestniczą w nim obowiązkowo wszyscy członkowie zespołu oraz kluczowi interesariusze zaproszeni przez Product Ownera (w tym klienci). Prezentacja dostarczonej funkcjonalności nie jest formalna, ale ma na celu pozyskanie informacji zwrotnej od klienta oraz podkreślenie wartości współpracy w procesie tworzenia produktu Sprint Retrospective W przeciwieństwie do przeglądu Sprintu, który skupia się na wartości funkcjonalnej pracy zespołu, Sprint Retrospective służy refleksji na temat procesu, aspektu ludzkiego i narzędzi. Ciągłe doskonalenie się jest ważnym elementem metodyki Scrum. Zespół powinien potrafić identyfikować swoje mocne strony oraz punkty wymagające ulepszenia. Zachęca się, aby zespół sam tworzył plany działania, które usprawnią proces, jakość produktu, a także zadowolenie z pracy członków zespołu Artefakty Czym są artefakty w Scrumie Jednym z istotnych elementów metodyki jest zdefiniowanie narzędzi wspierających proces. Powinny one być dostępne oraz zrozumiałe dla wszystkich stron zainteresowanych. Ich dostępność ułatwia procesy inspekcji i adaptacji oraz stanowi minimum dla dobrego funkcjonowania zespołu w Scrumie. Te narzędzia w żargonie metodyki nazywa się artefaktami, a mają one charakter zarówno materialny, jak i niematerialny Product Backlog Product Backlog jest listą wszystkiego, co może być potrzebne do wykonania produktu i stanowi jedyna podstawę do wprowadzania zmian w produkcie. Może zawierać zadania, testy, badania, ryzyko i wszystkie inne rzeczy, które są niezbędne, aby osiągnąć cel projektu. 15

21 Dokument jest otwarty, a zmiany w nim mogą zostać wprowadzone na każdym etapie projektu. Elementy w Product Backlogu są ułożone w porządku hierarchicznym, a każdy z nich ma przypisany opis, numer porządkowy, wartość oraz estymację (stopień skomplikowania zadania, niezbędny czas pracy lub inny parametr zdefiniowany w danym zespole). Ważną cechą Product Backlogu jest jego ewolucyjność. To właśnie ta charakterystyka nie pozwala na porównanie omawianego artefaktu do listy specyfikacji w klasycznym, liniowo zarządzanym projekcie. Product Backlog żyje razem z projektem i jego zawartość ewoluuje w czasie (podczas każdego planowania Sprintu można dodawać i usuwać elementy Product Backlogu). Nie jest możliwe, aby na początku projektu (lub nawet w jego połowie) precyzyjnie określić daty, koszty oraz szczegóły dotyczące końcowego produktu. Product Backlog jest fizycznym dowodem na jedną z podstawowych różnic pomiędzy myśleniem zwinnym, a tradycyjnym: zmiany na rynku, w technologii, w modzie albo w warunkach biznesu mają wpływ na rezultat projektu. Pewnych elementów nie można przewidzieć i zdefiniować w ramach sztywnej i niezmiennej listy specyfikacji. Stąd potrzeba stworzenia narzędzia do planowania, umożliwiającego dokonywanie zmian w trakcie projektu Sprint Backlog Sprint Backlog jest częścią Product Backlogu, wyselekcjonowaną podczas planowania Sprintu. Wyznacza wszystkie czynności do wykonania w celu osiągnięcia celu Sprintu. Może być modyfikowany, jednak tylko jeżeli Development Team tak zdecyduje. Jest to narzędzie służące do inspekcji, czym aktualnie się zajmuje zespół i jakimi środkami osiąga cel Sprintu. Zespół powinien zawsze (przynajmniej raz dziennie) być w stanie wykazać, jak dużo zostało jeszcze niewykonanych zadań do osiągnięcia celu. W szczególności, na koniec Sprintu na podstawie Sprint Backlogu dokonuje się analizy wykonanej pracy oraz produktywności zespołu Cel Sprintu Cel jest warunkiem określającym istnienie Sprintu. Jego realizacja jest możliwa dzięki skończeniu zadań wybranych przez zespół podczas Sprint Planningu. Autorzy metodyki nie wskazują na konkretne parametry celu. Może to być funkcjonalność, na którą złożą się wykonane elementy Product Backlogu, ale może to być również każda inna koncepcja, która skłoni zespół do wspólnej pracy Przyrost Inkrementacja produktu, czyli produkt z nową funkcjonalnością wykonaną podczas Sprintu, jest sumą wszystkich elementów ze Sprint Backlogu danej iteracji oraz przyrostów z poprzednich Sprintów Warunkiem zaakceptowania przyrostu jest spełnienie dwóch wymagań: potencjalnego działania produktu (w przypadku, gdy projekt zostałby zatrzymany w danym momencie, a klient chciałby dostać produkt, musi on być w stanie gotowym do użytku), spełniający definicję Done. Definicja Done Ostatnim artefaktem Scruma jest definicja Done (z ang. zrobione), czyli kiedy element Product Backlogu może zostać uznany za skończony. Definicja musi zostać uznana oraz 16

22 zrozumiana przez wszystkich członków zespołu, a także przez osoby wchodzące w interakcje z zespołem. Definicja może zawierać elementy funkcjonalne, designu oraz jakościowe i na jej podstawie decyduje się, czy cel Sprintu został osiągnięty lub nie Scrum a podejście zwinne W rozdziale wartości zarządzania zwinnego zostały zawarte w syntetycznej formie manifestu. W ramach podsumowania opisu metodyki Scrum warto zastanowić się, czy jej elementy pozostają w zgodzie z wartościami leżącymi u podstaw myślenia zwinnego. W Tabeli 2 znajduje się porównanie postulatów manifestu z elementami składowymi Scruma. Tabela 2. Porównanie wartości podejścia zwinnego z elementami Scruma Manifest Zarządzania Zwinnego Ludzie i interakcje ponad procesy i narzędzia Działające oprogramowanie ponad obszerną dokumentację Współpraca z klientem ponad formalne ustalenia Reagowanie na zmiany ponad podążanie za planem Elementy Scruma Samoorganizujący się zespół projektowy, częste spotkania zwiększające interakcje: Daily Scrum, Sprint Retrospective Przyrost zdefiniowany jako działający produkt; definicja Done Spotkania z klientem podczas Sprint Review, ewolucja specyfikacji projektu (Product Backlog) Ewolucyjny Product Backlog, spotkania służące adaptacji: Daily Scrum, Sprint Review; krótkie iteracje Źródło: Opracowanie własne Na podstawie powyższego porównania można uznać, że Scrum spełnia bez wątpienia założenia podejścia zwinnego i jest przykładem metodyki w stu procentach bazowanej na wartościach promowanych przez tę koncepcję. 1.4 Problematyka implementacji metod zwinnych Implementacja metodyk zwinnych w literaturze Aby umieścić niniejszą pracę w kontekście obecnego stanu wiedzy na temat implementacji metod zwinnych, został dokonany przegląd literatury. Badania literaturowe zostały zorientowane na poszukiwanie czynników mających wpływ na wdrażanie metod zwinnych. Szczególna uwaga została skupiona na kategoriach tych czynników. Na tej podstawie w dalszej części tego rozdziału zostanie zaproponowana klasyfikacja czynników implementacyjnych, będąca narzędziem stworzonym na potrzeby badań praktycznych z Rozdziału 2. 17

23 W literaturze tematyka implementacji metodyk zwinnych jest podejmowana w różnych aspektach: analizy ryzyka przy wdrażaniu [24]; barier i oporów wdrożeniowych [1]; czynników sukcesu lub porażki projektu zwinnego [4]. Część autorów zajmuje się wybranymi aspektami wdrażania [8, 17], a inni podejmują próbę zidentyfikowania wszystkich czynników mających wpływ na powodzenie implementacji [24]. Różnią się również metody badań. Duża część z nich opiera się na analizie konkretnych przedsiębiorstw [1,4]. Mniejszość stanowią badania a priori, mające na celu identyfikacje wszystkich czynników mających potencjalnie wpływ na wdrażanie [24]. Chociaż cele badawcze poszczególnych prac różnią się w kontekście wyżej przedstawionych aspektów, punktem wspólnym dla wszystkich autorów jest zastosowanie klasyfikacji czynników mających wpływ na implementację metod zwinnych. Niezależnie czy badania dotyczą problemów wdrożeniowych, czy ryzyka wszystkie skupiają się na identyfikacji i klasyfikacji różnych czynników wpływających na sukces implementacji. Tsun Chow i Dac-Buu Cao zajęli się tematyką krytycznych czynników sukcesu projektu zwinnego [4]. Autorzy wykorzystali ankietę przeprowadzoną w 109 projektach zwinnych w 25 różnych krajach, aby na jej podstawie zidentyfikować elementy mające wpływ na sukces lub porażkę projektu. Zaproponowane kategorie to: struktura organizacyjna, ludzie, proces, technika i projekt. 9 Przykłady czynników zidentyfikowanych przez Tsun Chow i Dac-Buu Cao znajdują się w Tabeli 3. Nerur i Mahapatra zaproponowali inną klasyfikację [18]. W jej ramach zostały sformułowane cztery kategorie obejmujące czynniki będące źródłami wyzwań przy wdrażaniu zarządzania zwinnego: Management i struktura organizacyjna: o kultura organizacyjna, o styl menedżerski, o zarządzanie wiedzą dotyczącą tworzenia oprogramowania, o system nagradzania; Ludzie: o umiejętność pracy w zespole, o wysoki stopień umiejętności, o relacja z klientem: zaufanie, zaangażowanie, szacunek; Proces: o zmiana podejścia zorientowanego na proces na zorientowane na ludzi i funkcjonalności, o krótkie, iteracyjne tworzenie produktu, które faworyzuje adaptacyjność, o wybór odpowiedniej metodyki zwinnej; Technologia: o dostosowanie do podejścia zwinnego istniejących technik i narzędzi, specyficzne umiejętności 9 Ostatnia kategoria występuje jedynie w przypadku czynników sukcesów. 18

24 Tabela 3. Czynniki sukcesu i porażki projektu zwinnego wg Tsun Chow i Dac-Buu Cao STRUKTURA ORGANIZACYJNA LUDZIE + Wsparcie kierownictwa + Członkowie zespołu o wysokich + Zaangażowane kierownictwo kompetencjach + Kultura organizacyjna oparta na + Członkowie zespołu o bardzo współpracy, a nie na zależnościach wysokiej motywacji do pracy hierarchicznych + Managerowie zapoznani z + Preferowanie komunikacji metodami zwinnymi bezpośredniej, twarzą w twarz + Styl zarządzania + Organizacje, w których metody charakteryzujący się otwartością na zwinne są generalnie zmiany i zaufaniem zaakceptowane + Zgrany, samoorganizujący się + Zlokalizowanie zespołu w zespół jednym miejscu + Dobre relacje z klientem + Przestrzeń pracy dostosowana do + Rozwinięte umiejętności pracy w narzędzi i technik metod zespole zwinnych - Opór ze strony pojedynczych osób + System nagradzania odpowiedni do stosowania metod zwinnych + Niezbyt rozbudowana struktura organizacyjna PROCES TECHNIKA + Definiowanie specyfikacji - Brak lub nieprawidłowe projektu dostosowane do procesu stosowanie niektórych praktyk zarządzania zwinnego zwinnych - Źle zdefiniowany plan projektu - Niedostosowanie technologii i - Brak procesów umożliwiających narzędzi pomiar postępu projektu zwinnego + Zdefiniowanie standardów - Brak obecności klienta podczas jakości kodu na początku projektu projektu (środowisko programistyczne) + Zaangażowanie i obecność + Wystarczająca, ale niezbyt klienta podczas projektu obszerna dokumentacja + Klient posiada wpływ na decyzje + Regularne dostarczanie dotyczące projektu funkcjonalności + Odpowiednie szkolenie techniczne dla członków z zespołu PROJEKT 19

25 + Projekty w małych zespołach + Brak zależności pomiędzy wieloma zespołami + Zmienny zakres projektu + Dynamiczny harmonogram projektu (o jak najkrótszym czasie trwania) + Analiza ryzyka i kosztów wykonana na początku projektu Źródło: Tsun Chow, Dac-Buu Cao, A survey study of critical success factors in agile software projects, The Journal of Systems and Software 2008, nr 81, s

26 Otoczenie Warto zauważyć, że obie powyższe klasyfikacje pozostają w zgodzie z modelem organizacji Leavitta (Rysunek 7). W tym kontekście, w obu zacytowanych propozycjach brakuje jednak kategorii otoczenia. Czynniki mające swoje źródła w otoczeniu projektu zostały zawarte w innych kategoriach. Rysunek 7. Model organizacji Leavitta Źródło: Krzyżanowski L., Podstawy nauk o organizacji i zarządzaniu, PWN, Warszawa Alternatywne do powyższych modeli kategorie zostały sformułowane w klasyfikacji barier implementacyjnych metodyk zwinnych Boehma i Turnera [1]. Zostały zaproponowane trzy klasy barier wdrożeniowych: Konflikt wartości zwinnych z procesem produkcji zarządzanym liniowo: o różne cykle życia projektu, o definiowanie zakresu projektu, o synchronizacja pracy różnych zespołów; Konflikt wartości zwinnych z procesami biznesowymi: o polityka zarządzania zasobami ludzkimi (profile zorientowane na pracę w zespole, a nie na indywidualne osiągnięcia), o metody pomiaru postępu projektu (tradycyjnie stosowane metody mogą się okazać niedostosowane do projektu zwinnego), o konflikt procesów zwinnych z wymogami niektórych certyfikatów jakości procesu (np. wymagany stopień szczegółowości dokumentacji); Problemy związane z czynnikiem ludzkim: o wsparcie i zaangażowanie menedżerów, o problematyka zarządzania zmianą, o zagadnienia dotyczące przestrzeni pracy. Wiele z powyżej wypisanych czynników pokrywa się z wynikami badań innych cytowanych autorów. Pojawiają się jednak również elementy nieobecne w innych analizowanych publikacjach, jak np. wymogi certyfikatów jakości a procesy zwinne. 21

27 Ostatnia z analizowanych publikacji, której autorem jest Wojciech Walczak, opiera identyfikację czynników wdrożeniowych na modelu 6M+E. Podejście ma na celu identyfikację jak najbardziej kompletnej mapy czynników mających potencjalnie wpływ na implementację metod zwinnych. Model ten może zostać wykorzystany na potrzeby analizy ryzyka w projekcie zwinnym [24, s.124]. Czynniki zostały pogrupowane w ramach siedmiu kategorii: Człowiek: o skład zespołu, o umiejętność pracy zespołowej, o indywidua w zespole i ich efektywność, o umiejętności i wiedza; Metoda: o wybór praktyk i technik zarządzania zwinnego, o elementy metod zwinnych: role, zdarzenia, narzędzia, o wybór jednej z metodyk zwinnych, o straty i oszczędności wywołane wdrożeniem metody zwinnej, o konflikt zarządzania zwinnego i liniowego; Maszyna: o środowisko programistyczne, o środowisko testów, o ciągła integracja i testowanie; Materiał: o definiowanie specyfikacji technicznych, o zapytania dotyczące zmian, o zależności od innych zespołów; Zarządzanie: o metody zarządzania projektami, o linia menedżerska, o starsi menedżerowie; Monitorowanie: o czytelność / widoczność statusu projektu (postępu), o estymacja projektu, o sprawozdawczość z projektu; Otoczenie: o przedsiębiorstwo, które jest otoczeniem projektu, o klient, o strony zainteresowane (zewnętrzne zespołowi), o obowiązki członków zespołu niezwiązane z projektem [24, s.126]. Mimo, że tematyka czynników mających wpływ na wdrażanie metod zwinnych została podjęta w różny sposób przez powyższych autorów, kilka czynników pojawiło się we wszystkich omawianych pozycjach literaturowych. Wszyscy autorzy wymienili problem konfliktu istniejących procesów w przedsiębiorstwie (opartych na tradycyjnym cyklu projektowym) z zarządzaniem zwinnym. Podobnie, analizowane publikacje wskazują na wpływ składu zespołu i profilów osób pracujących przy projekcie na wdrażanie metod zwinnych. Według cytowanych autorów czynnikiem mającym istotny wpływ na sukces implementacji jest nastawienie menedżerów, ich wsparcie i zaangażowanie. 22

28 1.4.2 Klasyfikacja czynników mających wpływ na wdrażanie metod zwinnych Ambicją tej pracy jest stworzenie jak najpełniejszej mapy czynników, które mają wpływ na wdrażanie metodyki zwinnej w analizowanym przedsiębiorstwie. Aby zminimalizować wpływ subiektywnego wyboru obszarów obserwacji podczas badań w przedsiębiorstwie, niezbędne jest stworzenie narzędzia, które pozwoli skierować zainteresowanie badacza na różnorodne źródła problemów wdrożeniowych. Takim narzędziem jest klasyfikacja czynników mających wpływ na wdrażanie metod zwinnych. Na podstawie istniejących, podobnych narzędzi, których przegląd został przedstawiony wcześniej w tym rozdziale, został sformułowany model kategorii problemów implementacyjnych. Posłużył on zarówno jako punkt odniesienia podczas badań (skierowanie obserwacji na różnorodne obszary), jak i narzędzie do analizy wyników tych badań. Pięć poniższych kategorii klasyfikuje czynniki mających wpływ na wdrażanie metod zwinnych. KAT 1: Organizacja Zespołu Projektowego Do tej kategorii zostaną przypisane czynniki związane ze składem i wielkością zespołu, a także celami i obszarami odpowiedzialności zespołu. KAT 2: Aspekty Psychologiczne i Kulturowe Czynniki zaklasyfikowane do drugiej kategorii są ściśle związane z czynnikiem ludzkim w zarządzaniu projektem. Dotyczą charyzmy ich członków, profilów umiejętności, przyzwyczajeń, kultury organizacyjnej, z której się wywodzą, etc. KAT 3: Proces oraz metoda Kategoria obejmuje czynniki związane z elementami wdrażanej metodyki, praktykami i stosowanymi technikami, narzędziami do monitorowania, a także zrozumienia podejścia zwinnego na poziomie zespołu i przedsiębiorstwa. KAT4: Otoczenie Czwarta kategoria dotyczy przede wszystkim umiejscowienia zespołu w strukturze organizacyjnej przedsiębiorstwa, relacji z klientem zespołu, powiązań z innymi zespołami oraz osobami w przedsiębiorstwie, a także relacji z jednostkami z otoczenia przedsiębiorstwa. KAT5: Technologia Ostatnia kategoria zawiera elementy związane ze specyfiką technologii, w której pracuje zespół: stopień niepewności szczegółów rozwiązań technologicznych, średni czas trwania zadań, czasy oczekiwań na dostawy, wymagane umiejętności techniczne członków zespołu, czy metody testowania i środowisko tworzenia produktu. Powyższe kategorie zostały wybrane tak, aby można było do nich przyporządkować możliwie wszystkie czynniki mające wpływ na wdrażanie metod zwinnych. Klasyfikacja powstała na podstawie porównania istniejących, wcześniej opisanych kategorii. W Tabeli 4 zostały zestawione kategorie istniejących klasyfikacji (wg nazwisk autorów cytowanych w 1.4.1) w stosunku do tej zaproponowanej na potrzeby tej pracy. 23

29 KAT 1 Tabela 4. Porównanie zaproponowanej klasyfikacji z istniejącymi w literaturze Leavitt Struktura Chow i Cao Struktura org. Nerur Managemen t i struktura KAT 2 Ludzie Ludzie Ludzie KAT 3 - Proces, Projekt Proces KAT 4 Otoczenie - - KAT 5 Technologi a Technika Technologi a Źródło: Opracowanie własne Walczak Człowiek, Człowiek, Zarządza nie Metoda, Monitorin g Otoczenie, Materiał, Zarządza nie Maszyna, Materiał Boehm i Turner Proces produkcji, biznesowy Czynnik ludzki Proces biznesowy Proces produkcji, biznesowy Proces produkcji Zaproponowane kategorie nie są całkowicie rozłączne (zidentyfikowane obszary wpływają na siebie nawzajem). Oznacza to, że dany czynnik może być zawarty w kilku kategoriach. Przykłady czynników, które posiadają przynależności do kilku kategorii zostały przedstawione na Rysunku 8. 24

30 Rysunek 8. Przykłady problemów implementacyjnych mających źródła w różnych kategoriach Źródło: Opracowanie własne Świadoma pasywność członków zespołu w wydarzeniach i zebraniach wymaganych przez metodykę może mieć źródło zarówno w braku zrozumienia celów takich spotkań (Kategoria 3), jak i indywidualnych cech psychologicznych członków zespołu (Kategoria 2). Tę samą ambiwalencję źródeł mogą mieć czynniki braku autorytetu i konfliktu władzy w grupie, które poza klasycznymi przyczynami wynikającymi z charyzmy osób, mogą również wynikać z braku pełnego zrozumienia i akceptacji podziału obowiązków pomiędzy rolami w metodach zwinnych (np. Scrum Master i Właściciel Produktu w Scrumie). Rozproszenie geograficzne członków zespołu może wynikać zarówno ze sposobu organizacji zespołu, jak i wymogów technicznych (np. praca w serwerowni zlokalizowanej w oddaleniu od głównej siedziby firmy). Pomimo powyżej opisanych problemów związanych z jednoznacznym przypisaniem czynników do kategorii, klasyfikacja jest istotnym narzędziem, które zostało wykorzystane w badaniach przedstawionych w Rozdziale 2. Pozwala na spojrzenie wieloaspektowe na problematykę, a także ułatwia szukanie przyczyn pojawiających się problemów, co jest niezbędne do sformułowania rekomendacji wdrożeniowych na koniec niniejszej pracy. 1.5 Zakończenie Na zakończenie rozważań teoretycznych dotyczących tematyki niniejszej pracy warto umieścić w ich kontekście badania praktyczne, będące przedmiotem kolejnego rozdziału. Podejście zwinne jest pewną filozofią zarządzania, która odwołuje się do ogólnych wartości. Wdrażanie zgodnych z nią wartości wymaga wyboru odpowiednich narzędzi i procesów. Istniejące metodyki oferują taką możliwość. Jednak wybór konkretnej metodyki nie oznacza, że jej implementacja będzie łatwym przełożeniem zaleceń teoretycznych na 25

31 potrzeby przedsiębiorstwa. Już na samym początku Przewodnika po Scrumie [21] dowiadujemy się, że jest to rama postępowania łatwa w zrozumieniu, jednak bardzo trudna we wdrożeniu. Jej autorzy nie wskazują konkretnych technik realizowania założeń metodyki, a raczej sugerują poszukiwania własnych rozwiązań, odpowiednich dla kontekstu przedsiębiorstwa. Metoda badań polegająca na analizie wdrażania metodyk zwinnych w konkretnych przedsiębiorstwach wydaje się w tym kontekście uzasadniona. Sami autorzy Scruma propagują tę formę poszukiwań rozwiązań implementacyjnych metodyki 10. Wszak sam Przewodnik po Scrumie powstał na podstawie doświadczeń w przedsiębiorstwach. Również przegląd publikacji o tematyce implementacji metod zwinnych wskazuje na popularność badań terenowych. Choć część ze zidentyfikowanych problemów wdrożeniowych pokrywa się u różnych autorów, wciąż istnieje potrzeba analizy kolejnych przykładów wdrażania metod zwinnych. Dzieje się tak choćby z powodu różnorodnych kontekstów projektów. 10 Liczne publikacje Kena Schwabera i Jeffa Sutherlanda dotyczą przypadków wdrażania Scruma w konkretnych przedsiębiorstwach. 26

32 2 Studium przypadku wdrażania Scrum 2.1 Wstęp Niniejszym rozdziałem rozpoczyna się część badawcza pracy. Aby umożliwić osiągnięcie celu pracy, zostały wykonane badania terenowe w przedsiębiorstwie. W kolejnych podrozdziałach zostały zaprezentowane dane zebrane podczas badań oraz ich analiza. Wprowadzeniem do badań jest ogólna charakterystyka przedsiębiorstwa. W sposób bardziej szczegółowy została opisana ewolucja struktury organizacji i zarządzania przedsiębiorstwa. Ten aspekt ma istotne znaczenie z punktu widzenia tematu niniejszej pracy. Szczegółowym przedmiotem badań było wdrażanie metodyki Scrum w jednym z zespołów przedsiębiorstwa. Jego opis znajduje się w Rozdziale 2.3. W dalszej części rozdziału znajduje się opis przeprowadzonych badań (Rozdział 2.4), a także analiza ich wyników (Rozdział 2.5). Niniejszy rozdział stanowi bazę do zidentyfikowania problemów wdrożeniowych i sformułowania rekomendacji dotyczących wdrażania metod zwinnych, będących tematem Rozdziału Charakterystyka przedsiębiorstwa Informacje ogólne Numergy to francuskie przedsiębiorstwo, którego siedziba znajduje się w Aubervilliers. Zostało zarejestrowane 1 sierpnia 2012 roku w formie prawnej SAS (fr. Société par actions simplifiée, odpowiednik spółki z ograniczoną odpowiedzialnością). Branża, w której działa to IT (z ang. Information Technology, technologie informacyjne), natomiast główny przedmiot działalności to przetwarzanie i przechowywanie danych oraz usługi w chmurze obliczeniowej. Przedsiębiorstwo powstało w ramach projektu francuskiego rządu, który miał na celu stworzenie niezależnej, francuskiej chmury obliczeniowej (projekt Andromeda, fr. Andromède). Kapitał w wysokości 75 milionów euro został zainwestowany przez rząd w dwa niezależne konsorcja o tym samym profilu działalności: Cloudwatt i Numergy. W przypadku Numergy inwestycja publiczna stanowi około 33% całkowitego kapitału przedsiębiorstwa (inwestycja La Caisse des Dépôts w ramach programu Investissements d Avenir, z fr. Inwestycje w przyszłość), na który składa się dodatkowo wkład akcjonariuszy, odpowiednio 47% SFR i 20% Bull. Całkowity kapitał, jakim dysponuje przedsiębiorstwo wynosi 225 milionów euro [29]. Misją Numergy jest produkcja energii numerycznej, zdefiniowana jako dostarczanie energii numerycznej partnerom przedsiębiorstwa oraz rozwijanie ich usług po to, aby współtworzyć ich zwinny oraz wydajny system informacyjny. Cele strategiczne przedsiębiorstwa to: zdobycie 15% rynku chmury publicznej we Francji w 2016 roku (estymowanego na 3 miliardy euro), zatrudnienie 400 pracowników (w tym 300 inżynierów badań i rozwoju) w ciągu trzech lat od rozpoczęcia działalności [2]. 11 Opracowane na podstawie [27] i informacji uzyskanych w przedsiębiorstwie. 27

33 Usługi obecnie oferowane przez Numergy to przede wszystkim usługi IaaS (z ang. Infrastructure as a service, infrastruktura na żądanie) w chmurze obliczeniowej: oferowanie serwerów i zdolności obliczeniowej (maszyny wirtualne, możliwość korzystania z licencji na oprogramowanie i systemy operacyjne), przechowywanie danych, usługi w sieci (przepustowość, publiczne adresy IP), usługi operacyjne (zapora Firewall, równoważenie obciążenia Load Balancing oraz backup maszyn wirtualnych). Przedsiębiorstwo pracuje nad rozwinięciem oferty PaaS (z ang. Platform as a service, platforma na żądanie) i SaaS (z ang. Software as a service, oprogramowanie na żądanie). Infrastruktura przedsiębiorstwa jest w całości zlokalizowana w regionie Île-de-France i składa się z siedziby głównej i czterech serwerowni. Wszyscy zatrudnieni są zlokalizowani w siedzibie głównej w Aubervilliers. Numergy należy do sektora małych i średnich przedsiębiorstw. Przez dwa lata funkcjonowania liczba zatrudnionych zwiększyła się z 6 do 100 pracowników. 12 Świadczy to o dynamicznym i gwałtownym powiększeniu przedsiębiorstwa w krótkim czasie, co ma znaczący wpływ na wymagania organizacyjne przedsiębiorstwa. Na Rysunku 1 z Załącznika 2 znajduje się ogólny schemat organizacyjny przedsiębiorstwa (stan na ). Struktura składa się z ośmiu pionów funkcjonalnych: dyrekcji zarządzania zasobami ludzkimi, marketingu i komunikacji, sprzedaży, finansów i administracji, prawnej, do spraw rozwoju, technicznej oraz operacyjnej. Największymi pionami przedsiębiorstwa (pod względem zatrudnionych) są: usługi operacyjne (36 pracowników), rozwiązania techniczne (31 pracowników), sprzedaż (14 pracowników). Hierarchia jest czteropoziomowa: 1. Prezes 2. Dyrektorzy pionów 3. Kierownicy, według szczegółowych dziedzin funkcjonalnych 4. Menedżerowie produktów (występują jedynie w pionie technicznym) Każda z komórek jest zależna od jednego dyrektora pionu, za wyjątkiem komórek Front Office i Prototypowanie, Bezpieczeństwo oraz Metodyki zwinne, które są zależne zarówno od dyrekcji technicznej, jak i operacyjnej (komórka Bezpieczeństwa jest w większym stopniu zależna od dyrektora operacyjnego, natomiast dyrekcja techniczna jest ważniejszym zwierzchnikiem komórki Metodyk Zwinnych oraz Front Office). Podczas dwuletniego rozwoju przedsiębiorstwa struktura wielokrotnie ewoluowała do formy z października 2014 roku 13. Główne zmiany dotyczyły dwóch największych pionów: technicznego i operacyjnego. Zatrudnieni w tych pionach w krótkim czasie wielokrotnie zmieniali przełożonych, miejsce w hierarchii, a także zespół bezpośrednich współpracowników. Dzisiejsza forma organizacyjna wciąż ewoluuje, głównie w związku z planowanym dynamicznym rozwojem przedsiębiorstwa (zatrudnienie 400 pracowników do 2016 roku) [27]. 12 Informacje uzyskane w przedsiębiorstwie 13 Zakończenie obserwacji w przedsiębiorstwie 28

34 2.2.2 Charakterystyka otoczenia Model analizy otoczenia Aby dokonać analizy elementów środowiska, kluczowych dla Numergy, został wykorzystany model pięciu wymiarów otoczenia Griffina [10, s.76] (Rysunek 9). W kolejnych paragrafach zostały przedstawione kluczowe dla tematyki niniejszej pracy elementy otoczenia bliższego i dalszego przedsiębiorstwa Rysunek 9. Model otoczenia organizacji Griffina Źródło: Griffin R.W., Podstawy Zarządzania Organizacjami. Wydawnictwo Naukowe PWN, Warszawa 2004, s.76. Otoczenie bliższe Numergy w sposób bezpośredni jest związane z dwoma sojusznikami strategicznymi: SFR i Bull. Są to zarówno główni akcjonariusze przedsiębiorstwa, jak i jego partnerzy. Współpraca opiera się na relacjach dwustronnych, z czego Numergy jest głównym beneficjentem korzyści dotyczących zasobów (finansowych, ludzkich i infrastruktury), natomiast SFR i Bull korzystają z usług Numergy oraz mają dostęp do know-how przedsiębiorstwa. Struktura klientów przedsiębiorstwa dzieli się na rynek B2C (z ang. Business to Consumer, handel bezpośredni z klientem) i B2B (z ang. Business to Business, handel z innymi przedsiębiorstwami). Większość dochodów pochodzi z usług oferowanych na rynku B2B (około 99,3%) 14. Oznacza to, że Numergy tylko w niewielkim stopniu obsługuje klienta detalicznego. Oferta jest skoncentrowana na potrzebach partnerów działających w sektorze B2B. Na Rysunku 10 zostały przedstawione szczegółowe usługi Numergy w zależności od typu klienta. 14 Informacje uzyskane w przedsiębiorstwie, stan na

35 Rysunek 10. Oferta Numergy w zależności od typu klienta Źródło: Opracowanie własne na podstawie informacji wewnętrznych firmy Klienci Numergy to przede wszystkim przedsiębiorstwa działające w sektorze IT (Wykres 1). Oferta skierowana do przedsiębiorstw o wysokim profilu zaawansowania technologicznego musi się charakteryzować nieskazitelną jakością rozwiązań, dopasowaniem do indywidualnych potrzeb klientów oraz innowacyjnością usług. Oprogramowanie Architektura SI Konsulting Inne Wykres 1. Partnerzy Numergy ze względu na profil działalności Źródło: Opracowanie własne na podstawie informacji wewnętrznych firmy, stan na wrzesień 2014 Bezpośrednią komunikacją z klientami zajmują się piony sprzedaży (pozyskiwanie klientów) oraz marketingu (zbieranie informacji o potrzebach, kolekcjonowanie informacji zwrotnej o produkcie, badanie poziomu satysfakcji klientów). Konkurenci Numergy mogą zostać podzieleni na bliższych (rynek francuski) i dalszych (rynek światowy). Niezaprzeczalnie najbardziej bezpośrednim konkurentem jest przedsiębiorstwo siostrzane, Cloudwatt. Projekt Andromède (patrz 2.2.1) zakładał założenie dwóch przedsiębiorstw o tym samym celu i podobnej strukturze kapitałowej. Inwestycja państwa w dwa przedsiębiorstwa miała pobudzić innowację wynikającą z konkurowania pomiędzy nimi [11]. 30

36 Na arenie międzynarodowej Numergy musi konkurować z gigantami rynków technologicznych, takimi jak [11]: IBM, HP, Amazon, Google, Microsoft. Są to liderzy rynku, którzy dysponują znacznie większą niż Numergy infrastrukturą. IBM rozpoczął masowe inwestycje (300 milionów euro we Francji) na konstrukcję pięciu serwerowni już w 2009 roku. Na poziomie światowym rywalizacja pomiędzy wymienionymi gigantami jest bardzo wysoka. Od kilku lat toczy się walka cenowa [26]. Na początku 2014 roku Google obniżyło ceny usług w chmurze od 30% do 75% w stosunku do swojej dotychczasowej oferty. W odpowiedzi Amazon zastosował 60%-ową obniżkę, na co Microsoft natychmiast zareagował cięciem cen. Innym istotnym elementem wpływającymi na funkcjonowanie przedsiębiorstwa są dostawcy. Numergy jest zależne od dostawców elementów infrastruktury serwerowni Otoczenie dalsze Według wyliczeń SFR z 2012 roku rynek Cloud Computing we Francji powinien osiągnąć wielkość 3 miliardów euro w 2016 roku [11]. Nowsze dane (2014, Markess International) pokazują, że Francja stała się liderem rynku cloud computing w Europie (ex aequo z Wielką Brytanią), z 200 przedsiębiorstwami działającymi w tej domenie. Rynek krajowy wzrósł z 2.2 miliarda euro w 2012 roku do 4.1 miliardów euro w 2014 roku. Jest to szybszy wzrost niż przewidywany [15]. Dynamika wzrostu rynku francuskiego jest częścią światowego trendu. Centaur Partners przewiduje wzrost światowej sprzedaży rozwiązań SaaS z 13.5 miliarda dolarów w 2011 roku do 32.8 miliarda dolarów w 2016 roku [7]. Jak przedstawiają niezależne badania Cisco, w 2018 roku 90% przepływu mobilnego danych będzie dotyczył rozwiązań opartych na chmurze (w porównaniu do 82% na koniec 2013) [7]. Podobnie, IDC przewiduje, że rynek usług w chmurze osiągnie poziom 75 miliardów dolarów w 2017 roku, a następnie przez okres pięciu lat będzie osiągał stały, 22%-owy wzrost. Badania Accenture w 2014 roku wykazały, że spośród technologii o najwyższym potencjale ROI (Return on Investment), Cloud Computing zajmuje drugie miejsce. 88% procent respondentów zajmujących stanowiska menedżerskie odpowiedziało, że przedsiębiorstwa nieinwestujące w rozwiązania cloud computing będą narażone na odejście z rynku [7]. Powyżej przedstawione prognozy wskazują, że rynek Cloud Computingu będzie się rozwijał w sposób dynamiczny w szybkim tempie. Nie tylko wymiar ekonomiczny sprawia, że otoczenie przedsiębiorstwa można określić jako burzliwe. Również technologia, w której pracuje przedsiębiorstwo charakteryzuje się wysoką innowacyjnością, a co się z tym wiąże, nieprzewidywalnością. Przedsiębiorstwo opiera swoje rozwiązania między innymi na platformie Openstack. Jest to rozwiązanie opensource owe, tworzone przez organizacje i indywidualnych deweloperów na całym świecie. Numergy jest twórcą oraz klientem tej platformy. 31

37 Przedsiębiorstwo tworzy swoją ofertę w środowisku wysoce niestabilnym, które zależy od innych podmiotów je tworzących. Numergy podlega również regulacjom prawnym. W statucie przedsiębiorstwa znajdują się cele strategiczne projektu Andromède. W związku z tym Numergy jest zobowiązane między innymi do stosowania się do postanowień paktu Unii Europejskiej, European Cloud Partnership (ECP) [2]. W 2012 roku Komisja Europejska wydała oświadczenie Uwolnienie Potencjału Europejskiej Chmury Obliczeniowej. Cele strategiczne wyrażone w tym dokumencie zakładają powstanie 2.5 miliona nowych miejsc pracy i roczny wzrost PKB Unii Europejskiej o 160 miliardów euro w 2020 roku. Przedsiębiorstwa, które znajdują się w ECP, zobowiązują się do realizowania celów finansowych i tworzenia nowych miejsc pracy. W celach strategicznych Numergy zawiera się ambitny plan zatrudnienia 400 osób w ciągu pierwszych trzech lat funkcjonowania. Struktura zatrudnienia ma się ponadto składać z 300 inżynierów o bardzo wysokich, specjalistycznych kompetencjach technicznych Wymagania otoczenia Z punktu widzenia powyżej opisanych elementów, otoczenie Numergy można określić jako dynamiczne i skomplikowane. Przedsiębiorstwo działające w takich warunkach musi stawiać czoło wielu wyzwaniom. W Tabeli 5 zostały przedstawione najważniejsze elementy otoczenia Numergy mające wpływ na różne aspekty zarządzania w przedsiębiorstwie. Element otoczenia Tabela 5. Kluczowe elementy otoczenia Numergy Wyzwanie dla przedsiebiorstwa Klient o wysokich wymaganiach i kompetencjach technologicznych Wysokie kompetencje pracowników Międzynarodowi konkurenci - giganci Dynamiczny wzrost sektora Innowacyjna technologia Stosowanie wysoko rozwiniętych technologicznie rozwiązań oraz tworzenie produktu dopasowanego do potrzeb indywidualnego klienta Dopasowanie stylu zarządzania do zarządzania wysoko wyspecjalizowanymi profilami pracowników Budowanie przewagi konkurencyjnej opartej na innych elementach niż wielkość infrastruktury serwerowni Reagowanie na zmiany w dynamicznym otoczeniu i zapewnienie szybkiego rozwoju przedsiębiorstwa Dostosowanie cyklu życia produktu do niepewnych warunków 32

38 technologicznych Regulacje (projekt Andromède i Spełnianie ambitnych celów ECP) strategicznych Źródło: Opracowanie własne 33

39 2.2.3 Ewolucja struktury i metod zarządzania 15 Numergy jest jednym z przedsiębiorstw, w których dyrekcja jest stuprocentowym ambasadorem stosowania metod zwinnych. Scrum i Agile to pojęcia na stale goszczące w sloganach firmowych, zarówno w komunikacji wewnętrznej jako ekspresja polityki oraz kultury organizacyjnej firmy, jak i zewnętrznej jako element marketingu oraz potencjalna przewaga konkurencyjna przedsiębiorstwa. Entuzjazm kadry zarządzającej wpłynął na stworzenie odważnych planów organizacji zarządzania wszystkich działów Numergy według zasad metodyk zwinnych. Pierwsze zmiany organizacyjne miały miejsce po roku funkcjonowania przedsiębiorstwa, we wrześniu 2013 roku. Do tego momentu właściwie nie można mówić o istnieniu jakiejkolwiek metody zarządzania w Numergy. Niewielkie przedsiębiorstwo u swych początków było zarządzane w sposób spontaniczny, a rozróżnienie pomiędzy menedżerami a pracownikami operacyjnymi było niemal niewidoczne. Wraz z dynamicznym wzrostem organizacji narodziła się potrzeba wprowadzenia bardziej formalnych zasad organizacji pracy. Decyzja linii menedżerskiej o wprowadzeniu zwinnych metod zarządzania była niemal natychmiastowa, a przesłanki ku temu następujące: innowacyjna technologia o wysokim stopniu niepewności, dynamiczne otoczenie wymagające ciągłych adaptacji. Ponadto, menedżerowie Numergy chcieli, poprzez wybór metod zwinnych zarządzania, dążyć do stworzenia jednolitej kultury organizacyjnej, integrującej pracowników o różnorodnych profilach, a także do stworzenia warunków zbliżonych do kultury startup, wspierających inicjatywy pracownicze. Wybór metody zarządzania miał być tym, co wyróżni Numergy na tle konkurencyjnych, gigantycznych korporacji oraz pozwoli nadążyć za dynamicznym tempem rozwoju rynku. Zwinność stała się z dnia na dzień elementem rozpoznawczym Numergy i została wpisana w misję przedsiębiorstwa. W 2013 roku został powołany zespół trenerów metodologii zwinnych, który miał za zadanie asystować wszystkim działom we wprowadzeniu metod pracy bazowanych na teorii metodyk zwinnych. Wdrażanie zostało zaplanowane jako ciąg następujących po sobie etapów, zaczynając od jednego zespołu, po którego sukcesie (rozumianym jako pełna akceptacja, zrozumienie oraz zdyscyplinowane stosowanie zasad wybranej metodyki) kolejne działy miały stopniowo wprowadzać nową metodę pracy. Celem długoterminowym było wdrożenie podejścia zwinnego w całym przedsiębiorstwie. Spośród metodyk zwinnych tymi, które stosuje się najszerzej w Numergy, są Scrum i Kanban dla oprogramowania, z czego Scrum jest metodyką dominującą. 15 Podstawowym źródłem informacji podanych w tym rozdziale są informacje uzyskane w przedsiębiorstwie. 34

40 Zespoły programistyczne Inne zespoły dyrekcji technicznej Reszta przedsiębiorstwa Rysunek 11. Schemat wdrażania podejścia zwinnego w Numergy Źródło: Opracowanie własne na podstawie informacji uzyskanych w firmie Pierwszymi zespołami, których dotknęły zmiany, zostały zespoły programistyczne. Kolejnym etapem było wprowadzenie metodyk zwinnych w zespołach operacyjnych: Scrum w dziale zajmującym się obsługą platformy Openstack i w dziale monitoringu. Następnie Scrum został wprowadzony w reszcie zespołów znajdujących się pod dyrekcją techniczną, w tym w zespole Architektury i Bezpieczeństwa Sieci (dalej Sieci). Jako końcowy etap zmian w przedsiębiorstwie zostało zaplanowane wdrożenie zarządzania zwinnego do działów nieinformatycznych (Zarządzanie Zasobami Ludzkimi, Marketing, Sprzedaż, Finanse i Przedsprzedaż). W momencie wykonywania badań w przedsiębiorstwie ostatni etap nie został jeszcze wdrożony. Linia menedżerska dysponuje pełnym zaufaniem dla zespołu wdrażającego (dział metod zwinnych) i raczej nie ingeruje w jego działania. Rysunek 12. Schemat cyklu projektowego w Numergy Źródło: Opracowanie własne na podstawie informacji uzyskanych w przedsiębiorstwie Wszystkie zespoły, w których wdrożone zostały metodyki zwinne, funkcjonują według wspólnego cyklu projektowego przedstawionego na Rysunku 12. Projekt jest złożony z 3-tygodniowych Sprintów. W ramach każdego z nich odbywają się zdarzenia Scrumowe (za wyjątkiem zespołów działających w metodyce Kan Ban): Sprint Planning, Sprint Retrospective i Sprint Review, a także Daily Scrum. Zdarzenia odbywają się raz w miesiącu (oprócz Daily Scrum, który ma miejsce codziennie), a ich czas trwania jest zależny od 35

41 zespołu. Na koniec każdego ze Sprintów mają miejsce dwa zdarzenia, w których uczestniczą wszystkie zespoły (działające w Scrum, Kan Ban oraz bez wdrożonych metodyk zwinnych): wspólna retrospektywa (2 godziny) oraz wspólny przegląd produktu (2 godziny). Podczas przeglądu produktu na koniec projektu obecni są kluczowi klienci przedsiębiorstwa. Dodatkowo, raz w tygodniu odbywa się spotkanie Scrum of Scrums, które ma na celu synchronizację pracy wszystkich zespołów. Trwa 30 minut, zawsze rozpoczyna się o tej samej godzinie i wymaga obecności przedstawicieli wszystkich zespołów. 2.3 Charakterystyka zespołu Sieci Wstęp W niniejszej pracy w sposób szczegółowy został poddany obserwacjom i analizie zespół Sieci, należący do pionu operacyjnego Numergy. W kolejnych podrozdziałach został zawarty opis tego zespołu oraz jego zależności z resztą przedsiębiorstwa Cele i technologia Formalnymi celami zespołu jest koncepcja, projektowanie oraz implementacja nowych funkcjonalności infrastruktury sieci, a w szczególności: tworzenie sieci szkieletowej (z ang. Backbone Network Design), tworzenie infrastruktury dla chmury obliczeniowej, zarządzanie bezpieczeństwem sieci, tworzenie nowej oferty usług. W praktyce dużą częścią pracy codziennej zespołu jest zarządzanie incydentami technicznymi w infrastrukturze sieci oraz wspieranie innych zespołów ekspertyzą techniczną, w szczególności zespołu obsługującego platformę Openstack (patrz 2.2.3). Usługi dostarczane przez zespół wymagają ciągłego pogłębiania kompetencji technicznych i śledzenia nowych rozwiązań technologicznych. Częste szkolenia są elementem codziennych obowiązków zespołu. Praca wykonywana przez członków zespołu ma często charakter długotrwały (kilka tygodni, a nawet miesięcy), wymagania oraz specyfikacje poszczególnych zadań projektowych często ujawniają się dopiero po rozpoczęciu prac nad projektem, a sporą część obowiązków stanowią prace badawcze i rozwojowe Struktura i ludzie Zespół architektury i bezpieczeństwa Sieci składa się z sześciu członków: Właściciel Produktu, Scrum Master, Młodszy i starszy inżynier sieci, Inżynier systemów i sieci (SI), Ekspert bezpieczeństwa sieci. Właściciel Produktu jest jednocześnie członkiem zespołu i posiada wysokie kompetencje techniczne w domenie architektury sieci. Każdy z inżynierów specjalizuje się w trzech różnych aspektach architektury sieci. Kompetencje dwóch z nich pokrywają się w około 20%, natomiast trzeci z nich jest ekspertem w odrębnej dziedzinie (inżynieria systemów). Tylko jeden członek zespołu posiada kompetencje dotyczące bezpieczeństwa sieci i jednocześnie jego profil nie pozwala na wykonywanie zadań typowych dla architektury sieci. Ponadto, ekspert do spraw 36

42 bezpieczeństwa ma jednocześnie obowiązki niezwiązane z pracą zespołu, dlatego jego dyspozycję czasową dla zespołu możemy określić jako 25% jego pełnego wymiaru czasu pracy. Członkowie zespołu Sieci mają różne doświadczenie pracy w Numergy. Jeden z inżynierów sieci dołączył do przedsiębiorstwa zaraz po jego założeniu (2012 rok), natomiast reszta członków ma około roczny staż pracy w tym przedsiębiorstwie. Wyjątkiem jest drugi z inżynierów sieci, który dołączył do firmy w czerwcu 2014, (czyli wraz z rozpoczęciem obserwacji w niniejszej pracy). Zespół został utworzony w powyższej konfiguracji w czerwcu Większość członków należała wcześniej do innych zespołów lub pracowała niezależnie. W kontekście zależności hierarchicznych, Właściciel Produktu podlega kierownikowi komórki Platforme Owner, trzech inżynierów sieci oraz systemów jest pod zwierzchnictwem menedżera komórki Service Delivery, ekspert do spraw bezpieczeństwa sieci należy do komórki Bezpieczeństwa, natomiast Scrum Master jest zależny od głównego trenera metodyk zwinnych, który jest jednocześnie kierownikiem komórki Metodyk Zwinnych (Rysunek 13). Rysunek 13. Umiejscowienie zespołu Sieci w strukturze przedsiębiorstwa Źródło: Opracowanie własne W Tabeli 6, zostały przedstawione poszczególne profile członków zespołu. Każdy z nich jest specjalistą w innej dziedzinie, za wyjątkiem dwóch inżynierów sieci, których umiejętności pokrywają się (jednak nie w stu procentach). 37

43 Rola Właściciel Produktu Scrum Master Inżynier Sieci Senior (1) Inżynier Sieci Senior (2) Inżynier Systemów Ekspert bezpieczeństw a Tabela 6. Podsumowanie profilów członków zespołu Sieci Praca w Numergy % czasu dla zespołu Kompetencje techniczne 1,5 roku 100% C, P, I 3 miesiące 2 lata 100% 3 miesiące 50% Brak 100% C (100%), P, I, B (10%), B, P, C (25%), 1,5 roku 100% SI, S (10%) 1,5 roku 25% S I Zwierzchnik hierarchiczny Dyr. Operacyjna, Platform Owner Dyr. Techniczna, Trener zwinny Dyr. Operacyjna, Service Delivery Manager Dyr. Operacyjna, Service Delivery Manager Dyr. Operacyjna, Service Delivery Manager Dyr. Operacyjna, Kierownik Bezpieczeństwa Źródło: Opracowanie własne Legenda: B-Backbone Network Design; C-chmura obliczeniowa; S-bezpieczeństwo; P-rozwój nowych produktów; I - incydenty, ekspertyza, naprawa; SI system informacyjny Tak jak w całym przedsiębiorstwie, również w zespole Sieci istnieje możliwość pracy zdalnej przez jeden dzień roboczy, raz w tygodniu. W takim wypadku, pracownik musi być dyspozycyjny, a kontakt z nim powinien być zapewniony podczas godzin pracy. Znajduje się on jednak fizycznie poza siedzibą firmy. Stanowiska pracy członków zespołu są zlokalizowane obok siebie w przestrzeni typu openspace (z ang. otwarta przestrzeń), w sąsiedztwie zespołu Openstack. Wyjątkiem jest Scrum Master oraz Ekspert Bezpieczeństwa, których biura znajdują się w fizycznym oddaleniu Otoczenie Teoretycznie głównym klientem zespołu są partnerzy Numergy, do których kierowana jest oferta usług związanych z siecią. W praktyce, najczęstszym bezpośrednim odbiorcą rozwiązań dostarczanych przez ten zespół są inne działy Numergy, a w szczególności współtwórcy platformy Openstack. Zespół ściśle współpracuje z innymi zespołami pionów technicznego i operacyjnego. Jest również zależny od jednostek zewnętrznych, w szczególności dostawców materiałów niezbędnych do budowy infrastruktury sieci. 38

44 2.4 Dziennik wdrażania metodyki Scrum w zespole Sieci Wstęp Niniejszy rozdział zawiera opis badań przeprowadzonych na potrzeby pracy. Jego celem jest zidentyfikowanie czynników, które mogą mieć potencjalnie wpływ na sukces lub porażkę wdrażania metodyki Scrum. W dalszych częściach pracy te czynniki zostaną poddane analizie. Na przeprowadzone badania składają się obserwacje i wywiady przeprowadzone w przedsiębiorstwie. W kolejnych podrozdziałach został przedstawiony dziennik obserwacji zawierający opis kolejnych etapów wdrażania, stosowanych w przedsiębiorstwie specyficznych technik oraz narzędzi zarządzania zwinnego, a także postaw oraz reakcji członków zespołu, którego dotyczyło wdrażanie. Wyniki z komplementarnej formy badań, wywiadów przeprowadzonych z osobami istotnymi z punktu widzenia wdrażania metodyki, zostały przedstawione w porządku chronologicznym ich wykonania. Wkomponowanie wyników wywiadów w dziennik obserwacji ma na celu umożliwienie lepszego zrozumienia zjawisk opisanych w dzienniku. Zespół Sieci był poddany obserwacjom od 13 czerwca do 24 września 2014 roku. Ten okres przypada na pierwsze 4 miesiące wdrażania Scruma w tym zespole. Z punktu widzenia cyklu projektowego Numergy (Rozdział 2.2.3) początek badań przypada na ostatni Sprint projektu (na potrzeby tej pracy zostanie nazwany Projektem 0) a ich okres przypada na cztery Sprinty Projektu 1. Pierwszy okres (Sprint 0) to czas, w którym zespół się formułuje. To jest również moment, kiedy członkowie zespołu dowiadują się o decyzji wdrożenia metodyki Scrum. Wraz z pierwszym Sprintem Projektu 1 zespół rozpoczyna funkcjonowanie zgodnie z zasadami metodyki Scrum. W kolejnych trzech Sprintach proces wdrażania jest kontynuowany. Na Rysunku 14 zaznaczono okres obserwacji zespołu Sieci w kontekście cyklu projektowego przedsiębiorstwa. 13/06/2014 Obserwacje Projekt 0 Projekt 1 Sprint Sprint 1 Sprint 2 Sprint 3 Sprint Rysunek 14. Okres obserwacji a cykl projektowy w Numergy. Źródło: Opracowanie własne 16 Informacje i opis wykorzystywanych narzędzi pochodzą z informacji uzyskanych w przedsiębiorstwie, chyba że zostało wskazane inne źródło. 39

45 2.4.2 Sprint 0 początki zespołu Wywiad z Trenerem metodyk zwinnych W poprzednim rozdziale została nakreślona ogólna historia wdrażania zarządzania zwinnego w całym przedsiębiorstwie. Ponieważ głównym przedmiotem zainteresowania tej pracy jest zespół Sieci, warto przyjrzeć się dokładniej genezie wyboru metody zarządzania dla tego konkretnego zespołu. Osobą, która jest odpowiedzialna za transformację metod zarządzania w przedsiębiorstwie, jest Trener Metod Zwinnych (dalej Trener). To właśnie z nim został przeprowadzony wywiad mający na celu ustalenie źródeł decyzji o wdrożeniu metodyki Scrum w zespole Sieci. Wywiad odbył się w pierwszym tygodniu badań w przedsiębiorstwie. Miał charakter nieformalny, odbył się w formie rozmowy. Miał za zadanie przede wszystkim uzyskać informacje dotyczące przesłanek do wdrożenia metodyki Scrum w zespole Sieci, a także subiektywną opinię Trenera na temat adekwatności wybranej metodyki w stosunku do technologii, w której pracuje zespół. Ogólny schemat tego wywiadu zawiera Tabela 7, a podsumowanie informacji uzyskanych podczas wywiadu znajduje się poniżej. Tabela 7. Ogólny schemat wywiadu z Trenerem metodyk zwinnych WYBÓR METODY ZARZĄDZANIA ZESPOŁEM SIECI Osoba, z którą przeprowadzany jest wywiad: Trener Metodyk Zwinnych przedsiębiorstwa Data: Czy zespół Sieci został utworzony z myślą, że będzie zarządzany zwinnie? Kto był pomysłodawcą zastosowania zarządzania zwinnego w tym zespole? Jakie alternatywne metodyki zarządzania zwinnego były rozważane do wdrożenia w tym zespole? Z jakiego powodu to właśnie Scrum został wybrany spośród metodyk zwinnych? Czy Pana zdaniem Scrum jest metodyką dostosowaną do technologii, w której pracuje zespół? Źródło: Opracowanie własne Zespół Sieci powstał w ramach ostatniej reorganizacji przedsiębiorstwa. Uznano, że istnieje potrzeba utworzenia zespołu, który zajmie się rozwijaniem nowych funkcjonalności związanych z infrastrukturą i bezpieczeństwem sieci. Uznano, że wyodrębnienie zespołu pozwoli na wykorzystanie inżynierów sieci o wysokich kompetencjach technicznych do tworzenia innowacyjnych funkcjonalności infrastruktury sieci. Zastosowanie zarządzania zwinnego w tym zespole było decyzją odgórną dyrektorów technicznych i samego trenera. Ponieważ w przedsiębiorstwie istnieje wspólny cykl projektowy oparty na metodyce Scrum, mający na celu synchronizację pracy wszystkich zespołów, według Trenera najlepszym rozwiązaniem jest stosowanie właśnie tej metodyki do zarządzania każdym z zespołów. 40

46 Trener uważa, że wdrożenie Scruma w zespole nieprogramistycznym wiąże się z wieloma wyzwaniami implementacyjnymi. Jeżeli zespół będzie wykonywał wiele czynności związanych z zarządzaniem incydentami technicznymi, zdaniem Trenera niezbędne będzie zaadaptowanie metodyki na potrzeby zespołu. W przypadku jednak gdy zespół skupi się na celach, które zostały mu postawione, Scrum przyniesie w efekcie wzrost produktywności zespołu oraz pozwoli na stworzenie nowych, innowacyjnych rozwiązań. Trener jest zwolennikiem natychmiastowego rozpoczęcia wdrażania i obserwowania efektów. W ten sposób będzie można szybko ocenić, czy Scrum jest odpowiednią metodyką lub czy należy szukać innych rozwiązań Pierwsze wdrożone narzędzia Decyzją komórki odpowiedzialnej za metody zwinne i za przyzwoleniem zwierzchników hierarchicznych zespół miał zacząć funkcjonować według zasad metodyki Scrum od pierwszego Sprintu Projektu 1. Osobą bezpośrednio odpowiedzialną za wdrażanie metodyki oraz Scrum Masterem w tym zespole stał się Trener (nie został on jednak członkiem zespołu). Tym samym członkowie zespołu Sieci mieli zacząć uczestniczyć we wszystkich wydarzeniach procesu Scrum na poziomie całego przedsiębiorstwa: wspólnych dla zespołów pionów technicznych Sprint Retrospective i Sprint Review na koniec każdego Sprintu oraz Scrum of Scrums w każdym tygodniu. Organizacja zdarzeń wewnątrz zespołu została pozostawiona Trenerowi oraz Product Ownerowi. Podstawowym narzędziem organizacji pracy zespołu został system informatyczny składający się z dwóch platform: Confluence i JIRA. 17 Pierwsza z nich jest podstawowym narzędziem intranetu firmy. Służy do komunikacji pomiędzy pracownikami firmy, umieszczania dzienników nowości, składowania dokumentów, raportów ze spotkań, etc. Wszyscy członkowie zespołu Sieci korzystali z tej platformy już przed wdrażaniem metod zwinnych. Nowością dla zespołu było drugie narzędzie, JIRA, czyli platforma służąca do zarządzania projektami zwinnymi. Służy między innymi do tworzenia wirtualnych tablic zwinnych, planowania Sprintów, a także przydzielania osób do zadań. Pozwala na śledzenie postępu Sprintu oraz pokazuje w czasie realnym, czym zajmuje się każdy z członków zespołu. W Numergy prowadzenie projektu w JIRA jest obowiązkowe dla wszystkich zespołów funkcjonujących według zasad metod zwinnych. Jest to podstawowe narzędzie synchronizacji pomiędzy zespołami, kontroli ich pracy, a także wykrywania błędów i przeszkód w osiągnięciu celu projektu. Na Rysunku 15 została przedstawiona tablica zwinna zespołu Sieci służąca do zarządzania projektem zwinnym w JIRA. Zadania zostały podzielone na cztery grupy: do zrobienia, będące aktualnie realizowane, znajdujące się w fazie zatwierdzania przez Product Ownera oraz zadania skończone. Ponadto zadania zostały podzielone ze względu na ich krytyczność (pilność wykonania). Każde z zadań ma symbol, nazwę, opis, estymację. Kiedy członkowie zespołu rozpoczynają pracę nad zadaniem, wyznaczają siebie jako osobę odpowiedzialną. 17 Są to dwa produkty komercyjne firmy Atlassian: JIRA, do pobrania online: [ dostęp Confluence, do pobrania online: [ dostęp

47 Rysunek 15. Zarządzanie projektem zwinnym w JIRA: tablica zwinna Źródło: Opracowanie własne Jedną z funkcji platformy JIRA jest tworzenie wykresów spalania (z ang. Burndown Chart). Jest to jedno z narzędzi proponowanych przez niektórych praktyków Scruma [20, s.439], służące do monitorowania postępu w osiągnięciu celu Sprintu. Jedną z zasad Scruma jest przejrzystość (Rozdział 1.3.3). Oznacza to, że wszystkie osoby związane z projektem powinny mieć w dowolnym momencie możliwość dostępu do informacji, na jakim etapie rozwoju Sprintu znajduje się zespół. Właśnie temu służy wykres spalania. W Numergy jest on tworzony w platformie JIRA na podstawie zadań, które zespół już wykonał w stosunku do tych, które się zobowiązał wykonać podczas Sprint Planningu. Wykresy spalania wszystkich zespołów są jawne i są prezentowane podczas wspólnego przeglądu produktu na koniec projektu (patrz Rozdział 2.2.3). Na Rysunku 16 został przedstawiony schemat wykresu spalania. Linia przerywana oznacza idealny postęp w wykonywaniu zadań. Jest funkcją liniową ustalaną na podstawie zadań, do których wykonania zaangażował się zespół 18 i czasu trwania Sprintu. Czerwona linia oznacza pracę faktycznie wykonaną przez zespół. Z każdym wykonanym zadaniem wykres zbliża się do osi X, informując, jak wiele zadań zostało do wykonania, aby osiągnąć cel Sprintu. Różnice pomiędzy wartościami określonymi przez szary (linia przerywana) i czerwony wykres dają obraz postępu prac zespołu i informują o tym, czy cel Sprintu nie jest zagrożony. Na koniec Sprintu dwie linie powinny się zbiec, natomiast często mamy do czynienia z luką, która oznacza pracę, której zespół nie zdążył wykonać. 18 Wyrażone w jednostce wybranej przez przedsiębiorstwo. W przypadku Numergy są to punkty estymacyjne, o których więcej zostało napisane w dalszej części rozdziału. 42

48 Zadania wykonane Zadania Zadani Czas Rysunek 16. Wykres spalania Źródło: Opracowanie własne na podstawie materiałów Numergy Oprócz uczestniczenia w zdarzeniach wspólnych dla zespołów technicznych oraz prowadzenia tablicy w platformie JIRA (i udostępniania wykresu spalania), zespół nie miał narzuconych innych narzędzi związanych z wdrażaniem metodyk zwinnych. Szkolenie zespołu Sieci na temat podejścia zwinnego oraz metodyki Scrum nie miało nigdy miejsca. Odbywały się jednak nieformalne rozmowy Trenera z członkami zespołu na temat wdrażanej metodyki. Indywidualne spotkania informacyjne miały miejsce najczęściej pomiędzy Trenerem i Product Ownerem zespołu. Nie zaobserwowano szczególnych reakcji członków zespołu na zainicjowane zmiany. Cały zespół bez oporów uczestniczył w rozmowach z Trenerem oraz Product Ownerem, a także w mini szkoleniach dotyczących wdrażanych narzędzi. Zaangażowanie członków zespołu można określić jednak jako minimalne. Nie zadawali pytań dotyczących szczegółów metodyki oraz nowej organizacji pracy. W sposób bierny zgadzali się na zaproponowane rozwiązanie i nie wykazywali inicjatywy współpracowania z Trenerem i Product Ownerem w opracowywaniu szczegółów nowej metody pracy. Po wprowadzeniu do narzędzi oraz ogólnego modelu organizacji pracy we wdrażanej metodyce, zespół rozpoczął oficjalne funkcjonowanie na zasadach Scruma wraz z początkiem Projektu Sprint 1 pierwsze tygodnie Scruma Pierwszy Sprint Planning zadania i estymacja Pierwszego dnia Sprintu 1 cały nowoutworzony zespół spotkał się w ramach planowania Sprintu. Spotkanie trwało 4 godziny, było prowadzone przez Product Ownera zespołu, a oprócz członków zespołu uczestniczył w nim Trener. Oprócz podstawowego celu Sprint Planningu, czyli wybrania zadań do wykonania podczas Sprintu i ich estymacji, należało określić zasady tworzenia i szacowania zadań. 43

49 Trener zaproponował podzielenie projektu na zadania w formie historyjek (z ang. User Story) 19. Jest to narzędzie często stosowane w metodyce Scrum [20, s. 427]. Historyjka zawiera opis określonej funkcjonalności opisanej z punktu widzenia jej użytkownika (klienta). Funkcjonalność oznacza działającą część produktu końcowego, który będzie dostarczony na koniec projektu. Treść historyjki zawiera trzy informacje: kto jest użytkownikiem, czego dotyczy funkcjonalność i czemu służy. Trener zaproponował stworzenie ujednoliconej formy pisania historyjek, dzięki której nie pominie się żadnej z tych informacji, np. Jako odwiedzający stronę www chcę, aby po kliknięciu na logo firmy otwierała się strona startowa, aby można w łatwy sposób nawigować po stronie. Istnieje kilka cech wymienianych w literaturze jako niezbędnych po to, aby historyjka mogła służyć za opis zadania do wykonania w Scrumie. Trener zaproponował, aby skorzystać z zasady INVEST. Według niej historyjka powinna być [5, s.219]: Samodzielna (ang. Independent), Negocjowalna (ang. Negotiable), Wartościowa (ang. Valuable), Mała (ang. Small), Testowalna (ang. Testable). Zasada samodzielności mówi, że zadanie w Scrumie powinno być możliwe do wykonania niezależnie od innych zadań (nie istnieją zależności sekwencyjne pomiędzy historyjkami). Kolejna cecha charakterystyczna dobrej historyjki to jej treść, która powinna być wartościowa, czyli odnosić się do konkretnej funkcjonalności (nie może dotyczyć elementów niemających wartości dla klienta, np. wyglądu kodu programistycznego). Szczegółowe zaprojektowanie rozwiązania podlega negocjacji pomiędzy Product Ownerem a zespołem wykonującym zadanie, określa to zasada negocjowalności. Historyjka powinna być również mała, czyli powinna być możliwa do wykonania w ciągu 1-3 dni. Ostatnia cecha odnosi się do oceny, czy historyjka jest wykonana. Muszą zostać sformułowane testy, które pozwolą zdecydować, czy zadanie zostało zakończone lub nie. Rysunek 17. Tworzenie historyjek w Scrumie Źródło: Opracowanie własne na podstawie Chrapko M., Scrum. O Zwinnym Zarządzaniu Projektami. Wyd Helion, 2012, s.219. Powyżej zaproponowane zasady od tej pory miały być stosowane w zespole Sieci, a bezpośredni nadzór nad ich spełnianiem ponosił Product Owner. Był on również odpowiedzialny za redakcję historyjek. 19 Od tej pory określenia zadanie i historyjka będą używane zamiennie w kontekście zadań z listy Product Backlog zespołu. 44

50 Drugą kwestią była estymacja historyjek. Aby zaplanować liczbę zadań, których wykonaniem zajmie się zespół podczas Sprintu, należy ustalić wielkość tych zadań. Estymacja pozwala również na przydzielenie wartości każdemu z zadań, co ma znaczenie dla narzędzi monitorowania pracy zespołu, takich jak wykres spalania. Stopień skomplikowania zadania (wartość estymacji) miał być funkcją wysiłku niezbędnego do wykonania zadania, ryzyka niepowodzenia oraz niepewności dotyczącej szczegółów zadania. Trener zaproponował, że zespół sam będzie szacował historyjki, przydzielając im wartości liczbowe z ciągu Fibonacciego: 1,2,3,5,8,13, W celu zgodzenia się co do wartości estymacji, zespół miał wspólnie dyskutować nad szczegółami historyjek. Po zaproponowaniu formalnych zasad tworzenia i estymowania zadań, zespół przystąpił do części właściwej spotkania, czyli planowania Sprintu. Product Owner przedstawił oczekiwania dotyczące funkcjonalności oraz dat ich dostarczenia (narzuconych przez linię menedżerską przedsiębiorstwa). Następnie zaproponował historyjki, które z jego punktu widzenia powinny zostać wykonane podczas Sprintu i wspólnie z zespołem dokonał ich estymacji. Nie odbyły się negocjacje dotyczące liczby historyjek do wykonania. Rezultatem spotkania było zaangażowanie się zespołu w wykonanie 109 punktów estymacyjnych podczas pierwszego Sprintu. Większość zadań została oszacowana na 13 lub więcej punktów Funkcjonowanie zespołu w trakcie Sprintu W ciągu Sprintu każdy z członków zespołu wykonywał zadania odpowiadające jego kompetencjom (patrz Rozdział 2.3.3). Dwie osoby, których stanowiska pracy były zlokalizowane w bezpośrednim sąsiedztwie, często konsultowały zadania, nad którymi pracowały. Reszta członków zespołu pracowała samodzielnie, nie informując o postępie swoich prac reszty zespołu. Product Owner regularnie odbywał rozmowy z poszczególnymi członkami zespołu na temat, czym się aktualnie zajmują i jaki jest postęp prac nad zadaniami. Następnie Product Owner wprowadzał te informacje do tablic zwinnych w platformie JIRA. Osoby spoza zespołu, chcące nawiązać kontakt z zespołem Sieci, kierowały się bezpośrednio do osoby, którą uznały za najbardziej kompetentną z punktu widzenia swojego problemu. Podczas całego Sprintu tą osobą był zawsze starszy inżynier sieci. W rezultacie przez większość Sprintu osoba na tym stanowisku przerywała wykonywanie zaplanowanych zadań po to, aby zająć się spełnieniem prośby z zewnątrz. Tak zlecone zadania nie widniały w tablicy zwinnej w platformie JIRA ani w żadnym innym miejscu w przedsiębiorstwie. Oprócz starszego inżyniera sieci, jedyną osobą w zespole, która wiedziała, czym on się aktualnie zajmuje, był Product Owner, dzięki swoim codziennym rozmowom z członkami zespołu. Spotkania Daily Scrum odbyły się kilkakrotnie podczas Sprintu, jednak nie codziennie. Inicjatorem spotkań był zawsze Trener, który proponował spotkania w nieregularnych odstępach czasu. Podczas tych spotkań Trener starał się uzyskać informację zwrotną o pierwszych rezultatach wdrażania metodyki. Zespół zwykle nie miał większych zastrzeżeń odnośnie pierwszych wdrożonych narzędzi. Podczas Daily Scrum rzadkością była wymiana informacji zdefiniowanych w teoretycznym opisie tego zdarzenia. Raz w tygodniu Product Owner brał udział w spotkaniu Scrum of Scrums z przedstawicielami innych zespołów. 20 Estymację za pomocą liczb z ciągu Fibonacciego stosuje się, aby podkreślić zasadę, że wraz ze wzrostem trudności zadań, różnice pomiędzy kolejnymi poziomami skomplikowania stają się coraz większe. 45

51 Trener pojawiał się od czasu do czasu w życiu zespołu, przede wszystkim, aby skonsultować postęp wdrażania metodyki. Mimo, że Trener miał pierwotnie sprawować rolę Scrum Mastera zespołu, oprócz punktowej działalności informacyjnej na tematy związane z metodyką, nie wykonywał żadnych zadań tej roli sformułowanych w Przewodniku po Scrumie Wywiad z Product Ownerem W pierwszym okresie zauważono, że duże znaczenie dla funkcjonowania zespołu miała osoba Product Ownera. Z tego względu został przeprowadzony wywiad z osobą pełniącą tę rolę. Celem wywiadu było ustalenie, w jaki sposób Product Owner postrzega swoją rolę w zespole Sieci. Wywiad został przeprowadzony w formie rozmowy. Miał charakter nieskategoryzowany. Oznacza to, że ustalone wcześniej pytania mogły zostać zmienione, pogłębione lub pominięte w zależności od przebiegu rozmowy. Product Owner został poinformowany o celu wywiadu. W Tabeli 8 znajduje się schemat poglądowy przeprowadzonego wywiadu. Tabela 8. Schemat wywiadu z Product Ownerem zespołu Sieci ROLA PRODUCT OWNERA Osoba, z którą przeprowadzany jest wywiad: Product Owner zespołu Sieci Data: Czy mógłby Pan określić obszary odpowiedzialności Product Ownera w metodyce Scrum? Czy mógłby Pan określić podstawowe czynności, które Pan wykonuje na co dzień? Czy te czynności pokrywają się z zakresem odpowiedzialności Product Ownerów innych zespołów? Czy mógłby Pan wymienić, które z tych czynności są typowe dla roli Product Ownera? Czy uważa Pan, że zakres Pana odpowiedzialności jest odpowiedni w stosunku do roli, którą Pan sprawuje? Źródło: Opracowanie własne Product Owner zespołu Sieci określił, że jest przede wszystkim odpowiedzialny za wizję produktu i funkcjonalności tworzonych przez zespół. Ponadto, jest podstawowym kanałem komunikacyjnym pomiędzy zespołem i jego otoczeniem. Oprócz tego, powinien współpracować ze Scrum Masterem, aby szukać jak najlepszych technik zarządzania Product Backlogiem oraz dbać o to, aby był on widoczny i zrozumiały dla wszystkich osób zainteresowanych pracą zespołu. Ostatecznie, Product Owner nie jest menedżerem, ale członkiem zespołu. Jako czynności wykonywanych przez siebie na co dzień, Product Owner wymienił definiowanie zadań w Product Backlog na podstawie informacji uzyskanych od innych zespołów oraz dyrektorów technicznych oraz ustalanie ich priorytetów. Ponadto, jego zadaniem jest aktualizacja platformy JIRA, uzyskiwanie informacji o tym, czym aktualnie zajmują się członkowie zespołu oraz reprezentowanie zespołu podczas zdarzeń w przedsiębiorstwie, takich jak Scrum of Scrums i wspólny Sprint Review. Product Owner zajmuje się również organizacją sali i ustalania godzin rozpoczęcia i czasów trwania zdarzeń 46

52 Scrumowych w zespole, takich jak Sprint Planning i Sprint Retrospective. Ponadto Product Owner zespołu Sieci wykonuje część zadań technicznych z Product Backlogu zespołu. Zdaniem Product Ownera, czynności, które wykonuje, w zasadzie pokrywają się z zakresem zadań innych Product Ownerów w przedsiębiorstwie. Uważa on, że chociaż część z tych czynności nie jest opisana w teorii metodyki Scrum i być może ani on, ani jego koledzy w Numergy nie powinni się nimi zajmować, to ten stan rzeczy mu odpowiada. Product Owner uznał, że gdyby nie to, nie miałby wystarczająco dużo zróżnicowanych zadań. Jedyna część jego pracy, która jego zdaniem powinna być wykonywana przez kogoś innego, to organizacja zdarzeń Scrumowych Sprint Retrospective 1 Scrum Master dołącza do zespołu Na koniec pierwszego Sprintu Trener uznał, że jego dyspozycyjność czasowa nie pozwala mu na sprawowanie roli Scrum Mastera zespołu Sieci. Została podjęta decyzja o przydzieleniu osoby dedykowanej tej roli. Tym samym do zespołu dołącza Scrum Master. Jego czasowa dyspozycyjność dla zespołu wynosi 50% jego całkowitego czasu pracy (reszta jest przeznaczona na działania na poziomie całego przedsiębiorstwa). Nowy Scrum Master zespołu Sieci formalnie należy do komórki metodyk zwinnych i podlega głównemu trenerowi metodyk zwinnych. Funkcjonalnie, został przydzielony jako członek zespołu Sieci. W celu jak najszybszego zapoznania się z zespołem Sieci i uniknięcia nieciągłości we wdrażaniu metodyki w tym zespole, nowy Scrum Master uczestniczył w zdarzeniu zwieńczającym Sprint 0, czyli retrospektywie Sprintu. Pierwszy Sprint Retrospective zespołu Sieci trwał jedną godzinę. Czas i miejsce spotkania zostały ustalone przez Product Ownera i to on zaprosił członków zespołu do przybycia. W spotkaniu uczestniczyli: Product Owner, inżynier SI oraz młodszy inżynier sieci, a także nowy Scrum Master. Ekspert bezpieczeństwa sieci był nieobecny. Uznał, że jego obecność nie jest obowiązkowa, ponieważ jest przypisany do zespołu jedynie w 25% swojego czasu pracy, więc nie jest jego pełnoprawnym członkiem. Starszy inżynier sieci nie pojawił się z powodu innego spotkania, niezwiązanego z pracą zespołu. Wszyscy obecni, za wyjątkiem Product Ownera i Scrum Mastera, przyszli na spotkanie spóźnieni. Spotkanie miało charakter swobodnej rozmowy pomiędzy uczestnikami. Przedstawiony został bilans Sprintu. Ze 109 punktów estymacyjnych, do których wykonania zobowiązał się zespół, tylko 51 zostało skończonych. Wykres spalania z pierwszego Sprintu (Rysunek 18) jest płaski. Oznacza to, że przez długie okresy żadne zadania nie były kompletowane. 47

53 Sprint Rysunek 18. Wykres spalania zespołu Sieci, Sprint 1 Źródło: Dokumentacja wewnętrzna firmy Scrum Master zapytał członków zespołu o ich pierwsze odczucia związane z wdrażaną metodyką. Po raz pierwszy od początku istnienia zespołu został zaobserwowany aktywny udział wszystkich obecnych członków zespołu w dyskusji na temat wdrażania metodyki. Wszystkie osoby obecne na spotkaniu nie miały żadnych oporów w wyrażaniu swoich opinii, z których najważniejsze zostały zacytowane poniżej: Inżynier SI: Przedstawiony wykres spalania nie odzwierciedla pracy, którą wykonaliśmy, ponieważ nie bierze pod uwagę zadań spoza Sprint Backlogu. Ale teraz wszyscy w przedsiębiorstwie będą myśleć, że nic nie robimy. Inżynier SI: Mam również poważne wątpliwości dotyczące sposobu estymowania zadań, większość historyjek z tego Sprintu oceniłbym na bardziej skomplikowane niż zostało to ustalone Młodszy inżynier sieci: Właściwie do tej pory nie rozumiem, na czym polega ta nowa metoda. Nic się nie zmieniło, oprócz tego, że tracimy czas na dodatkowe zebrania. Product Owner: Nie podoba mi się, że nikt oprócz mnie nie dba o to, aby nowe narzędzia zostały prawidłowo wdrożone. Jestem jedyną osobą, która aktualizuje tablicę w platformie JIRA, a na początku powiedziano mi jasno, że każdy jest odpowiedzialny za informowanie o postępie zadań, nad którymi pracuje. Product Owner: Kilkakrotnie odkryłem, że niektórzy z członków zespołu zajmują się zadaniami spoza Sprint Backlogu. Nie powinno tak być, że dowiaduję się o tym po fakcie. W jaki sposób mogę zarządzać priorytetami produktowymi, jeżeli nie ja w pierwszej kolejności jestem informowany o zadaniach spoza planu? Uczestnicy spotkania nie wydawali się być zdenerwowani. Wręcz przeciwnie, chętnie dzielili się swoimi opiniami, nie formułując oskarżeń przeciwko konkretnym osobom. W rozmowie często pojawiały się humorystyczne akcenty i można było wyczuć, że członkowie zespołu mają ze sobą przyjacielski kontakt. 48

54 Cząstkowe wyniki badań (I) Pierwsze trzy tygodnie obserwacji pozwoliły zidentyfikować pierwsze czynniki mające wpływ na wdrażanie metodyki Scrum w zespole Sieci. W Tabeli 9 zostały one pogrupowane według kategorii sformułowanych w Rozdziale Tabela 9. Czynniki mające wpływ na wdrażanie metodyki Scrum, zidentyfikowane na koniec Sprintów 0 i 1 CZYNNIKI MAJĄCE WPŁYW NA WDRAŻANIE METODYKI SCRUM KAT 1: Organizacja Zespołu Projektowego Rozdzielne obszary kompetencji członków zespołu (-) Niepełny wymiar dyspozycyjności czasowej niektórych członków zespołu (-) Niewielka liczba członków zespołu (+) KAT 2: Aspekty Psychologiczne i Kulturowe Indywidualizm członków zespołu (-) Przyjazne stosunki pozaprofesjonalne pomiędzy członkami zespołu (+) Spóźnianie się na spotkania (-) Absencja na spotkaniach (-) Nieinformowanie o absencji na spotkaniach (-) Niechęć do informowania innych członków zespołu o postępie swojej pracy (-) Strach przed oceną przez osoby spoza zespołu (-) Świadoma bierność w stosowaniu narzędzi Scruma (JIRA) (-) Otwartość członków zespołu (+) Wysokie kompetencje członków zespołu (+) Wysoka motywacja do pracy zespołu (+) KAT 3: Proces oraz metoda Niepełnie uczestnictwo Scrum Mastera w życiu zespołu (-) Różne postrzeganie wartości estymacyjnej zadań (-) Nierespektowanie wytycznych do przeprowadzania zdarzeń w Scrumie (brak negocjacji pomiędzy Product Ownerem i zespołem podczas Sprint Planningu) (-) Brak regularności w prowadzeniu platformy JIRA (-) Absencja niektórych zdarzeń Scrumowych lub ich nieregularność (Daily 49

55 Scrum) (-) Niezrozumienie celów poszczególnych elementów metodyki (-) KAT4: Otoczenie Zewnętrznie ustalone daty dostarczenia danych części projektu (-) Brak synchronizacji zebrań poza Scrumowych z cyklem Sprintów i zdarzeń Scrumowych w przedsiębiorstwie (-) KAT5: Technologia Pojawianie się pilnych niezaplanowanych zadań spoza Sprint Backlogu (-) Źródło: Opracowanie własne Dostrzeżono zarówno czynniki mające pozytywny wpływ na wdrażanie (+), jak i negatywny (-). W pierwszych dwóch kategoriach znalazło się najwięcej pozytywnych czynników. Głównie dotyczyły składu zespołu i charakteru jego członków. Dostrzeżono, że przyjazne nastawienie i otwartość członków zespołu sprzyjają wdrażaniu metodyki. Niestety, zaobserwowano także, że członkowie zespołu charakteryzują się również wysokim stopniem indywidualności i preferują pracę samodzielną od współpracy. Te czynniki mają wpływ negatywny, ponieważ zespół nie może spełniać podstawowych wymogów metodyki dotyczących roli zespołu w Scrumie (patrz ). Inne negatywne czynniki należą do kategorii odnoszących się do metody, technologii i otoczenia. To właśnie dotychczasowy wybór praktyk i technik metodyki Scrum ma, w kontekście przeprowadzonych obserwacji, najbardziej negatywny wpływ na jej wdrażanie Sprint 2 początki zmian Wywiad ze Scrum Masterem zespołu Sieci W pierwszym Sprincie w zespole Sieci zostały wprowadzone podstawowe narzędzia i zebrania charakterystyczne dla metodyki Scrum. Podczas retrospektywy na koniec Sprintu okazało się jednak, że przed zespołem jeszcze sporo pracy oraz że niezbędna jest osoba, która ułatwi wdrażanie metodyki w tym zespole. Wywiad z nowym Scrum Masterem został przeprowadzony po to, aby zrozumieć, na których elementach wdrażania skupi się najbardziej, a także, aby poznać jego opinię na temat wyboru metodyki Scrum dla zespołu Sieci. Poniżej znajduje się schemat wywiadu przeprowadzonego z nowym Scrum Masterem (Tabela 10) i informacje uzyskane w tym wywiadzie (poniżej). Tabela 10. Schemat wywiadu ze Scrum Masterem zespołu Sieci WYZWANIA IMPLEMENTACYJNE Osoba, z którą przeprowadzany jest wywiad: Scrum Master zespołu Sieci Data: Dlaczego zdecydował się Pan przyłączyć do zespołu Sieci? 2. Jak Pan ocenia dotychczasowy postęp wdrażania metodyki Scrum w tym zespole? 50

56 3. 4. Czy dostrzega Pan elementy już wdrożone, które wymagają natychmiastowej zmiany lub adaptacji? Na czym według Pana polegają największe trudności w implementacji metodyki Scrum w tym zespole? 5. Czy Pana zdaniem metodyka Scrum jest odpowiednia dla tego zespołu? Źródło: Opracowanie własne Scrum Master przyznał, że wdrażanie Scruma w zespołach nieprogramistycznych jest zadaniem skomplikowanym. Jego zdaniem wymagane są niezbędne adaptacje metodyki na potrzeby zadań, które niekoniecznie kończą się dostarczeniem działającej funkcjonalności. Mimo to Scrum Master dostrzega, że w przypadku zespołu Sieci istnieje duże prawdopodobieństwo, że to przedsięwzięcie zakończy się sukcesem. Ważnymi dostrzeżonymi przez niego czynnikami jest wysoka motywacja do pracy zespołu oraz otwartość i zaufanie jego członków. Scrum Master uważa, że czynnik ludzki gra kluczową rolę we wdrażaniu metodyk zwinnych. Do tej pory zespół był zdaniem Scrum Mastera zostawiony sam sobie we wdrażaniu metodyki i na pewno trzeba wprowadzić więcej dyscypliny i rygoru. Według niego należy najpierw wdrożyć podstawowe elementy metodyki tak, aby były stosowane według ścisłych zasad teoretycznych, a dopiero potem można ewentualnie rozpoczynać ich adaptację na potrzeby zespołu. Członkowie zespołu do tej pory nie rozumieją, na czym polega proces tworzenia produktu w metodyce Scrum, a tym samym nie czują potrzeby uczestniczenia w nim. Jego zdaniem, trzeba natychmiast przeprowadzić solidne szkolenia z zakresu zarządzania zwinnego. Następnie należy znaleźć sposób, aby zespół stosował się do wszystkich zasad opisanych w Przewodniku po Scrumie. Scrum Master uważa, że właśnie poprzez praktykę można przekonać zespół do wartości podejścia zwinnego. Największym wyzwaniem implementacyjnym, które Scrum Master dostrzegł, to wdrożenie metodyki w taki sposób, aby wziąć pod uwagę specyfikę pracy zespołu. Chodzi przede wszystkim o pojawianie się dodatkowych zadań podczas Sprintu oraz silne zależności od innych zespołów. To właśnie od rozwiązania tych zagadnień technicznych, zdaniem Scrum Mastera, zależy sukces implementacji Sprint Planning nr 2 estymacji ciąg dalszy Podczas obserwacji w pierwszym Sprincie Scrum Master wysunął wnioski dotyczące działań, które należy w sposób pilny przeprowadzić w zespole. Pierwszym problemem sygnalizowanym przez członków zespołu było zagadnienie estymacji. Podczas pierwszego planowania Sprintu zespół ustalił wartość historyjek podczas wspólnej, otwartej rozmowy. Scrum Master uznał, że taki sposób szacowania nie jest odpowiedni dla zespołu. Członkowie zespołu posiadają różnorodne i często niepokrywające się kompetencje. W otwartej rozmowie zabiorą głos osoby, które posiadają największe umiejętności do wykonania danego zadania. W rezultacie historyjka zostanie oszacowana na mniejszą liczbę punktów estymacyjnych, niż gdyby została oceniona przez mniej kompetentnych członków zespołu. Jeżeli w trakcie Sprintu okaże się, że zadanie będzie wykonywane przez inną osobę niż ta, która dokonała estymacji, przyznane zadaniu punkty nie będą wiarygodne. Z tego powodu Scrum Master zaproponował stosowaną przez praktyków [5, s.294] grę estymacyjną: Planning Poker. Estymowanie za pomocą gry Planning Poker wymaga kart, które reprezentują kolejne punkty estymacyjne (Rysunek 19). Każdy z członków zespołu zastanawia się w ciszy, na ile punktów oszacowałby dane zadanie. Kiedy wszyscy członkowie są gotowi, każdy z nich 51

57 pokazuje kartę z odpowiednią liczbą odpowiadającą punktom estymacyjnym. Następnie zespół dyskutuje na temat różnic w szacunkach. W tym momencie zespół powinien dojść do kompromisu dotyczącego wielkości estymacji pomiędzy członkami bardziej lub mniej wykwalifikowanymi w danym zadaniu. Ponadto, ta forma estymacji pozwala ukierunkować dyskusję członków na ewentualne problemy związane z zadaniem. Aby zachęcić zespół Sieci do uczestniczenia w tej grze, Scrum Master przygotował spersonalizowane talie kart dla każdego z członków zespołu, stworzone pod kątem ich zainteresowań (Rysunek 19). Chciał tym samym uzyskać sympatię zespołu, do którego niedawno dołączył. W taliach kart stworzonych dla zespołu Sieci nie było punktów estymacyjnych większych niż 13. W ten sposób, zespół został zmuszony do estymowania zadań na najwyżej sześciu poziomach (1, 2, 3, 5, 8 i 13). Scrum Master zauważył, że zadania z pierwszego Sprintu, które zostały oszacowane na dużą ilość punktów, były albo zbyt obszerne, aby je wykonać w czasie jednego Sprintu, albo wiązały się ze zbyt dużą niepewnością dotyczącą szczegółów wykonania, co prowadziło do porzucenia zadań w trakcie trwania Sprintu. Od tej pory, zadania szacowane na więcej niż 13 punktów (oznaczone symbolem nieskończoności) miały zostać ponownie przeanalizowane przez Product Ownera pod kątem ich wielkości i definicji Done (patrz ). Rysunek 19. Jedna z talii kart zastosowanych do Planning Poker w zespole Sieci Źródło: Materiały uzyskane w przedsiębiorstwie Podczas planowania drugiego Sprintu członkowie zespołu Sieci po raz pierwszy skorzystali z techniki estymacji Planning Poker. Spersonalizowane talie kart wywołały uśmiechy na twarzach członków zespołu, którzy następnie przystąpili do gry bez oporów. Podczas szacowania zadań największe różnice w przyznawaniu punktów występowały pomiędzy starszym inżynierem sieci oraz inżynierem SI. To właśnie ten ostatni jest osobą o najmniej rozwiniętych kompetencjach dotyczących architektury Sieci. Zespół wziął pod uwagę ten fakt przy późniejszym rozdzielaniu zadań pomiędzy poszczególne osoby z zespołu. Kilkakrotnie podczas planowania Sprintu pojawiały się karty ze znakiem nieskończoności. Oznaczało to albo, że zespół oceniał zadania na dużo bardziej skomplikowane niż inne zadania oszacowane w skali 1-13, albo że specyfikacje zadania były na tyle niejasne, że zespół nie był w stanie go oszacować. W takich przypadkach zadania były usuwane z listy priorytetów na kolejny Sprint, a Product Owner zobowiązywał się dopracować zadania: albo je doprecyzować i jeszcze raz sformułować wymagania według zasady Done, albo podzielić je na kilka niezależnych zadań, o mniejszym stopniu skomplikowania. 52

58 Ponadto, Scrum Master wyjaśnił zespołowi, że liczba zadań i punktów estymacyjnych, do których wykonania się zobowiązują, zależy wyłącznie od nich. W metodyce Scrum zespół jest oceniany na podstawie stosunku zadań wykonanych do zadań, do których wykonania zespół się zaangażował. W interesie zespołu leży realistyczne ocenianie swoich możliwości. W rezultacie zespół Sieci zadeklarował, że w ciągu drugiego Sprintu wykona zadania za łączną liczbę 49 punktów. Liczba ta jest dwukrotnie niższa niż w poprzednim Sprincie Inżynier Sieci potrzebny od zaraz Product Owner w metodyce Scrum jest osobą, która odpowiada za Product Backlog, czyli listę zadań, które musi wykonać zespół, aby osiągnąć cele poszczególnych Sprintów oraz projektu. Aby Product Owner mógł dobrze sprawować swoją rolę, niezbędne jest, aby to on podejmował wszystkie decyzje dotyczące wyboru i ustalania priorytetów zadań wykonywanych przez zespół. Osoby z zewnątrz zespołu powinny kierować wszystkie pytania oraz prośby dotyczące zadań zespołu właśnie do Product Ownera, a sam zespół powinien go informować o zidentyfikowanych niezbędnych zadaniach do wykonania. Jednak to zawsze do osoby Product Ownera należy ostateczna decyzja dotycząca Product Backlogu (patrz ). Powołanie zespołu Sieci i wyznaczenie w jego obrębie ról typowych dla metodyki Scrum odbyło się w stosunkowo krótkim czasie. Zespół został zaprezentowany w sposób oficjalny na forum wszystkich zespołów pionów technicznych na koniec pierwszego Sprintu, podczas wspólnego przeglądu Sprintu. Z tego powodu osoby z otoczenia zespołu nie wiedziały ani o wdrażaniu metodyki Scrum w tym zespole, ani o nowopowstałej roli Product Ownera zespołu Sieci. Podczas pierwszego Sprintu często miały miejsce sytuacje, kiedy osoby spoza zespołu, mające prośby dotyczące wykonania pewnych zadań przez zespół Sieci, zwracały się bezpośrednio do starszego inżyniera sieci. Takie zdarzenia miały miejsce często, ponieważ wiele zespołów było zależne od zespołu Sieci. Ponadto, za każdym razem, gdy pojawiały się incydenty techniczne na platformach, na których pracowały inne zespoły, to zespół Sieci był jedynym, który posiadał niezbędne kompetencje, aby temu zaradzić. Z powyższych powodów, starszy inżynier sieci często otrzymywał prośby i zapytania dotyczące wykonania zadań od osób z zewnątrz. Tym samym do pracy zespołu włączane były zadania nieprzewidziane w Sprint Backlogu, a Product Owner często nie był bezpośrednio o nich informowany. Taki schemat włączania zadań, wynikających z próśb i zapytań z otoczenia, miał dwa podstawowe skutki: zespół nie mógł wykonać zadań ze Sprint Backlogu z powodu dodatkowej pracy przydzielonej podczas Sprintu, podział pracy pomiędzy członkami zespołu nie był równomierny, ponieważ to starszy inżynier sieci wykonywał większość zadań wynikających z próśb osób z otoczenia. Scrum Master zespołu Sieci uznał, że powyższy problem może mieć źródło w braku zrozumienia roli Product Ownera w przedsiębiorstwie. Jeżeli wszystkie zapytania byłyby kierowane bezpośrednio do niego, Product Owner mógłby decydować o zadaniach, które należy wykonać pilnie, a także o tym, który z członków je wykona. Została rozpoczęta kampania komunikacyjna mająca na celu uświadomienie osobom z otoczenia, do kogo powinny się zwracać w przypadku próśb i zapytań dotyczących zadań wykonywanych przez zespół Sieci. 53

59 Podczas porannych zebrań Daily Scrum, Scrum Master zespołu Sieci ogłosił, kim jest Product Owner nowego zespołu oraz przypomniał, że to właśnie do niego powinno się zwracać z wszelkimi zapytaniami dotyczącymi zadań do wykonania. Następnym krokiem było stworzenie miejsca w platformie JIRA, gdzie zapytania mogłyby zostać sformalizowane. Utworzono tablicę, do której miały dostęp wszystkie zespoły. Osoby mające prośbę do zespołu Sieci miały tworzyć zadanie w tej tablicy, a następnie omawiały jego szczegóły z Product Ownerem. Następnie Product Owner analizował zadanie i albo włączał je do bieżącego Sprintu jako problem krytyczny i pilny, albo przekształcał je w zadanie do wykonania w kolejnych Sprintach, czyli włączał je do Product Backlogu zespołu. Osoby z otoczenia mogły w każdej chwili skonsultować w platformie JIRA, na jakim etapie wykonania znajduje się zadanie. Scrum Master zespołu Sieci przedstawił schemat tego procesu w formie humorystycznej, a następnie zakomunikował go wszystkim osobom z otoczenia zespołu Sieci (Rysunek 20) Rysunek 20. Schemat zwracania się z zapytaniami do zespołu Sieci dla osób z zewnątrz Źródło: Materiały uzyskane w przedsiębiorstwie Spóźnione szkolenie Podczas pierwszej retrospektywy Sprintu okazało się, że niektóre osoby z zespołu nie znają podstawowych zasad i wartości wdrażanej metodyki. Od początku wdrażania nie zostało przeprowadzone szkolenie z zakresu podejścia zwinnego, a większość wiedzy członków zespołu na ten temat pochodziła z obserwacji innych zespołów. Z tego powodu zostało przeprowadzone szkolenie, otwarte dla osób z różnych zespołów, jednak zorganizowane głównie na potrzeby nowopowstałego zespołu Sieci. Ostatecznie w szkoleniu uczestniczyło dwóch członków zespołu, młodszy inżynier sieci i inżynier SI. Szkolenie miało charakter poglądowy na temat podejścia zwinnego ogólnie, 54

60 ogólnych założeń metodyki Scrum oraz niektórych technik zarządzania w Scrumie. Warsztaty zostały zakończone sesją pytań i odpowiedzi. Członkowie zespołu Sieci uczestniczyli aktywnie w tym szkoleniu, zadając wiele pytań odnoszących się do ich codziennej pracy i dotychczasowych doświadczeń z metodyką Anty-zwinna propaganda Zespół Sieci był silnie skorelowany z zespołem Openstack (patrz 2.2.3). Wiele zadań obu sąsiednich zespołów są zależne od siebie. Oprócz tego, część członków obu zespołów należała do tych samych komórek przed ostatnią reorganizacją przedsiębiorstwa. Pomiędzy niektórymi członkami tych zespołów powstały więzi pozaprofesjonalne. Zespół Openstack jest jednym z ostatnich, w którym została podjęta próba wdrażania metodyki Scrum. Opór przy wdrażaniu był bardzo wysoki, a niektórzy z członków tego zespołu odmówili brania udziału we wszystkich zdarzeniach związanych z metodyką. Takie zachowania w tym zespole były tolerowane, a stosowanie się do zasad zarządzania zwinnego w tym zespole było traktowane fakultatywnie. Głównym opozycjonistą podejścia zwinnego w tym zespole był jeden ze starszych inżynierów, pracujący w Numergy niemal od samego początku i posiadający bardzo wysokie kwalifikacje eksperckie. Ta osoba pozostaje w częstym i przyjacielskim kontakcie z członkami zespołu Sieci. Chociaż nie wszyscy członkowie zespołu Sieci demonstrują zdecydowaną niechęć przeciwko wdrażanej metodyce, to negatywny przykład sąsiedzkiego zespołu ma wpływ na niektóre osoby z zespołu. Podczas drugiego Sprintu obserwuje się znaczącą absencję członków zespołu w zdarzeniach Scrumowych. Spotkania Daily Scrum nie odbywają się codziennie, a na większości z nich brakuje co najmniej dwóch członków zespołu. Na cotygodniowych zebraniach Scrum of Scrums wciąż pojawia się wyłącznie Product Owner zespołu. Sprint Planning oraz Sprint Review i Sprint Retrospective są traktowane fakultatywnie przez większość członków zespołu. Nieobecność na zebraniach tłumaczona jest często ważniejszymi zadaniami do wykonania w tym czasie 21. Zespół Sieci na tym etapie nie demonstruje bezpośredniego oporu przeciwko metodyce Scrum, ale wykazuje znaczny brak rygoru oraz przekonania, że skoro w zespole Openstack metodyka nie została całkowicie wdrożona, być może również w ich przypadku nigdy to nie nastąpi. Pod największym wpływem osób z zespołu Openstack pozostaje starszy inżynier sieci Retrospektywa nr 2 Na koniec drugiego Sprintu została przeprowadzona retrospektywa zespołu. Uczestniczyli w nim wszyscy członkowie zespołu poza jednym, inżynierem bezpieczeństwa sieci, który, jak ostatnim razem, uznał, że nie jest w stu procentach członkiem zespołu, a zatem jego obecność nie jest niezbędna. Aby pozwolić wypowiedzieć się każdej z obecnych osób, zastosowano technikę trzech kolorów karteczek. Ta prosta technika polega na wręczeniu każdemu z członków karteczek, na których mają zostać wypisane dwa rodzaje informacji: które elementy pracy zespołu są pozytywne (zielone karteczki), które elementy należy poprawić (czerwone karteczki). 21 Cytowana wypowiedź jednego z członków zespołu Sieci 55

61 Uczestnicy spotkania wypisują zjawiska, które pojawiły się podczas Sprintu, odpowiednio na zielonych lub czerwonych karteczkach. Następnie Scrum Master zbiera wszystkie karteczki i wspólnie z zespołem je omawia, rozpoczynając od elementów pozytywnych. Celem dyskusji jest ustalenie planów działania, które muszą zostać podjęte po to, aby wyeliminować dysfunkcje w pracy zespołu (żółte karteczki). Na koniec spotkania wybieranych jest kilka planów działania do wdrożenia w kolejnych Sprintach. Dzięki takiemu rozwiązaniu można z powodzeniem realizować założenie podejścia zwinnego dotyczące nieustannego polepszania metod pracy i produktywności zespołu. Wśród pozytywnych elementów członkowie zespołu Sieci najczęściej wymieniali zaangażowanie zespołu oraz dobrą atmosferę pracy i przyjazne stosunki pomiędzy członkami zespołu. Na czerwonych karteczkach wielokrotnie pojawił się problem wąskiego gardła zespołu w osobie starszego inżyniera sieci. Jego umiejętności i doświadczenie pozwalają mu na wykonanie niemal wszystkich zadań zespołu w najefektywniejszy sposób. Członkowie zespołu zauważyli, że w przypadku, gdyby starszy inżynier sieci był nieobecny, reszta miałaby poważne problemy, aby kontynuować pracę nad Product Backlogiem. Ponadto, zespół uznał, że w stosunku do całości pracy do wykonania (związanej z projektem oraz dodatkowej, wynikającej z zapytań z zewnątrz i incydentów technicznych), zespół jest za mały. Ostatnim negatywnym elementem wskazanym przez zespół była zbyt duża liczba historyjek, do wykonania których zobowiązał się zespół. Następnie zespół rozpoczął dyskusję, jakimi działaniami można by rozwiązać powyższe problemy. Zostały sformułowane plany działań (Tabela 11). Tabela 11. Plany działania sformułowane przez zespół Sieci podczas drugiej retrospektywy Sprintu Problem Wąskie gardło w postaci starszego inżyniera sieci Brak zasobów w stosunku do pracy Plan Działania Praca w parach (pomiędzy starszym i młodszym inżynierem sieci) Zoptymalizować liczbę zadań w Sprincie Zbyt wiele zadań w Sprincie? Źródło: Informacje uzyskane w przedsiębiorstwie Podczas tej retrospektywy członkowie zespołu zauważyli, że współpracując przy zadaniach mogą znacznie zwiększyć efektywność zespołu jako całości. Zaproponowana praca w parze pomiędzy dwoma inżynierami sieci miała ułatwić transfer umiejętności bez tracenia czasu na specjalne szkolenia lub tworzenie obszernej dokumentacji. Zespół ochoczo zgodził się na takie rozwiązanie, dostrzegając pilną potrzebę usunięcia wąskiego gardła. Mniej oczywiste okazało się rozwiązanie problemu produktywności zespołu. W drugim Sprincie zespół wykonał zadania o wartości 21 punktów w stosunku do 49, do których wykonania się zaangażował. Produktywność zespołu nieznacznie wzrosła w stosunku do ostatniego Sprintu (z 53% na 57%, więcej o wskaźniku produktywności w Rozdziale 2.6). Jednak, mimo że zespół zaangażował się wykonać ponad dwa razy mniej pracy niż w pierwszym Sprincie, to i tak nie udało mu się wykonać całości pracy. Oznacza to, że 56

62 problem ma swoje źródło gdzie indziej niż w liczbie zadań do wykonania przez zespół. Wielkość wskaźnika produktywności wywarła negatywny wpływ na zadowolenie z pracy członków zespołu. Scrum Master zobowiązał się obserwować różne aspekty pracy zespołu po to, aby znaleźć przyczynę problemu. Podczas tej retrospektywy zespół prowadził żywą dyskusję otwarcie przedstawiając problemy. Członkowie zespołu chętnie proponowali możliwe rozwiązania problemów i wykazywali gotowość do brania udziału w działaniach naprawczych Cząstkowe wyniki badań (II) Obserwacje w drugim Sprincie przyniosły kolejne cząstkowe wnioski na temat pozytywnych i negatywnych czynników mających wpływ na wdrażanie metodyki Scrum w zespole Sieci (Tabela 12). Podobnie jak po pierwszym Sprincie, najwięcej pozytywnych czynników zostało zidentyfikowanych w kategorii aspektów psychologicznych i kulturowych. Dostrzeżono, że humor i przyjazne nastawienie członków zespołu mają pozytywny wpływ na wdrażanie. Istotnym negatywnym czynnikiem, który został dostrzeżony w drugim etapie badań, było stosowanie mierników produktywności niezaadaptowanych do potrzeb zespołu. Stosunek zadań wykonanych do wszystkich włączonych do Sprint Backlogu nie daje kompletnego obrazu pracy wykonanej przez zespół w Sprincie. Ma jednak wpływ na spadek motywacji i zniechęcenie zespołu do metodyki. W drugim Sprincie pojawił się również czynnik pochodzący z zewnątrz zespołu. Dostrzeżono, że negatywne nastawienie innego zespołu, a konkretnie jednego z jego członków, może mieć wpływ na wdrażanie metodyki w zespole Sieci. Ryzyko jest tym większe, że członkowie obu zespołów pozostają w przyjaznych, pozaprofesjonalnych relacjach. Tabela 12. Czynniki mające wpływ na wdrażanie metodyki Scrum, zidentyfikowane na koniec Sprintu 2 CZYNNIKI MAJĄCE WPŁYW NA WDRAŻANIE METODYKI SCRUM KAT 2: Aspekty Psychologiczne i Kulturowe Humorystyczne podejście do niektórych aspektów procesu (+) Zwyczaj w przedsiębiorstwie zwracania się z prośbami bezpośrednio do Starszego Inżyniera Sieci (-) KAT 3: Proces oraz metoda Obecność na spotkaniach Scrumowych traktowana fakultatywnie (-) Przedwczesne stosowanie wskaźników produktywności, które na wczesnych etapach wdrażania są niemiarodajne (-) KAT4: Otoczenie Niezrozumienie roli Product Owner jako osoby, z którą powinno się kontaktować w sprawach związanych z produktem (-) 57

63 Zależności pomiędzy różnymi zespołami (-) Negatywny przykład nieudolnego wdrażania metodyki w innym zespole (-) Brak reguły komunikowania się z zespołem w sprawie dodatkowych zadań lub działań krytycznych naprawczych (-) KAT5: Technologia Zadania o bardzo wysokim stopniu niepewności (-) Źródło: Opracowanie własne Przedstawione powyżej cząstkowe wyniki badań pozwolą skierować zainteresowanie badacza na stosowane w analizowanym studium przypadku techniki wdrażania. Na koniec będzie możliwa ocena ich skuteczności w eliminowaniu negatywnego wpływu wymienionych czynników na implementację metodyki. 58

64 2.4.5 Sprint 3 etap dojrzewania Sprint Planning estymacja po raz trzeci Zespół Sieci już po raz trzeci przystąpił do Sprint Planningu. Dla Scrum Mastera zespołu bardzo ważne było to, aby wszyscy członkowie zespołu mieli tę samą definicję poszczególnych wielkości estymacyjnych. Chciał, aby każda z osób posiadała to samo wyobrażenie o stopniu skomplikowania zadania oszacowanego na danym poziomie punktów. Aby ułatwić zespołowi zrozumienie, co oznaczają kolejne poziomy punktów, został zaproponowany system porównywania zadań. Na początku zebrania, zamiast od razu rozpocząć szacowanie zadań do kolejnego Sprintu, Scrum Master zaproponował krótką grę. Namalował na tablicy sześć kolumn i poprosił zespół o to, aby umieścili w nich karteczki z zadaniami z poprzedniego Sprintu w taki sposób, aby były pogrupowane w kolejnych kolumnac od najprostszego do najtrudniejszego (odpowiednio od lewej do prawej). Kiedy zespół wykonał to zadanie, Scrum Master umieścił w każdej z kolumn liczby odpowiadające estymacji (1,2,3,5 ). Następnie zespół rozpoczął dyskusję na temat przydzielonych punktów estymacyjnych w porównaniu z tymi, które zostały oszacowane w poprzednim Sprincie. Scrum Master poprosił, aby przy kolejnym szacowaniu wziąć pod uwagę wyniki tego ćwiczenia. Odtąd każda z wielkości estymacji miała być określona na podstawie relatywnej trudności zadania w stosunku do zadań już wykonanych. Przykładowe rozumowanie (na podstawie Tabeli 13): 1 oznacza, że zadanie jest tak łatwe, jak ZAD oraz mniej skomplikowane, niż ZAD005; 5 oznacza, że zadanie jest łatwiejsze od ZAD008, ale trudniejsze niż ZAD003, etc. Scrum Master uznał, że po pewnym czasie stosowania tej praktyki przy szacowaniu, zespół będzie mógł trafniej i szybciej dokonywać estymacji zadań. Tabela 13. Fragment tablicy do szacowania zadań zespołu Sieci ZAD002 ZAD005 ZAD003 ZAD001 ZAD008 ZAD006 Źródło: Materiały uzyskane w przedsiębiorstwie Wprowadzenie nowej praktyki podczas estymowania nie oznaczało rezygnacji z gry Poker Planning. Wręcz przeciwnie, dwie techniki miały się uzupełniać. Spotkanie Sprint Planning znacznie się przedłużyło w stosunku do przewidzianego czasu trwania (3godz. 30min. w stosunku do 2 godzin). Wpływ na to miało nie tylko wprowadzenie dodatkowego ćwiczenia służącego do estymacji, ale również nieodpowiednie przygotowanie historyjek, z których duża część wymagała doprecyzowania, a nawet całkowitego przedefiniowania. Na początek trzeciego Sprintu zespół zaangażował się do wykonania zadań za łączną liczbę 110 punktów estymacyjnych. Część z historyjek (50 punktów) włączonych do nowego Sprint Backlogu, to były zadania niedokończone w poprzednim Sprincie, więc zespół uznał, że ich skończenie nie zajmie wiele czasu. 22 Przykładowe symbole zadań 59

65 Wprowadzenie rygoru Podczas pierwszych dwóch Sprintów zespół Sieci nie wykazywał dyscypliny w stosowaniu się do zasad Scruma. Spotkania Daily Scrum odbywały się rzadko i nigdy w obecności wszystkich członków zespołu. Platforma JIRA była aktualizowana jedynie przez Product Ownera. Żaden z członków zespołu Sieci, oprócz Product Ownera, nigdy nie uczestniczył w zebraniach Scrum of Scrums. Ponieważ zespół nie demonstrował otwartej niechęci przeciwko wdrażanej metodyce, Scrum Master uznał, że zespołowi po prostu brakuje dyscypliny. Aby w sposób regularny przypominać członkom zespołu o ich powinnościach związanych z wdrażaną metodyką, Scrum Master stworzył Agile Reminders (z ang. zwinne przypomnienia). Codziennie, o identycznej godzinie wszyscy członkowie zespołu otrzymywali wiadomości z jedną z zasad Scruma przedstawioną w sposób humorystyczny. W większości wiadomości dotyczyły tych elementów procesu, które nie zostały właściwie wdrożone w zespole, a treść przypomnień była często napisana pod kątem rzeczywistych zdarzeń i osób z zespołu. Rysunek 21. Codzienne przypomnienia Agile Reminders zespołu Sieci Źródło: Materiały uzyskane w przedsiębiorstwie. Członkowie zespołu Sieci żywo reagowali na pojawiające się wiadomości, komentowali je między sobą nawiązując do żartów. Dzięki przypomnieniom członkowie zespołu zaczęli częściej uaktualniać tablicę w platformie JIRA. Zaczęły się również odbywać codzienne spotkania Daily Scrum. Cały zespół spotykał się raz dziennie, aby przez 15 minut omówić, czym aktualnie zajmuje się każdy z członków zespołu oraz czy nie wystąpiły problemy stojące na przeszkodzie, aby osiągnąć cel Sprintu. Zdaniem kończącym to spotkanie było zawsze przypomnienie o aktualizacji tablicy zwinnej w platformie JIRA. Niestety nie wszyscy członkowie zespołu byli obecni na tych spotkaniach. Do najczęstszych przyczyn nieobecności należały: praca zdalna, inne zebrania, niechęć do uczestniczenia w Daily Scrum. Niektórzy z członków zespołu nie mogli uczestniczyć w Daily Scrum, ponieważ musieli być obecni na zebraniach spoza cyklu projektowego Scruma. Ponieważ w przedsiębiorstwie system zebrań nie był dostosowany do procesu Scrum, często członkowie zespołów zwinnych byli zmuszeni do nieuczestniczenia w obowiązkowych zebraniach Scrumowych właśnie z tego powodu. Bez podjęcia działań na poziomie całego przedsiębiorstwa, była to przeszkoda nie do przeskoczenia. 60