…er stóra spurningin sem, Heiðar Eldberg Eiríksson teymisstjóri hjá APRÓ, velti fram í samnefndu erindi á UT-messunni.

Við fengum Heiðar til að setjast niður og reifa fyrirlesturinn og segja betur frá DevOps, aukningu kulnunar í upplýsingatækni og af hverju lausnirnar eigi alltaf að snúast um fólk.

„Skilvirkni er grunnforsendan í útgáfuferlum í upplýsingatækni. Hinvegar kemur það gjarnan fyrir að sókn í átt að skilvirkni snúist upp í andhverfu sína - og getur jafnvel ollið kulnun hjá starfsfólki“ segir Heiðar og bendir á nýlegar rannsóknir[1][2] sem sýna að starfsfólk í upplýsingatækni er oft undir miklu álagi, sérstaklega í kjölfar Covid-faraldursins.

Í erindi sínu kom Heiðar inn á hvernig bregðast megi við þessum vanda. Þar á meðal voru hugmyndir Richard Seroter um „Shift Down„ en einnig kynnti Heiðar sína útfærslu af sama meiði sem hann hefur nefnt „Shift Out.“ Það er útfærsla sem sérfræðingar APRÓ hafa þróað og eru nú í innleiðingarferli með bæði góðum árangri og ánægju. En byrjum á byrjuninni.

Hvaðan kemur álagið? Og er verið að ætlast til of mikils?

„Síðustu áratugi hefur „agile“ verið allsráðandi í skipulagi á hugbúnaðarverkefnum“ segir Heiðar og bætir við að „..þessi aðferðafræði fær stundum önnur nöfn, eins og Scrum eða DevOps, en í raun er þetta mikið til frá sömu rótum komið.“

Meginmarkmiðið að sögn Heiðars er að færa fleiri og fleiri þætti til vinstri í virðiskeðju hugbúnaðargerðar. Á þetta að efla hvert og eitt teymi til að geta séð um alla þætti virðiskeðjunnar og fjarlægja hindranir í útgáfu hugbúnaðar.

Fossinn flæðandi

Til útskýringar lýsir Heiðar vinnuferlinu, sem tíðkast víða hjá upplýsingatæknifyrirtækjum í dag: 

„Ímyndum okkur hefðbundið og línulegt verklag í hugbúnaðargerð, oft nefnt waterfall. Gefum okkur að það sé ákveðinn vandi eða þörf sem ekki er mætt og út frá því eru settar fram kröfur um hvernig lausn gæti litið út.
Því næst tekur við greining þar sem möguleg lausn er metin að verðleikum t.d. hvers konar notendur væru að lausninni og hvort það sé markaður fyrir henni o.s.fr. Yfirleitt sjá vörustjórnun og/eða söluteymi um þessa þætti.

Þaðan taka forritarar við og hanna kerfið s.s. Kröfurnar eru þýddar í kerfishögun. Þaðan hefst forritun á lausninni og í kjölfarið prófun af hendi prófara til að sannreyna að kerfið standist fyrirgreindar kröfur.
Að lokum er komið að útgáfu og almennri notkun - að því gefnu að ágætlega hafi tekist til. Þá er kerfið komið í hendur kerfisstjóra í rekstur og viðhald.“

Sameiginlegt markmið - mismunandi ábyrgð

Þetta fyrirkomulag getur gengið upp, en raunveruleikinn er oft annarr, líkt og Heiðar bendir á:
Hann nefnir að vörustjórar og söluteymi eru yfirleitt í þeirri stöðu að reyna að flýta framkvæmd eins og unnt er, þar sem meginmarkmiðið er að skapa virði fyrir kúnnann á sem stystum tíma. 

Heiðar heldur áfram og nefnir að forritarar sem taka næst við vilja auðvitað líka skapa virði fyrir kúnnann en þeir þurfa líka að passa að rétt sé farið að hlutunum.
„Það þarf að vanda til verka við kerfishögun og gagnaskipan til að lenda ekki í vandræðum þegar frammí sækir.“ 

