Skipulag tæknivinnu

Ég tel að þekking á eðli stjórnunarhátta í kring um hugbúnaðarþróun sé almennt orðin nokkuð góð á Íslandi. Það er, hvernig við finnum út úr því hvað er rétt að þróa með góðri vörustjórnun og hvernig við komum á trausti, sýnileika og þéttum samskiptum með góðri teymisþjálfun. Þetta er augljóslega forsenda fyrir því að hugbúnaðarverkefni geti gengið vel.

Sé góð teymisþjálfun og vörustjórnun forsenda fyrir vel heppnuðu hugbúnaðarverkefni, þá er skipulag tæknivinnu (e. software development strategy) frumforsenda. Án þess verður enginn hugbúnaður þróaður til að byrja með. Þetta er því augljóslega ansi mikilvægt efni að skilja. Fólk sem er ekki innviklað í tæknivinnu frá degi til dags hefur yfirleitt takmarkaða innsýn í skipulag á tæknivinnunni, og þar með á hvers konar ákvarðanir er verið að taka þar og hvaða afleiðingar þær hafa. Það hefur síðan þær afleiðingar að úthlutun á tíma forritara verður stundum að full miklu reipitogi á milli þess að bæta tækniskipulagið og að þróa nýja notendavirkni. Þetta er tilraun til að auka umræðu um þessa hlið hugbúnaðarþróunar.

Hvert er markmið skipulags tæknivinnu?

Ein ágætis einföldun á muninum á markmiðum skipulagi vörustjórnunar og skipulagi tæknivinnu, er að vörustjórnun snýst um að þróa réttu hlutina, en skipulag tæknivinnu snýst um að þróa hlutina rétt. Hvað nákvæmlega er rétt í þeim efnum er augljóslega breytilegt eftir samhengi, og það eru ýmis sjónarmið sem togast á þar. Helstu markmið skipulags tæknivinnu í hugbúnaðarþróun tel ég vera eftirfarandi:

• Hámarka líkur á að nýir eiginleikar séu nothæfir og virki eins og til er ætlast.
• Lágmarka tíma í loftið fyrir breytingar (e. change cycle time).
• Lágmarka handavinnu í kringum að koma breytingum til notenda.
• Lágmarka tíma í loftið fyrir fyrstu virkni (e. bootstrap lead time).
• Lágmarka líkur á að breytingar brjóti eldri virkni.
• Hámarka möguleika á þéttri endurgjöf frá hagsmunaaðilum.
• Lágmarka kostnað við rekstur lausna, annars vegar á meðan þær eru í þróun, og hins vegar til framtíðar.
• Hámarka möguleika til að endurnýta virkni sem nú þegar er búið að þróa.
• Lágmarka líkur á innbrotum í kerfin / Hámarka öryggi.
• Hámarka dreifingu á tækniþekkingu.
• Lágmarka uppsöfnun á tækniskuld.

Það er því í mörg horn að líta, og mörg af þessum markmiðum vinna gegn hverju öðru. Sem dæmi þá er það ekki til þess fallið að hámarka öryggi að lágmarka kostnað. Því er nauðsynlegt að meta hver kostnaðurinn af öryggisbresti væri, sem eitt og sér er flókið vandamál, og fjárfesta passlega í öryggisráðstöfunum miðað við það mat. Einnig þarf að þekkja viðeigandi öryggisstaðla, en að uppfylla þá er að sjálfsögðu lágmarks fjárfestingin í öryggi. Eins þá togast á þau markmið að lágmarka tíma í loftið og að lágmarka líkur á að breytingar brjóti eldri virkni. Helsta aðferðin við að lágmarka líkurnar á að eldri virkni brotni er að keyra sjálfvirkar prófanir, sem þarf bæði að skrifa og keyra, en það eykur aftur tímann sem tekur að koma stakri breytingu í loftið.

Hvaða aðferðir hjálpa til við að ná þessum markmiðum?

• Samfelld samþáttun og útgáfa ( CI/CD )
• Sjálfvirkar prófanir — Test automation
• Sjálfvirk greining á afurðum — Static code analysis
• Sjálfvirkt eftirlit og viðvaranir — Monitoring and notifications (errors, logs, load, etc)
• Kóðarýni — Code reviews
• Nýtileika/nytsemis/könnunarprófanir — Exploratory/usability testing (handvirkar)
• Kostnaðargreining og eftirlit — Cost analysis and monitoring
• Sjálfvirkar þróunarútgáfur — (e. Automatic branch/feature deployments) til að auðvelda endurgjöf frá hagsmunaaðilum.
• Viðeigandi hönnunarreglur og hugbúnaðarhögun. Sem dæmi “SOLID principles” og “microservices”.
• Endurþáttun eða endurhönnun kóða. (e. Refactoring or redesigning/rewriting code) til að lágmarka uppsöfnun á tækniskuld.
• Öryggisúttektir frá ytri aðilum sem sérhæfa sig í öryggi.

Það að gefa út þróunarútgáfur sjálfvirkt hefur þá sérstöðu að vera tækniaðferð sem er eingöngu ætluð til að styðja við vörustjórnun, þ.e.a.s. að auðvelt sé að fá endurgjöf á hugbúnað í þróun. Hún er er fyrst og fremst viðeigandi fyrir notendaviðmót eins og vefi og öpp, minna nytsamleg fyrir API þjónustur, og ennþá minna fyrir gagnageymslur.

Að auki mætti nefna að UI hönnun og notkun UI/UX frumgerða hefur veruleg áhrif á að byggja vöruna rétt, en fellur ekki strangt til tekið undir tækniskipulag hugbúnaðarþróunar.

