Index of /rozprawy2/11577

Pełen tekst

(1)Akademia Górniczo-Hutnicza im. Stanisława Staszica Wydział Zarządzania Katedra Zarządzania Organizacjami, Kadrami i Prawa Gospodarczego. Rozprawa doktorska. WPŁYW ZWINNEGO ZARZĄDZANIA ZESPOŁAMI PROJEKTOWYMI NA WARTOŚĆ DLA INTERESARIUSZY PROJEKTÓW WYTWARZANIA OPROGRAMOWANIA. mgr inż. Paweł Paterek. Promotor: dr hab. inż. Alina Kozarkiewicz, prof. AGH. Kraków, 2019.

(2) Składam serdeczne podziękowania Pani Promotor dr hab. inż. Alinie Kozarkiewicz, prof. AGH za poświęcony czas, życzliwość, opiekę merytoryczną i pomoc w realizacji niniejszej pracy.. 2.

(3) Składam również podziękowania dla ekspertów i praktyków zwinnego zarządzania za poświęcony mi czas w wywiadach oraz za liczne cenne uwagi, dyskusje i pomoc w przeprowadzeniu moich badań naukowych. Szczególne wyrazy uznania przekazuję dla: Mariusz Chrapko, Magdalena Firlit, Piotr Górak, Piotr Gruszczyk, Grzegorz Gubiński, Justyna Gwóźdź, Krystian Kaczor, Paweł Kmiotek, Adam Kwiecień, Łukasz Machowski, Ludmiła Pisiewicz, Michał Rosołowski, Agata Śladowska, Justyna Wykowska, Marcin Ziarnik, Marcin Ziółek, oraz Paweł Gawidziel, Paweł Golec, Marcin Grochowina, Ewa Koprowska, Mariusz Petlić, Anna Mankiewicz, a także dla Społeczności Agile w Polsce, która wzięła udział w badaniu ankietowym.. 3.

(4) SPIS TREŚCI: WPROWADZENIE .................................................................................................................... 7 1. GENEZA I ROZWÓJ ZWINNEGO ZARZĄDZANIA PROJEKTAMI ........................... 14 1.1. Ewolucja podejścia zwinnego w zarządzaniu – zarys problematyki .......................... 14 1.2. Antecedencje zwinnego podejścia do zarządzania projektami ................................... 16 1.2.1. Podejście iteracyjno-przyrostowe w projektach .............................................. 16 1.2.2. Japońska myśl zarządzania a rozwój metodyk zwinnych ............................... 20 1.2.3. „Manifest programowania zwinnego” i jego znaczenie .................................. 24 1.3. Definiowanie zwinności we współczesnym zarządzaniu projektami ......................... 28 1.4. Znaczenie podejścia zwinnego we współczesnym zarządzaniu projektami ............... 35 1.5. Porównanie tradycyjnego i zwinnego podejścia projektowego .................................. 37 2. ZWINNE ZARZĄDZANIE ZESPOŁEM, PROJEKTEM I PRZEDSIĘBIORSTWEM PROJEKTOWYM .................................................................................................................... 43 2.1. Zwinne zarządzanie zespołem projektowym .............................................................. 43 2.1.1. Zwinność zespołu projektowego ..................................................................... 44 2.1.2. Praktyki zwinnego zarządzania zespołem projektowym................................. 48 2.1.3. Uwarunkowania zwinnego zarządzania zespołem projektowym .................... 53 2.2. Zwinne zarządzanie projektami .................................................................................. 57 2.2.1. Znaczenie metodyk w zarządzaniu projektami ............................................... 58 2.2.2. Zwinność w zarządzaniu projektami ............................................................... 64 2.2.3. Ogólna charakterystyka i kryteria wyboru metodyk zwinnych ...................... 65 2.2.4. Przegląd metodyk zwinnych ........................................................................... 68 2.2.5. Modele skalowania metodyk zwinnych .......................................................... 80 2.3. Zwinne zarządzanie przedsiębiorstwami projektowymi ............................................. 83 2.3.1. Zwinność przedsiębiorstwa projektowego ...................................................... 85 2.3.2. Pomiar zwinności przedsiębiorstwa projektowego ......................................... 87 2.3.3. Transformacja zwinna przedsiębiorstwa ......................................................... 92 2.3.4. Modele zwinnego zarządzania przedsiębiorstwem ......................................... 97 3. SYSTEMATYCZNY PRZEGLĄD LITERATURY........................................................ 104 3.1. Przebieg postępowania badawczego ......................................................................... 104 3.2. Obszary tematyczne dotyczące badań nad zwinnością ............................................. 110 3.3. Przegląd badań na osi czasu ...................................................................................... 111 4.

(5) 3.4. Analiza bibliometryczna ........................................................................................... 114 3.5. Kryteria oceny i selekcji publikacji dotyczących zwinności .................................... 126 3.6. Przegląd dotychczasowych badań nad zwinnością ................................................... 129 3.7. Identyfikacja i potwierdzenie luki badawczej rozprawy ........................................... 140 4. DEFINIOWANIE I POMIAR ZWINNOŚCI ZESPOŁU PROJEKTOWEGO – PODSTAWY MODELU KONCEPTUALNEGO ................................................................. 144 4.1. Zwinny zespół projektowy jako podmiot badań ....................................................... 144 4.2. Praktyki zwinnego zarządzania zespołem – priorytetyzacja i selekcja ..................... 149 4.3. Kluczowe uwarunkowania zwinnego zarządzania zespołem projektowym ............. 156 4.4. Pomiar zwinności w zarządzaniu zespołami projektowymi...................................... 162 4.5. Pomiar zwinności zespołu projektowego w badaniach własnych ............................. 177 5. WARTOŚĆ DLA INTERESARIUSZY PROJEKTÓW WYTWARZANIA OPROGRAMOWANIA I SPOSÓB JEJ POMIARU............................................................. 183 5.1. Specyfika projektów wytwarzania oprogramowania ................................................ 183 5.2. Identyfikacja interesariuszy projektów wytwarzania oprogramowania .................... 188 5.3. Wartość dla interesariuszy projektów wytwarzania oprogramowania ...................... 193 5.4. Pomiar wartości dla interesariuszy projektów wytwarzania oprogramowania ......... 197 6. PRZEBIEG BADAŃ EMPIRYCZNYCH ....................................................................... 205 6.1. Etapy badań empirycznych ....................................................................................... 205 6.2. Uzasadnienie wyboru metod badawczych ................................................................ 207 6.3. Populacja oraz próba badawcza ................................................................................ 209 6.4. Przebieg badań ilościowych ...................................................................................... 213 6.5. Przebieg badań jakościowych ................................................................................... 222 7. WYNIKI BADAŃ EMPIRYCZNYCH ........................................................................... 225 7.1. Wyniki pilotażowego badania ilościowego ............................................................... 225 7.2. Wyniki badań ilościowych ........................................................................................ 238 7.2.1. Charakterystyka badanych zespołów projektowych ..................................... 239 7.2.2. Wyniki modelowania równań strukturalnych SEM ...................................... 250 7.2.3. Analiza wartości ścieżkowych ...................................................................... 257 7.2.4. Analiza efektów mediacyjnych ..................................................................... 262 7.2.5. Analiza efektów moderacyjnych ................................................................... 263 7.2.6. Analiza modelu zależności zwrotnych .......................................................... 267 7.3. Wyniki badań jakościowych ..................................................................................... 269 7.3.1. Charakterystyka respondentów ..................................................................... 270 5.

(6) 7.3.2. Analiza ilościowa transkrypcji przeprowadzonych wywiadów .................... 271 7.3.3. Zwinność zespołu projektowego w opiniach respondentów ......................... 274 7.4. Dyskusja wyników i wnioski z badań ....................................................................... 294 PODSUMOWANIE................................................................................................................ 301 BIBLIOGRAFIA .................................................................................................................... 306 SPIS TABEL........................................................................................................................... 329 SPIS RYSUNKÓW ................................................................................................................ 331 ZAŁĄCZNIKI ........................................................................................................................ 334 1.. Kwestionariusz ankiety w badaniu pilotażowym ...................................................... 334. 2.. Kwestionariusz ankiety docelowej ............................................................................ 338. 3.. Plan przeprowadzenia wywiadu ................................................................................ 342. 4.. Wyniki ankiety docelowej ......................................................................................... 343. 5.. Wynikowy model PLS-SEM z programu WarpPLS 6.0........................................... 357. 6.