Prófarar reyna eftir fremsta megni að sjá til þess að varan sé eins laus við galla og unnt er, en kerfisstjórar hugsa mögulega fyrst og fremst um uppitíma og öryggi:

„Öll eru með sama markmiðið, að gefa út góðan hugbúnað eins vel og hratt og unnt er, en vegna þess að þetta eru aðskilin teymi með aðskilda ábyrgð getur myndast þessi togstreita milli teyma“ segir Heiðar.

Heiðar lýsir núningum sem skapast gjarnan: „Forritarar þurfa í vissum tilfellum að halda aftur af vörustjórn sem vill fara hraðar, en þurfa svo líka að ýta áfram á prófara sem halda á vissan hátt aftur af forriturunum“ 

Hann segir það eðlilegt að prófararnir vilji vanda betur til verka í tilraun til að koma í veg fyrir að alvarlegur galli sleppi út til notandans.

Þegar prófarar hafi lokið sér af leggjast þeir á með forriturum og vörustjórn um að vilja koma þessu út sem fyrst. Þá eru það kerfisstjórar sem standa í vegi fyrir útgáfu með sitt breytingarstjórnunarferli, í tilraun til að lágmarka áhættu af útgáfunni þegar kemur að öryggi og uppitíma kerfisins.

Mynd: UT-messan

Þrálátur grunnágreiningur

„Þungt breytingarstjórnunarferli hvetur til fleiri breytinga samtímis, sem eykur líkur á vandamálum við útgáfu, sem síðan leiðir til hertari stjórnunnar“ segir Heiðar.

Hann nefnir að fleiri breytingar þýðir fleiri próf, sem lengir prófunartímann, sem hvetur forritara til að gera fleiri og fleiri breytingar samtímis og svona koll af kolli. 

„Í DevOps fræðunum er þessi togstreita kölluð The Core Chronic Conflict og tregðan sem eykst milli teyma þegar viðbrögðin við vandamálum sem koma upp eru að fara hægar nefnist The Downward Spiral.“

Ýmiskonar agile aðferðafræði hefur komið fram á sjónarsviðið til að eyða umræddri togstreitu með því að færa ábyrgðina á verkþáttum eins og hægt er til vinstri í virðiskeðjunni. 

Heiðar útskýrir að algengast sé að setja forritara og prófara saman í teymi og færa þannig ábyrgðina á prófun til vinstri. Þá er eitt teymi sem hannar, skrifar kóða og prófar.

Einnig er algengt segir hann að nota t.d. nokkuð sem kallast „Continuous Integration“ til að auka hringrás endurgjafar og gera teyminu kleift að gera frekar fleiri smærri breytingar heldur en færri og stærri.

Flöskuhálsinn færist

Eftir situr hinsvegar flöskuhálsinn á milli þróunarteymis og kerfisstjóra en þar kemur DevOps aðferðafræðin inn.
Með því að draga ábyrgðina á útgáfu, rekstri og viðhaldi inní teymið þá skapast hvati fyrir forritunarteymið að leysa algengustu vandamál sem koma upp í rekstri með sjálfvirkum lausnum og sífellt fleiri og betri hringrásum endurgjafar.

Með því að einbeita sér að þremur kjarnaþáttum DevOps aðferðafræðinnar (þ.e. Flow, Feedback & Experimentation and Learning) verður hvati í teyminu til að hámarka skilvirkni í uppgötvun og úrbótum á göllum sem dregur úr sóun og endurtekinni vinnu, eykur gæði og öryggi vörunnar og eykur uppitímann, því jafnvel þó vandamál komi upp, er búið að lágmarka tímann sem það tekur að finna vandamálið, bregðast við því og leysa það.

„Auðvitað er þetta gríðarleg einföldun á yfirgripsmikilli aðferðafræði sem best er að kynna sér í The DevOps Handbook” en Heiðar hvertur líka lesendur til að kynna sér ræturnar í Lean, Toyota Production Systems o.fl.

Kostirnir við DevOps

Ávinningurinn af því að starfa samkvæmt þessari aðferðafræði er nokkuð ótvíræður en rannsóknir[3] sýna m.a. að fyrirtæki:

