{"id":6263,"date":"2019-07-10T09:47:42","date_gmt":"2019-07-10T07:47:42","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=6263"},"modified":"2023-09-13T10:04:11","modified_gmt":"2023-09-13T08:04:11","slug":"quo-vadis-agile-zwinne-wytwarzanie-oprogramowania","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/quo-vadis-agile-zwinne-wytwarzanie-oprogramowania\/","title":{"rendered":"Quo vadis, Agile? Zwinne wytwarzanie oprogramowania"},"content":{"rendered":"\n

Wytwarzanie wielu produkt\u00f3w (nie tylko oprogramowania) charakteryzuje si\u0119 du\u017c\u0105 niepewno\u015bci\u0105. Tym artyku\u0142em otwieramy seri\u0119 zwi\u0105zan\u0105 z szeroko rozumianym Agile – om\u00f3wimy w nim pokr\u00f3tce przesz\u0142o\u015b\u0107 i tera\u017aniejszo\u015b\u0107 Agile na \u015bwiecie, a tak\u017ce spr\u00f3bujemy spojrze\u0107 dalej – w przysz\u0142o\u015b\u0107. Szykujcie zatem kryszta\u0142owe kule i zapraszam do lektury!<\/p>\n\n\n\n

Opowiem Wam histori\u0119\u2026 Stosunkowo nie tak dawno temu, ludzie spojrzeli w lustro i zadali sobie pytanie: czego chcemy i dok\u0105d zmierzamy? Tradycyjne podej\u015bcie (maj\u0105ce swoje korzenie w pocz\u0105tkach ery industrialnej) do wytwarzania oprogramowania sprawdza\u0142o si\u0119 w pewnych przypadkach, na pewno nie zawsze. Opiera si\u0119 ono poniek\u0105d na systemie masowej produkcji: produkt jecha\u0142 na ta\u015bmie, gdzie nast\u0119powa\u0142y po sobie kolejne etapy produkcji\u2026<\/p>\n\n\n\n

\u2026Wymagania, analiza, wycena, produkcja, testy, wdro\u017cenie\u2026<\/p>\n\n\n\n

Mi\u0142o, je\u015bli wszystko przebiega\u0142o zgodnie z planem \u2013 analiza by\u0142a kompletna i przewidywa\u0142a wszystkie ryzyka. Wycena to strza\u0142 w dziesi\u0105tk\u0119, produkcja przebiega\u0142a bez zarzutu, nikt w projekcie nie chorowa\u0142 i nie bra\u0142 urlop\u00f3w, testy przechodzi\u0142y na zielono, klienci byli wniebowzi\u0119ci z dostarczonego rozwi\u0105zania i nie zg\u0142aszali \u017cadnych uwag, a wdro\u017cenie by\u0142o jak bu\u0142ka z mas\u0142em.<\/p>\n\n\n\n

Tyle, \u017ce takie projekty zdarza\u0142y i nadal zdarzaj\u0105 si\u0119 niezbyt cz\u0119sto, w szczeg\u00f3lno\u015bci je\u015bli m\u00f3wimy o du\u017cych produktach, gdy\u017c planowanie w szerokim horyzoncie czasowym ma nisk\u0105 szans\u0119 powodzenia. Wed\u0142ug <\/span>Standish Group Chaos Report 2015<\/span><\/a>, projekty na czas, w bud\u017cecie i osi\u0105gaj\u0105ce cel (nazywane w raporcie jako Successful Chaos Resolution<\/em>), to jedynie oko\u0142o 30% wszystkich projekt\u00f3w, a ryzyko ich niepowodzenia ro\u015bnie wraz z ich wielko\u015bci\u0105 i <\/span>sposobem ich realizacji.<\/p>\n\n\n\n

\"Project<\/a>
Ryc. 1 \u201cChaos Resolution\u201d w podziale na rozmiar projektu.
\u0179r\u00f3d\u0142o:\u00a0Standish Group Chaos Report<\/a><\/figcaption><\/figure>\n\n\n\n
\"Chaos<\/a>
Ryc. 2 \u201cChaos Resolution\u201d z podzia\u0142em na typy podej\u015bcia u\u017cywanego przy wytwarzaniu produkt\u00f3w.
\u0179r\u00f3d\u0142o:\u00a0Standish Group Chaos Report<\/a><\/figcaption><\/figure>\n\n\n\n

Wida\u0107 pewien trend, prawda?<\/p>\n\n\n\n

Czym jest Agile?<\/h2>\n\n\n\n

Cz\u0119sto, je\u015bli mieli\u015bmy do czynienia z du\u017cym produktem, ten zanim wyszed\u0142 na rynek by\u0142 ju\u017c przestarza\u0142y (na przyk\u0142ad program prom\u00f3w kosmicznych NASA, kt\u00f3ry wszed\u0142 do produkcji w latach \u201980 bazowa\u0142 na rozwi\u0105zaniach z lat \u201960 – „na szcz\u0119\u015bcie” nie by\u0142 komercyjny) lub nie spe\u0142nia\u0142 wymaga\u0144 klient\u00f3w.<\/p>\n\n\n\n

Pami\u0119tacie Pana Spinacza z pakietu MS Office? To idealny przyk\u0142ad na to, jak brak konsultacji i reagowania na nastroje rynku mo\u017ce sprawi\u0107, \u017ce oddamy u\u017cytkownikom co\u015b, co nie tylko nie spe\u0142ni ich oczekiwa\u0144 – ale czasami wywo\u0142a nawet irytacj\u0119.<\/span><\/p>\n\n\n\n

\"Pan<\/a>
Ryc. 3 Office Assistant, czy te\u017c Pan Spinacz jest doskona\u0142ym przyk\u0142adem na to,
jak zbudowa\u0107 co\u015b, czego nikt nie chcia\u0142 u\u017cywa\u0107.
\u0179r\u00f3d\u0142o:\u00a0wikipedia.org<\/a><\/figcaption><\/figure>\n\n\n\n

Problem trwa\u0142 w latach \u201960, \u201970 i na pocz\u0105tku \u201980. W pewnym stopniu istnieje nawet do dzi\u015b. Ale przela\u0142a si\u0119 czara goryczy.<\/p>\n\n\n\n

Zainspirowani tezami Williama Edwarda Deminga dotycz\u0105cymi continuous improvement<\/em> (sta\u0142ej poprawy), cz\u0142onkowie spo\u0142eczno\u015bci deweloperskich w latach \u201980 XX wieku dostrzegli potrzeb\u0119 zmiany podej\u015bcia, kt\u00f3re poprawi\u0142oby spos\u00f3b, w jaki podchodzimy do wytwarzania oprogramowania z tradycyjnego, kt\u00f3re zyska\u0142o miano waterfall<\/em> (czyli kaskadowego modelu) do modelu iteracyjno-przyrostowego, opartego na sta\u0142ym dostarczaniu warto\u015bci biznesowej. W ko\u0144cu Carpaccio z buraka jest przyjemniejsze w spo\u017cyciu ni\u017c ca\u0142y burak.<\/p>\n\n\n\n

W celu poprawy jako\u015bci wytwarzania produkt\u00f3w i zwi\u0119kszenia decyzyjno\u015bci, ju\u017c w trakcie trwania proces\u00f3w wytw\u00f3rczych opracowano podej\u015bcia oparte na cyklach wytwarzania oprogramowania, zamiast budowania ca\u0142ego oprogramowania jako jeden wielki blok. Najwi\u0119ksi przedstawiciele iteracyjnych metodyk tamtych czas\u00f3w (to jest przed rokiem 1990) to m.in. Evolutionary Project Management<\/em>, Adaptive Programming<\/em> oraz Spiral Model<\/em>. <\/span><\/p>\n\n\n\n

Potem nadci\u0105gn\u0119\u0142a z\u0142ota \u2018era\u2019 Agile. W latach \u201990 powsta\u0142 Scrum,<\/em> Rapid Application Development<\/em>, Extreme Programming<\/em>.<\/p>\n\n\n\n

Wci\u0105\u017c jednak dominowa\u0142o podej\u015bcie waterfall<\/em>. Zacz\u0119\u0142o si\u0119 to dopiero zmienia\u0107 na pocz\u0105tku XXI wieku (czyli w\u0142a\u015bciwie stosunkowo niedawno), a to za spraw\u0105 Agile Manifesto<\/em> (Manifestu Zwinno\u015bci), kt\u00f3ry powsta\u0142 w 2001 roku.<\/p>\n\n\n\n

Tre\u015b\u0107 tego manifestu mo\u017cna sprowadzi\u0107 do kilku linijek (nie \u017ceby sam manifest by\u0142 opas\u0142ym dokumentem):<\/p>\n\n\n\n

\u201eZacz\u0119li\u015bmy bardziej ceni\u0107:<\/em>
Ludzi i interakcje od<\/strong> proces\u00f3w i narz\u0119dzi;<\/em>
Dzia\u0142aj\u0105ce oprogramowanie od<\/strong> szczeg\u00f3\u0142owej dokumentacji;<\/em>
Wsp\u00f3\u0142prac\u0119 z klientem od<\/strong> negocjacji um\u00f3w;<\/em>
Reagowanie na zmiany od<\/strong> realizacji za\u0142o\u017conego planu;\u201d<\/em><\/p>\n\n\n\n

Ja r\u00f3wnie\u017c po przeczytaniu tego po raz pierwszy pomy\u015bla\u0142em, \u017ce Agile to chyba synonim chaosu. Ale na szcz\u0119\u015bcie tw\u00f3rcy dodali jedno, zamykaj\u0105ce (wr\u0119cz uspokajaj\u0105ce) zdanie:<\/p>\n\n\n\n

\u201eOznacza to, \u017ce elementy wypisane po prawej stronie s\u0105 warto\u015bciowe, ale wi\u0119ksz\u0105 warto\u015b\u0107 maj\u0105 dla nas te, kt\u00f3re wypisano po lewej.\u201d<\/em><\/p>\n\n\n\n

Wiele os\u00f3b, nawet dzisiaj, ignoruje przekaz zawarty w tym ostatnim zdaniu, kt\u00f3ry podkre\u015bla fakt, \u017ce nie zaleca si\u0119 w \u017cadnym wypadku porzucenia proces\u00f3w, narz\u0119dzi, dokumentacji, um\u00f3w, planu. Te elementy nadal s\u0105 istotne w procesie wytw\u00f3rczym, ale w \u015brodowisku zwinnym, ci\u0119\u017car jest przeniesiony na lew\u0105 stron\u0119.<\/p>\n\n\n\n

Opr\u00f3cz tego, Agile Manifesto<\/em> zawiera 12 pryncypi\u00f3w, kt\u00f3re przy\u015bwiecaj\u0105 tej filozofii (warto to podkre\u015bli\u0107 – filozofii, a nie metodyce!):<\/p>\n\n\n\n

Najwy\u017cszy priorytet ma dla nas zadowolenie klienta <\/em>dzi\u0119ki wczesnemu i ci\u0105g\u0142emu wdra\u017caniu <\/em>warto\u015bciowego oprogramowania.<\/em><\/p>\n\n\n\n

B\u0105d\u017acie gotowi na zmiany wymaga\u0144 <\/em>nawet na p\u00f3\u017anym etapie jego rozwoju. <\/em>Procesy zwinne wykorzystuj\u0105 zmiany <\/em>dla zapewnienia klientowi konkurencyjno\u015bci.<\/em><\/p>\n\n\n\n

Dostarczajcie funkcjonuj\u0105ce oprogramowanie cz\u0119sto, <\/em>w kilkutygodniowych lub kilkumiesi\u0119cznych odst\u0119pach. <\/em>Im cz\u0119\u015bciej, tym lepiej.<\/em><\/p>\n\n\n\n

Zespo\u0142y biznesowe i deweloperskie musz\u0105 \u015bci\u015ble ze sob\u0105 <\/em>wsp\u00f3\u0142pracowa\u0107 w codziennej pracy przez ca\u0142y czas trwania <\/em>projektu.<\/em><\/p>\n\n\n\n

Tw\u00f3rzcie projekty wok\u00f3\u0142 zmotywowanych ludzi. <\/em>Zapewnijcie im potrzebne \u015brodowisko oraz wsparcie i zaufajcie, \u017ce <\/em>wykonaj\u0105 powierzone zadanie.<\/em><\/p>\n\n\n\n

Najbardziej efektywnym i wydajnym sposobem przekazywania <\/em>informacji zespo\u0142owi deweloperskiemu i wewn\u0105trz niego jest <\/em>rozmowa twarz\u0105 w twarz.<\/em><\/p>\n\n\n\n

Dzia\u0142aj\u0105ce oprogramowanie jest podstawow\u0105 miar\u0105 post\u0119pu.<\/em><\/p>\n\n\n\n

Procesy zwinne umo\u017cliwiaj\u0105 zr\u00f3wnowa\u017cony rozw\u00f3j. <\/em>Sponsorzy, deweloperzy oraz u\u017cytkownicy powinni by\u0107 w stanie <\/em>utrzymywa\u0107 r\u00f3wne tempo pracy.<\/em><\/p>\n\n\n\n

Ci\u0105g\u0142e skupienie na technicznej doskona\u0142o\u015bci i dobrym <\/em>projektowaniu zwi\u0119ksza zwinno\u015b\u0107.<\/em><\/p>\n\n\n\n

Prostota \u2013 sztuka minimalizowania ilo\u015bci koniecznej pracy \u2013 jest kluczowa.<\/em><\/p>\n\n\n\n

Najlepsze rozwi\u0105zania architektoniczne, wymagania i projekty <\/em>pochodz\u0105 od samoorganizuj\u0105cych si\u0119 zespo\u0142\u00f3w.<\/em><\/p>\n\n\n\n

W regularnych odst\u0119pach czasu zesp\u00f3\u0142 analizuje mo\u017cliwo\u015bci <\/em>poprawy swojej wydajno\u015bci, a nast\u0119pnie dostraja i dostosowuje <\/em>swoje dzia\u0142ania do wyci\u0105gni\u0119tych wniosk\u00f3w.<\/em><\/p>\n\n\n\n

Ot, ca\u0142a filozofia. Tyle trzeba, \u017ceby wytwarza\u0107 produkty zwinnie. Tylko tyle i a\u017c tyle.<\/p>\n\n\n\n

Chcia\u0142bym w tym miejscu jeszcze raz to podkre\u015bli\u0107, gdy\u017c w dziedzinie wytwarzania oprogramowania powsta\u0142 pewien dosy\u0107 niebezpieczny mit, jakoby implementacja (nie wdro\u017cenie!) Scrum,<\/em> tablic kanbanowych, User Stories<\/em> lub praktyk Extreme Programming<\/em> mia\u0142oby sprawi\u0107, \u017ce b\u0119dziemy zwinni.<\/p>\n\n\n\n

O ile sprawienie, \u017ce zespo\u0142y b\u0119d\u0105 pracowa\u0107 w Scrum<\/em> mo\u017ce pom\u00f3c, o tyle nie osi\u0105gniemy pe\u0142nej korzy\u015bci ze zwinnej transformacji tylko dzi\u0119ki narz\u0119dziom. Transformacja zwinna to przede wszystkim zaadaptowanie nowej filozofii, a wi\u0119c tak\u017ce zmiana my\u015blenia, podej\u015bcia i sposobu dzia\u0142ania biznesu – ta cz\u0119\u015b\u0107 jest najtrudniejsza.<\/p>\n\n\n\n

Co mi daje ten Agile?<\/h2>\n\n\n\n

Ale co nam w\u0142a\u015bciwie daje zwinne wytwarzanie produktu? Mo\u017cna wymieni\u0107 kilka g\u0142\u00f3wnych punkt\u00f3w z biznesowego punktu widzenia, przede wszystkim:<\/p>\n\n\n\n