Agile-menetelmästä on hyvistä syistä tullut kaupallisen ohjelmistokehityksen hallitseva lähestymistapa: se vähentää toimitusriskiä tiheän integroinnin avulla, nostaa väärinkäsitykset esiin varhaisessa vaiheessa toimivan ohjelmiston demonstraatioiden kautta ja sallii laajuuden mukauttamisen sitä mukaa kun ymmärrys vaatimuksista kehittyy. Nämä hyödyt ovat todellisia ja sovellettavissa puolustusohjelmistohankkeisiin. Haasteena on, että puolustushankkeet tuovat mukanaan rajoitteita, joita vakiintuneet Agile-käytännöt eivät ole suunniteltu käsittelemään — eikä näiden rajoitteiden sivuuttaminen saa niitä katoamaan.
Tässä artikkelissa tarkastellaan, missä yleisesti harjoitettu Agile on ristiriidassa puolustusvaatimusten kanssa, mitkä sopeutukset ovat osoittautuneet tehokkaiksi ja missä yleinen käsitys Agilen soveltamisesta puolustusalalla kaipaa päivitystä sen perusteella, mikä todellisuudessa toimii käytännössä.
Missä Agile on ristiriidassa puolustusvaatimusten kanssa
Turvaluokitus ja pääsynhallinta. Vakiintunut Agile olettaa, että kaikki tiimin jäsenet voivat työskennellä koodikannan kaikkien osien parissa ja osallistua kaikkiin seremonioihin. Puolustushankkeet, joissa on turvaluokiteltuja komponentteja, voivat rajoittaa sitä, kuka saa työskennellä minkäkin alijärjestelmän parissa turvaselvityksen tason perusteella. Tämä luo tiimirakenteita, joita Agilen monialaisen tiimin malli ei ennakoi: sprinttiimi voidaan joutua jakamaan selvitettyihin ja selvittämättömiin osiin, jolloin pariohjelmointi tai yhteinen koodikatselmointi turvaluokitusrajojen yli on rajoitettua. Sprintin suunnittelu ja retrospektiivit, jotka tavallisesti pidettäisiin koko tiimin kesken, voidaan joutua erottelemaan.
ITAR- ja vientivalvontarajoitteet. Hankkeissa, joissa on käytössä Yhdysvalloista peräisin olevaa teknologiaa, johon sovelletaan International Traffic in Arms Regulations -säädöksiä (ITAR), tiimin kokoonpanoa rajoittavat kansalaisuusvaatimukset. Vakiintuneet Agile-rekrytointikäytännöt — pätevimmän saatavilla olevan tiimin kokoaminen — voivat olla ristiriidassa ITAR-vaatimusten kanssa, jotka estävät ulkomaan kansalaisia pääsemästä käsiksi tiettyihin teknisiin tietoihin. Tämä vaikuttaa tiimin kokoon, kokoonpanon joustavuuteen ja kykyyn vahvistaa tiimejä nopeasti, mihin kaikkeen Agile nojaa.
Muodollinen akkreditointi ja käyttölupa (Authority to Operate, ATO). Puolustusohjelmistojärjestelmät edellyttävät tyypillisesti turva-akkreditointia ennen kuin niitä voidaan ottaa käyttöön operatiivisissa ympäristöissä. Akkreditointiprosessit — toteutettiin ne sitten Yhdysvalloissa Risk Management Frameworkin (RMF) tai muissa maissa vastaavien kehysten mukaisesti — eivät sovi sprintteihin. Niihin liittyy laaja dokumentaatio, todisteiden kerääminen, kolmannen osapuolen arviointi ja valtuuttavan viranomaisen (Authorizing Official) muodollinen päätöksenteko. Tämä luo rakenteellisen ristiriidan: Agile tuottaa toimivaa ohjelmistoa jatkuvasti, mutta käyttöönottoa rajoittavat akkreditointiaikataulut, jotka voivat jäädä kehityksestä kuukausia jälkeen.
Ilmarakoistetut kehitysympäristöt. Turvaluokiteltua tietoa käsittelevät puolustushankkeet edellyttävät usein, että kehitys tapahtuu ilmarakoistetuissa ympäristöissä — järjestelmissä, jotka on fyysisesti irrotettu julkisista verkoista. Vakiintuneet CI/CD-putket riippuvat internetin kautta saavutettavista pakettivarastoista, konttirekistereistä ja pilvipohjaisesta build-infrastruktuurista. Ilmarakoistettu ympäristö edellyttää, että kaikki nämä replikoidaan sisäisesti, mikä on toteutettavissa mutta vaatii merkittävää infrastruktuuri-investointia ja luo jatkuvia synkronointihaasteita silloin, kun komponenttien versioita on päivitettävä.
Sopeutukset: sprinttiporrastetut turvakatselmoinnit ja akkreditointitietoinen CI/CD
Tehokkaat puolustusalan Agile-hankkeet eivät poista edellä mainittuja rajoitteita — ne ottavat ne kehitysprosessissa nimenomaisesti huomioon.
Sprinttiporrastetut turvakatselmoinnit integroivat turva-arviointitoiminnot sprintin kiertoon sen sijaan, että niitä käsiteltäisiin kertaluonteisena porttina. Jokainen sprintti sisältää turvakatselmointitoimia suhteessa tehtyihin turvallisuuden kannalta merkityksellisiin muutoksiin: tunnistautumislogiikkaa muokkaava sprintti sisältää kohdennetun turvakatselmoinnin näistä muutoksista; sprintti, joka lisää ei-arkaluonteista raportointitoiminnallisuutta, voi vaatia vain tavanomaisen koodikatselmoinnin. Tämä jakaa turvakatselmoinnin kuormituksen koko hankkeen ajalle ja estää sellaisen turvavelan kertymisen, joka tuottaa hallitsemattoman katselmointijonon ennen akkreditointia.
Sprinttiporrastetut katselmoinnit luovat myös jatkuvan todistepohjan akkreditointia varten. Sen sijaan, että akkreditointidokumentaatio tuotettaisiin takautuvasti hankkeen lopussa — mikä on sekä tehotonta että tarkkuudeltaan kyseenalaista — sprinttikohtaisesti tuotetut turvakatselmointitiedot muodostavat ajantasaisen todisteen siitä, että turvatoimet suoritettiin kehityksen edetessä. Akkreditoijat hyväksyvät yhä useammin tämän sprintti kerrallaan -todistemallin tiukempana kuin tiettyyn ajankohtaan sidotun dokumentaation.
Akkreditointitietoinen CI/CD vastaa ilmarakon ja akkreditointiaikataulun haasteisiin. Putki suunnitellaan lopullinen akkreditointiympäristö mielessä: se käyttää vain komponentteja, jotka voidaan peilata ilmarakoistettuun ympäristöön, se tuottaa akkreditoijien vaatimat artefaktityypit (SBOM:t, haavoittuvuusskannausraportit, staattisen analyysin tulokset) ja se ylläpitää buildin toistettavuutta, jotta akkreditointia varten toimitettu tarkka artefakti voidaan tarvittaessa luoda uudelleen.
Akkreditointitietoinen CI/CD myös aikatauluttaa työn niin, että mahdollisimman suuri osa akkreditointitodisteista voidaan tuottaa automaattisesti. Akkreditoijien vaatima manuaalinen dokumentaatio — järjestelmän turvallisuussuunnitelmat, turva-arviointiraportit sekä toimenpide- ja virstanpylvässuunnitelmat — mallinnetaan ja päivitetään jatkuvasti sen sijaan, että se kirjoitettaisiin alusta hankkeen lopussa.
Havaittu kaava: Hankkeet, jotka käsittelevät akkreditointia erillisenä, Agile-kehityksen rinnalla kulkevana työvirtana, suoriutuvat johdonmukaisesti paremmin kuin hankkeet, jotka yrittävät lykätä akkreditointitoimia loppuun. Akkreditointitietoisuuden ylläpitämisen kuormitus koko hankkeen ajan on pienempi kuin se kuormitus, joka syntyy, kun todisteita yritetään rekonstruoida ja havaintoja korjata sen jälkeen, kun kehitys on nimellisesti valmis.
Dokumentaatiovaatimukset vs. Agile-manifesti
Agile-manifesti ilmaisee asettavansa "toimivan ohjelmiston kattavan dokumentaation edelle". Tämä on järkevä periaate kaupallisessa ohjelmistossa, jossa edistymisen ensisijainen mittari on toimitettu arvo. Puolustushankkeissa dokumentaatio palvelee tehtäviä, jotka ulottuvat sen tallentamista pidemmälle, mitä ohjelmisto tekee: se on oikeudellinen tallenne siitä, mitä on sovittu, mitä on toimitettu ja miten se on verifioitu; se on todistepohja sääntelyvaatimusten noudattamiselle; ja se on artefakti, jonka avulla pitkäikäisiä puolustusjärjestelmiä voivat ylläpitää ja päivittää tulevat tiimit, joilla ei ole jatkuvuutta alkuperäisten kehittäjien kanssa.
Käytännön ratkaisu ei ole valita toimivan ohjelmiston ja dokumentaation välillä, vaan määritellä nimenomaisesti, mitä dokumentaatioartefakteja vaaditaan, milloin ne on tuotettava ja millä tarkkuustasolla. Puolustushankkeen ohjelmistovaatimusten määrittelyä (Software Requirements Specification) ei pidä sekoittaa kattavaan Agile-tehtäväjonoon; sen on oltava muodollinen, versioitu asiakirja, jolla on jäljitettävyys suunnittelu- ja testausartefakteihin. Ohjelmiston suunnitteludokumentti (Software Design Document) ei ole sama asia kuin arkkitehtuuripäätöstietueet, vaikka molemmat voivat olla rinnakkain olemassa.
Tehokkaasti toimivat puolustusalan Agile-hankkeet tuottavat dokumentaatiota jatkuvasti ohjelmiston rinnalla ja käsittelevät dokumentaatioartefakteja omina toimituksinaan eivätkä jälkikäteisajatuksena. Tämä edellyttää kapasiteetin nimenomaista varaamista — jos dokumentaatio ei ole edustettuna sprintin suunnittelussa, sitä ei tuoteta vaaditulla tahdilla.
Mikä todellisuudessa toimii käytännössä
Puolustushankkeilla, jotka soveltavat Agile-periaatteita onnistuneesti vaatimustenmukaisuudesta tinkimättä, on useita yhteisiä piirteitä.
Ne käyttävät skaalattua kehystä — SAFe:a (Scaled Agile Framework) tai hankekohtaista sovellusta — joka tarjoaa sprinttitason yläpuolelle rakenteen hanketason kysymysten käsittelyyn: julkaisusuunnitteluun, tiimien välisten riippuvuuksien hallintaan ja vuorovaikutukseen sopimusviranomaisen kanssa. Pelkkä Scrum ilman hanketason rakennetta skaalautuu harvoin puolustushankkeen monimutkaisuuteen.
Ne investoivat turvalliseen, vaatimustenmukaiseen kehitysinfrastruktuuriin ennen hankkeen alkua, eivät sen aikana. Ilmarakoistettu ympäristö, akkreditointitietoinen putki ja asiakirjanhallintajärjestelmä ovat hankkeen edellytyksiä, eivät ensimmäisten sprinttien tuotoksia. Hankkeet, jotka aloittavat kehityksen ennen kuin tämä infrastruktuuri on paikallaan, kohtaavat johdonmukaisesti kalliita ja aikatauluun vaikuttavia jälkiasennuksia.
Ne erottavat toisistaan vaatimustenmukaisuustoiminnot, jotka voivat olla ketteriä (turvakatselmoinnit sprintissä, jatkuvasti päivitettävä dokumentaatio, automaattinen todisteiden tuotanto), ja ne, jotka eivät voi (muodollinen akkreditointipäätös, asiakkaan hyväksyntätestaus, sopimukselliset virstanpylväskatselmoinnit). Edelliset voidaan integroida sprintin rytmiin; jälkimmäiset on suunniteltava hanketason tapahtumiksi, joilla on omat aikataulunsa ja aloituskriteerinsä.
Ne kouluttavat koko tiimin — eivät vain prosessivastaavia — niihin puolustusalan erityisvaatimuksiin, jotka vaikuttavat päivittäiseen työhön: mikä muodostaa turvaluokitellun kehitysympäristön, miten vientivalvonnan alaista tietoa käsitellään ja mikä laukaisee muutospyynnön sprintin tehtäväjonon päivityksen sijaan. Vaatimustenmukaisuuden epäonnistumiset puolustusalan Agile-hankkeissa johtuvat useimmiten siitä, että tiimin jäsenet soveltavat kaupallisia Agile-vaistoja konteksteissa, joissa nämä vaistot ovat vääriä, eivät tahallisesta vaatimusten rikkomisesta.