• Eru fljótari að gefa hugbúnað út og eru þannig fljótari á markað og að bregðast við breytingum á markaði.

• Uppgötva galla fyrr, sem lágmarkar neikvæð áhrif og lækkar kostnað.

• Sjá aukinn áreiðanleika og sjálfvirkni sem eykur sömuleiðis hagkvæmni og takmarkar endurtekna vinnu og sóun.

• Gæði vörunnar aukast því vandamál uppgötvast og leysast fyrr og eftirfylgni er betri því ábyrgðin á viðhaldi færist ekki milli teyma.

Árlega skýrslan State of DevOps Report úr smiðju PuppetLabs og DORA teymi Google (DevOps Research and Assessment) sýna svipaðar niðurstöður ár eftir ár, segir Heiðar þar sem „fyrirtæki sem vinna samkvæmt DevOps aðferðafræðinni eru margfalt líklegri (amk. 1.35 til 2 sinnum líklegri) til að ná settum markmiðum hvort sem þau markmið snúi að:

• Arðsemi

• Framleiðni

• Markaðshlutdeild 

• Fjölda viðskiptavina 

• Sölutölum vöru eða þjónustu

• Rekstrarhagkvæmni 

• Ánægju viðskiptavina

• Gæðum vöru eða þjónustu sem veitt er 

• Ná markmiðum fyrirtækisins/stofnunnar
  
  

  
  

Heiðar segir að það eigi jafnt við hagnaðardrifin einkafyrirtæki sem og þær stofnanir sem ekki eru reknar í hagnarskyni, þ.m.t. menntastofnanir og opinberar stofnanir[4].

Vönduð innleiðing og réttar áherslur draga úr áhættu á kulnun.

Ýmis önnur tölfræði hefur komið fram segir Heiðar, sem bendir til þess að það skipti verulegu máli hvernig slíkt er innleitt:;  „Hvernig staðið er að því að færa til vinstri í virðiskeðjunni verkþætti og ábyrgðir. Svo má ekki gleyma hættunni sem fylgir ofmetnaði á því sviði, hvort sem það er kallað Agile, DevOps eða eitthvað annað.“

Heiðar vitnar í orð Richard Seroter, Chief Evangelist hjá Google, um málefnið en Seroter segir m.a.

„Vissulega er vinstri færsla - sú aðferð að fella öryggis- og gæðaendurskoðanir inn í þróunarferlið fyrr - fullkomlega skynsamleg hugmynd. En með tímanum hafa fleiri tegundir verkefna, sem hafa ekki alltaf verið hluti af starfslýsingu forritara, verið að færast til vinstri í nafni þess að efla „full stack" forritara.”

Seroter leyfir sér að taka smá „rant” máli sínu til stuðnings:

“Það eru um það bil níu raunverulegir „full stack" forritarar á jörðinni. Nánast enginn skrifar framenda í React, setur upp Kubernetes, stillir RabbitMQ klasa, útvegar pláss á SAN, og setur upp svissinn í rekka.
Í dag er þess krafist af forriturum að þekkja til vefumgjarða (web frameworks), högunarmynstra, prófunaraðferða, buildkerfa, margra tegunda gagnagrunna, skyndiminnis, sjálfvirknibúnaðar, gámastjórnunarkerfa, L4-L7 nethugtaka, SaaS API-a, vöktunarkerfis, fjölda opinberra skýjalausna, og já, kannski smá gervigreind. Ég var að fletta í gegnum Indeed.com, og það er athyglisvert að sjá hvað við erum að krefjast af nýjum og reyndum forritum.

Það er of mikið.”[5]

Hvar liggur ábyrgðin?

Samkvæmt rannsóknum Upwork Research Institute[1] kemur meðal annars fram að:

• 71% starfsfólks í fullu starfi séu með einkenni kulnunar

• 96% Stjórnenda vilja nýta AI meira en 47% starfsfólks veit ekki hvernig þau eiga að fara að því

• 77% segja að AI tól hafi aukið vinnuálag þeirra

  
  

