Noen liker fossefalls-mora

Smidig utvikling har forført mange kompetansefirmaer. De har tidligere vært helt avhengig av andre tilnærmelser. Mange vil fortsatt være det. Det å få frem og realisere kravene kan være viktigere enn å dekke behovene.

Smidig har veldig fokus på prosjekteiers behov, men disse er ikke alltid forenlig med virksomhetens behov. Krav skal reflektere virksomhetens politikk på det området prosjektet skal dekke, ikke bare øyeblikkets behov, men også fremtidens.

Å svare på øyeblikkets behov kan lett reflektere prosjekteiers oppfatninger, spesielt hvis personen har klare oppfatninger. Mange prosjekter har lidd under sterke personers oppfatninger.

Først identifikasjon siden spesifikasjon, som en styringsgruppe kan gå god for bør smidig vurdere, slik at ikke løsningen fullstendig blir til under utviklingsfasen, uten at man ser for seg det endelige målet før utviklingen er ferdig. Selv om veien blir til mens man går er det greit at man vet hvor den skal.

Kostbart vedlikehold

Når mange større utviklingsoppdrag er ferdigstilte, er de foreldete. De reflekterer enten de opprinnelige spesifikasjonene eller behovene underveis. Utfordringen er å forbedre dem med minst mulig kostnad.

I all programvare er det feil. Utfordringen er å finne dem raskt og gjøre forbedringer på en profesjonell måte. Det krever spesifikasjon, dokumentasjon, testing og testresultater for å demonstrere feilrettingen.

Vedlikehold er det man bruker penger på. Mange smidige prosjekter har ennå ikke fått behov for større forbedringer.

Alle undersøkelser tilsier at anskaffelseskostnadene nærmer seg null i forhold til totalkostnadene. Det dokumenteres kontinuerlig ved at inntil 80 prosent av it-budsjettene benyttes til å holde applikasjonene og utrustningen oppegående.

Drømmen er at prosenten er mye lavere. Derfor synes skytjenester så forlokkende. Kundene bryr seg ikke med hva slags utviklingsmetodikk som ligger bak. Det skal virke, det skal være rimelig.

Kode i tenårene

Smidig retter seg mye mer mot én oppdragsgivers behov, enn mot en oppdragsgiver som skal tilfredsstille behovene til mange kunder med mange brukere.

All historikk viser at applikasjoner lever. Større applikasjoner lever mer enn ti år. Når applikasjonene kommer i tenårene, begynner de å ha mindre nykker, det vil si at de fleste feilene er blitt luket bort.

Derfor er det fornuftig som Gartner ser det, å ha eksplisitte prosesser i henhold til internasjonale standarder som ISO 12207 for applikasjoner som skal leve.

Det gjelder å dele opp oppgaven i mindre deler ikke ulikt det som skjer i smidig og dokumentere i et katalogsystem. Epost er forbudt for dokumentasjon med hensyn til behov, krav, spesifikasjon og testresultater.

Robuste mødre

Dernest gjelder det å ha et testregime som foretar kvalitetssikring. For testing er alle utviklere enig i. Spørsmålet er med hva slags data applikasjonen skal testes. I første omgang skal det være riktige data for å dokumentere riktige resultater.

Skal det være realsistisk benyttes det sandkasse-produksjon. Alt er identisk med virkelige behov. Det benyttes virkelige data, men resultatene får ingen påvirkning på databasene, uansett hvilke feil som oppstår.

Utfordringen i dag er at applikasjoner ikke lenger lever innen virksomhetens vegger. De har tilkobling til nettet. De blir utsatt for utenforstående som har andre hensikter enn å benytte forutsatte data.

Derfor må applikasjoner testes med manglende data, med sære data, for å se hva koden gjør når den mottar andre data enn forutsatt.

Hvorvidt smidig i løpet av en scrum-periode blir testet mot en innbryterens strategi, er usikkert. Men før et smidig-prosjektet er ferdig, bør også det kjøres gjennom sandkassetesting med forbryterisk hensikt.

Vi er redde for våre døtre. De er ukjente med hensyn til andres hensikter. Mødre er mer erfarne og robuste og takler derfor utfordinger bedre.