Hvernig mælum við hversu gott tækniskipulagið er?

Tom Gilb nokkur hélt því fram á ráðstefnu hér á landi fyrir nokkrum árum að hægt væri að mæla allt ef menn ætluðu sér það. Sjálfur efa ég það ekki eftir að hafa horft á hann skilgreina hvernig hægt er að mæla ást.

Hér á eftir fara helstu mælingar sem ég tel bæði nytsamlegar og ódýrar í framkvæmd, og gefa okkur verðmæta innsýn inn í hversu gott tækniskipulagið, og framkvæmd þess, er:

Tími í loftið fyrir breytingar (e. change cycle time) er mældur með því að finna þann stað í kóðabasanum sem tekur lengstan tíma að breyta og koma í loftið, og skoða hvað tekur langan tíma að koma breytingu þar til notenda í gegn um CI/CD pípuna með öllu tilheyrandi. Góð tala hér telst vera 1–2 mínútur, allt innan 10 mínútna ásættanlegt, 10–60 mínutur frekar slappt. Ef við erum farin að tala um daga eða vikur hér þá er CI/CD kerfið líklega brotið eða ekki til staðar. Ég mæli með að þessi mæling sé gerð á hreinum keyrslutíma. Sem dæmi, ekki mæla tímann sem tekur að finna hverju á að breyta, heldur frá tímanum sem er ýtt á “push” þar til breytingin er virk í raunumhverfi.

Villutíðni mælist í meðaltíma á milli villna (e. Mean Time Between Failures). Hér er nauðsynlegt að flokka villur eftir alvarleika, því villur hafa mjög mismunandi afleiðingar. Það getur verið allt frá því að valda alvarlegu líkamstjóni eða setja fyrirtæki á hausinn, yfir í að vera útlits eða smekksatriði. Nákvæm útlistun á þessu er fyrir utan efni þessarar greinar.

Dekkun prófana (e. test coverage). Ýmis tól eru til sem mæla hversu stórt hlutfall af kóða er undir sjálfvirkum prófunum. Þau geta nýst vel til að gefa hugmynd um hvar verkefni eru stödd. Vandamálið við þessar mælingar er að þær segja okkur ekki hversu vel virknin er prófuð, og eru því vandmeðfarnar sem stjórntæki, og í raun ónothæfar sem eitthvað til að setja markmið eftir.

Tími fram að fyrstu virkni (e. bootstrap lead time) er mæld með því að skoða tímann frá því að byrjað er að forrita nýja virkni (svo sem vef, þjónustu eða app) þar til hægt er að ákveða að setja hana í loftið. Í góðu tækniskipulagi mælist þetta í klukkutímum, í mesta lagi dögum. Athugið að mæla ekki tímann fram að fyrstu nothæfu virkni, þar sem það er einnig mæling á vörustjórnun.

Í sumum tilfellum eru mælingin einfalt já eða nei. Sjálfvirkar þróunarútgáfur eru þannig, annað hvort eru þær til staðar eða ekki. Ef svarið er “stundum”, þá breytist mælingin í fjöldi sem segir “já” vs fjöldi sem segir “nei”.

Notendakannanir eru almennt miðaðar við að segja okkur hvort hugbúnaður sé að leysa rétta vandamálið. Þær geta sagt okkur ýmislegt um hvort varan sé rétt gerð líka, svo sem varðandi hraða, hversu auðvelt er að nálgast hana og byrja og hversu margar villur koma upp í daglegri notkun.

Hvernig tala ég sem vörustjóri/eigandi þá við tækniteymið um þessi mál?

Þegar öllu er á botninn hvolft, þá er tæknifólk ráðið til þess að taka ákvarðanir um tæknimál. Oft á tíðum eru vafamál samt mörg, margir kostir í stöðunni, og óljóst hvert iðnaðurinn er að stefna. Eitt dæmi um það eru kostir og gallar þess að nota svokölluð “monorepo”, sem ég skrifaði um hér nýlega. Í þeim tilfellum sem stórar stefnubreytingar eru gerðar í tæknimálum, þá er nauðsynlegt að eigendur verkefnis séu meðvituð um líklegan kostnað slíkra stefnubreytinga, og að tækniteymið sé vel meðvitað um hvaða þætti tækniskipulags slíkum breytingum er ætlað að hafa áhrif á, og af hverju. Að allir hagsmunaaðilar teymis taki sameiginlega umræðu um markmið og mælingar skipulags tæknivinnu út frá punktunum hér að ofan getur líklega auðveldað samtöl um tækniákvarðanir verulega. Ég segi líklega, þar sem þetta er alveg óreynd kenning sem er að fæðast með þessari grein.

Hversu mikil vinna er þetta?

Það er ansi breytilegt. Fyrir lítil vefverkefni, þá getur verið mjög lítið mál að komast af stað með tólum eins og Vercel og Heroku sem eru búin að vinna stóran hluta af grunnvinnunni fyrirfram. Fyrir stærri verkefni og fyrirtæki sem vilja varðveita eldri kóða sem uppfyllir ekki viðmið í dag, þá getur þetta verið veruleg fjárfesting. Margt að þessu snýr að því að tileinka sér og viðhalda þekkingu sem er verkefni sem aldrei lýkur. Þessi hugsunarháttur þarf því að vera innbyggður í kúltúr tækniteyma til að geta virkað. Nauðsynlegur þáttur í því er skilningur og stuðningur stjórnenda til lengri tíma.

Þetta eru áreiðanlega ekki tæmandi listar, ef þú hefur fleiri nytsamleg markmið, aðferðir eða mælingar sem eiga við tækniskipulag, þá væri gaman að fá athugasemd á þessa færslu.