(7) WPROWADZENIE Bardzo dynamiczny postęp transformacji cyfrowej, digitalizacji i informatyzacji wielu obszarów działalności człowieka, w tym działalności gospodarczej, sprawił, że lawinowo wzrosła liczba realizowanych projektów wytwarzania oprogramowania. Projekty te cechuje często duża nieprzewidywalność co do wyniku, czyli końcowego rozwiązania w postaci produktu – oprogramowania. Planowanie długofalowe i realizacja z wykorzystaniem tradycyjnych metod zarządzania projektami powodowały liczne opóźnienia lub przekraczanie budżetu. Podejście zwinne (Agile) powstało jako jedna z możliwych odpowiedzi na powyższe problemy i obejmuje liczny zbiór standardów, metodyk, technik oraz praktyk, których wspólnym mianownikiem są wartości oraz zasady zawarte w filozofii Agile, zwanej Manifestem programowania zwinnego (Beck et al., 2001). Manifest ten zakłada, że w pracach projektowych bardziej cenione są: „ludzie i interakcje ponad procesami i narzędziami, działające oprogramowanie ponad obszerną dokumentację, współpraca z klientem ponad formalne ustalenia oraz reagowanie na zmiany ponad podążanie za planem” (Beck et al., 2001). W praktyce zarządzania istnieją liczne metodyki zwinne implementujące podejście zwinne. Podejście zwinne jest stosowane przede wszystkim w organizacji pracy zespołów projektowych (Nerur i Balijepally, 2007; Conboy, 2009; Lee i Xia, 2010), jednak co raz bardziej widoczne jest jego szersze zastosowanie – w zarządzaniu projektami i programami (Szyjewski, 2004; Wyrozębski, 2011a), w zarządzaniu portfelem projektów przedsiębiorstwa, a nawet w zarządzaniu całym przedsiębiorstwem projektowym (Denning, 2016b). Zwinność jest pojęciem wielowymiarowym,. może być różnie definiowana i. klasyfikowana (Conboy, 2009; Ganguly et al., 2009; Lee i Xia, 2010). Częścią wspólną większości definicji zwinności jest zdolność do szybkiej i zamierzonej odpowiedzi na zmieniające się potrzeby interesariuszy z jednoczesnym kontrolowaniem ryzyka oraz umiejętność proaktywnego, sprawnego dostosowania się do skali działania i wprowadzania innowacji. Pojęcie zwinności zostanie w rozprawie szerzej przedstawione w ramach systematycznego. przeglądu. literatury,. a. następnie. wykorzystane. jako. przedmiot. prowadzonych badań empirycznych. Tematyka rozprawy doktorskiej dotyczy relacji pomiędzy podejściem zwinnym stosowanym w zarządzaniu zespołami projektowymi a wartością dla interesariuszy projektów wytwarzania oprogramowania. Przedmiotem badań w niniejszej rozprawie doktorskiej będą zespoły projektowe stosujące podejście zwinne do organizacji pracy w przedsiębiorstwach wytwarzających oprogramowanie, które prowadzą swoją działalność w Polsce. 7.

(8) Wybór tematyki rozprawy doktorskiej podyktowany został rosnąca powszechnością zastosowania podejścia zwinnego w praktyce zarządzania projektami, głównie w projektach informatycznych i kreatywnych, wymagających znacznych i stale aktualizowanych zasobów wiedzy (Ahimbisibwe et al., 2015; Denning, 2016b; Hoda et al., 2017). Dotychczasowe badania wskazują na stosunkowo niewielką liczbę, fragmentaryczność i niską jakość dostępnych badań empirycznych dotyczących podejścia zwinnego, jak również na brak dobrze przedstawionych metod badawczych, brak rzetelności i poprawności wyników, szczególnie dotyczących wpływu zwinności na pracę zespołów projektowych. S. Jalali i C. Wohlin (2011) podkreślają ponadto potrzebę prowadzenia badań dotyczących podejścia zwinnego w projektach wytwarzania oprogramowania przy ścisłej współpracy środowiska akademickiego oraz środowiska praktyków i przedsiębiorstw realizujących te projekty. Przedsiębiorstwa wprowadzają podejście zwinne do praktyki zarządzania bardzo często bez jasnego zrozumienia zwinności, sposobów jej pomiaru oraz bez możliwości kontrolowania jej wpływu, a tym samym bez możliwości określenia wartości dla różnych grup interesariuszy (Vázquez-Bustelo et al., 2007; Lee i Xia, 2010; Serrador i Pinto, 2015). Spełnienie różnorodnych, złożonych, wzajemnie powiązanych, zmiennych, a czasami również sprzecznych oczekiwań różnych grup interesariuszy projektów jest niemałym wyzwaniem dla każdego przedsiębiorstwa (Łada i Kozarkiewicz, 2010). Stosunkowo niewielka liczba oraz fragmentaryczność przeprowadzonych dotychczas badań empirycznych pokazuje, że istnieje wyraźna luka badawcza dotycząca pomiaru poziomu zwinności zespołu projektowego i jej wpływu na wyniki przedsiębiorstwa, w tym na wartość dla różnych grup interesariuszy. Autor tej rozprawy, jako kierownik projektów wytwarzania oprogramowania z wieloletnim doświadczeniem zarówno w podejściu tradycyjnym, jak i zwinnym, spotyka się w praktyce z licznymi problemami zarządzania w środowisku projektowym, w szczególności dotyczącym pracy zwinnych zespołów projektowych. Duże znaczenie przy wyborze tematyki miał również bezpośredni udział i własne obserwacje autora dotyczące przejścia z podejścia tradycyjnego na podejście zwinne w zarządzaniu projektami przez duże przedsiębiorstwo wytwarzające oprogramowanie. Dodatkową przesłanką jest fakt, że projekty związane z wytwarzaniem oprogramowania są obecnie jednymi z dominujących w Polsce, ze względu na duży potencjał wykształconej kadry inżynierskiej i menedżerskiej. Badania. zaprezentowane. w. dysertacji. są. skierowane. na. wypełnienie. luki. teoriopoznawczej związanej z brakiem spójności definicyjnej dotyczącej podejścia zwinnego i zwinności oraz brakiem kompleksowych badań empirycznych dotyczących wpływu zwinności zespołów projektowych na wartość dla różnych grup interesariuszy w 8.

(9) przedsiębiorstwach projektowych wytwarzających oprogramowanie i funkcjonujących na rynku polskim. Istnieje wyraźna luka badawcza wynikająca z fragmentaryczności dotychczas przeprowadzonych badań empirycznych dotyczących pomiaru poziomu zwinności zespołów projektowych i jej wpływu na korzyści dostarczane przez zespół projektowy (Conboy, 2009; Lee i Xia, 2010; Annosi et al., 2016; Recker et al., 2017). Główne pytanie badawcze rozprawy zostało sformułowane następująco: W jaki sposób poziom zwinności zespołu projektowego wpływa na wartość dla różnych grup interesariuszy? W odniesieniu do problemu zasadniczego wskazano następujące problemy i pytania szczegółowe: 1. W jaki sposób poziom zwinności zespołu wpływa na wartość dla właścicieli przedsiębiorstwa, klientów lub użytkowników, a w jaki na wartość dla samego zespołu projektowego, związaną z rozwojem, samorealizacją, uczeniem się, zdobywaniem wiedzy i tworzeniem innowacyjnych rozwiązań produktowych? 2. Które praktyki zarządzania stosowane w ramach podejścia zwinnego mają największe znaczenie dla określenia poziomu zwinności zespołu projektowego? 3. Które praktyki zarządzania stosowane w ramach podejścia zwinnego mają największe znaczenie w kontekście wartości dla różnych grup interesariuszy projektów? 4. Jaki wpływ na badaną relację pomiędzy zwinnością a wartością dla interesariuszy mają wielkość zespołu, złożoność realizowanych projektów i produktów, doświadczenie zespołu, dostęp zespołu do klienta lub użytkownika oraz typ organizacji, w której pracuje zespół projektowy? Poszukiwanie odpowiedzi na tak sformułowany problem badawczy określa cel ogólny badań. Celem metodyczno-aplikacyjnym badań podjętych w proponowanej rozprawie doktorskiej jest zdefiniowanie poziomów zwinności zarządzania zespołami projektowymi wytwarzającymi. oprogramowanie. oraz. opracowanie. metody. pomiaru. zwinności. umożliwiającej identyfikację poziomu zaawansowania. Celem teoretyczno-poznawczym jest ustalenie relacji pomiędzy poziomem zaawansowania zwinności zespołu projektowego a wartością dla wybranych grup interesariuszy. Celem empirycznym jest weryfikacja zaproponowanego modelu poprzez porównanie z wynikami przeprowadzonych badań. Celem utylitarnym pracy jest natomiast określenie możliwości zastosowania zaproponowanego modelu do wspomagania decyzji w zakresie wdrażania oraz doskonalenia sposobów implementacji. podejścia. zwinnego. w. organizacji. wytwarzających oprogramowanie.. 9. pracy. zespołów. projektowych.

(10) Hipoteza główna rozprawy brzmi następująco: HG. Poziom zwinności zespołu projektowego, który można zidentyfikować za pomocą stopnia wykorzystania praktyk zarządzania zwinnego, wpływa na wartość dla różnych grup interesariuszy zespołu projektowego. Z hipotezy głównej wynikają następujące hipotezy szczegółowe: H1. Zwinność zespołu projektowego wpływa korzystnie na wartość dla: H1.1 właścicieli przedsiębiorstwa, H1.2 klientów lub użytkowników. H2. Zwinność zespołu projektowego wpływa na wartość dla zespołu projektowego związaną z rozwojem, samorealizacją, uczeniem się, zdobywaniem wiedzy i tworzeniem innowacyjnych rozwiązań produktowych. H3. Można zidentyfikować grupy praktyk zarządzania stosowane w ramach podejścia zwinnego o większym znaczeniu w określeniu poziomu zwinności zespołu projektowego. H4. Można zidentyfikować grupy praktyk zarządzania stosowane w ramach podejścia zwinnego o większym znaczeniu w kontekście wartości dla różnych grup interesariuszy zespołu projektowego: H4.1 właścicieli przedsiębiorstwa, H4.2 klientów lub użytkowników, H4.3 zespołu projektowego. H5. Wpływ zwinności zespołu na wartość dla różnych grup interesariuszy (właścicieli przedsiębiorstwa, klientów lub użytkowników, zespołu projektowego) zależy od: H5.1 wielkości zespołu projektowego, H5.2 złożoności realizowanych projektów i produktów, H5.3 doświadczenia zespołu projektowego, H5.4 dostępu zespołu projektowego do klienta lub użytkownika, H5.5 typu organizacji, w której pracuje zespół projektowy. W odniesieniu do celów utylitarnych dysertacji można natomiast sformułować następującą tezę: pomiar zwinności zespołu projektowego może być wykorzystany do określenia aktualnego stanu zaawansowania podejścia zwinnego w organizacji pracy zespołów projektowych oraz do wyboru sposobów doskonalenia zarządzania takim zespołem.. 10.