Niðurstöður Upwork Research institute benda þannig til að vandamálið sé vinnuaðferðafræðin og innleiðing hennar - og svokallaðar top down mælingar á afköst.

Að mati Heiðars séu mælingar hjá stjórnendum á frammistöðu og framgang einmitt í andstöðu við hugmyndafræði Agile og DevOps sem leggja áherslu á sjálfstæði teymis, til að mæla, meta og taka ábyrgð á eigin afköstum.

Önnur áhugaverð rannsókn sem Heiðar vísar í Tulili, Capiluppi og Rastogi “Burnout in software engineering:

A systematic mapping study” sem reynir að draga lærdóm af samtals 92 rannsóknum á kulnun í upplýsingatæknigeiranum á heimsvísu allt aftur til ársins 1990, en í henni kemur fram að yfir 80% UT sérfræðingana hafa verið eða eru með einkenni kulnunar eftir Covid-19.[2]

Í rannsókn sinni skoða Tulili et. al. hvernig kulnun innan upplýsingatæknigeirans hefur verið rannsökuð hingað til, hvort hægt sé að draga lærdóm af þeim og hvort hægt sé að gera betur í greiningu, m.a. með aðstoð gervigreindar eða vélnáms (e. machine learning).

„Eitt það merkilegasta sem mér fannst þó koma úr rannsókninni var tilraun þeirra til að draga saman lærdóm allra þessara rannsókna í einhverskonar flæðirit orsakasamhengis kulnunar, en þar sjáum við ákveðin mynstur sem er vert að veita athygli.” segir Heiðar og tekur saman nokkra punkta.

„Við sem einstaklingar berum ábyrgð á okkur sjálfum. Mögulega eru stærstu áhættuþættirnir á kulnun okkar eigin persónueinkenni en kulnun er oft kölluð sjúkdómur hinna samviskusömu. Þannig að við þurfum að vera meðvituð um og í tengingu við okkur sjálf“ 

Heiðar heldur áfram og bætir við að ef fólk upplifi einkenni kulnunar vegna streitu hvetji hann viðkomdi til að leita sér aðstoðar.

En stjórnendur bera líka ábyrgð segir Heiðar. Starfskröfur og álag verður að vera raunhæf en það hefur líka komið í ljós að samskipti stjórnenda við starfsfólk sitt skipta miklu máli.

Heiðar segir að það skipti miklu máli að starfsfólk upplifi að það sé að fá nægilega miklar og réttar upplýsingar frá stjórnendum, hvort sem það snýr að starfinu, stöðu fyrirtækisins eða hvað annað, að starfsfólkið upplifi að það sé að fá að heyra sannleikann.“

Þar að auki er innleiðing á svokölluðum agility practices og Heiðar nefnir að það sé mikilvægt að hlutverkin séu skýr og segir: 

Kulnun kostnaðarsöm

Heildarkostnaðurinn af kulnun er í rauninni ómældur að miklu leyti segir Heiðar. Þ.e.a.s. ef um 80% starfsfólk í UT finnur fyrir kulnun má draga þá ályktun að þeirra afköst hafi dregist saman um eitthvað X, en það er gríðarlega erfitt að mæla.

Þó er hægt er að nýta starfsemi VIRK sem ákveðna mælieiningu, en ávinningurinn af starfseminni er talinn 19 milljarðar á ári og skjólstæðingar úr röðum upplýsingatækni ásamt stjórnsýslunni, fjármálaþjónustu og almennum skrifstofustörfum tróna á toppnum sem stærsti skjólstæðingahópur VIRK.[6]

Hvað er til ráða?

Heiðar vitnar aftur í Seroter sem hefur komið fram með hugmynd sem hann kallar „shift down“ sem mögulegri lausn á þessu vandamáli. Seroter hefur útskýrt lausnina á þennan veg:

„Sem atvinnugrein þurfum við að hjálpa til. Í fyrsta lagi, í stað þess að segja forriturum (og stjórnendum þeirra) að færa allt til vinstri, þurfum við að hvetja þá til að færa niður með því að nýta til fulls þá tækni sem þeim stendur til boða og flytja meiri vinnu niður á þau platform sem þeir eru þegar að nota. Þjappið saman tæknistafla ykkar. Ekki þvinga fólk til að þurfa að vita svona mikið til að sinna starfi sínu. Bjóðið upp á platform abstractions.”[5]

