POLITECHNIKA POZNA ´ NSKA
WYDZIAŁ IN ˙ ZYNIERII ZARZ ˛ ADZANIA
Rozprawa doktorska
Wpływ klimatu organizacyjnego na efektywno´s´c zespołów stosuj ˛ acych zwinne metodyki wytwarzania oprogramowania
Autor
mgr Karolina GROBELNA
Promotor
prof. dr hab. in˙z. Stefan TRZCIELI ´ NSKI
Pozna´n, 2020
Spis tre´sci
1 Wprowadzenie 1
1.1 Uzasadnienie podj˛ecia tematu . . . . 1
1.2 Problem badawczy, cele i hipotezy rozprawy . . . . 2
1.3 Metody badawcze zastosowane w rozprawie . . . . 6
1.4 Układ pracy . . . . 8
2 Wytwarzanie oprogramowania 10 2.1 Zespół programistyczny . . . . 10
2.2 Metodyki wytwarzania oprogramowania . . . . 11
2.2.1 Powstanie metodyk wytwarzania oprogramowania . . . . 11
2.2.2 Metodyki tradycyjne . . . . 15
2.2.2.1 Model kaskadowy . . . . 15
2.2.2.2 Model przyrostowy . . . . 19
2.2.2.3 Model prototypowy . . . . 22
2.2.2.4 Model spiralny . . . . 24
2.2.3 Metodyki zwinne . . . . 26
2.2.3.1 Elementy zbie˙zno´sci metodyk zwinnych z koncepcj ˛ a przed- si˛ebiorstwa szczupłego i zwinnego . . . . 26
2.2.3.2 Scrum . . . . 31
2.2.3.3 Kanban . . . . 35
2.2.3.4 Programowanie ekstremalne . . . . 37
2.2.3.5 DSDM . . . . 39
2.2.4 Podsumowanie . . . . 43
3 Klimat organizacyjny 46
3.1 Poj˛ecie klimatu organizacyjnego . . . . 46
3.2 Czynniki klimatu organizacyjnego . . . . 48
3.3 Pomiar klimatu organizacyjnego . . . . 54
3.4 Klimat organizacyjny a motywacja i efektywno´s´c . . . . 59
4 Efektywno´s´c zwinnych zespołów informatycznych 64 4.1 Poj˛ecie efektywno´sci w odniesieniu do zwinnych zespołów informatycznych . 64 4.2 Miary efektywno´sci . . . . 69
4.3 Podsumowanie . . . . 82
5 Klimat organizacyjny a efektywno´s´c zwinnych zespołów informatycznych 84 5.1 Model badawczy . . . . 84
5.2 Metodyka bada´n empirycznych . . . . 88
5.3 Wyniki bada´n empirycznych . . . . 89
5.3.1 Efektywno´s´c w zwinnych zespołach programistycznych . . . . 89
5.3.2 Ewaluacja efektywno´sci zespołów z wykorzystaniem analizy taksono- micznej . . . . 99
5.3.2.1 Metoda TMR . . . . 99
5.3.2.2 Metoda TOPSIS . . . 106
5.3.2.3 Wa˙zona metoda TOPSIS . . . 110
5.3.2.4 Porównanie wyników wybranych metod . . . 114
5.3.2.5 Podział zespołów zwinnych na grupy wg efektywno´sci . . . 117
5.3.3 Klimat organizacyjny w zwinnych zespołach wytwarzaj ˛ acych oprogra- mowanie . . . 118
5.3.4 Istotno´s´c zwi ˛ azku pomi˛edzy klimatem organizacyjnym a efektywno- ´sci ˛ a zwinnych zespołów wytwarzaj ˛ acych oprogramowanie . . . 125
5.3.5 Czynniki klimatu organizacyjnego ró˙znicuj ˛ ace zespoły zwinne pod wzgl˛edem efektywno´sci . . . 129
5.4 Podsumowanie . . . 137
6 Podsumowanie i wnioski 141 6.1 Główne osi ˛ agni˛ecia rozprawy . . . 141 6.2 Przyszłe problemy badawcze . . . 144 6.3 Praktyczne implikacje wyników bada´n . . . 146
Bibliografia 150
Spis rysunków 164
Spis tabel 166
Spis zał ˛ aczników 167
1. Wprowadzenie
1.1 Uzasadnienie podj˛ecia tematu
W dobie informatyzacji i e-gospodarki wytwarzanie produktu informatycznego (produktu IT) jest niezmiernie wa˙zne. W ostatnich latach, na styku informatyki oraz in˙zynierii zarz ˛ adza- nia powstała nowa dyscyplina, jak ˛ a jest zarz ˛ adzanie wytwarzaniem produktów informatycz- nych. Jej praktycznym wykorzystaniem zainteresowane s ˛ a niemal wszystkie przedsi˛ebiorstwa, w szczególno´sci te opieraj ˛ ace swoj ˛ a działalno´s´c na IT, ale równie˙z i te, które działy informa- tyczne wykorzystuj ˛ a jedynie dla swoich wewn˛etrznych potrzeb. Id ˛ ac dalej mo˙zna stwierdzi´c, i˙z jakakolwiek działalno´s´c wykorzystuj ˛ aca ró˙znego rodzaju oprogramowanie b˛edzie czerpała korzy´sci z osi ˛ agni˛e´c i usprawnie´n w wytwarzaniu oprogramowania i zarz ˛ adzaniu nim.
Cyfryzacja gospodarki powoduje, ˙ze klienci oczekuj ˛ a całodobowego dost˛epu do danych, aplikacji czy serwisów transakcyjnych. Ka˙zda niedost˛epno´s´c usług, ka˙zdy przestój w ich ´swiad- czeniu, czy po prostu stagnacja i bark ich rozwoju, w tak konkurencyjnej rzeczywisto´sci b˛edzie powodowa´c olbrzymie straty dla firmy [Jankowski 2015]. Dlatego przedsi˛ebiorstwa coraz wi˛ek- sze znaczenie przykładaj ˛ a do kwestii zabezpieczenia i rozwoju systemów informatycznych.
Dost˛epno´s´c usług teleinformatycznych oraz wynikaj ˛ ac ˛ a z niej ci ˛ agło´s´c biznesow ˛ a, jest zapew- niana poprzez odpowiedni sprz˛et i innowacyjne oprogramowanie. Zatem w interesie całego społecze´nstwa – społecze´nstwa informatycznego - jest rozwój tej dyscypliny.
Praca zawodowa autorki w roli osoby odpowiedzialnej za jak najszybszy rozwój oprogra-
mowania i codzienna obserwacja pracy zwinnych zespołów programistycznych pozwoliły za-
uwa˙zy´c, i˙z intuicyjnie rozumiana i dostrze˙zona w praktyce efektywno´s´c pracy tych zespołów
charakteryzuje si˛e cykliczno´sci ˛ a. Co wi˛ecej wydawała si˛e mie´c ona bezpo´sredni zwi ˛ azek z eta-
pem prac nad produktem i poziomem jego dojrzało´sci. Jednak˙ze ró˙zne zespoły ulegały ró˙znym,
co do wielko´sci, wahaniom efektywno´sci przy zachowaniu jednolitej metodyki wytwarzania oprogramowania. Zespoły ró˙zni ˛ a si˛e mi˛edzy sob ˛ a przede wszystkim: wielko´sci ˛ a, ró˙znorodno-
´sci ˛ a członków pod wzgl˛edem wieku, płci, wykształcenie, sta˙zu pracy czy kompetencji, osob ˛ a lidera/kierownika (jego do´swiadczeniem i podej´sciem do zarz ˛ adzania zespołem), przyj˛etymi metodami komunikacji czy panuj ˛ acymi relacjami mi˛edzyludzkimi. W zespołach tych panuje ró˙zny klimat organizacyjny, na co wskazuje wła´snie ró˙zna atmosfera w zespołach, styl kierowa- nia przeło˙zonego, style komunikacji czy stosowane standardy oraz poziom autonomii członków zespołu.
Wzbudziło to ciekawo´s´c badawcz ˛ a autorki czy istnieje zwi ˛ azek pomi˛edzy klimatem orga- nizacyjnym a efektywno´sci ˛ a zespołów stosuj ˛ acych zwinne metodyki wytwarzania oprogramo- wania. Jest to nie tylko problem naukowy, ale równie˙z praktyczny. Takie praktyczne działanie narz˛edziami organizacyjnymi i motywacyjnymi na zespoły w celu utrzymania stałego poziomu efektywno´sci (lub jego podniesienia) pozwala na zapewnienie ci ˛ agło´sci operacyjnej i przewi- dywalno´sci w dostarczaniu kolejnych etapów produktu informatycznego.
1.2 Problem badawczy, cele i hipotezy rozprawy
Klimat organizacyjny jest poj˛eciem opisywanym na przestrzeni wielu ju˙z lat przez ró˙znych autorów i badaczy (niemal 3 tysi ˛ ace wyników w bazie Scopus dla zapytania w j˛ezyku angiel- skim). Pocz ˛ atki bada´n nad klimatem organizacyjnym si˛egaj ˛ a w literaturze lat ’30 [Schneider i in. 2017], a wzrost zainteresowania tym tematem obserwuje si˛e od lat 2000. Tematyk ˛ a t ˛ a (w rozumieniu ogólnym) zajmuj ˛ a si˛e mi˛edzy innymi: Litwin i Stringer (1968), Schneider i in.
(1968, 2017), Caplan (1987), Bratnicki, Kry´s, Stachowicz (1988), Koys i De Cotiis (1991), De-
nison (1996), Mikuła (2000, 2011), Pocztowski (2004), Bock i in. (2005), Patterson (2005),
Juchniewicz (2008, 2016) czy Wudarzewski (2013, 2014). Ka˙zdy z nich nieco inaczej postrze-
ga to poj˛ecie, kład ˛ ac nacisk na ró˙zne jego elementy. Warto zwróci´c uwag˛e na kilka wyró˙z-
niaj ˛ acych si˛e nurtów badawczych dotycz ˛ acych klimatu organizacyjnego. Jednym z nich jest
kontekst zachowa ´n liderów i kierowników oraz wpływ preferowanego stylu kierowania na
poziom klimatu organizacyjnego. Zale˙zno´sci te były opisywane ju˙z w latach 30-tych w ba-
daniach Lewina, Lippitty i White’a (1939), czy kolejnych przez Litwina i Stringera (1968),
Wallace, Hunt i Richards (1999) oraz Bamela i in. (2011). Badacze zwracaj ˛ a tutaj uwag˛e na
wyra´zne powi ˛ azania mi˛edzy stylem przywództwa preferowanym przez liderów a charakterem ukształtowanego klimatu organizacyjnego oraz efektywno´sci ˛ a zachowa´n w takich sytuacjach.
St ˛ ad drugi bardzo wyra´zny nurt bada´n dotycz ˛ acy wpływu klimatu organizacyjnego na poziom osi ˛ aganych wyników i efektów przedsi˛ebiorstwa. Wzrost zainteresowa´n w tym zakresie jest widoczny szczególnie w latach 90-tych. Denison (1990) uwzgl˛ednia takie elementy klimatu, jak zach˛ecanie pracowników do zaanga˙zowania zespołowego i podejmowania decyzji udowad- niaj ˛ ac pozytywn ˛ a korelacj˛e mi˛edzy tymi czynnikami a wynikami finansowymi przedsi˛ebiorstw.
Równie˙z Patterson, Warr i West (2004) pokazuj ˛ a zwi ˛ azki mi˛edzy klimatem a produktywno´sci ˛ a przedsi˛ebiorstwa. Nast˛epnym kierunkiem bada´n w literaturze jest wpływ klimatu organizacyj- nego na relacje mi˛edzy organizacj ˛ a a pracownikami, czy szerzej rozumiane, jako zadowolenie i satysfakcja z pracy. Badania Pritcharda i Karasicka (1973) potwierdzaj ˛ a ten silny zwi ˛ azek z satysfakcj ˛ a pracowników, podobnie jak Schanke (1983) czy Castro i Martins (2010). Z ko- lei Rota, Reynolds i Zanasi (2012) podkre´slaj ˛ a zwi ˛ azek klimatu z zaufaniem pracowników do przedsi˛ebiorstwa, ich satysfakcj ˛ a, zaanga˙zowaniem oraz ch˛eci ˛ a do współpracy. Analiza wpływ klimatu organizacyjnego wła´snie na zaanga˙zowanie i motywacj˛e pracowników jest silnie wi- doczna równie˙z u takich badaczy jak DeCotiisa i Summersa (1987) czy Langford (2009). Pa- trz ˛ ac szerzej na powy˙zsze czynniki mówi si˛e równie˙z o klimacie organizacyjnym w kontek´scie wydajno´sci i efektywno´sci pracowników. Temat ten poruszaj ˛ a mi˛edzy innymi: Lawler, Hall i Oldham (1974), Uthayasuriyan (1989), Carr i in. (2003), Irimie, Cristian i Zeininger (2017) czy Sambandam i Chockalingam (2019). W zwi ˛ azku z powy˙zszym z analizy literatury wynika za- równo bezpo´sredni wpływ klimatu organizacyjnego na efektywno´s´c zespołów pracowniczych, jak i po´sredni - poprzez motywacj˛e i organizacj˛e pracy.
O zwi ˛ azkach klimatu organizacyjnego z efektywno´sci ˛ a zespołów pracowniczych w do´s´c specyficznej
1bran˙zy jak ˛ a jest IT i wytwarzanie oprogramowania mówi si˛e ju˙z stosunkowo nie- wiele (baza Scopus znajduje jedynie 14 dokumentów o zbli˙zonej tematyce). O pewnych czyn- nikach klimatu (takich jak indywidualna kreatywno´s´c, podobie´nstwo członków zespołu czy nastawienie) i ich zwi ˛ azku z zespołami informatycznymi poruszaj ˛ a Bhatt i in. (2006) (w odnie- sieniu do zespołów zajmuj ˛ acych si˛e utrzymaniem produktów informatycznych), Kang, Yang i Rowley (2006) oraz Ac˛ıkgöz i Günsel (2016).
Wybór metodyki wytwarzania oprogramowania determinuje niektóre czynniki klimatu or-
1Specyficznej ze wzgl˛edu na nieco inne zachowania pracowników ich oczekiwania i czynniki motywuj ˛ace
ganizacyjnego. W metodykach zwinnych wi˛ekszy nacisk kładzie si˛e na takie elementy jak:
samodzielno´s´c pracowników, bezpo´srednie formy kontaktu czy rozproszone podejmowanie de- cyzji. Jednak˙ze w literaturze praktycznie nie mówi si˛e o wpływie klimatu organizacyjnego na efektywno´s´c pracy zespołów developerskich w zale˙zno´sci od stosowanej metodyki. W zwi ˛ azku z tym autorka nie napotkała na literatur˛e dotycz ˛ ac ˛ a zwi ˛ azków pomi˛edzy klimatem organizacyj- nym a efektywno´sci ˛ a zwinnych zespołów wytwarzaj ˛ acych oprogramowanie.
Co wi˛ecej, na poziomie teoretycznym i praktycznym niewiele mówi si˛e o poprawie efek- tywno´sci pracy zespołów zwinnych. Uznaje si˛e, ˙ze jest to najefektywniejsza forma wytwarza- nia oprogramowania, by´c mo˙ze w zwi ˛ azku z tym brak dalszych analiz dotycz ˛ acych poprawy.
W zwi ˛ azku z tym autorka dostrzegła w tym aspekcie luk˛e badawcz ˛ a.
Syntetycznie zarysowany powy˙zej przegl ˛ ad wiedzy wykazuj ˛ acy istnienie luki poznawczej, a tak˙ze wcze´sniejsze zainteresowania autorki problematyk ˛ a zwinnych zespołów informatycz- nych oraz obserwacja tych˙ze zespołów w praktyce, doprowadziły do sformułowania problemu badawczego rozwa˙zanego w niniejszej rozprawie. Jest nim poszukiwanie odpowiedzi na py- tanie: "Czy i jakie czynniki klimatu organizacyjnego wpływaj ˛ a na efektywno´s´c zwinnych ze- społów wytwarzaj ˛ acych oprogramowanie? A je˙zeli istnieje ten wpływ, to jaka jest zale˙zno´s´c pomi˛edzy tymi czynnikami a efektywno´sci ˛ a".
Co najmniej cz˛e´sciowe wypełnienie luki badawczej odbywa si˛e poprzez realizacj˛e dwóch grup celów: teoretycznych i utylitarnych.
A. Cele teoretyczne:
(a) analiza i synteza literatury dotycz ˛ acej metod wytwarzania oprogramowania oraz efektywno´sci zespołów stosuj ˛ acych zwinnych metodyki,
(b) opracowanie zagregowanej miary efektywno´sci zwinnych zespołów wytwarzaj ˛ a- cych oprogramowanie,
(c) analiza i synteza literatury dotycz ˛ acej wpływu klimatu organizacyjnego na efektyw- no´s´c zespołów,
(d) okre´slenie mechanizmu wpływu czynników klimatu organizacyjnego na efektyw-
no´s´c zwinnych zespołów wytwarzaj ˛ acych oprogramowanie w fazach okresowego
spadku tej efektywno´sci.
B. Cele utylitarne:
(a) okre´slenie faz cyklu rozwoju produktu i wprowadzania go na rynek przez zwinne zespoły, w których potencjalnie mo˙zna spodziewa´c si˛e spadku efektywno´sci zespo- łu,
(b) dostarczenie liderom zwinnych zespołów wytwarzaj ˛ acych oprogramowanie narz˛e- dzia do pomiaru efektywno´sci zespołu,
(c) okre´slenie symptomów spadku efektywno´sci zwinnych zespołów wytwarzaj ˛ acych oprogramowanie, na podstawie których liderzy mog ˛ a podj ˛ a´c działania zapobiegaw- cze,
(d) opracowanie wykazu czynników klimatu organizacyjnego, których odpowiednie kształtowanie wpływa na popraw˛e efektywno´sci zwinnych zespołów wytwarzaj ˛ a- cych oprogramowanie.
Obserwacje i bezpo´srednia praca z ró˙znymi zespołami wytwarzaj ˛ acymi oprogramowanie w sposób zwinny zwróciła uwag˛e autorki na brak stabilno´sci pracy tych zespołów i intuicyjnie rozumian ˛ a zmienno´s´c efektywno´sci ich pracy. Co wi˛ecej, bior ˛ ac pod uwag˛e cały czas pracy nad danym produktem informatycznym, efektywno´s´c zespołów naprzemiennie rosła i malała, a jej przebieg zdawał si˛e by´c sinusoidalny. Doprowadziło to do sformułowania pierwszej hipotezy pracy, mówi ˛ acej, i˙z:
H1: efektywno´s´c zespołów wytwarzaj ˛ acych oprogramowanie charakteryzuje si˛e cykliczno-
´sci ˛ a.
Jednak˙ze, w zale˙zno´sci od zespołu, długo´s´c okresu wzrostu czy te˙z spadku efektywno´sci była ró˙zna. W krótszych projektach okres zmian zdawał si˛e by´c znacznie mniejszy, to znaczy dla krótszych projektów te cykliczne zmiany efektywno´sci zdawały si˛e wyst˛epowa´c szybciej i zale˙ze´c od etapu prowadzonych prac. Obserwacja ta przerodziła si˛e w drug ˛ a hipotez˛e:
H2: cykliczno´s´c efektywno´sci zespołu wytwarzaj ˛ acego oprogramowanie pozostaje w zwi ˛ azku z etapem rozwoju produktu i wprowadzania go na rynek.
Ponadto wielko´s´c tych cyklicznych spadków efektywno´sci była ró˙zna w zale˙zno´sci od ze-
społu. Zespoły wyró˙zniaj ˛ ace si˛e jakimi´s cechami, np. komunikatywno´sci ˛ a, poziomem innowa-
cji, dobrymi towarzyskimi relacjami czy silnej osobowo´sci lidera wydawały si˛e ulega´c mniej-
szym spadkom efektywno´sci, a przez to w ogólno´sci były uwa˙zane za bardziej efektywne i do-
ceniane przez pracodawców. Elementy te wchodz ˛ a w skład szeroko postrzeganego klimatu or- ganizacyjnego, st ˛ ad zainteresowanie autorki t ˛ a tematyk ˛ a i powstanie trzeciej hipotezy niniej- szej pracy:
H3: synergiczne kształtowanie warto´sci czynników klimatu organizacyjnego umo˙zliwia zła- godzenie cyklicznych spadków efektywno´sci zwinnych zespołów wytwarzaj ˛ acych oprogramo- wanie.
Powy˙zsze hipotezy badawcze zostały zweryfikowane w toku przeprowadzonych prac.
1.3 Metody badawcze zastosowane w rozprawie
Wiod ˛ acym problemem tej rozprawy jest zidentyfikowanie wpływu klimatu organizacyjne- go na efektywno´s´c oraz wskazanie tych czynników klimatu, które wpływaj ˛ a pozytywnie wła-
´snie na efektywno´s´c zespołów wytwarzaj ˛ acych oprogramowanie w sposób zwinny. Zarówno tematyce klimatu organizacyjnego, jak i tematyce zwinnego wytwarzania oprogramowania po-
´swi˛econo wiele publikacji teoretycznych opartych cz˛esto na badaniach empirycznych (mi˛edzy innymi: Abrahamsson, Salo, Ronkainen, Warsta (2017), Łabuda (2015), Greer, Hamon (2011), Cockburn (2006), Schwaber, Beedle (2002), Beck (2001)). Studia literaturowe obejmowały po- zycje zarówno krajowe, jak i zagraniczne z zakresu teorii zarz ˛ adzania, koncepcji wytwarzania oprogramowania, in˙zynierii oprogramowania i prakseologii. Wsparcie dotycz ˛ ace formułowania my´sli w odpowiednich ramach formalnych stanowiły pozycje opisuj ˛ ace metodologi˛e prac dok- torskich oraz projektowanie bada´n społeczno-ekonomicznych. Publikacje miały przede wszyst- kim form˛e monografii i artykułów naukowych oraz artykułów bran˙zowych, a tak˙ze podr˛eczni- ków akademickich. Pierwszy etap realizacji pracy po´swi˛econy został zatem analizie dost˛epnych publikacji i wyników przeprowadzonych do tej pory bada´n.
W tym czasie autorka obserwowała prace kilku zespołów zwinnych. Na podstawie bada´n literaturowych, obserwacji faktycznie działaj ˛ acych zespołów oraz rozmów z osobami bezpo-
´srednio zarz ˛ adzaj ˛ acymi takimi zespołami, powstał zestaw miar okre´slaj ˛ acych efektywno´s´c ze- społów wytwarzaj ˛ acych oprogramowanie w sposób zwinny.
Po dokonaniu analizy literatury przedmiotu mo˙zliwe było rozpocz˛ecie kolejnego etapu pra-
cy, zbli˙zaj ˛ acego do rozwi ˛ azania postawionego problemu, czyli sformułowania problemu ba-
dawczego tej rozprawy, a nast˛epnie zaplanowanie metodyki bada´n empirycznych, adekwatnych
do weryfikowanych hipotez. Na bazie wiedzy teoretycznej oraz do´swiadcze´n własnych, au- torka sformułowała trzy hipotezy odnosz ˛ ace si˛e do efektywno´sci zespołów zwinnych. W celu zweryfikowania postawionych hipotez opracowano plan bada´n empirycznych. Badaniami ob- j˛eto trzydzie´sci pi˛e´c zespołów pracuj ˛ acych przy wykorzystaniu metodyk zwinnych. Znajduj ˛ a si˛e one zarówno w przedsi˛ebiorstwach, których główna działalno´s´c opiera si˛e na wytwarzaniu oprogramowania, jak i w przedsi˛ebiorstwach, w których zespoły wytwarzaj ˛ a oprogramowa- nie jedynie na u˙zytek wewn˛etrzny firmy. Zespoły te operuj ˛ a na terenie ró˙znych miast Polski.
Głównymi metodami do zebrania danych były: obserwacja uczestnicz ˛ aca i nieuczestnicz ˛ aca, wywiad, ankiety oraz analiza dokumentów. Nast˛epnie przy pomocy metod analizy statystycz- nej przedstawione zostały zwi ˛ azki pomi˛edzy klimatem organizacyjnym a efektywno´sci ˛ a w ba- danych zespołach. Opracowywanie i prezentacja wyników bada´n odbywały si˛e przy wsparciu programów i narz˛edzi informatycznych, w szczególno´sci pakietu MS Office (MS Word i MS Excel) oraz programu do analizy statystycznej Statistica 13.3.
W toku prowadzonych prac nad rozpraw ˛ a doktorsk ˛ a zastosowano wiele metod badaw- czych. S ˛ a to:
• metoda analizy, syntezy i krytyki literatury oraz metoda opisowa (metody odnosz ˛ ace si˛e do analizy pi´smiennictwa naukowego oraz bran˙zowego),
• metoda eksplanacji (wyja´snienia), odnosz ˛ aca si˛e opisu metodologii prowadzenia bada´n empirycznych,
• wywiady swobodne eksperckie (z Produkt Managerami i osobami odpowiedzialnymi za zarz ˛ adzanie zwinnymi zespołami informatycznymi), maj ˛ ace na celu wybranie odpowied- nich miar efektywno´sci i ich znaczenia,
• obserwacja uczestnicz ˛ aca (pracy zwinnych zespołów informatycznych) pozwalaj ˛ aca na zaobserwowanie zjawisk i bezpo´srednie zrozumienie ich istoty
• badania ankietowe prowadzone w oparciu o przygotowany kwestionariusz ankiety, maj ˛ a- ce na celu zebranie danych dotycz ˛ acych klimatu organizacyjnego,
• metody statystyczne, wykorzystane w procesie wielowymiarowej analizy porównawczej
oraz badaniu korelacji i siły zwi ˛ azku zjawisk,
• wnioskowanie dotycz ˛ ace charakterystyki pracy, efektywno´sci i klimatu organizacyjne- go zespołów informatycznych oraz zwi ˛ azków mi˛edzy tymi elementami przeprowadzo- ne zostało przy wykorzystaniu takich metod badawczych, jak refleksja naukowa, analiza i synteza, indukcja i dedukcja oraz analogia i redukcja.
1.4 Układ pracy
Realizacja celów szczegółowych pracy, a tak˙ze nakre´slony plan rozprawy stanowiły o ukształtowaniu struktury pracy. Poszczególne etapy prowadzonych bada´n zawarte zostały w sze´sciu rozdziałach niniejszej dysertacji.
Studium literaturowe obejmuje trzy główne nurty. Po pierwsze przyj˛eto definicj˛e poj˛e- cia "zespół informatyczny" oraz wyszczególniono cechy charakterystyczne dla tych zespołów.
Przyjrzano si˛e charakterystyce pracy takich zespołów, w zale˙zno´sci od stosowanej metodyki, a w szczególno´sci metod charakterystycznych dla zespołów zwinnych oraz dokonano ich kry- tycznego przegl ˛ adu. Wyniki przeprowadzonej analizy zamieszczone zostały w rozdziale dru- gim rozprawy.
Drugim kierunkiem bada´n literaturowych był klimat organizacyjny w zespołach informa- tycznych. W rozdziale trzecim niniejszej rozprawy opisano koncepcj˛e poj˛ecia oraz ró˙zne jego definicje, nast˛epnie okre´slono czynniki klimatu organizacyjnego i sposoby jego pomiaru. Na ko´ncu przeanalizowany został jego teoretyczny wpływ na motywacj˛e oraz efektywno´s´c zespo- łów.
Trzecim aspektem analizy ´zródłowej było zgł˛ebienie tematu efektywno´sci zespołów infor- matycznych. Autorka skupiła si˛e tu przede wszystkim na okre´sleniu, czym jest efektywno´s´c w kontek´scie zespołów zwinnych oraz na ró˙znych miarach tej efektywno´sci opisywanych w li- teraturze i ich krytykach w odniesieniu praktycznym. Wyniki tej analizy zostały przedstawione w rozdziale czwartym.
Druga cz˛e´s´c rozprawy obejmuje metodologi˛e oraz wyniki bada´n empirycznych prowadzo-
nych w latach 2017-2019. W rozdziale pi ˛ atym zawarto opis przeprowadzonych bada´n wła-
snych, zebrane dane dotycz ˛ ace zarówno efektywno´sci zwinnych zespołów informatycznych,
jak i klimatu organizacyjnego panuj ˛ acego w tych zespołach. Przy pomocy metod statystycz-
nych stworzone zostały miary syntetyczne bior ˛ ace pod uwag˛e ró˙zne czynniki efektywno´sci
i pozwalaj ˛ ace na porównanie jej pomi˛edzy zespołami. Nast˛epnie przedstawione zostały ana- lizy i ich wyniki pokazuj ˛ ace wpływ i zale˙zno´sci pomi˛edzy badanymi elementami. W dalszej cz˛e´sci, na podstawie analizy statystycznej wskazano te czynniki klimatu organizacyjnego, któ- re maj ˛ a bezpo´sredni wpływ na podnoszenie efektywno´sci zwinnych zespołów wytwarzaj ˛ acych oprogramowanie oraz wyszczególniono cztery czynniki, które w sposób znacz ˛ acy wpływaj ˛ a na popraw˛e efektywno´sci w zespołach zwinnych. ´Swiadome kształtowanie synergii tych czynni- ków w zespołach b˛edzie prowadziło do podniesienia ich efektywno´sci zwłaszcza w momentach cyklicznych spadków tej efektywno´sci zwi ˛ azanych z etapem wytwarzania produktu i wprowa- dzania go na rynek.
Prac˛e wie´nczy rozdział siódmy, b˛ed ˛ acy podsumowaniem procesu pracy nad zadanym pro-
blemem i wskazuj ˛ acy potencjalne kierunki bada´n w analizowanym obszarze.
2. Wytwarzanie oprogramowania
2.1 Zespół programistyczny
Zespoły programistyczne czy te˙z - jak cz˛esto si˛e je nazywa - deweloperskie składaj ˛ a si˛e z programistów o ró˙znych umiej˛etno´sciach, w zale˙zno´sci od produktu – programistów o kom- petencjach backendowych
1, webdeweloperskich
2czy testerskich
3oraz osoby koordynuj ˛ acej
4(menad˙zera produktu/projektu). Organizacja pracy takiego zespołu jest bezpo´srednio zwi ˛ azana z wybran ˛ a metodyk ˛ a wytwarzania oprogramowania.
W celu dobrego zdefiniowania i okre´slenia celów zespołów wytwarzaj ˛ acych oprogramo- wanie (programistycznych) nale˙zy najpierw prze´sledzi´c, cho´c pokrótce, proces wytwarzania produktu informatycznego. Fazy rozwoju takiego produktu s ˛ a wzgl˛ednie stałe, niezale˙znie od zastosowanej metodyki, cho´c mog ˛ a ró˙zni´c si˛e kolejno´sci ˛ a czy poziomem szczegółowo´sci. Za- równo dla nowo powstaj ˛ acego produktu, jak i tego rozwijanego, w pierwszej kolejno´sci okre-
´slana jest wizja. Nast˛epuje to poprzez zdefiniowanie potrzeb, ustalenie wymaga´n biznesowych z interesariuszami (czy to zewn˛etrznymi, czy te˙z wewn˛etrznymi), przy pomocy ró˙znych metod, okre´slenie kontekstów i scenariuszy u˙zycia. Dalej nast˛epuje zaprojektowanie danego rozwi ˛ a- zania, wykonanie danej funkcjonalno´sci, a nast˛epnie jej utrzymanie oraz zapewnienie stabil-
1Backend developer odpowiedzialny jest za dostarczanie rozwi ˛aza´n które tworz ˛a zaplecze i podstawow ˛a logi- k˛e obliczeniow ˛a strony, oprogramowania czy systemu informatycznego, tzn. odpowiada za stron˛e serwera, dzi˛eki którym aplikacja otrzymuje niezb˛edne dane. Zajmuje si˛e on głównie takimi elementami jak: tworzenie API, ko- munikacja z bazami danych czy wykorzystanie zewn˛etrznych baz danych. Słowem backendowcy odpowiadaj ˛a za te cz˛e´sci systemu, których nie wida´c “gołym okiem” [Techopedia 2017].
2Webdeweloper czy te˙z frontend developer odpowiedzialny jest za tworzenie wizualnych elementów opro- gramowania, aplikacji czy te˙z strony internetowej. Tworzy on komponenty oraz funkcje, które s ˛a bezpo´srednio widoczne i dost˛epne dla u˙zytkownika ko´ncowego lub klienta [Techopedia 2017].
3Tester oprogramowania (ang. software tester) to osoba odpowiedzialna za testowanie oprogramowanie pod k ˛atem bł˛edów, wad, niespójno´sci lub innych problemów, które mog ˛a mie´c wpływ na wydajno´s´c i sposób działania oprogramowania [Techopedia 2017].
4W literaturze nie zawsze osoba koordynuj ˛aca projekt jest zaliczana do zespołu, jednak z obserwacji autorki wynika, ˙ze w praktycznym podej´sciu, osoba taka jest cz˛e´sci ˛a zespołu programistycznego.
no´sci działania. Przede wszystkim to te ostatnie elementy le˙z ˛ a w odpowiedzialno´sci zespołów programistycznych, cho´c uczestnicz ˛ a one w pewnym stopniu w całym procesie. Mo˙zliwo´sci wytwórcze zespołów programistycznych s ˛ a zazwyczaj najbardziej ograniczone, podczas gdy pomysły i potrzeby spływaj ˛ a z ró˙znych ´zródeł (mi˛edzy innymi potrzeby biznesowe, wymogi prawne i technologiczne). Mo˙zna wi˛ec powiedzie´c, ˙ze te mo˙zliwo´sci wytwórcze zespołów s ˛ a w ˛ askim gardłem w całym procesie wytwarzania oprogramowania.
Patrz ˛ ac na powy˙zszy proces mo˙zna zaobserwowa´c, jaki jest cel zespołów deweloperskich.
Wydawa´c by si˛e mogło, ˙ze jest to wytwarzanie oprogramowania, jednak byłoby to zbyt du-
˙zym uproszczeniem. Mianowicie, „od zespołów programistycznych z jednej strony wymaga si˛e przede wszystkim, jak najszybszego wytwarzania funkcjonalno´sci, zgodnie z zało˙zeniami i ustalonymi kryteriami, natomiast z drugiej strony - wysokiej jako´sci tworzonych rozwi ˛ a- za´n, pozwalaj ˛ acych na ci ˛ agło´s´c i poprawno´s´c działania funkcjonalno´sci (utrzymanie, stabil- no´s´c) oraz na kontrybucj˛e w projekcie przez innych programistów (łatwo´s´c wej´scia w produkt).”
[Grobelna, Trzcieli´nski 2017].
Zespół deweloperski mo˙zna zatem traktowa´c jako podstawow ˛ a jednostk˛e odpowiedzialn ˛ a za powstawanie oprogramowania, jednak jego postrzeganie zmienia si˛e w wraz z wykorzystywan ˛ a metodyk ˛ a wytwarzania oprogramowania.
2.2 Metodyki wytwarzania oprogramowania
2.2.1 Powstanie metodyk wytwarzania oprogramowania
Metodyki wytwarzania oprogramowania, czy te˙z sama in˙zynieria oprogramowania, powsta- ły stosunkowo niedawno. Oficjalnie za narodziny tej dyscypliny podaje si˛e lata 1968 - 1969, w których to odbyły si˛e dwie konferencje sponsorowane przez NATO [Bourque, Fairley 2014], na których zacz˛eto mówi´c o tak zwanych modelach SDLC (ang. software developement li- fe cycle). Patrz ˛ ac na histori˛e rozwoju oprogramowania mo˙zna zauwa˙zy´c, ˙ze do ko´nca lat ‘60 oprogramowanie tworzyło si˛e, bez powa˙zniejszych reguł i metod. W 1970 roku została zdefi- niowana pierwsza metodyka wytwarzania oprogramowania – obecnie zwana klasyczn ˛ a, oparta na modelu kaskadowym [Smilgin 2017]. W kolejnych latach pojawiały si˛e ró˙zne jej ewolucje.
Od 2001 r. mówi si˛e o podej´sciu nowoczesnym, zwinnym (ang. agile), które jest odpowiedzi ˛ a
na ci ˛ agł ˛ a zmienno´s´c ´srodowiska i potrzeb biznesowych. W podej´sciu tym metodyki oparte s ˛ a na iteracyjnym (przyrostowym) modelu, który ma zapewnia´c łatwo´s´c adaptowania zmian. Me- todyki zwinne obecnie uznawane s ˛ a za najefektywniejsz ˛ a form˛e wytwarzania oprogramowania.
Cały czas pojawiaj ˛ a si˛e ich ewolucje, w których coraz cz˛e´sciej odchodzi si˛e od sformalizowa- nych metod opisu pracy programistów, a stawia si˛e przede wszystkim na produktywno´s´c.
Projekt b ˛ ad´z te˙z produkt informatyczny mo˙zna zdefiniowa´c jako „niepowtarzaj ˛ acy si˛e, nie- rutynowy proces realizacji okre´slonych celów (wytworzenia i utrzymania stabilno´sci działania oprogramowania), w okre´slonym czasie, za pomoc ˛ a okre´slonych ´srodków” [Szyjewski 2011].
Zatem elementami takiego projektu zawsze b˛ed ˛ a:
• produkt ko´ncowy (zdefiniowany zakres prac),
• czas realizacji (termin dostarczenia/ wydania oprogramowania),
• koszt realizacji (zdefiniowany bud˙zet).
Powy˙zsze zale˙zno´sci przedstawione zostały na Rysunku 2.1.
Rysunek 2.1: Parametry Projektu Zródło: Szyjewski 2011 ´
W zale˙zno´sci od zastosowanej metodologii modyfikacjom mog ˛ a ulega´c powy˙zsze elementy, podczas gdy reszta pozostaje stała.
Wypadkow ˛ a powy˙zszych elementów jest jako´s´c oprogramowania. Zale˙zy ona bezpo´srednio
od zakresu prac, przeznaczonego czasu na ich wykonanie oraz zało˙zonego bud˙zetu. W in˙zynierii
oprogramowania mówi ˛ ac o jako´sci wymienia si˛e dziewi˛e´c czynników [Martin 2011]:
• poprawno´s´c - okre´sla na ile stworzone oprogramowanie jest poprawne, tzn. czy jest zgod- ne z wymaganiami oraz pozbawione bł˛edów,
• łatwo´s´c u˙zycia – okre´sla na ile łatwe i intuicyjne jest korzystania z oprogramowania czy systemu informatycznego,
• czytelno´s´c – okre´sla na ile powstały kod jest zrozumiały i intuicyjny dla innych develo- perów (jak wysoki jest próg wej´scia w projekt),
• ponowne u˙zycie (wielokrotne u˙zycie lub re-u˙zycie) – okre´sla przydatno´s´c wytworzonego oprogramowania (zarówno całego systemu, jak i jedynie fragmentów) do zastosowania i wykorzystania w innych produktach programistycznych,
• stopie´n strukturalizacji (modularno´s´c) - okre´sla mo˙zliwo´s´c podzielenia danego oprogra- mowania na cz˛e´sci, tworz ˛ ace swego rodzaju odr˛ebne elementy (z dobrze wyra˙zon ˛ a se- mantyk ˛ a oraz okre´slon ˛ a wzajemn ˛ a interakcj ˛ a),
• wydajno´s´c – okre´sla stopie´n wykorzystania zasobów takich, jak: sprz˛et, bazy danych, moc obliczeniowa czy programy b˛ed ˛ ace podstaw ˛ a działania tworzonego systemu,
• przenaszalno´s´c – okre´sla mo˙zliwo´s´c łatwego przenoszenia oprogramowania na inne plat- formy sprz˛etowe czy programowe,
• skalowalno´s´c – okre´sla mo˙zliwo´sci systemu przy wzro´scie wykorzystania oprogramo- wania, tj. wzro´scie liczby u˙zytkowników, obj˛eto´sci przetwarzanych danych, doł ˛ aczaniu nowych składników do systemu, itp.,
• współdziałanie - okre´sla mo˙zliwo´s´c niezawodnej współpracy danego systemu z innymi niezale˙znie skonstruowanymi SI.
W latach ’60 pojawił si˛e tzw. kryzys oprogramowania. Polegał on na powi˛ekszaj ˛ acej si˛e roz-
bie˙zno´sci pomi˛edzy wytwarzaniem sprz˛etu (i rosn ˛ acej mocy obliczeniowej) a produkcj ˛ a opro-
gramowania. W tych latach zacz˛eły powstawa´c du˙ze systemy, niestety wi˛ekszo´s´c wdro˙ze´n była
znacz ˛ aco opó´zniona, przekraczała zało˙zony bud˙zet lub nie ko´nczyła si˛e powodzeniem w ogó-
le. W efekcie zarówno wytwarzanie, jak i utrzymywanie oprogramowania stało si˛e zbyt kosz-
towne; oprogramowanie, wykorzystywane ju˙z na coraz wi˛eksz ˛ a skal˛e, było zawodne; współ-
działanie produktów programistycznych (kompatybilno´s´c ró˙znych systemów) stanowiła coraz
powa˙zniejszy problem [Piasecki 2010]. Za przyczyny takiego stanu rzeczy uznaje si˛e przede wszystkim [D ˛ abrowski 2005]:
• brak jasno zdefiniowanej odpowiedzialno´sci za systemy informatyczne (SI), wynikaj ˛ acej z rosn ˛ acej zło˙zono´sci systemów,
• brak mo˙zliwo´sci re-u˙zycia wytworzonych ju˙z wcze´sniej elementów oprogramowania i niezwykle indywidualne podej´scie do rozwi ˛ aza´n,
• cykl wytwarzania oprogramowania oraz jego utrzymania był długi, a przez to kosztowny, poniewa˙z cz˛esto wymagał globalnych zmian,
• coraz wi˛eksze wykorzystanie, a przez to uzale˙znienie si˛e organizacji od SI, które cz˛esto okazywały si˛e niestabilne w długim horyzoncie czasowym,
• pojawianie si˛e problemów współdziałania niezale˙znie zbudowanego oprogramowania i braku mo˙zliwo´sci integracji ró˙znych systemów.
Jako odpowied´z na problemy b˛ed ˛ ace przyczyn ˛ a tego kryzysu, podj˛eto próby formalizacji procesu wytwarzania oprogramowania i od tego momentu mo˙zna mówi´c o powstaniu meto- dyki, zwanej dzisiaj klasyczn ˛ a (b ˛ ad´z tradycyjn ˛ a). Wraz z rozwojem in˙zynierii oprogramowa- nia powstawały kolejne metody, adresuj ˛ ace konkretne problemy. Te modele, czy te˙z metody wprowadzaj ˛ a pewien ład i schematyczno´s´c, tzn. definiuj ˛ a mi˛edzy innymi fazy ˙zycia oprogra- mowania, okre´slaj ˛ a czynno´sci wykonywane w poszczególnych fazach oraz ustalaj ˛ a kolejno´s´c ich realizacji. Pozwalaj ˛ a one na uporz ˛ adkowanie przebiegu prac, ułatwiaj ˛ a planowanie zada´n oraz monitorowanie przebiegu ich realizacji.
Metodyki klasyczne charakteryzuj ˛ a si˛e wysokim poziomem kontroli i uporz ˛ adkowan ˛ a
struktur ˛ a. Opieraj ˛ a si˛e na fazowym cyklu wytwarzania produktu, w którym podstawowe czyn-
no´sci traktowane s ˛ a jako odr˛ebne fazy projektu, a pocz ˛ atek i koniec ka˙zdej fazy s ˛ a z góry
okre´slone. W podej´sciu tym zespoły s ˛ a jednorodne, o stałym składzie [Grobelna 2017]. Para-
metrem stałym projektu (zdefiniowanym na jego pocz ˛ atku i niemodyfikowalnym - jest zakres
prac, podczas gdy czas i koszty mog ˛ a podlega´c zmianom. Jako´s´c jest tutaj wypadkow ˛ a powy˙z-
szych czynników.
2.2.2 Metodyki tradycyjne
2.2.2.1 Model kaskadowy
Pierwszym formalnym modelem cyklu ˙zycia oprogramowania wprowadzonym przez Roy- ca [1970] był model kaskadowy (inaczej zwany liniowym, sekwencyjnym lub wodospadowym, ang. waterfall). Powstał on poprzez analogi˛e do modeli obecnych w in˙zynierii produkcji i in-
˙zynierii zarz ˛ adzania tzw. sekwencyjnego projektowana wyrobu [Grobelna, Trzcieli´nski 2017].
W obu przypadkach produkt przechodzi kolejno przez nast˛epuj ˛ ace po sobie fazy wytwarzania (krokowy rozwój), a ka˙zda faza jest realizowana przez wyspecjalizowany zespół.
Podstawowym zało˙zeniem tego modelu jest wykonywanie ka˙zdego ze zdefiniowanych eta- pów projektu jako odr˛ebnych faz projektowych. Ka˙zda kolejna faza mo˙ze rozpocz ˛ a´c si˛e dopiero po, cz˛esto formalnym, zako´nczeniu i udokumentowaniu fazy poprzedzaj ˛ acej. Je˙zeli na którym´s z etapów otrzymany zostanie niesatysfakcjonuj ˛ acy produkt (niezgodny ze specyfikacj ˛ a, zawie- raj ˛ acy bł˛edy zgodnie z definicj ˛ a jako´sci oprogramowania) nale˙zy cofn ˛ a´c faz˛e, poprawiaj ˛ ac j ˛ a a˙z do momentu otrzymania w pełni satysfakcjonuj ˛ acego produkt na ko´ncu danej fazy [Osman 2010].
Ka˙zdy z etapów projektu został okre´slony przez autora, najcz˛e´sciej te˙z umiej˛etno´sci do wykonania poszczególnych etapów oraz odpowiedzialno´s´c za nie, rozproszona jest po ró˙znych zespołach.
1. Planowanie systemu lub te˙z okre´slanie wymaga´n systemu (ang. requirements) – w fazie tej okre´slane s ˛ a cele oraz szczegółowe wymagania wobec tworzonego systemu.
2. Analiza systemu (ang. system analizing) – w fazie tej przeprowadzana jest analiza wy- maga´n oraz studium ich wykonalno´sci.
3. Projektowanie systemu (and. system design) - w fazie tej powstaje szczegółowy projekt systemu i poszczególnych jego struktur, spełniaj ˛ acy ustalone wcze´sniej wymagania.
4. Implementacja i testowanie modułów, czyli podsystemów (ang. implementacion and mo-
dul testing) – w fazie tej nast˛epuje wytworzenie kodu, projekt zostaje zaimplementowany
w konkretnym ´srodowisku programistycznym; wykonywane s ˛ a równie˙z testy poszcze-
gólnych modułów.
5. Testowanie (ang. testing) – w fazie tej integrowane s ˛ a ze sob ˛ a poszczególne moduły oraz ponownie testowane s ˛ a wszystkie moduły, a przede wszystkim cały system.
6. Wdro˙zenie i piel˛egnacja powstałego systemu (ang. maintenance) – w fazie tej oprogramo- wanie zostaje udost˛epnione u˙zytkownikom oraz jest ono utrzymywane, tzn. wykonywane s ˛ a modyfikacje maj ˛ ace na celu popraw˛e wszelakich bł˛edów i ewentualne rozszerzenia funkcjonalne systemu. [Royc 1970].
Czasem dodatkowo wyszczególniana jest jeszcze faza integrowania (poszczególnych modułów)
5. Na Rysunku 2.2 przedstawione zostały poszczególne fazy tego modelu wraz z mo˙zliwymi przej´sciami pomi˛edzy nimi.
Rysunek 2.2: Model kaskadowy
Zródło: opracowanie własne na podstawie Szyjewski 2011 ´
5Dodana ona została w pó´zniejszych modyfikacjach modelu.
Obecnie nie zaleca si˛e wykorzystania takiego podej´scia (cho´c jest ono nadal do´s´c powszech- nie stosowane
6w praktyce in˙zynierskiej). Uznaje si˛e, i˙z mo˙ze by´c ono u˙zyte wył ˛ acznie w przy- padku systemu, dla którego wszystkie wymagania s ˛ a zrozumiałe i przejrzyste oraz mog ˛ a by´c zdefiniowane ju˙z na pocz ˛ atku projektu. Wynika to z faktu, i˙z ka˙zdy etap jest czasochłonny i wy- maga du˙zych wydatków, bł˛edy wytworzone w danej fazie wykrywane s ˛ a dopiero w kolejnych fazach, co znacznie wydłu˙za cały proces.
7Obecnie wyszczególnia si˛e nast˛epuj ˛ ace zalety oraz wady prowadzenia projektów informa- tycznych z wykorzystaniem modelu kaskadowego (Tabela 2.1).
Ze wzgl˛edu na liczne wady modelu oraz jego krytyk˛e i nieefektywno´s´c przy wielu projektach informatycznych zwłaszcza na poziomie praktycznym wprowadzane były kolejne modele wytwarzania oprogramowania. Jednak to model kaskadowy pozostaje po dzi´s dzie´n najbardziej znanym i najcz˛e´sciej stosowanym modelem metodyk tradycyjnego wytwarzania oprogramowania.
6Model ten jest wykorzystywany zwłaszcza przez przedsi˛ebiorstwa nie zajmuj ˛ace si˛e wytwarzaniem oprogra- mowania jako swoj ˛a działalno´sci ˛a, a wytwarzaj ˛ace oprogramowanie jedynie na potrzeby wewn˛etrzne przedsi˛e- biorstwa.
7Na temat praktycznego wykorzystania tego modelu znale´z´c mo˙zna skrajnie ró˙zne opinie [mi˛edzy innymi: Di- ma, Maassen 2018, Kuhrmann i in. 2017]. Z jednej strony twierdzi si˛e, ˙ze praktycznie ˙zadne rzeczywiste przedsi˛e- wzi˛ecie programistyczne nie mo˙ze zosta´c i nie zostało zrealizowane w pełni zgodnie z zało˙zeniami teoretycznymi tego modelu. Z drugiej strony, grono innych autorów uwa˙za, ˙ze zdecydowana wi˛ekszo´s´c rzeczywistych przed- si˛ewzi˛e´c przebiega zgodnie z podstawowymi zało˙zeniami modelu kaskadowego. Te sprzeczne opinie wynikaj ˛a z ró˙znej interpretacji zało˙ze´n modelu. Interpretacja ´scisła, dosłowna i przewa˙zaj ˛aca w praktycznym podej´sciu do takiego wytwarzania oprogramowania traktuje poszczególne fazy jako konkretne okresy realizacji produktu infor- matycznego, okresy te nie nakładaj ˛a si˛e na siebie i s ˛a wykonywane ´sci´sle w sposób sekwencyjny. Interpretacja ogólna odnosi si˛e do poszczególnych faz w sposób szerszy, nadaj ˛ac poszczególnym fazom znaczenie bardziej kon- cepcyjne, ni˙z dosłowne. Oznacza to, i˙z ró˙zne elementy wytwarzanego systemu mog ˛a znajdowa´c si˛e jednocze´snie w ró˙znych fazach realizacji, fazy te zatem nie s ˛a ju˙z ´sci´sle sekwencyjne.
Tabela 2.1: Zalety i wady zastosowania modelu kaskadowego
Zródło: opracowanie własne na podstawie Cusumano i Smith 1995, Tomal 2011, Aguileta ´
i Gomez 2019
2.2.2.2 Model przyrostowy
Model przyrostowy, inaczej nazywany te˙z modelem inkrementalnym (ang. iterative, incre- mental) powstał w celu wyeliminowania wad modelu kaskadowego poprzez rezygnacj˛e ze ´sci- słego, liniowego nast˛epstwa faz. Pocz ˛ atkowo był on wykorzystywany do tworzenia jedynie małych elementów oprogramowania. W przeciwie´nstwie do poprzedniego modelu, jest on nie- co bardziej elastyczny w przypadku, gdy klient nie potrafi w pełni okre´sli´c potrzeb i wymaga´n funkcjonalnych systemu. W modelu tym funkcjonalno´s´c systemu jest dzielona na cz˛e´sci [D ˛ a- browski 2005]. Z ka˙zdym przyrostem cz˛e´s´c funkcjonalno´sci jest wydawana (wdra˙zana) poprzez prac˛e w ró˙znych zespołach (np. wymagania, implementacja, testy itd.).
Fazy przy wykorzystaniu tego modelu s ˛ a bardzo zbli˙zone do faz w modelu kaskadowym, jednak˙ze fazy ´srodkowe (poza pocz ˛ atkow ˛ a i ko´ncow ˛ a) mog ˛ a zosta´c podzielona na kilka cz˛e´sci (przyrostów), które okre´sla si˛e ramami czasowymi, a nie funkcjonalnymi [Larman, Basili 2003].
Na Rysunku 2.3 przedstawiono poszczególne fazy modelu.
Rysunek 2.3: Model przyrostowy Zródło: Wieczorek 2015 ´
Mimo, i˙z w modelu tym mówi si˛e o nieliniowym nast˛epstwie faz, to wyszczególnia si˛e cztery etapy
8projektu, w których to z ró˙zn ˛ a intensywno´sci ˛ a nast˛epuj ˛ a fazy wytwarzania opro-
8Cz˛esto w literaturze, zwłaszcza angloj˛ezycznej etapy te nazywane s ˛a fazami (ang. phase), natomiast przyj˛ete w niniejszym opisie fazy - dyscyplinami ( ang. disciplines and workflows).
gramowania [Brdjanin, Maric 2005]. Etapy te mog ˛ a mie´c ró˙zn ˛ a długo´s´c, lecz powinna by´c ona ustalona z góry. Te etapy to:
1. etap rozpocz˛ecia (ang. inception phase), 2. etap opracowywania (ang. elaboration phase), 3. etap konstrukcji (ang. construction phase), 4. etap przekazania systemu (ang. transition phase).
Na Rysunku 2.4 przedstawiony został przykładowy przebieg faz
9(w wierszach) w podziale na przyrosty tworz ˛ ace etapy (w kolumnach) w projekcie, w którym oprogramowanie jest wy- twarzane zgodnie z modelem przyrostowym. Kolorem oznaczony został czas przewidziany na prowadzenie prac w ka˙zdej z faz podczas danego etapu i przyrostu.
Rysunek 2.4: Przebieg faz projektu z wykorzystaniem modelu przyrostowego Zródło: opracowanie własne na podstawie Tomal 2011 ´
9Faza planowanie czasem okre´slana jest mianem modelowania biznesowego.
Zaleca si˛e zastosowanie modelu przyrostowego, gdy [ISTQBExamCertification 2017]:
• wymagania dotycz ˛ ace całego systemu s ˛ a jasno okre´slone i zrozumiałe,
• istnieje potrzeba wcze´sniejszego wprowadzenia produktu na rynek, cho´cby jeszcze w niepełnej wersji,
• wykorzystywana jest nowa technologia,
• nie s ˛ a w pełni dost˛epne zasoby z wymaganymi umiej˛etno´sciami,
• projekt ma kilka celów, które wi ˛ a˙z ˛ a si˛e z wysokim ryzykiem.
Obecnie analizuj ˛ ac to podej´scie wyró˙znia si˛e nast˛epuj ˛ ace wady i zalety (Tabele 2.2).
Tabela 2.2: Zalety i wady zastosowania modelu przyrostowego
Zródło: opracowanie własne na podstawie Tomal 2011, Aguileta i Gomez 2019 ´
2.2.2.3 Model prototypowy
Model prototypowy (ang. prototyping) powstał równie˙z jako odpowied´z na problemy z za- stosowaniem modelu kaskadowego, a przede wszystkim adresuje problem du˙zego kosztu bł˛e- dów popełnionych w pierwszych fazach (analiza, planowanie).
W modelu tym mówi si˛e o dodatkowych, nowych fazach – fazach tworzenia prototypu. Za prototyp uznaje si˛e niepełny systemem informatyczny, spełniaj ˛ acy cze´s´c podstawowych wyma- ga´n. Jego celem jest przedstawienie i przetestowanie przez klienta zaproponowanego rozwi ˛ aza- nia; sprawdzenie wymaga´n i potrzeb. Pozwala on na: szybkie wykrycie nieporozumie´n pomi˛e- dzy potrzebami klientów a powstałymi wymaganiami, wykrycie brakuj ˛ acych funkcji, szybk ˛ a identyfikacj˛e problematycznych elementów czy braków w specyfikacji. Z zało˙zenia prototyp nie jest elementem ostatecznego systemu informatycznego (ostateczny system budowany jest od podstaw, po zaakceptowaniu rozwi ˛ aza´n zastosowanych w prototypie) [Budde i in. 1992].
Wyszczególnia si˛e nast˛epuj ˛ ace fazy modelu:
1. ogólne okre´slenie wymaga´n, 2. budowa prototypu,
3. weryfikacja prototypu przez klienta,
4. realizacja pełnego systemu zgodnie z modelem kaskadowym.
Fazy te przedstawiono na Ryskunku 2.5.
W literaturze wyszczególnia si˛e cztery rodzaje prototypowania
10:
• Szybkie prototypowanie (ang. Rapid Throwaway Prototyping)
Opiera si˛e on na zało˙zeniach wst˛epnych; jego celem jest jak najszybsze pokazanie, w jak sposób zrealizowane b˛edzie (jak b˛edzie wygl ˛ ada´c) główne zało˙zenie (wymaganie).
Informacje zwrotne od klienta pomagaj ˛ a wprowadza´c zmiany do wymaga´n, a prototyp jest ponownie tworzony do momentu spełnienia wymaga´n [Spitzer, Kuhl, Muller-Glaser 2001].
10W praktyce, wszystkie elementy tych podej´s´c przenikaj ˛a si˛e i cz˛esto trudno okre´sli´c, jaki rodzaj prototypowa- nia został zastosowany.
Rysunek 2.5: Model prototypowy
Zródło: opracowanie własne na podstawie [Szyjewski 2011] ´
• Ewolucyjne prototypowanie (ang. Evolutionary Prototyping)
Opracowany prototyp jest stopniowo udoskonalany w oparciu o opinie klientów, a˙z do ostatecznego zaakceptowania. Podej´scie to pomaga zaoszcz˛edzi´c czas i wysiłek; opra- cowanie od podstaw prototypu dla ka˙zdej interakcji procesu mo˙ze czasami by´c bardzo frustruj ˛ ace. Dopuszcza si˛e tu by prototyp był cz˛e´sci ˛ a ostatecznego rozwi ˛ azania [Carr, Verner 1997].
• Prototypowanie przyrostowe (ang. Incremental Prototyping)
W tym podej´sciu produkt ko´ncowy jest dzielony na kilka ró˙znych mniejszych prototypów, które s ˛ a opracowywane osobno. Nast˛epnie te ró˙zne prototypy mog ˛ a (cho´c nie musz ˛ a) zo- sta´c poł ˛ aczone. Ta metoda jest przydatna, aby skróci´c czas reakcji mi˛edzy u˙zytkownikiem a zespołem programistycznym [Pomberger i in. 1991].
• Ekstremalne prototypowanie (ang.Extreme Prototyping)
Ekstremalna metoda prototypowania jest najcz˛e´sciej u˙zywana do tworzenia stron inter- netowych. Prototypowane s ˛ a wszystkie strony, symulowany jest proces przetwarzania danych, a nast˛epnie tworzony jest ostateczny prototyp integruj ˛ acy [Egwoh, Nonyelum 2017].
Zalety i wady tego podej´scia przedstawione zostały w Tabeli 2.3.
Tabela 2.3: Zalety i wady zastosowania modelu prototypowego
Zródło: opracowanie własne na podstawie Rudd, Stern, Isensee 1996, D ˛ ´ abrowski 2005
Model prototypowy zalecany jest przy realizacji systemów, dla których okre´slenie wyma- ga´n jest stosunkowo łatwe lub modyfikacja wymaga´n podczas realizacji projektu jest bardzo kosztowna lub wr˛ecz niemo˙zliwa (np. programy kosmiczne).
2.2.2.4 Model spiralny
W 1989 roku Barry Boehm zaproponował kolejny model wytwarzania oprogramowania – model spiralny (ang. spiral). Jest on niejako podej´sciem hybrydowym, powstałym poprzez poł ˛ aczenie modelu kaskadowego oraz prototypowego. Proces ten obrazowo przedstawia si˛e w postaci spirali (Rysunek 2.6), w której ka˙zda p˛etla odpowiada kolejnej fazie etapu procesu.
Dodatkowo ka˙zda z faz podzielony jest na cztery etapy [Boehm 1989].
1. Ustalenie celów – rozwa˙za si˛e ogólne zało˙zenia danej wersji systemu.
2. Rozpoznanie i redukcja zagro˙ze´n – analiza ryzyka zwi ˛ azanego z realizacj ˛ a. W fazie tej najcz˛e´sciej budowany jest prototyp, w celu przedstawienia kolejnej wersji systemu.
3. Tworzenie i testowanie – tworzona i testowana jest kolejna wersja systemu zgodnie z mo- delem kaskadowym.
4. Planowanie nast˛epnej fazy – planowane s ˛ a czynno´sci, które b˛ed ˛ a realizowane w kolejnej
fazie.
Rysunek 2.6: Model spiralny Zródło: Tomal 2011 ´
W ka˙zdej fazie - p˛etli spirali przechodzi si˛e przez kolejne kroki modelu kaskadowego z pro- totypem podzielone na etapy. Podczas etapu pierwszego przechodzi si˛e dwie pierwsze fazy modelu kaskadowego, mianowicie planowanie oraz analiz˛e, w etapie drugim tworzony jest pro- totyp, natomiast w etapie trzecim zgodnie z modelem kaskadowym tworzony jest projekt, nast˛e- puje jego implementacja, testowanie oraz piel˛egnacja, a˙z do etapu czwartego, gdzie podejmo- wana jest decyzja czy projekt nale˙zy kontynuowa´c i je´sli tak, to planowana jest nast˛epna faza.
Ka˙zda kolejna faza jest bardziej szczegółowa. Pierwsza mo˙ze dotyczy´c studium wykonalno´sci projektu, kolejna definicji wymaga´n systemowych, w trzeciej tworzona mo˙ze by´c koncepcja ogólna itd. Fazy nast˛epuj ˛ a po sobie dopóki uzasadnione jest kontynuowanie projektu [Boehm, Hansen 2000].
Model ten ma do´s´c ogólny charakter i mo˙zna go dostosowywa´c do potrzeb konkretnego
projektu informatycznego. Dodatkowo podział na cz˛e´sci - kolejne spirale pozwala na kontynu-
owanie projektu przez długi czas, jednocze´snie pokazuj ˛ ac efekty w ka˙zdej fazie. W zwi ˛ azku
z tym stosuje si˛e go przede wszystkim przy stosunkowo du˙zych przedsi˛ewzi˛eciach programi- stycznych.
Do wad i zalet najcz˛e´sciej zalicza si˛e (Tabela 2.4):
Tabela 2.4: Zalety i wady zastosowania modelu spiralnego
Zródło: opracowanie własne na podstawie Tomal 2011 ´
2.2.3 Metodyki zwinne
2.2.3.1 Elementy zbie˙zno´sci metodyk zwinnych z koncepcj ˛ a przedsi˛ebiorstwa szczupłego i zwinnego
Wraz ze wzrostem znaczenia oprogramowania „metodyka klasyczna okazała si˛e jednak
zbyt mało elastyczna i niewystarczaj ˛ aca przy dynamicznie zmieniaj ˛ acych si˛e potrzebach biz-
nesowych” [Grobelna, Trzcieli´nski 2017]. W odpowiedzi na te zmiany, zachodz ˛ ace zarówno
w ´srodowisku zewn˛etrznym, jak i wewn˛etrznym poprzez modyfikowanie wymaga´n, w 2001 roku w bran˙zy IT ogłoszono Manifest Zwinnych Metodyk (Manifesto for Agile Software De- velopment) [Manifesto... 2001]. Zapocz ˛ atkowało to nurt zwinnych metodyk wytwarzania opro- gramowania. Manifest zawiera cztery zasady, które stanowi ˛ a trzon zwinnego podej´scia do wy- twarzania oprogramowania [Martin, Marti 2006]:
• „ludzie i interakcje ponad procesy i narz˛edzia,
• działaj ˛ ace oprogramowanie ponad obszern ˛ a dokumentacj˛e,
• współpraca z klientem ponad formalne ustalenia,
• reagowanie na zmiany ponad pod ˛ a˙zanie za planem.”
Powy˙zsze o´swiadczenie nale˙zy interpretowa´c, i˙z cho´c wprawdzie cały czas wa˙zne i docenia- ne pozostaj ˛ a elementy wymienione po prawej stronie, to jednak na znaczeniu znacz ˛ aco zyskuj ˛ a elementy wymienione po lewej stronie i to one s ˛ a wa˙zniejszymi warto´sciami.
Za nadrz˛edny cel metodyk zwinnych (iteracyjnych) uwa˙za si˛e zapewnienie jak najwi˛ekszej satysfakcji klienta w mo˙zliwie najkrótszym czasie, przy jednoczesnym zapewnieniu mo˙zliwo-
´sci ci ˛ agłego udoskonalenia projektu [Balsamski, Gamrat 2014, s. 13]. W podej´sciu tym za stał ˛ a uznaje si˛e przede wszystkim jako´s´c, a czasem równie˙z czas oraz koszty, natomiast zakres pod- lega zmianom.
Działaj ˛ ace oprogramowanie jest tu dostarczanie w krótkich okresach (tzw. iteracjach). Faza rozpocz˛ecia i zamkni˛ecia przedsi˛ewzi˛ecia nie jest jasno zdefiniowana, a tak˙ze o ile nie jest to niezb˛edne, nie powstaje pocz ˛ atkowa dokumentacja, do której mo˙zna by porówna´c wyniki [Grobelna, Trzcieli´nski 2017].
Jedna z zasad Manifestu Agile mówi: “twórz projekty wokół zmotywowanych osób. Stwórz
im warunki, zaspokajaj ich potrzeby i obdarz ich zaufaniem, tak aby zadania zostały wykona-
ne” („Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done”) [Manifesto... 2001]. Zdaniem praktyków [Wieczorek
2014] „zwinne metodyki maj ˛ a mi˛edzy innymi na celu lepsze motywowanie członków zespołu
programistycznego”. Jest to jedna z ró˙znic ukazuj ˛ aca now ˛ a jako´s´c w wytwarzaniu oprogramo-
wania w porównaniu z metodykami tradycyjnymi.
Równie˙z w podej´sciu zwinnym bardzo silnie widoczny jest wpływ in˙zynierii produkcji i za- rz ˛ adzania na in˙zynieri˛e oprogramowania. Wła´snie w produkcji, najpierw zacz˛eto odchodzi´c od podej´scia sekwencyjnego na rzecz in˙zynierii współbie˙znej. Metoda ta bazuje na realizowaniu poszczególnych faz cyklu w sposób współbie˙zny, co oznacza, ˙ze co najmniej cz˛e´sciowo na- kładaj ˛ a si˛e one na siebie, przez co cały cykl ulega istotnemu skróceniu [Grobelna, Trzcieli´nski 2016]. Interpretuj ˛ ac dalej to podej´scie, mo˙zna stwierdzi´c, ˙ze cała metodyka agile opiera si˛e na maksymalnym zrównolegleniu prac nad produktem. Nie ma ju˙z jasno oddzielonych od siebie faz wytwarzania produktu, a on sam nie „przechodzi” pomi˛edzy ró˙znymi zespołami/działami.
Za cały produkt (poprzez wszystkie fazy, tj. od jego analizy biznesowej, wytworzenia, poprzez utrzymanie oraz ewentualne wycofanie) odpowiada jeden zespół/dział . W zwi ˛ azku z tym od- powiedzialno´s´c takiego zespołu jest znacznie wi˛eksza. W zwinnych metodykach wytwarzania oprogramowania mówi si˛e o samoorganizuj ˛ acym si˛e zespole. Oznacza to, ˙ze takiemu zespołowi nie zostaje narzucony z góry podział pracy czy wewn˛etrzne zasady. Jest to odpowied´z na tzw.
upodmiotowienie szczebla wykonawczego (ang. empowerment) w metakoncepcji lean. Zespół, który jest uprawniony do podejmowania decyzji, zobowi ˛ azany jest równie˙z do brania na siebie odpowiedzialno´sci. Aby ta odpowiedzialno´s´c nie była rozproszona, konieczne jest wyposa˙ze- nie pracowników w odpowiedni ˛ a wiedz˛e (w lean oznacza to nastawienie przedsi˛ebiorstwa na kultur˛e uczenia si˛e). Podej´scie to jest obecne równie˙z w zwinnych zespołach programistycz- nych i objawia si˛e nie tylko nastawieniem na ci ˛ agły rozwój i zdobywanie nowej wiedzy, ale przede wszystkim wymaganiem od członków zespołu wszechstronno´sci, tj. znajomo´sci ró˙z- nych technologii, j˛ezyków programowania oraz pełnienia ró˙znych funkcji (tworzenie wizualne oraz funkcjonalne oprogramowania, testowanie, wdra˙zanie itp., gdy˙z odpowiadaj ˛ a oni za cały produkt
11). Zatem nacisk na samorozwój w nowoczesnych metodach wytwarzania oprogramo- wania jest bardzo wysoki.
Kolejnym elementem zbie˙zno´sci pomi˛edzy metodykami zwinnymi wytwarzania oprogra- mowania a koncepcj ˛ a przedsi˛ebiorstwa szczupłego (lean) jest metoda sterowania przepływów produkcji kanban. Polega ona na takim organizowaniu procesu wytwórczego, aby ka˙zda komór- ka organizacyjna produkowała dokładnie tyle, ile w danej chwili jest potrzebne. W metodzie tej za czynnik krytyczny zarz ˛ adzania materiałami uznano sterowanie zapasami. Podobnie w me-
11W metodykach zwinnych nie ma ju˙z stricte podziału na programistów backendowych, frontendowych czy testerów. Zespół odpowiada za produkt informatyczny na ka˙zdym etapie jego wytwarzani.
todzie o tej samej nazwie przy wytwarzaniu oprogramowania limituje si˛e prace rozpocz˛ete lub b˛ed ˛ ace w danej fazie. Słowo kanban – w pierwotnym jego znaczeniu z j˛ezyka japo´nskiego – oznacza: szyld, tabliczk˛e z napisem informuj ˛ acym, billboard. Kanban jako metoda wytwarza- nia oprogramowania opiera si˛e wła´snie o wizualizacj˛e, tzw. tablic˛e kanbanow ˛ a [Kniberg, Skarin 2010].
Zasada ci ˛ agłego przepływu (w lean - flow), cho´c mo˙ze nie tak oczywista w zwinnych me- todykach, stanowi ich clou. Stosunkowo krótkie iteracje zapewniaj ˛ a mo˙zliwo´s´c pokazywania i oddawania klientowi cho´cby niewielkich przyrostów tworzonego produktu. Poszczególne prace w etapie s ˛ a maksymalnie minimalizowane, dzi˛eki czemu przechodzenie przez etapy jest szybkie i nast˛epuje bez przerw i przestojów. Zasada ci ˛ agłego przepływu odnosi si˛e równie˙z do przepływu informacji. Niezb˛edny jest bie˙z ˛ acy przepływ informacji pomi˛edzy ró˙znymi zespo- łami, samymi członkami zespołu, zespołem a managementem oraz zespołem i klientami. Ta potrzeba informacji zwrotnej wynika równie˙z z nastawienia na odbiorc˛e. Z kolei cała meta- koncepcja zarz ˛ adzania zwinnego opiera si˛e na kompleksowym zaspokajaniu potrzeb klientów, szczególnie poprzez zapewnienie elastyczno´sci i adaptacyjnych mo˙zliwo´sci przedsi˛ebiorstwa.
Dokładnie te same zasady buduj ˛ a zwinne metodyki wytwarzania oprogramowania, st ˛ ad i zbie˙z- no´s´c nazw nie jest przypadkowa (metodyki agile). Wyra˙za to czwarta zasada Manifestu Agile (reagowanie na zmiany ponad pod ˛ a˙zanie za planem).
Kolejn ˛ a, wydaj ˛ ac ˛ a si˛e oczywist ˛ a, analogi ˛ a le˙z ˛ ac ˛ a u podstaw obecnie stosowanych podej´s´c zarówno do zarz ˛ adzania przedsi˛ebiorstwem, jak i wytwarzania oprogramowania jest zoriento- wanie na klienta. Filary podej´scia lean, zało˙zenia agile oraz Manifest Agile stawiaj ˛ a odbiorc˛e prac na najwy˙zszym miejscu. Wszystkie metody i narz˛edzia maj ˛ a na celu jak najszybsze zaspo- kajanie (cz˛esto poprzez konsultowanie) potrzeb klienta oraz usprawnianie współpracy z nim.
Jest to tak samo wa˙zne na poziomie wytwarzania produktu (równie˙z produktu informatyczne- go), jak i podczas zarz ˛ adzania całym przedsi˛ebiorstwem [Grobelna, Trzcieli´nski 2017].
Istot ˛ a programowania zwinnego jest cykliczno´s´c, iteracyjno´s´c całego procesu. Rozpoczyna
si˛e on od zdefiniowanie wymaga´n (cho´c nie s ˛ a one tak formalne i szczegółowe, jak miało to
miejsce w metodykach klasycznych), nast˛epnie wytwarzane jest oprogramowanie w kilku cy-
klach (zgodnie z wybran ˛ a metodyk ˛ a) oraz nast˛epuje wdro˙zenie. w tym miejscu nale˙zy zada´c
pytanie, czy wdro˙zony fragment oprogramowania spełnia wymogi klienta; je´sli tak - nast˛epuje
przekazanie oprogramowania klientowi, je´sli nie - wprowadzane s ˛ a zmiany, nast˛epuje ponowna
priorytetyzacja zada´n oraz przygotowanie do kolejnej iteracji. Na poni˙zszym diagramie (Rys.
2.7) przedstawiona została koncepcj˛e programowania zwinnego.
Rysunek 2.7: Model programowania zwinnego Zródło: Patel 2019 ´
Podsumowuj ˛ ac, zwinne metodyki wytwarzania oprogramowania (ang. agile software deve- lopment) opieraj ˛ a si˛e na iteracyjnym modelu, gdzie wymagania i rozwi ˛ azania ewoluuj ˛ a przy współpracy samoorganizuj ˛ acych si˛e zespołów. Najwa˙zniejsze zasady, którymi kieruj ˛ a si˛e te metodyki to [Agile Business Consortium 2014]:
• satysfakcja klienta jako najwa˙zniejszy element udanego projektu, osi ˛ agana poprzez szyb- kie i regularne dostarczanie działaj ˛ acego oprogramowania,
• zmiany wymaga´n, jako nieodzowna cz˛e´s´c projektu - akceptacja zmian, na ka˙zdym etapie produktu (nawet w pó´znych etapach powstawania),
• widoczny przyrost i post˛ep prac - cz˛este dostarczanie działaj ˛ acego oprogramowania (ty- godnie nie miesi ˛ ace),
• działaj ˛ ace oprogramowanie jako najwa˙zniejsza miara post˛epu prac,
• zrównowa˙zone wytwarzanie, zdolno´s´c utrzymania ci ˛ agłego (wzgl˛ednie stałego) tempa,
• bliska współpraca mi˛edzy biznesem, a zespołem wytwarzaj ˛ acym oprogramowanie,
• ograniczenie dokumentacji - bezpo´srednie ustalenia jako najlepsza i najszybsza forma komunikacji,
• projekty budowane wokół zmotywowanych jednostek, godnych zaufania – du˙zy nacisk na rozwój i motywacj˛e zespołu,
• stała jako´s´c, wzgl˛ednie stały koszt i czas, przy zmiennym zakresie,
• regularne przystosowywanie si˛e do zmieniaj ˛ acych si˛e okoliczno´sci.
Obecnie metodyki te powszechnie uznawane s ˛ a za najefektywniejsz ˛ a form˛e wytwarzania oprogramowania.
2.2.3.2 Scrum
Scrum jako jedna z najbardziej obecnie rozpowszechnionych metodyk zwinnych, jest tak naprawd˛e szkieletem procesu (ang. framework) zawieraj ˛ acym zestaw praktyk i predefi- niowanych ról. Skupia si˛e on przede wszystkim na dostarczaniu kolejnych, coraz bardziej dopracowanych wyników projektu, skonsultowanych w mo˙zliwie maksymalny sposób z przy- szłymi u˙zytkownikami [Schwaber, Sutherland 2005].
Głównymi rolami okre´slonymi w Scrumie s ˛ a:
1. Mistrz (ang. Scrum Master) - osoba odpowiedzialna za zarz ˛ adzanie procesami i ci ˛ agłe ich doskonalenie,
2. Wła´sciciel Produktu (ang. Product Owner, ale w praktyce cz˛esto te˙z Product Manager) – osoba odpowiedzialna za ustalanie priorytetów, zbieraj ˛ aca wymagania i przeprowadza- j ˛ aca analizy, reprezentuj ˛ aca klienta i interesariuszy (zarówno zewn˛etrznych, jak i we- wn˛etrznych),
3. Zespół developerski (ang. Team) – grupa od kilku do kilkunastu osób (liczebno´s´c zespołu
zale˙zy od zapotrzebowania w budowanym produkcie i wewn˛etrznej polityki przedsi˛ebior-
stwa; z reguły jest to od 5 do 9 osób), faktycznie zajmuj ˛ aca si˛e wytwarzaniem produktu
informatycznego (analiz ˛ a, projektowaniem, implementacj ˛ a, testowaniem, itd.). Warto pa- mi˛eta´c, ˙ze mamy tu do czynienia nie tylko z zespołami niejednorodnymi, ale równie˙z
„samoorganizuj ˛ acymi si˛e”. Oznacza to w praktyce, ˙ze członkowie zespołu maj ˛ a pełn ˛ a dowolno´s´c przy podziale zada´n, wyborze sposobu ich realizowania czy innych preferen- cji, równocze´snie bior ˛ ac odpowiedzialno´s´c za wytwarzany produkt.
Przez cały czas trwania prac nad produktem, tworzona jest lista wymaga´n dla systemu (wymaga´n funkcjonalnych, u˙zyteczno´sciowych, jako´sciowych, dost˛epno´sci itp.) Ka˙zda taka funkcjonalno´s´c - wyizolowana jedna cecha systemu, zostaje opisana w postaci "historyjki”
12(ang. story). Zespół podczas jednej iteracji
13pracuje zwykle w tygodniowym (czasem 2- tygodniowym) przedziale czasowym, zwanym sprintem. Efektem ka˙zdej iteracji powinno by´c wykonanie jakiego´s zdefiniowanego działaj ˛ acego fragmentu produktu (jednej b ˛ ad´z kliku hi- storyjek). Podczas przebiegu (iteracji), co do zasady, nie modyfikuje si˛e zakresu pracy (liczby i tre´sci historyjek), zatem wymagania s ˛ a zamro˙zone. Wytwarzanie jest ograniczone ramami czasowymi (czasem trwania sprintu
14). Je´sli jakie´s zadanie
15nie zostanie zako´nczone w termi- nie, rozpatruje si˛e je na nowo (mo˙ze, ale co wa˙zne nie musi by´c ono wzi˛ete na kolejny sprint
16).
Po zako´nczeniu iteracji nast˛epuje przegl ˛ ad prac i wytworzonego oprogramowania [Grobelna, Trzcieli´nski 2017].
Scrum najcz˛e´sciej opisywany jest jako framework, czyli szkielet, zbiór zasad i ogólnych mechanizmów działania, który w elementach nie opisanych mo˙zna dostosowywa´c w zale˙zno-
´sci od potrzeb [Samarawickrama, Perera 2017]. Poza sprecyzowanymi rolami i prac ˛ a w iteracji opisuje on równie˙z spotkania, które powinny si˛e odbywa´c podczas ka˙zdej iteracji, dla zacho- wania idei i zało˙ze´n. Ka˙zde z tych spotka´n realizuje potrzeby b˛ed ˛ ace filarami podej´scia. Wa˙zn ˛ a rol˛e w nim odgrywa planowanie danej iteracji (ang. Sprint Planning). Podczas tego spotkania wybierane s ˛ a zadania do wykonania w trakcie danej iteracji, a zespół deklaruje ich wykona- nie w tym czasie (czasie trwania sprintu). Jedn ˛ a z naczelnych zasad jest cz˛esta synchronizacja
12Historyjka to opis funkcjonalno´sci lub nawet jej fragmentu, czy te˙z zwykły opis zadania do wykonania przez zespół programistyczny.
13Iteracja to jeden cykl wytwarzania oprogramowania w metodykach zwinnych zgodnie z rozumieniem zapre- zentowanym na Rysunku2.7.
14Sformułowanie sprint jest zwykle stosowane zamiennie ze sformułowaniem iteracja i najcz˛e´sciej uto˙zsamiane z tygodniem pracy.
15W ogólnym rozumieniu scrumowym zadanie i historyjka s ˛a to˙zsame; opisuj ˛a wszystkie rodzaje funkcjonal- no´sci. Natomiast w podej´sciu praktycznym historyjk ˛a definiuje si˛e jedynie funkcjonalno´s´c biznesow ˛a, natomiast zadanie ma charakter techniczny. Na potrzeby niniejszej pracy przyj˛eto to pierwsze rozumienie zadania i historyjki.
16Wynika to z mo˙zliwej zmiany priorytetów w kolejnej iteracji.
prac (odbywa si˛e ona na tzw. ang. Daily Scrum). Prezentacja prac, demo (ang Sprint Review) odbywa si˛e na koniec ka˙zdej iteracji. Podsumowana zostaje praca oraz nast˛epuje sprawdzenie, czy zało˙zony plan został wykonany. Jest to równie˙z miejsce na prezentacj˛e rezultatów intere- sariuszom i zweryfikowanie wraz z nimi zało˙ze´n i otrzymanych rezultatów. Ostatnie opisane w sposób formalny spotkanie
17jest mo˙zliwo´sci ˛ a przeanalizowania całej iteracji i wyci ˛ agni˛e- cia wniosków do kolejnych - retrospektywa (ang. Sprint Retrospective). Pozwala to na ci ˛ agł ˛ a popraw˛e procesu (ang. continnous improvement).
Scrum został stworzony do zarz ˛ adzania projektami wytwarzania oprogramowania, jednak w praktyce stosowany jest równie˙z z powodzeniem do usystematyzowania pracy zespołów zaj- muj ˛ acych si˛e konserwacj ˛ a oprogramowania lub mo˙ze by´c stosowany jako ogólne podej´scie do zarz ˛ adzanie programem/projektem bez wzgl˛edu na rozmiar tego projektu [Tomal 2011].
Metoda ta ma wiele zalet, jednak wymaga do´s´c du˙zej dyscypliny zarówno ze strony osób wytwarzaj ˛ acych oprogramowanie, jak i klientów, aby nie wpa´s´c w pułapki tego podej´scia.
Bez umocowanego, samoorganizuj ˛ acego si˛e zespołu oraz zaanga˙zowania ze strony biznesu zastosowanie tego podej´scia oka˙ze si˛e trudne i nieefektywne. Poni˙zej przedstawiono zalety i wady Scruma (Tabela 2.5).
17Spotkaniem nie wymaganym i doprecyzowanym w metodyce pó´zniej jest Grooming b ˛ad´z Refinement [Schwa- ber, Sutherland 2016] (z czasem słowo grooming zostało oficjalnie zast ˛apione slowem refinement ze wzgl˛edu na złe konotacj˛e znaczeniowe tego pierwszego w j˛ezyku angielskim). Na spotkaniu tym doprecyzowywane i uszcze- góławiane s ˛a historyjki.