(11) Nauki o zarządzaniu cechuje wieloparadygmatyczność, co ma swoje konsekwencje w postaci. wielowymiarowości. koncepcji. klasyfikowania. paradygmatów. organizacji. i. zarządzania (Burrell i Morgan, 1979, s. 22; Sułkowski, 2012, s. 106; 2013, s. 17; 2014, s. 157). W pracy zostanie wykorzystany paradygmat neopozytywistyczno-funkcjonalistycznosystemowy – korzystając z nazewnictwa za Ł. Sułkowskim (2014, s. 159). Najważniejszym. aspektem. epistemologii. neopozytywistyczno-funkcjonalistyczno-. systemowej jest dążenie do konstruowania zintegrowanych systemów zarządzania i weryfikacja prawdy przy zastosowaniu obiektywnych metod ilościowych (Sułkowski, 2012). Podejście analityczne jest tu najistotniejsze, ponieważ umożliwia uogólnianie teorii za pomocą matematycznego modelowania wyników badań i rzeczywistości nauk społecznych korzystając z neopozytywistycznego schematu poznawczego w postaci: hipotez, weryfikacji i teorii (Sułkowski, 2012). Istotę tego paradygmatu stanowi dążenie do zinterpretowania faktów, zjawisk oraz procesów społecznych poprzez ustalenie ich funkcji w społeczeństwie. W badaniach wychodzi się z założenia neutralności aksjologicznej i nieingerencji badacza w celu tworzenia jak najbardziej obiektywnych, uniwersalnych teorii społecznych oraz modeli zarządzania organizacjami, a powstałą w ten sposób teorię wyróżnia wysoka ogólność i moc predykcyjna (Sułkowski, 2013). W naukach społecznych w ramach funkcjonalizmu przyjmuje się często perspektywę poznawczą samoregulujących się systemów społecznych (Sułkowski, 2013, s.21), gdzie procesy społeczne mogą być obiektywnie i matematycznie reprezentowane za pomocą sekwencyjnych związków zmiennych przyczynowo-skutkowych. Proces badawczy zastosowany w rozprawie doktorskiej przedstawiono na Rys. 1. W ramach realizacji celów pracy doktorskiej wykorzystano metody badawcze w postaci systematycznego oraz tradycyjnego przeglądu literatury polsko- i angielskojęzycznej. W części empirycznej zastosowano triangulację metodologiczną. Triangulacja metodologiczna w postaci złożenia metod ilościowych i jakościowych pozwoliła spojrzeć na problem badawczy z różnych perspektyw oraz zwiększyć wiarygodność wyników badań. Całość pracy składa się z siedmiu rozdziałów. Celem dwóch pierwszych rozdziałów jest całościowe i kompleksowe ujęcie tematyki, uporządkowanie terminologii stosowanej w ramach podejścia zwinnego oraz usystematyzowanie dotychczasowej wiedzy na podstawie przeglądu literatury przedmiotu. Rozdział 1 dotyczy pojęć, koncepcji oraz ich ewolucji. Rozdział 2 przedstawia pojęcie zwinności w kontekście zarządzania zespołami, projektami oraz przedsiębiorstwami. Rozdział 1 i rozdział 2 są wynikiem tradycyjnego, natomiast rozdział 3 jest wynikiem systematycznego przeglądu literatury. 11.

(12) Rys. 1 Model procesu badawczego w rozprawie doktorskiej. Źródło: opracowanie własne. Celem dwóch kolejnych rozdziałów opartych na tradycyjnym przeglądzie literatury jest konstrukcja modelu badawczego oraz przygotowani przygotowaniee pilotażowego narzędzia badawczego badawczego. Rozdział 4 zawiera definicję zwinności w zarządzaniu zespołem projektowym projektowym, przegląd praktyk zwinnych i uwarunkowań zwinnego zarządzania zespołem projektowym projektowym,, a także przegląd dotychczasowych sposobów pomiaru omiaru zwinności. zwinności. Rozdział 5 zawiera analizę specyfiki projektów wytwarzania oprogramowania wraz z identyfikacją kluczowych interesariuszy oraz wartości dla interesariuszy interesariuszy.. 12.

(13) Rozdział szósty przedstawia szczegóły dotyczące przebiegu procesu badawczego (Rys. 1) niniejszej. rozprawy. doktorskiej,. natomiast. rozdział. siódmy. przedstawia. wyniki. przeprowadzonych badań. Rozdział 7 składa się z trzech podrozdziałów: 7.1 – zawierającego wyniki pilotażowego badania ilościowego, 7.2 – zawierającego właściwe wyniki badań ilościowych z wykorzystaniem modelowania równań strukturalnych SEM oraz 7.3 – zawierającego wyniki badania jakościowego. W podrozdziale 7.4 przedstawiono dyskusję i wnioski z wyników badań oraz wyniki weryfikacji postawionych w pracy hipotez badawczych. W podsumowaniu dokonano syntezy wyników, wskazując jednocześnie możliwości prowadzenia przyszłych badań w tym obszarze. Praca ma charakter poznawczo-aplikacyjny. Poza uzupełnieniem zidentyfikowanej luki teoriopoznawczej, daje możliwość zastosowania zaproponowanego modelu jako narzędzia do wspomagania decyzji w zakresie oceny gotowości do wdrożenia podejścia zwinnego w organizacji pracy zespołu projektowego, analizy stanu aktualnego i wskazania zmian koniecznych w związku pojawiającymi się problemami w jego stosowaniu, a także do oceny lub zbudowania własnej metodyki zwinnej dostosowanej do potrzeb różnych interesariuszy projektów wytwarzania oprogramowania.. 13.

(14) 1. GENEZA I ROZWÓJ ZWINNEGO ZARZĄDZANIA PROJEKTAMI Podejście zwinne, rozumiane jako ogół metodyk zwinnych (Agile) oraz metodyk szczupłych (Lean), jest dzisiaj najpowszechniej stosowanym podejściem w zarządzaniu projektami wytwarzania oprogramowania, a szczególnie w organizacji pracy zespołów projektowych wytwarzających oprogramowanie. Dziś już nie tylko małe przedsiębiorstwa projektowe, ale także duże korporacje informatyczne (IT), teleinformatyczne (ICT) oraz przedsiębiorstwa wysokich technologii (high-tech) tworzą oprogramowanie na potrzeby złożonych systemów informatycznych i informacyjnych stosując podejście zwinne do zarządzania dużymi projektami i programami, do zarządzania portfelem projektów, a nawet do zarządzania całą organizacją. Celem rozdziału pierwszego jest przedstawienie genezy i ewolucji zwinnego podejścia do zarządzania projektami. We współczesnym zarządzaniu podejście to może być różnie definiowane w kontekście zespołu projektowego, projektu, a także całego przedsiębiorstwa. Rozdział prezentuje różnorodność interpretacji podejścia zwinnego, jak i różnorodność definiowania pojęcia zwinności. Ponadto, zawiera porównanie podejścia tradycyjnego oraz zwinnego. 1.1. Ewolucja podejścia zwinnego w zarządzaniu – zarys problematyki Metodyki zwinne (Agile) są relatywnie młode (ich dynamiczny rozwój przypadł na lata 90-te), jednakże geneza i historia podejścia zwinnego sięga, co najmniej pierwszej połowy ubiegłego wieku (Rys. 2). Masowa produkcja, automatyzacja oraz dążenie do maksymalizacji zysku były podstawą rewolucji przemysłowej ubiegłego wieku. Wraz z jej nastaniem człowiek stał się tylko jednostką wykonującą określone, często rutynowe czynności w określony sposób, porzucając naturalne procesy dążenia do doskonałości w swoim fachu. Jednocześnie procesy myślowe stały się domeną kierownictwa, które z kolei często oderwane było od samego procesu produkcji i tym samym możliwości wpływania na nie.. 14.

(15) Rys. 2 Geneza i ewolucja podejścia zwinnego. Źródło: opracowanie własne. 15.