Þar vísar Seroter, útskýrir Heiðar, til framþróunar sem orðið hefur á DevOps aðferðafræðinni sem er kölluð Platform Engineering. Sú snýst um að hjúpa flækjustigið af innleiðingu, samþættingu og rekstri og auðveldar hagnýtingu einhverjar getu innan virðiskeðju hugbúnaðarþróunar.

Þessi þróun, að byggja upp platform engineering teymi má sjá víðar síðustu misseri bendir Heiðar á, en samkvæmt Gartner eru um 80% fyrirtækja að áætla að vera með teymi helgað Platform Engineering fyrir 2026[7] að fyrirmynd fyrirtækja eins og Google.

Og Seroter heldur áfram:

„Hjá Google bjóðum við upp á platform fyrir forritun, prófanir, build, útgáfu, dreifingu, hýsingu, viðvaranir og fleira. Sérstök teymi frá Google styðja við þessi mikilvægu platform svo að vöruþróararnir okkar geti einbeitt sér að því sem þeir þurfa að gera án þess að þurfa að þekkja til eða reka ”full stack" af innviðum. Sérhver stofnun ætti að gera slíkt hið sama.”[5]

Þrátt fyrir að vera sammála hugmyndafræðinni bendir Heiðar á að þetta sé ekki raunhæft nema hjá stærri fyrirtækjum eins og Google eru og segir:

„Það er ekki raunhæft fyrir lítið þróunarteymi með kannski 4-6 forritara að byggja upp heilt annað platform teymi sér til stuðnings, hvað þá mörg teymi fyrir mismunandi hluta platformsins.”

Heiðar leggur þó til að sérfræðingar og stjórnendur á Íslandi gefi ekki hugmyndafræðina upp á bátinn.

Það er þá að sögn Heiðars sú hugmynd að fá aðkeypt platform sem uppfyllir þarfirnar hverju sinni til þróunarumhverfis og virðiskeðju, til að ná fram árangri.

APRÓ hefur undanfarið þróað slíkt platform fyrir íslenskan markað er nefnist APRÓ Hraðallinn. Þannig geti minni fyrirtæki og stofnanir fengið aðgang að mikilli reynslu og góðum tólum án þess að auka til muna álag á starfsfólk sitt eða stór auka útgjöld í þróunarkostnaði.

APRÓ Hraðallinn

„APRÓ hraðallinn er þróaður í samstarfi við íslensk fyrirtæki og stofnanir og snýst að miklu leyti um að safna saman og formfesta það sem við vitum að hefur gefist vel í gegnum tíðina.” segir Heiðar og bendir jafnframt á að mikla stærðarhagræðingu er hægt að sækja með því að taka þátt - þvert á fyrirtæki og stofnanir. 

Hraðallinn býður upp á möguleikann á að nýta og þróa saman platform fyrir þarfir íslenskra fyrirtækja og stofnana í stað þess að þau vinna hvert í sínu horni að því að leysa í grunnin sömu vandamálin.

Heiðar segir að Apró hraðallinn sé leið fyrir fyrirtæki að úthýsa flækjustiginu og stórum hluta álagsins til aðila sem hafa það sem sína kjarnastarfsemi að leysa þau mál.

„Á meðan geta þróunarteymi viðskiptavina okkar einbeitt sér að því að skapa virði fyrir sitt fyrirtæki án þess að gefa afslátt á getu sína til þróunarhraða, vöktunar, upptíma, öryggis eða hvaðeina. Það er okkar kjarnastarfsemi.”

Heiðar bendir líka á að þau hjá APRÓ sjái líka aukna þörf í fyrirtækjaumhverfinu að geta nýtt sér gervigreind á öruggan hátt en á sama tíma sjáum við að það felur í sér aukið álag og flækjustig fyrir þróunarteymi. Þaðan hafi hugmyndin um gagna og gervigreindar hraðallinn sprottið upp.