(16) Podobnie rzecz miała się później z projektami, szczególnie projektami wytwarzania oprogramowania, gdzie bardzo dynamiczny rozwój technologii IT oraz ICT spowodował, że narzędzia, automatyzacja, jak również stosowane metodyki zarządzania projektami wyparły w pewien sposób naturalne umiejętności ludzkie do komunikacji, współpracy i wspólnego dążenia do technicznej doskonałości, które to konieczne są przy realizacji złożonych przedsięwzięć, nie tylko na dużą skalę. Formalizacja procesów oraz rozbudowane struktury hierarchiczne pogłębiły jeszcze bardziej wspomniany problem degradacji umiejętności komunikacji i współpracy, czyli mówiąc ogółem osłabienia umiejętności miękkich uczestników zespołów projektowych. Niewątpliwie przyczyniło się to do powstania nowych metod organizacji pracy zespołów projektowych, znacznie bardziej ukierunkowanych na aspekty ludzkie. 1.2. Antecedencje zwinnego podejścia do zarządzania projektami Pierwsze prace nad poszukiwaniem odpowiednich sposobów zapewnienia jakości w produkcji miały miejsce w pierwszej połowie ubiegłego wieku (Rys. 2). Głównym wynikiem prac prekursorów jakości było odejście od liniowości procesów na rzecz regularnie powtarzalnych cykli. Miało to swoje odzwierciedlenie w zarządzaniu projektami w postaci powstania metodyk iteracyjnego i przyrostowego rozwoju produktów IID (Iterative and Incremental Development), które to metodyki szybko znalazły szerokie zastosowanie w projektach wytwarzania oprogramowania (Larman i Basili, 2003; Wysocki, 2011). Drugim ważnym źródłem rozwoju podejścia zwinnego w zarządzaniu projektami był System Produkcyjny Toyoty (TPS) będący wynikiem japońskiej myśli w zarządzaniu produkcją (Ohno, 1978; 1988). Podobnie było z powstaniem jednej z najbardziej znanych dzisiaj metodyk podejścia zwinnego – metodyki Scrum (Schwaber, 1995), która swoje źródło ma w pracy japońskich uczonych (Takeuchi i Nonaka, 1986). 1.2.1. Podejście iteracyjno-przyrostowe w projektach W celu odkrycia źródeł i genezy podejścia zwinnego (Rys. 2) warto najpierw prześledzić rozwój. procesów. zapewnienia. jakości. produkcji. oraz. koncepcji. zarządzania. popularyzowanych przez ich prekursorów (W. Shewhart, W.E. Deming, J. Juran), a następnie należy zrozumieć źródła problemów w realizacji dużych i złożonych projektów we wczesnych etapach rozwoju zarządzania projektami oraz wynikającą z tych problemów potrzebę zastosowania podejścia iteracyjno-przyrostowego. Twórca statystycznej kontroli jakości – W. Shewhart, pracujący w słynnym Bell Laboratories opracował najpierw ideę karty kontrolnej, do poprawy jakości wytwarzanych 16.

(17) produktów. Następnie w 1939 w opracowanym wcześniej przez siebie Cyklu Shewhart’a składającym się z trzech głównych i sekwencyjnych kroków: specyfikacji (specification), produkcji (production) i kontroli (inspection) wprowadził jedną, ale bardzo istotną zmianę – zapętlił ten cykl, umożliwiając tym samym ciągłą poprawę procesu (Shewhart, 1939). To właśnie informacja w postaci sprzężenia zwrotnego otrzymanego z wyników końcowej kontroli jakości była podstawą do ciągłego ulepszania procesu produkcji w przedstawionej przez niego statystycznej kontroli jakości (SPC). Cykl Shewhart’a został tak nazwany, a później też zmodyfikowany przez kolegę W. Shewart’a z Bell Laboratories, mianowicie przez W.E. Deminga, kolejnego słynnego prekursora jakości. W.E. Deming zaproponował czteroetapowy cykl ciągłego doskonalenia (kaizen) w postaci czterech kroków nazwanych cyklem PDCA (Plan Do Check Act) lub później cyklem Deming’a: najpierw planuj, później wykonuj, następnie sprawdź, a na końcu podejmij działanie usprawniające proces – krok ten był nowym w stosunku do cyklu W.Shewhart’a – i wróć do początku cyklu (Deming, 1950). Warto już na tym etapie zaznaczyć, że cykl ten bardzo przypomina ideę sprintu w metodyce zwinnej Scrum, gdzie planowanie sprintu, realizacja zadań, przegląd sprintu i retrospektywa, stanowią poszczególne kroki powtarzane regularnie w kolejnych iteracjach. Podstawą koncepcji cyklu Deminga i zarazem przełomową zmianą była idea pomiaru jakości już w trakcie produkcji poprzez ciągłą obserwację procesu i wprowadzanie do niego nawet niewielkich usprawnień, które długofalowo skutkowały poprawą całego procesu. Zaraz po II wojnie światowej W.E. Deming wyjechał do Japonii nauczać nowoczesnego podejścia do zarządzania jakością, gdzie stał się autorytetem w tej dziedzinie, a jego koncepcje podstawą narodzin i rozwoju Toyota Production System. W Bell Laboratories (a później także w AT&T) razem z dwójką wyżej wspomnianych współpracował jeszcze jeden z uznanych autorytetów w dziedzinie jakości – J. Juran. Efektem prac nad statystyczną kontrolą jakości była publikacja „Quality Control Handbook” (Juran, 1951), która została doceniona przez JUSE (Japanese Union of Scientists and Engineers), czego efektem było zaproszenie J. Jurana do Japonii na cykl wykładów poświęconych jakości. J. Juran (1951) był twórcą zasady 80/20 (nazwanej przez niego Pareto) wyjaśniającej różne zjawiska z obszaru ekonomii i zarządzania, polegającą na tym, że 80% obserwowanych zdarzeń pochodzi z 20% badanych źródeł.. 17.

(18) Rys. 3 Podejście iteracyjno iteracyjno-przyrostowe rzyrostowe (IID). Źródło: opracowanie własne na podstawie: Polytechnique Montreal (2014 2014). Wspomniane prace nad zapewnieniem jakości miały z pewnością znaczenie nie tylko w produkcji, ale również w zarządzaniu projektami. Pierwsze wzmianki na temat zastosowania podejścia iteracyjnego i przyrostowego rozwoju produktu (IID) pochodzą z realizacji projektu naddźwiękowego samolotu X-15 X z 1950 roku (Larman (Larman i Basili Basili, 2003,, s. 47). Podejście IID (Rys. Rys. 3) zakłada cykl życia rozwoju produktu składający się z określonej liczby powtórzeń (iteracji iteracji),, w ramach ramach, których następuje ten sam sekwencyjny zestaw działań w postaci: wstępnego planowania; planowania właściwego; definiowania wymagań, analizy i projektowania; implementacji, wdrożenia, testowania i oceny końcowej (Polytechnique Montreal, 2014). 2014). Iteracje mają ustalony lony czas trwania oraz dotyczą trzech etapów rozwoju produktu: planowania i projektowania, wykonania i testowania produktu: stowania oraz testowania i wdrożenia. W 1958 roku część osób pracujących nad projektem X X-15 15 zasiliła szeregi zespołu pracującego nad rządowym projektem Mercury (NASA) i był były y to jedne z pierwszych prób zastosowania podejścia IID do projektów projekt wywarzania opro oprogramowania gramowania, a z kolei doświadczenia wyniesione z tego projektu stały się udziałem członków zespoł zespołów,, którzy przeszli później do projekt projektów ów realizowanych w IBM Federal Systems Division (FSD), również z wykorzystaniem podejścia IID (Larman i Basili, 2003, s. 47). 47) G.M. Weinberg, Weinberg który był managerem w projekcie Mercury, w ramach swoich osobistych wspomnień podkreślał, że pierwsze praktyki związane z podejściem IID były stosowane na długo zanim w ogóle pojawiła się metodyka zwinna XP, a nawet zanim zaczął pracę w projekcie Mercury, ponieważ już rok wcześniej wraz z H. Jacobs’em i kolegami pracowali nad złożonym projektem z ich wykorzystaniem – symulacją dla firmy Motorola ((Larman Larman i Basili, 2003, 2003 s. 48). ). W latach 1968-1969 1968 1969 pojawiły się pierwsze oficjalne publikacje opisujące i rekomendujące podejście IID jako efekt doświadczeń projektowych pochodzących z IBM T.J. Watson Research Center ((Randell Randell i Zurcher Zurcher, 1968). ). 18.

(19) W 1970 roku W.W. Royce przedstawił proces sekwencyjnej realizacji dużych i złożonych projektów wytwarzania oprogramowania w ramach ograniczeń i założeń narzucanych mu przez kontrakty rządowe (proces rozpowszechniony mocno w projektach NASA). Model przedstawiający tę koncepcję (w różnych odmianach) nazywany jest do dziś modelem kaskadowym, bardzo często utożsamiany jest z tradycyjnym sposobem realizacji projektów, a jego idea działania poddawana jest nieustannej krytyce i stoi w kontraście do podejścia zwinnego, przy czym najczęściej zapomina się lub pomija założenia i ograniczenia źródłowe w jakich on powstał i do czego służył. W modelu kaskadowym zakładano, że prace w projekcie da się z góry dokładnie przewidzieć z dużym prawdopodobieństwem, a zidentyfikowane raz wymagania nie będą się zmieniać przez cały cykl życia projektu, w związku, z czym, wszystkie zdarzenia i etapy projektu następowały po sobie sekwencyjnie, począwszy od zbierania wymagań, przez projekt biznesowy i techniczny, następnie realizację zaplanowanych zadań, po poszczególne etapy testów, a kończąc cały proces sprawdzaniem jakości gotowego produktu i jego wdrożeniem (Royce, 1970). Takie podejście często kończyło. się. bardzo. drogim. procesem. naprawczym,. ponieważ. długoterminowe. przewidywanie i planowanie nie sprawdzało się, a rzeczywistość w otoczeniu projektów zmieniała się dynamicznie, przez co zmieniały się też oczekiwania i wymagania klientów. Dodatkowo rozbudowana struktura hierarchiczna wprowadzała wiele problemów i ograniczeń, głównie spowodowanych licznymi błędami w komunikacji oraz ograniczeniami w rozwiązywaniu problemów spowodowanymi brakiem elastycznych procesów. W latach 1970-1975 podejście IID było z powodzeniem stosowane i rozwijane w dużych i złożonych projektach wytwarzania oprogramowania we wspomnianym wcześniej IBM Federal Systems Division (FSD), a jako największe zalety tego podejścia uważano wtedy możliwość tworzenia prostych rozwiązań, pozyskiwanie informacji zwrotnej pochodzącej z działającego produktu oraz możliwość jego sukcesywnego ulepszania w trakcie kolejnych iteracji na podstawie pozyskanej dotąd wiedzy (Basili i Turner, 1975; Larman i Basili, 2003). Na bazie własnych doświadczeń z podejścia IID T. Gilb (1976) wprowadził nowe określenie ewolucyjnego zarządzania projektami, w którym termin „ewolucji” przedstawił jako technikę małych kroków w tworzeniu złożonego oprogramowania lub systemu oraz pomiaru wyników za pomocą jasno zdefiniowanych metryk umożliwiających eliminację błędów na bardzo wczesnym etapie. Zarówno T. Gilb (1976), jak i znany już z projektu Mercury – G.M. Weinberg (1980) mocno podkreślali potrzebę włączenia klienta lub użytkownika tworzonych rozwiązań na każdym etapie rozwoju tworzonego oprogramowania. 19.

(20) w celu wykorzystania pochodzącej od niego informacji zwrotnej do wczesnego reagowania na błędy lub zmiany w wymaganiach. Śledząc historię rozwoju podejścia IID warto też zwrócić uwagę na model spiralny tworzenia oprogramowania oparty o priorytetyzowanie zadań na podstawie oceny ryzyka w każdej iteracji (Boehm, 1985). B. Boehm nie był pierwszym, który próbował wykorzystać priorytetyzacje cykli na podstawie analizy ryzyka (proponował to wcześniej np. T. Gilb), jednak to on pierwszy przedstawił i sformalizował taką koncepcję. Kolejne lata to już stały i konsekwentny rozwój podejścia IID, a zarazem nasilająca się krytyka podejścia kaskadowego (Brooks, 1987). Z czasem zmiany nastąpiły również w konserwatywnych standardach i rekomendacjach rządowych dotyczących zarządzania projektami – US Department of Defense (DoD) w 2000 roku wprowadził standard 5000.2 rekomendujący podejście ewolucyjne IID w projektach wytwarzania oprogramowania (Larman i Basili, 2003). Jak łatwo możemy dostrzec wiele cech i zalet podejścia IID zostało wprost przeniesione lub zaadaptowane na poczet późniejszego rozwoju metodyk zwinnych. 1.2.2. Japońska myśl zarządzania a rozwój metodyk zwinnych Rozwój metodyk zwinnych miał też drugie bardzo ważne (a może nawet znacznie ważniejsze) i niezależne źródło – System Produkcyjny Toyoty (TPS), rozwijany w latach 1956-1980. Kiedy w USA rozwijało się podejście IID oraz model kaskadowy w zarządzaniu projektami w dalekiej Japonii rozwijał się system zarządzania produkcją TPS wraz ze znanymi później na całym świecie koncepcjami lean oraz kanban. Tyle, że w odróżnieniu od tego, co działo się USA, w Japonii pierwsza oficjalna publikacja twórcy systemu TPS T. Ohno ukazała się w 1978 w języku japońskim, a dopiero w 1988 w języku angielskim. Podstawowym założeniem koncepcji Systemu Produkcyjnego Toyoty było dążenie do doskonałości procesów i ludzi, co pozwala już w samym założeniu dostrzec fundamentalną zgodność metodyk zwinnych z założeniami systemu TPS, przy czym nie jest to jedyny ich wspólny mianownik. W systemie TPS każdy pracownik przedsiębiorstwa obdarzony był z góry zaufaniem, traktowany był na równi ze wszystkimi, jako jednostka myśląca, dążąca do doskonałości poprzez eliminację marnotrawstwa oraz chęć do ciągłego rozwoju i nauki (Ohno, 1988). Wobec takiego podejścia każdy pracownik miał możliwość udziału w rozwiązywaniu problemów, poprawie bezpieczeństwa, poprawie jakości oraz w zmniejszaniu kosztów na każdym etapie produkcji, a rolą kierownictwa było motywowanie pracowników do podejmowania tych możliwości, a tym samym do ciągłego ich doskonalenia (Ohno, 1988).. 20.

(21) Nie bez powodu Japończycy zaprosili do siebie prekursorów jakości w osobie J. Juran’a czy W.E. Deming’a, którego cykl PDCA został wykorzystany w TPS jako sposób myślenia i uczenia się z praktyki działania. Podstawą doskonalenia i poprawy jakości procesów w systemie TPS było ograniczanie marnotrawstwa poprzez rozwiązywanie problemów od razu w momencie ich pojawienia się, co pozwalało z kolei rozwijać i doskonalić tych pracowników, którzy myśleli jak ten proces usprawnić (Ohno, 1988). Pomocnym elementem systemu TPS był system kanban służący do komunikacji wewnątrz procesów i pomiędzy procesami. Kanban pozwalał zwizualizować cały przekaz informacji, a tym samym znacznie ułatwiał zrozumienie działania tych procesów i ich modyfikowanie. W Toyocie najważniejszym elementem systemu był człowiek jako jednostka myśląca, stąd inwestycja w rozwój jego zdolności, a to z kolei budowało kulturę firmy opartą na ciągłym uczeniu się i szacunku do każdego pracownika. Koncepcja TPS odnosiła się do systemu produkcyjnego i nazywana była również produkcją szczupłą (Lean Production). W 1990 przeniesiona została na obszar zarządzania tworząc „szczupłe zarządzanie” (Lean Management), a stąd droga do zarządzania zespołami projektowymi była już bliska. Koncepcje, założenia i cechy podejścia lean zostały odzwierciedlone w tym, co później stanowiło podstawę zasad oraz wartości ustalonych przez twórców „Manifestu Agile”1, a tym samym przyczyniły się one do rozwoju metodyk zwinnych. Źródłem metodyki zwinnej Scrum (a później też całego podejścia zwinnego) był przełomowy artykuł „The New New Product Development Game” autorstwa dwóch japońskich profesorów Hirotaka Takeuchi i Ikujiro Nonaka, który ukazał się w 1986 roku w Harvard Business Review. Autorzy za cel swojej analizy obrali zespoły projektowe i projekty, a w szczególności sposób tworzenia nowych produktów w projektach dużych firm produkcyjnych o największej wydajności jak Hawlett-Packard, Fuji-Xerox czy Honda, jednocześnie odnosząc się do wad modelu kaskadowego rozpowszechnianego w tym czasie przez projekty NASA w Stanach Zjednoczonych. H. Takeuchi i I. Nonaka (1986) porównali sposób pracy zespołów projektowych nad nowymi produktami do zasad gry w rugby opisując holistyczne procesy produkcyjne, a pracę najlepszych zespołów odnosząc do rugbystów uczestniczących w młynie (scrum). Kluczem do wysokiej wydajności zespołów projektowych był z jednej strony bardziej elastyczny proces, który zakładał zrównoleglenie zadań i tym samym przyspieszenie realizacji całości prac, a z drugiej strony autonomiczność zespołów, 1. Manifest programowania zwinnego lub Manifest zwinnego wytwarzania oprogramowania nazywany jest w skrócie Manifestem Agile (oryginalna nazwa to Agile Manifesto, Manifesto for Agile Software Development). Sama nazwa Agile, podawana w rozumieniu filozofii podejścia zwinnego jest powszechnie stosowana w języku polskim zamiennie z jej dosłownym tłumaczeniem – „zwinny”.. 21.

(22) które same podejmowały decyzje i nawzajem się uzupełniały (Takeuchi i Nonaka, 1986). Zadaniem kierownictwa było ułatwianie realizacji zadań i usuwanie przeszkód stojących na drodze zespołów projektowych, a więc podobnie jak w systemie TPS była to rola służebna, którą w metodyce Scrum dostrzeżemy później w roli mistrza scruma (Scrum Master). Na początku lat 90-tych Jeff Sutherland pracując w firmie Easel poszukiwał lepszego sposobu organizacji pracy zespołu projektowego tworzącego oprogramowanie, a trafiając na powyższy artykuł japońskich uczonych postanowił wykorzystać proponowaną przez nich metodę i tym samym rozpoczął pierwsze prace nad metodyką zwinną Scrum. Należy zauważyć już na wstępie, że tak jak i w przypadku systemu Toyoty, tak i w przypadku Scruma nie chodziło o samą metodykę, a o całkowitą zmianę sposobu myślenia i postępowania. W 1995 roku Ken Schwaber i Jeff Sutherland zaprezentowali oficjalnie koncepcję metodyki Scrum („SCRUM Development Process”) na konferencji OOPSLA’95 w Austin w stanie Texas (Schwaber, 1995). Od tego momentu do dzisiaj obaj razem pracują nad kolejnymi wersjami metodyki udostępniając kolejne wersje elektronicznego podręcznika „The Scrum Guide” (Schwaber i Sutherland, 2017). Krótkie, stałej długości, regularnie planowane i powtarzane iteracje, w ramach, kórych zespół dostarcza działający kawałek produktu, podlegający ocenie i dalszym modyfikacjom w kolejnych iteracjach stały się „wizytówką” idei działania metodyki Scrum. Lata 90-te to już bardzo dynamiczny rozwój podejścia zwinnego oraz pojawienie się całej rodziny metodyk zwinnych (Rys. 2, Rys. 4). Przyglądając się mapie ewolucji metodyk zwinnych (Rys. 4) możemy dostrzec, po pierwsze, mnogość różnych i niezależnych źródeł, a po drugie, zauważyć jak przebiegały równoległe kierunki rozwoju metodyk zwinnych prowadzących do powstania „Manifestu Agile” (Abrahamsson et al., 2003). Metodyki zwinne koncentrują się bardziej na aspektach miękkich niż procesowych, kładąc nacisk na: kreatywność członków zespołów projektowych; działające oprogramowanie jako miernik postępu prac w projekcie i gotowości produktu do wydania; relację i częstą komunikację z klientem w celu pozyskania informacji zwrotnej do oceny działającej części produktu oraz adaptacyjne planowanie i reagowanie na zmiany w projekcie (Abrahamsson et al., 2003). Część metodyk zwinnych i ich autorów zasługuje jednak na szczególne wyróżnienie (Rys. 2), ponieważ ich koncepcje stanowiły przyczynek do późniejszego powstania „Manifestu Agile”.. 22.