„Með nálgun APRÓ geta fyrirtæki á öruggan hátt nýtt sér möguleikana sem felast í spunagreind og nútíma gagnainnviðum án þess að gera málamiðlanir í öryggi.“

Hann útskýrir að gervigreindarmódelin séu keyrð í lokuðu umhverfi á hagkvæman hátt „sem gerir viðskiptavinum okkar kleift að auðga gervigreindina, jafnvel með sínum viðkvæmustu gögnum, en samtímis örugg í þeirri vitneskju að ekkert er að fara í gegnum kerfi erlendra stórfyrirtækja.”

APRÓ gervigreindin nýtir Bedrock þjónustu AWS, með þannig högun að innviðirnir eru aðskildir frá öðrum viðskiptavinum APRÓ eða AWS og með dulkóðun sem uppfyllir ströngustu öryggis og gæðastaðla.

Fleiri vilja verða hluti af lausninni

Nútímaupplýsingatækni kallar á nútímalegar lausnir og vinnuaðferðir sem skapa starfsgleði og ánægju jafnt sem aukna skilnvirkni og hagkvæmni - nokkuð sem ekki má gefa afslátt af segir Heiðar. 

„Aðferðir okkar eru stöðugt í þróun, en DevOps og Shift Out hafa reynst okkur hjá APRÓ afar vel, og við trúum á þessa lausn.“ 

Hann bætir við að því fleiri fyrirtæki og stofnanir sem verði hluti af APRÓ hraðlinum, því betri verður lausnin - svo lausnin sé sjálfbær að því leyti að hún eflist með aukinni þátttöku.

 Allt leiðir þetta til bæði betri aðferða en ekki síður bættri líðan þeirra sem koma að verkefnunum, og Heiðar bætir við lokaorðunum:

„Lausnirnar okkar verða aldrei betri en fólkið sjálft sem vinnur vinnuna, og lykillinn er að finna leið sem hámarkar báða þætti“ 

Viltu vita meira um APRÓ Hraðalinn? Smelltu hér

Tilvísanir og annað ítarefni

[1] Monahan, Kelly, and Gabby Burlacu. “From Burnout to Balance: AI-Enhanced Work Models for the Future.” Upwork, July 23, 2024. https://www.upwork.com/research/ai-enhanced-work-models.  

[2] Tien Rahayu Tulili, et al., “Burnout in software engineering: A systematic mapping study”, Information and Software Technology, Vol. 155, (2023), https://doi.org/10.1016/j.infsof.2022.107116. (https://www.sciencedirect.com/science/article/pii/S0950584922002257)

[3] Rubén Grande et al., “Is it worth adopting DevOps practices in Global Software Engineering? Possible challenges and benefits.”  Computer Standards & Interfaces, Vol. 87 (2024), https://doi.org/10.1016/j.csi.2023.103767 (https://www.sciencedirect.com/science/article/pii/S092054892300048X) 

[4] Dr. Nicole Forsgren, Jez Humble, Gene Kim, Nigel Kersten, et al. ”State of DevOps Report” 2013-2024 PuppetLabs, DORA, https://www.puppet.com/resources/history-of-devops-reports, https://www.puppet.com/resources/state-of-platform-engineering 

[5] Seroter, Richard. “Richard Seroter on Shifting down vs. Shifting Left | Google Cloud Blog.” Google, June 8, 2023. https://cloud.google.com/blog/products/application-development/richard-seroter-on-shifting-down-vs-shifting-left.

[6] Stefánsdóttir, Berglind, and Guðrún Rakel Eiríksdóttir. “Kulnun í Starfi.” VIRK Starfsendurhæfingarsjóður, May 23, 2022. https://www.virk.is/is/um-virk/upplysingar/frettir/kulnun-i-starfi.  

[7] David Sandilands, Margarret Lee. ”2024 State of DevOps Report: The Evolution of Platform Engineering, Puppet by Perforce, https://www.puppet.com/resources/history-of-devops-reports, https://www.puppet.com/resources/state-of-platform-engineering