(23) Rys. 4 Ewolucja metodyk zwinnych. Źródło: opracowanie własne na podstawie: Abrahamsson et al. (2003). W roku 1996 K. Beck, W. Cunningham i R. Jeffries w ramach prac nad projektem C3 zaproponowali zwinną metodykę programowania ekstremalnego XP (eXtreme Programming), której podstawę stanowił zbiór czterech wartości: odwagi, prostoty, komunikacji, informacji zwrotnej oraz dwanaście praktyk związanych z prostotą i krótkimi iteracjami, szybkim pozyskiwaniem informacji zwrotnej zwrotnej,, ciągły ciągłym procesem proces testowania i planowania, dużym zaangażowaniem aangażowaniem klienta klienta oraz współpracą zespołową opartą na pracy w parach ((Beck, Beck, 1999). 1999 Rok wcześniej brytyjskie konsorcjum DSDM (obecnie Agile Business) przedstawiło pierwszą wersję metodyki zwinnej DSDM (Dynamic Systems Development Method), której koncepcja powstała na bazie bazie doświadczeń 16 praktyków korzystających wcześniej z metodyki RAD (Rapid Application Development). Metodyka szybkiego tworzenia aplikacji (RAD) otwierała programistom możliwość korzystania z istniejących komponentów w celu szybkiego prototypowania i uzysk uzyskania ania wyników już we wczesnych fazach etapu programowania. Metodyka DSDM zakładała zakładała,, że zadania wykonywane w celu wytworzenia oprogramow nia podlegają ciągłym zmianom (DSDM oprogramowania DSDM Consortium Consortium, 1994).. A. Cockburn (1998; 2001) stworzył całą rodzinę metodyk zwinnych Crystal opierając ich koncepcję na wynikach badań przeprowadzonych wśród zespołów, które brały udział w pomyślnie zakończonych projektach. Nacisk w metodykach zwinnych Crystal położony 23.

(24) został na: ludzi i interakcje, społeczności (communities), umiejętności (skills), zdolności (talents) i komunikację (Cockburn, 2001). A. Hunt i D. Thomas (1999) zaproponowali koncepcję Pragmatic Programming (PP) w postaci zbioru porad jak usprawnić proces wytwarzania oprogramowania z pragmatycznego punktu widzenia. Głównymi cechami pragmatycznego programisty były umiejętność wczesnej i szybkiej adaptacji, dociekliwość i krytyczne myślenie, realizm oraz uniwersalne podejście (Hunt i Thomas, 1999). Drugą znaczącą metodyką, która powstała obok metodyki DSDM, ale mającą korzenie w tej samej metodyce szybkiego tworzenia aplikacji RAD była metodyka zwinna Adaptive Software Development (ASD) opracowana przez J. Highsmith’a i S. Bayer’a w roku 2000. Głównym założeniem metodyki ASD była ciągła adaptacja procesu do realizowanych prac, skąd wynikały takie jej cechy jak iteracyjność, skupienie na misji i celu, współpraca, tolerancja dla zmian czy sterowanie ryzykiem (Highsmith, 2000). 1.2.3. „Manifest programowania zwinnego” i jego znaczenie W roku 2000 nastąpił bardzo dynamiczny rozwój metodyk zwinnych, a Bob Martin postanowił. zainicjować. organizację. historycznego. spotkania. grupy. wizjonerów. i. zwolenników nowego podejścia do wytwarzania oprogramowania, które stanowiłoby alternatywę podejścia tradycyjnego opartego na modelu kaskadowym. Spotkanie 17 myślicieli i wizjonerów odbyło się w lutym 2001 roku w ośrodku narciarskim „The Lodge at Snowbird” w górach Wasatch w stanie Utah (Rys. 5). Wynikiem spotkania był „Manifest programowania zwinnego” (Manifesto for Agile Software Development) stanowiący deklarację i zbiór podstawowych wartości oraz zasad, które w prosty i jasny sposób oddają filozofię zwinności. Treść „Manifestu Agile” jest następująca (Beck et al., 2001): „Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić: . Ludzi i interakcje od procesów i narzędzi;. . Działające oprogramowanie od szczegółowej dokumentacji;. . Współpracę z klientem od negocjacji umów;. . Reagowanie na zmiany od realizacji założonego planu.. Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.”. 24.

(25) Rys. 5 Twórcy "Manifestu Agile". Źródło: U. Banerjee (2012). Autorzy „Manifestu Agile” (Rys. (Rys. 5)) określili również ddwanaście wanaście podstawowych zasad zwinnego tworzenia oprogramowania, które brzmią następująco (Beck et al., al. 2001): „1) Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania. 2) Bądźcie ądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnie zapewnienia nia klientowi konkurencyjności. 3) Dostarczajcie funkc funkcjonujące jonujące oprogramowanie często, w kilkutygodniowych llub kilkumiesięcznych odstępach. Im częściej, tym lepiej. 4) Zespoły biznesowe i dew deweloperskie eloperskie muszą ściśle ze sobą współpracować w codziennej codzienne pracy przez cały czas trwania projektu. 5) Twórzcie projekty proj wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisk środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie. 6) Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz. deweloperskiemu 25.

(26) 7) Działające oprogramowanie jest podstawową miarą postępu. 8) Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy. 9) Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność. 10) Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa. 11) Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów. 12) W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.” Cztery główne idee zawarte w „Manifeście Agile” przyjęto dość szybko w ramach konsensusu. Nazwę Agile dla Manifestu zasugerował na spotkaniu J. Highsmith i było to jedyne ustalenie tamtego spotkania przyjęte w drodze głosowania. Dwanaście zasad zawarte w Manifeście zostało z kolei wstępnie ustalonych drugiego dnia spotkania, a sfinalizowano je w drodze komunikacji elektronicznej w ciągu kilku następnych miesięcy. Zwinny (agile) jako słowo - przymiotnik oznacza tu „potrafiący myśleć, rozumieć i poruszać się szybko i łatwo” (Oxford Dictionaries, 2017). Natomiast podejście zwinne (Agile 2 ) jest dużo szerszym pojęciem obejmującym liczny zbiór standardów, metodyk, technik oraz praktyk możliwych do wykorzystania w zarządzaniu zespołami projektowymi, projektami, a nawet w kontekście zarządzania całą organizacją. Nierozłącznymi cechami podejścia zwinnego są atrybuty takie jak: przyrostowość, kooperatywność, prostota oraz adaptacyjność (Abrahamsson et al., 2003). Głównymi elementami filozofii Agile są narzędzia i procesy, praktyki, zasady, wartości oraz najważniejsze - sposób myślenia (mindset) (Highsmith, 2004). Agile jako sposób myślenia, podobnie jak w systemie produkcyjnym Toyoty, jest znacznie ważniejszy od jakiejkolwiek metodyki, procesu, systemu, technik, praktyk czy struktury organizacyjnej (Denning, 2016a; 2016b). Ten sam mindset powoduje, że wszyscy w organizacji koncentrują się na dostarczeniu klientowi jak największej wartości w jak najkrótszym czasie oraz to, że każdy może porozmawiać z każdym (pracownicy, kierownictwo, klienci i użytkownicy), aby osiągnąć ten nadrzędny cel (Denning, 2016a).. 2. Agile jako filozofia podejścia zwinnego może stanowić nazwę własną, a więc podawana będzie dalej z dużej litery, w odróżnieniu od przymiotnika „zwinny” (agile) określającego cechę jakiegoś elementu lub podmiotu.. 26.

(27) Rys. 6 Filozofia Agile. Źródło: Opracowanie własne na podstawie: S. Powers (2016). S. Powers (2017) dokonał ciekawej analizy i syntezy, tego, co składa się na sposób myślenia zawarty w filozofii filoz fii Agile (Rys. (Rys. 6)) bazując na trzech przeświadczeniach: . złożoności oności – próba rozwiązania złożonych problemów adaptacyjnych niesie ze sobą zmianę natury samego problemu oraz rozwiązanie końcowe nie jest możliwe do przewidzenia na samym początku,. . ludzi – z założenia każdy ma dobre intencje, ponieważ nadrzędnym jego celem jest bycie częścią czegoś większego niż on sam sam; każdy ażdy ma też pewien potencjał pod warunkiem, że ma zaspokojone podstawow podstawowee potrzeby życiowe,. . proaktywności – w nieustającym dążeniu do poprawy, ponieważ jest ona nieodłączną częścią procesu empirycznego.. Warto podkreślić, że „„Manifest Manifest Agile Agile” pozostaje od ponad 17 lat niezmieniony, nie pozostawiono również takiej opcji w momenci momenciee jego tworzenia, a jednocześnie nadal zachowuje on swoją ponadczasową wartość i znaczenie w ewolucji zwinnych metod organizacji pracy zespołów projektowych oraz zwinnych metodyk zarządzania projektami projektami, co w przypadku bardzo dynamicznego rozwoju metod zarządzania zarządzania projektami wytwarz wytwarzania oprogramowania zasługuje na szczególne uznanie. oprogramowania Po ogłoszeniu „Manifestu Agile” nadal nadal powstawały i powstają kolejn kolejnee odmiany metodyk zwinnych (Rys. Rys. 2) jak choćby rozpoznawane i bazujące na znanych koncepcjach lean – Lean Software Development ((M. M. Poppendieck i T. Poppendieck, Poppendieck, 2003 2003) czy kanban – Kanban Software Development elopment (Anderson, 2010). Co ciekawe, nawet najbardziej rozpoznawane na świecie organizacje tworzące od lat standardy zarządzania projektami tworzą własne adaptacje metodyk uniwersa uniwersalnych lnych uwzględniające filozofię A Agile, gile, czego dobrymi 27.

(28) przykładami są PMI-ACP (PMI, 2016) oraz Prince2 Agile (Richards, 2015). Z całą pewnością można powiedzieć, że rozwój podejścia zwinnego nadal trwa – dobrym przykładem może tu być rozwijająca się koncepcja DevOps. 1.3. Definiowanie zwinności we współczesnym zarządzaniu projektami W podejściu zwinnym, zarówno w terminologii polskiej, jak i angielskiej funkcjonuje pojęcie zwinności (agility) rozumiane jako pewna cecha lub właściwość danego podmiotu mówiąca o szybkości, lekkości i łatwości poruszania się – mówi się, więc o byciu zwinnym (to be nimble). Źródłem licznych analiz, interpretacji oraz tworzenia autorskich definicji zwinności są podstawy koncepcji podejścia zwinnego, a przede wszystkim zawarty w nim: sposób myślenia (mindset) oraz wartości i zasady zwinnego wytwarzania oprogramowania przedstawione w Manifeście Agile (Williams i Cockburn, 2003; Sharp i Ryan, 2008), a dopiero w dalszej kolejności również praktyki stosowane w ramach metodyk zwinnych (Singh et al., 2014; Recker et al., 2017). Zwinność może być interpretowana jako (Highsmith, 2002; Wysocki, 2011): . umiejętność inicjowania i reagowania na zmiany w celu osiągnięcia zysku w globalnym i turbulentnym środowisku biznesowym,. . umiejętność szybkiej zmiany priorytetów w wykorzystywaniu zasobów w trakcie, gdy zmieniają się wymagania, technologia i wiedza,. . bardzo szybka reakcja w odpowiedzi na nagłe zmiany rynkowe i pojawiające się zagrożenia spowodowane intensywną interakcją z klientami,. . zastosowanie. ewolucyjnego,. przyrostowego. oraz. iteracyjnego. (regularnie. powtarzanego w cyklach) dostarczania produktu w celu uzyskania optymalnego rozwiązania dla klienta, . maksymalizowanie wartości biznesowej za pomocą odpowiednio dobranych i dopasowanych do potrzeb danej chwili procesów oraz dokumentacji.. Zwinność jest pojęciem wielowymiarowym, które jest definiowane i klasyfikowane na różne sposoby w zależności od: . podmiotu badań lub rozważań – zespołu projektowego (Sharp i Ryan, 2008; Lee i Xia, 2010), metodyki zarządzania projektami (Qumer i Henderson-Sellers, 2008a; Conboy, 2009), empirycznego procesu wytwarzania oprogramowania (Williams i Cockburn, 2003), projektu i jego otoczenia (Mafakheri et al., 2008; Sheffield i Lemétayer, 2013), bądź przedsiębiorstwa projektowego (Sherehiy et al., 2007; Berg, 2008; Appelbaum et al., 2017), 28.

(29) . kontekstu badań – np. branży produkcyjnej (Vazquez-Bustelo et al., 2007), bądź projektów wytwarzania oprogramowania (Cockburn i Highsmith, 2001),. . przyjętej perspektywy badawczej – np. wpływu praktyk zarządzania na zwinność (Recker et al., 2017), bądź zwinności jako metryki do pomiaru wyników przedsiębiorstwa (Yauch, 2011),. . pochodzenia autora, który może reprezentować punkt widzenia praktyki zarządzania, własny lub przynależny do danej organizacji (Berg, 2008), bądź też akademicki, ściśle związany z badaniami naukowymi (Conforto et al., 2016).. Zagadnienie zwinności rozpatrywane jest często w kontekście: zarządzających (kierownictwa), pozyskiwania i kontraktowania, planowania strategicznego, analizy zdolności podmiotu,. zarządzania. programami. i. projektami,. rozwijania. systemów,. zmiany. organizacyjnej, systemów informacyjnych, procesów i praktyk, narzędzi oraz technologii. Wielowymiarowość zwinności rozciąga się od stylów kierowania po aspekty technologicznie, co pokazuje, że zakres tego pojęcia zdecydowanie wykracza poza wąski obszar IT, jednak w kolejnych rozdziałach pracy to zwinność zarządzania zespołami projektowymi będzie stanowić główny punkt uwagi. Szerokie możliwości zastosowania podejścia zwinnego w praktyce zarządzania oraz duże zainteresowanie środowiska naukowego przyczyniły się do powstania w literaturze obcojęzycznej, jak i polskojęzycznej wielu, bardzo często równoznacznie traktowanych i zamiennie stosowanych pojęć określających podejście zwinne. W literaturze obcojęzycznej, a szczególnie w terminologii stosowanej w publikacjach naukowych czasopism z listy filadelfijskiej, najczęściej stosowanym pojęciem jest podejście zwinne (agile methods) w szerokim rozumieniu standardów, procesów, metodyk, technik oraz praktyk (Moe et al., 2010; Serrador i Pinto, 2015; Dikert et al., 2016). Drugim bardzo często stosowanym terminem są metodyki zwinne sensu stricte (agile methodologies lub agile methods) rozumiane jako zbiór zasad i wytycznych dotyczących sposobów planowania i realizacji prac w projekcie (Williams i Cockburn, 2003; Nerur et al., 2005; Annosi et al., 2016). Inne alternatywnie stosowane pojęcia to: procesy zwinne (agile processes) (Schwaber, 2004; Boehm i Turner, 2005), zwinne zarządzanie projektami (agile project management) (Hossain et al., 2009; Wysocki, 2011; Conforto et al., 2014), zwinne wytwarzanie oprogramowania (agile software development) (Cockburn i Highsmith, 2001; Dyba i Dingsoyr, 2008), zwinne wytwarzanie systemów (agile system development) (Abrahamsson et al., 2009) oraz zwinność (agility) stosowana w różnych kontekstach jako pewna cecha i konstrukt teoretyczny w zarządzaniu projektami (Conboy, 2009; Conforto et al., 2016), a 29.

(30) szczególnie w wytwarzaniu oprogramowania (software development agility) (Lee i Xia, 2010; Sheffield i Lemétayer, 2013). W literaturze polskojęzycznej mnogość pojęć przedstawiających różne aspekty podejścia zwinnego wydaje się być jeszcze bogatsza niż w literaturze obcojęzycznej pomimo znacznie mniejszej ilości dostępnych publikacji w tej tematyce. Najczęściej stosowanymi i zamiennie używanymi terminami są tutaj: podejście zwinne (Spałek i Zdonek, 2013; Łabuda, 2015; Spałek, 2018), podejście lekkie (Trzeciak i Spałek, 2016), koncepcja i filozofia zwinna (Chrapko, 2013), metody i metodyki lekkie (Szyjewski, 2004; Ćwiklicki et al., 2010; Chmielarz, 2012), metody i metodyki zwinne (Wyrozębski, 2011a; Woźniak, 2015), zwinne zarządzanie projektami (Wyrozębski, 2011a; Spałek, 2018) oraz zwinność jako cecha i pojęcie używane w różnych kontekstach zarządzania projektami (Wendler, 2013; Lasek i Adamus, 2014), podobnie jak w literaturze obcojęzycznej. Praktycy zarządzania częściej stosują termin metody 3 zwinnej (Chrapko, 2003; Kaczor, 2016) zamiast metodyki zwinnej (Wyrozębski, 2011a; Chmielarz, 2012), jednak przy bliższej interpretacji tych pojęć okazuje się, że ich znaczenie jest rozumiane podobnie i pojęcia te mogą być traktowane jak synonimy. Heterogeniczność terminów określających podejście zwinne dla praktyków zarządzania może mieć mniejsze znaczenie, ponieważ większość publikacji dotyczy szerokiego wachlarza podobnych znaczeniowo zagadnień i obejmuje ten sam szeroki kontekst rozważań, co angielskie odpowiedniki podejścia zwinnego. Niemniej jednak różnorodność terminologii powoduje pewien rozdźwięk i problem niespójności, szczególnie w obszarze badań naukowych. To czy dana publikacja naukowa dotyczy szerszego znaczenia – w rozumieniu podejścia zwinnego, czy węższego – jako metodyki zwinnej, zarówno w publikacjach obcojęzycznych, jak i polskojęzycznych zależy w największym stopniu od kontekstu prowadzonych i przedstawianych badań, szczególnie jeśli w całej publikacji stosowane jest konsekwentnie to samo nazewnictwo. Wobec powyższego, autorzy publikacji, w tym prac naukowych, muszą zwracać szczególną uwagę na stosowane nazewnictwo dotyczące podejścia zwinnego oraz na odpowiednie przedstawienie kontekstu swoich badań, tak, aby umożliwić formułowanie jednoznacznie rozumianych teorii oraz aby umożliwić innym odnoszenie się do ich wyników badań. Ze względu na bardzo szeroką gamę możliwości zastosowania podejścia zwinnego autorzy muszą zwracać szczególną uwagę na dokładne rozróżnienie przedmiotu i podmiotu badań. Badania mogą dotyczyć różnego rodzaju aspektów zwinnych metod i technik 3. Rozumiany jako świadomie stosowany sposób postępowania w projekcie lub zespole projektowym mający prowadzić do osiągnięcia zamierzonego celu.. 30.

(31) wytwarzania oprogramowania, zwinnych metodyk zarządzania projektami i programami, zwinnego zarządzania portfelem projektów, jak również zwinnego zarządzania zespołami projektowymi tworzącymi oprogramowanie, z których to ostatnie zagadnienie stanowi przedmiot badań niniejszej rozprawy. Jasne określenie przedmiotu i podmiotu badań jest przede wszystkim ważne ze względu na wspomniane wcześniej zamienne używanie pojęć dotyczących zwinności i samego podejścia zwinnego, ze względu na mnogość obszarów i dyscyplin naukowych, w których jest ono używane oraz ze względu na znaczącą liczbę sposobów ich klasyfikowania oraz definiowania, zarówno w języku polskim, jak i angielskim. Zwinność jest przedmiotem zainteresowań i badań w dwóch głównych nurtach: poznania konstruktu teoretycznego tego zagadnienia oraz poszukiwania sposobów jej pomiaru poprzez ocenę ogólną sukcesu projektu lub bardziej szczegółową – wyników projektu lub zespołów projektowych. Heterogeniczności w definiowaniu zwinności nie da się uniknąć, pomimo, że dla większości definicji istnieje wspólny mianownik w postaci wartości i zasad pochodzących z Manifestu Agile. Liczne definicje zwinności albo powstały na bazie już istniejących, jako ich zapożyczenie, rozwinięcie lub rozszerzenie (Sheffield i Lemetayer, 2013; CegarraNavarro et al., 2016; Gren et al., 2017), albo wynikały wprost z celu, kontekstu, podmiotu lub przedmiotu badań (McAvoy et al., 2013; Chen et al., 2014; Gurd i Ifandoudas, 2014) prowadzonych w ramach szeroko rozumianego zakresu podejścia zwinnego stosowanego w zarządzaniu projektami i zespołami projektowymi. Zwinność często nie jest nazywana i podawana wprost, dopiero po analizie i interpretacji tekstów lub badań okazuje się, że dane rozumienie czy przyjęta perspektywa stanowi właśnie taką definicję (Dyba i Dingsoyr, 2008; Jalali i Wohlin, 2011; Annosi et al., 2016). A. Ganguly et al. (2009, s. 412) analizując różne definicje zwinności przedsiębiorstw wyróżnili sześć zasadniczych cech zwinności: szybkość, koszty, responsywność, elastyczność, jakość i potrzeby klienta. Tylko dwie definicje zwinności przedsiębiorstwa obejmowały wszystkie sześć cech i były to: „zwinność przedsiębiorstwa to skuteczne odkrywanie podstawowych cech decydujących o przewadze konkurencyjnej (szybkości, elastyczności, proaktywności innowacyjnej, jakości i rentowności) poprzez integrację rekonfigurowanych zasobów i zarządzania wiedzą w celu dostarczenia produktów i usług zorientowanych na klienta w szybko zmieniającym się otoczeniu rynkowym” (Yusuf et al., 1999) oraz „zwinność przedsiębiorstwa to zdolność przedsiębiorstwa do skutecznej i efektywnej odpowiedzi na: proaktywne i reaktywne potrzeby oraz na pojawiające się możliwości w obliczu nieprzewidywalnego i niepewnego środowiska” (Dove, 1999; 2001).. 31.

(32) Patrząc z perspektywy całego przedsiębiorstwa definicja zwinności może być „zdolnością do korzystnego prosperowania w konkurencyjnym środowisku charakteryzującym się ciągłymi i nieprzewidywalnymi zmianami w oczekiwaniach klientów” (Goldman et al., 1995) lub inaczej mówiąc sposobem na „adaptacyjne i elastyczne zarządzanie przedsiębiorstwem w dynamicznie i stale zmieniającym się środowisku biznesowym” (Sherehiy et al., 2007). Z perspektywy systemowej zwinność określa cechę „systemu produkcyjnego o określonych możliwościach. i. zdolnościach. (miękkie. i. twarde. techniki,. zarządzanie. ludźmi,. wykwalifikowana kadra zarządzająca, przepływ informacji) będącego w stanie sprostać zmieniającym się potrzebom rynku (szybkości, elastyczności, klientom, konkurencji, dostawcom, infrastrukturze, reaktywności) (Yusuf et al., 1999, s. 37). Dekomponując przedsiębiorstwo na jego elementy składowe można przedstawić zwinność jako „szybką i proaktywną adaptację elementów przedsiębiorstwa do nieoczekiwanych i nieprzewidzianych zmian (Kidd, 1994). Y. Yusuf et al. (1999, s. 448) wyróżnili trzy aspekty zwinności związane z różnymi poziomami przedsiębiorstwa: elementarnym – odnoszącym się do indywidualnych jednostek (ludzi, maszyn i zarządzania), mikrozwinności (micro-agility) – odnoszącym się do przedsiębiorstwa oraz makrozwinności (macro-agility) – odnoszącym się do poziomu oddziaływań i współpracy pomiędzy przedsiębiorstwami. Zwinność jednostki (agile entity) jest „trwałym zachowaniem lub zdolnością wrażliwego podmiotu cechującego się elastycznością w szybkim dostosowaniu się do oczekiwanych lub nieoczekiwanych zmian, poszukiwaniem rozwiązania w najkrótszym możliwym czasie, wykorzystując w tym celu ekonomiczne, proste i wysokiej jakości instrumenty w dynamicznym środowisku oraz stosując zaktualizowaną wcześniejszą wiedzę i doświadczenie do nauki z wewnętrznego i zewnętrznego środowiska” (Qumer i Henderson-Sellers, 2008a). J. Sharp i S. Ryan (2008) zdefiniowali zwinność zespołu (team agility) jako odpowiedź na pytanie w jakim stopniu zespół działa zgodnie z głównymi wartościami i zasadami określonymi w Manifeście Agile, jak również jaka jest zgodność tych działań z wybranymi praktykami stosowanymi w ramach określonych metodyk zwinnych. Definicja ta może nie wyczerpuje rozumienia zwinności w kontekście zespołu projektowego, jednak wydaje się bardzo trafna, a zarazem prosta w zrozumieniu. Z kolei K. Conboy (2009, s. 333-340) skrupulatnie przedstawił proces formowania własnej nadrzędnej definicji zwinności wychodząc z definicji elastyczności (flexibility) i szczupłości (leanless). Przedstawił zasady i metody klasyfikowania zwinności w tworzeniu i rozwoju systemów informacyjnych. K. Conboy (2009, s. 341) zobrazował tę zwinność w kontekście metodyki rozwoju systemów informacyjnych jako pewien ciągły stan gotowości 32.

(33) do szybkiego lub nieodłącznego kreowania potrzebnych zmian, proaktywnego lub reaktywnego działania w obliczu pojawiających się zmian oraz uczenia się na podstawie zmian, przyczyniając się tym samym do zwiększenia wartości postrzeganej przez klienta (ekonomia, jakość i prostota), poprzez zrównoważone współdziałanie jej poszczególnych komponentów oraz uwzględnianie relacji z otoczeniem środowiskowym. Tak postawiona definicja zwinności metodyki bardzo dobrze ujmuje trójstronną relację pomiędzy: zmianą jako nieodłącznym elementem adresowanym przez metodyki zwinne, wartością dla użytkownika. oraz. potrzebą. minimalizowania. kosztów. i. marnotrawstwa. zasobów. projektowych. Zaproponowana definicja zwinności jest na tyle uniwersalna, że pozwala na zastosowanie jej do dowolnego poziomu, a szczególnie do poziomu zespołu projektowego. Analiza teoretyczna konstruktu zwinności oraz jego taksonomia z perspektywy metodyk zarządzania projektami stanowi odrębny i interesujący przedmiot badań w kontekście oceny efektywności danej metodyki (Qumer i Henderson-Sellers, 2008a; Conboy, 2009), a także z perspektywy oceny wykorzystania tej metodyki w projektach wytwarzania oprogramowania (Mafakheri et al., 2008; Sheffield i Lemétayer, 2013). Heterogeniczność definiowania zwinności metodyki zarządzania projektami i jej ocena wymuszona jest rozmaitością sposobów wdrożenia podejścia zwinnego w zarządzaniu projektami, stale powiększającą się grupą metodyk zwinnych oraz częstymi rozwiązaniami hybrydowymi. E. C. Conforto et al. (2016) przedstawili modelową analizę konstruktu zwinności z perspektywy teorii zarządzania projektami, w której szczególną uwagę zwrócili na brak spójności, kompletności oraz jasności tej definicji, a jednocześnie dowiedli, że sam konstrukt zwinności może być spójny i użyteczny w różnych kontekstach zarządzania projektami, w szczególności w projektach wytwarzania oprogramowania oraz projektach przedsiębiorstw wysokich technologii (high-tech). Kluczowe implikacje dla teorii i praktyki zarządzania projektami będące wnioskami z przeprowadzonych badań to (Conforto et al., 2016, s. 660): . zwinność powinna być rozumiana w kontekście wydajności i wyników zespołu, a nie jedynie przymiotnika dla praktyk czy metodyk,. . zwinność jako wydajność, może zależeć od kombinacji czynników dotyczących organizacji, zespołu projektowego i samego projektu,. . poziom wydajności zwinności może być mierzony w kontekście dwóch głównych czynników: zmian szybkości planowania projektu oraz stopnia zaangażowania klienta.. Wynikiem semantycznej analizy definicji zwinności (Conforto et al., 2016, s. 667) w zarządzaniu zespołem projektowym była zdolność do szybkich zmian planu projektu w celu odpowiedzi na potrzeby różnych interesariuszy, w szczególności klientów lub użytkowników 33.