Cybersikkerhed, realtidsdata og robuste it-systemer er blevet fundamentet for moderne forsvar.
Agile metoder vs. Vandfaldsmetode
Agile metoder Agile softwaremetoder henviser til en række forskellige metoder, der er baseret på iterative processer i projekt det vil sige en gentagelse af de klassiske udviklingsgrundsten: Analyse, design, implementering og test, og gentagende gange forbedre hver fase gennem hele projektet.
Nogle af de vigtigste årsager til brug af agile udviklingsmetoder er:
- Hurtig og konstant levering af mindre dele af opgaven til kunden - Softwaren bliver afleveret med mellemrum på uger frem for måneder - Man betaler ved levering og kan relativt nemt skifte leverandør undervejs i projektet - Fleksibel over for nye ønsker om funktioner selv på et sent tidspunkt i projektet - Tæt samarbejde mellem kunde og udviklere - Software kan afprøves med det samme
De agile udviklingsmetoder har vundet stort indpas i de seneste 10 år, men metoderne bliver også kritiseret for, at de kræver en meget rutineret projektledelse, der kan håndtere de konstant flydende processer.
Konkrete agile metoder:
- Scrum - eXtreme Programming (XP) - Lean Software Development - Feature Driven Development - Getting Real
Vandfaldsmetoden Vandfaldsmetoden blev for første gang introduceret i 1970 af den amerikanske it-mand Winston W. Royce, der ironisk nok selv var en fortaler for agile metoder. Uden at kalde den stramt faseinddelte styring af et projekt for vandfaldsmodel, forklarede Winston W. Royce, at metoden inviterede til fiasko, fordi kundens krav konstant ændrer sig undervejs i et projekt.
Den oprindelige vandfaldsmodel bygger på syv grundsten: Kravspecifikation, design, implementering, integration, test, installation og vedligeholdelse, der ligger i syv fastlåste udviklingstrin. Når eksempelvis kravspecifikationen er skrevet, vil man gå videre til designfasen. Når designet er overstået vil man derefter gå videre til implementering uden at se sig tilbage eller ændre på de foregående, overståede trin.
Der er ingen overlap eller læring fra ét trin til det næste, men derimod er metoden en slavisk udførelse af kravspecifikationen. Metoden kræver derfor en stor, ekstrem præcis kravspecifikationer.
Af samme grund er metoden stærkt kritiseret for, at den er alt for rigid til at få indført nye ønsker undervejs i projektet og lære af fejl undervejs. .
Retfærdigvis skal det siges, at Winston W. Royce netop påpegede de fastlåste farer i en senere model, hvor han gjorde rede for, at det skulle være muligt at gå tilbage til et tidligere trin og på den måde udnytte den stærkt faseopdelte model iterativt.
ComputerViews: Den agile model er på mange måder bedre end vandfalds-modellen til komplekse projekter, men historisk har det været en tung omgang at få den accepteret.
I vandfalds-modellen beslutter en organisation sig som bekendt for at skifte system, hvorefter den formulerer sine krav og ønsker og indhenter tilbud fra forskellige leverandører, der så afleverer en færdig og stort set komplet plan for implementering af produktet, som svar på en kravspecifikation.
I den agile model formuleres projektet og målene i små bidder i takt med, at projektet skrider frem, og problemerne identificeres og justeres og løses løbende. På den måde tilpasses leverancerne hele tiden til foranderlige udfordringer hos kunden.
Sværdslag og blod, sved og tårer
I dag er it-verdenen for alvor begyndt at få øjnene op for den agile model, som eksempelvis på flere måder fremmes af staten, der for et halvt års tid siden barslede med standardkontrakten K03 - ikke mindst inspireret af it-projekter i det private erhvervsliv. Det kan du læse mere om her.
Men helt nemt er det ikke, og det har krævet sværdslag og kostet blod, sved og tårer at nå så langt.
Det kan være en stor udfordring for en indkøber i en organisation at købe ind efter det agile tankesæt, hvor man ikke køber et produkt, men skal købe ind på en vision - og så sammen med en leverandør gradvist arbejde sig hen mod målet.
Det er et tankesæt, der kan ligge langt fra den traditionelle indkøber i en organisation, der fra begyndelsen - ikke mindst af budgetmæssige årsager - har brug for at være i kontrol over det produkt, som han mener, at organisationen har brug for.
Ellers kan man jo ikke styre prisen. Eller tiden. Eller få placeret det endelige ansvar, hvis det hele skulle køre af sporet.
Det kræver detaljer i massevis at få overblik, og overblik er nødvendigt, hvis man skal føle, at man har indtænkt alle de mulige faldgruber, problemer, potentielle blindgyder og andre ubehageligheder, som et projekt kan løbe ind i.
Historien viser imidlertid, at det er meget svært at tage højde for alting, når det gælder indkøb og implementering af store it-systemer.
Måske er det ret beset faktisk svært at tage højde for noget som helst andet end det mest forudsigelige.
Agile metoder vs. Vandfaldsmetode
Agile metoder Agile softwaremetoder henviser til en række forskellige metoder, der er baseret på iterative processer i projekt det vil sige en gentagelse af de klassiske udviklingsgrundsten: Analyse, design, implementering og test, og gentagende gange forbedre hver fase gennem hele projektet.
Nogle af de vigtigste årsager til brug af agile udviklingsmetoder er:
- Hurtig og konstant levering af mindre dele af opgaven til kunden - Softwaren bliver afleveret med mellemrum på uger frem for måneder - Man betaler ved levering og kan relativt nemt skifte leverandør undervejs i projektet - Fleksibel over for nye ønsker om funktioner selv på et sent tidspunkt i projektet - Tæt samarbejde mellem kunde og udviklere - Software kan afprøves med det samme
De agile udviklingsmetoder har vundet stort indpas i de seneste 10 år, men metoderne bliver også kritiseret for, at de kræver en meget rutineret projektledelse, der kan håndtere de konstant flydende processer.
Konkrete agile metoder:
- Scrum - eXtreme Programming (XP) - Lean Software Development - Feature Driven Development - Getting Real
Vandfaldsmetoden Vandfaldsmetoden blev for første gang introduceret i 1970 af den amerikanske it-mand Winston W. Royce, der ironisk nok selv var en fortaler for agile metoder. Uden at kalde den stramt faseinddelte styring af et projekt for vandfaldsmodel, forklarede Winston W. Royce, at metoden inviterede til fiasko, fordi kundens krav konstant ændrer sig undervejs i et projekt.
Den oprindelige vandfaldsmodel bygger på syv grundsten: Kravspecifikation, design, implementering, integration, test, installation og vedligeholdelse, der ligger i syv fastlåste udviklingstrin. Når eksempelvis kravspecifikationen er skrevet, vil man gå videre til designfasen. Når designet er overstået vil man derefter gå videre til implementering uden at se sig tilbage eller ændre på de foregående, overståede trin.
Der er ingen overlap eller læring fra ét trin til det næste, men derimod er metoden en slavisk udførelse af kravspecifikationen. Metoden kræver derfor en stor, ekstrem præcis kravspecifikationer.
Af samme grund er metoden stærkt kritiseret for, at den er alt for rigid til at få indført nye ønsker undervejs i projektet og lære af fejl undervejs. .
Retfærdigvis skal det siges, at Winston W. Royce netop påpegede de fastlåste farer i en senere model, hvor han gjorde rede for, at det skulle være muligt at gå tilbage til et tidligere trin og på den måde udnytte den stærkt faseopdelte model iterativt.
Den store bundvending af hele it-organisationen
Der følger forandringer med
Bedre bliver det ikke, hvis det indkøbte it-system er så stort (og smart), at der følger en bundvending af forandringer i organisationen med, fordi teknologien hele tiden skubber grænserne for det mulige og for effektiviserings-graden.
Problemet har ellers været kendt længe.
Helt tilbage i 1968 blev problemerne med de store, færdigsyede it-manuskripter diskuteret på et møde for en række af datidens it-kyndige, som dengang fandt sted i Tyskland.
"Vi har det med at bruge flere år og investere mange penge i at erkende, at et system, som vi ikke forstod til bunds fra begyndelsen, ikke fungerer som forventet," lød det dengang fra it-mødet. Der altså fandt sted i 1968.
"Det mest risikable inden for softwareudvikling er den model, som alle ser ud til at følge, hvor man specificerer præcist, hvad man skal gøre. Og så gør man det. Her opstår de fleste af vores problemer," lød det på mødet.
Wc-papir og it-systemer
Problemet skal muligvis - i hvert fald historisk - findes i organisationernes indkøbs-kompetencer og evner til at udforme en kravspecifikation, der dokumenterer, hvad virksomhederne rent faktisk får for pengene.
Omvendt er det krævende og stiller krav til indkøberen at satse på en agil model, som kræver et yderst tæt parløb med leverandøren.
Der har været en tendens til, at indkøbere og budget-ansvarlige i organisationer har sværget til Big Bang-modellen i mange andre sammenhænge. Sådan historisk set.
Når det gælder indkøb af møbler, biler, køkkenruller eller lignende er det da også nemt at få overblik, og indkøbet af produktet er afsluttet, når varen er leveret, og så kan vi komme videre til næste projekt.
Men sådan fungerer det ikke med it-projekter, der i dag i meget stort omfang ofte kræver vedvarende forandringer af organisationen bag, og derfor er tunge og krævende i både omfang og impact.
Men modsat de 'enkle' og 'overskuelige' krav til indkøbs-organisationen, når det gælder vandfalds-metoden, så kræver den agile tilgang en helt anden langsigtet dedikation og et langsigtet nærvær.
Indkøberen skal løbende være med, sætte sig ind i problemerne, forholde sig løbende til udviklingen, have indsigt nok til at styre projektet i den rigtige retning.
Agile metoder vs. Vandfaldsmetode
Agile metoder Agile softwaremetoder henviser til en række forskellige metoder, der er baseret på iterative processer i projekt det vil sige en gentagelse af de klassiske udviklingsgrundsten: Analyse, design, implementering og test, og gentagende gange forbedre hver fase gennem hele projektet.
Nogle af de vigtigste årsager til brug af agile udviklingsmetoder er:
- Hurtig og konstant levering af mindre dele af opgaven til kunden - Softwaren bliver afleveret med mellemrum på uger frem for måneder - Man betaler ved levering og kan relativt nemt skifte leverandør undervejs i projektet - Fleksibel over for nye ønsker om funktioner selv på et sent tidspunkt i projektet - Tæt samarbejde mellem kunde og udviklere - Software kan afprøves med det samme
De agile udviklingsmetoder har vundet stort indpas i de seneste 10 år, men metoderne bliver også kritiseret for, at de kræver en meget rutineret projektledelse, der kan håndtere de konstant flydende processer.
Konkrete agile metoder:
- Scrum - eXtreme Programming (XP) - Lean Software Development - Feature Driven Development - Getting Real
Vandfaldsmetoden Vandfaldsmetoden blev for første gang introduceret i 1970 af den amerikanske it-mand Winston W. Royce, der ironisk nok selv var en fortaler for agile metoder. Uden at kalde den stramt faseinddelte styring af et projekt for vandfaldsmodel, forklarede Winston W. Royce, at metoden inviterede til fiasko, fordi kundens krav konstant ændrer sig undervejs i et projekt.
Den oprindelige vandfaldsmodel bygger på syv grundsten: Kravspecifikation, design, implementering, integration, test, installation og vedligeholdelse, der ligger i syv fastlåste udviklingstrin. Når eksempelvis kravspecifikationen er skrevet, vil man gå videre til designfasen. Når designet er overstået vil man derefter gå videre til implementering uden at se sig tilbage eller ændre på de foregående, overståede trin.
Der er ingen overlap eller læring fra ét trin til det næste, men derimod er metoden en slavisk udførelse af kravspecifikationen. Metoden kræver derfor en stor, ekstrem præcis kravspecifikationer.
Af samme grund er metoden stærkt kritiseret for, at den er alt for rigid til at få indført nye ønsker undervejs i projektet og lære af fejl undervejs. .
Retfærdigvis skal det siges, at Winston W. Royce netop påpegede de fastlåste farer i en senere model, hvor han gjorde rede for, at det skulle være muligt at gå tilbage til et tidligere trin og på den måde udnytte den stærkt faseopdelte model iterativt.
Det kræver det af it-chefen - og af it-afdelingen
Mod og viden og strategisk tæft
Han/hun skal have mod og viden og strategisk tæft nok til ikke at købe et færdigt produkt - og ikke engang forsøge på det - men til derimod at købe ind på en vision, der gør, at produktet ikke nødvendigvis har en færdig-implementerings-dato overhovedet.
Derimod skal de kunne tilpasses og justeres løbende i takt med, at behovene, organisationen og teknologien udvikler og ændrer sig.
Det er et drømmescenarie for it-producenterne, hvis indkøberne vil gøre det på denne måde.
Dels vil det gøre det indledende arbejde langt nemmere, dels vil det sikre et tæt, nærmest intimt, forhold til kunderne og lægge bunden for langvarige, stabile kundeforhold.
Men det er ikke nødvendigvis et drømmescenarie for kunderne, der ofte arbejder fra projekt til projekt, og som ikke nødvendigvis er interesserede i it-projekter, der kører i årevis.
Imidlertid er det en udvikling, som er begyndt at se spire i de seneste år - ikke mindst fordi it-cheferne, CIO'erne og it-afdelingerne er blevet meget dygtigere til implementering og strategisk it-tænkning.
Og fordi staten for alvor har fået øjnene op for den agile projektmodel.
Stærkt øget modenhed
Vi ser stærkt øget it-modenhed i landets organisationer og virksomheder, der i stigende omfang erkender, at it ikke er et redskab, men et grundlag, for hele forretningen, og derfor opprioriterer arbejdet og viljen til at satse på it.
Det går med andre ord den rigtige vej. Dybest set er det jo et spørgsmål om tillid mellem leverandør og kunde.
Lad mig høre din mening. Hvad taler for og imod agile projekter? Hvad taler for (og imod) vandfaldsmodellen?
Er du klar til en dag, der udfordrer din forståelse af, hvad Identity & Access Management kan gøre for din organisation? En dag fyldt med indsigt, inspiration og løsninger, der sætter kursen for, hvordan vi arbejder med IAM i de kommende år.
Verden er i opbrud. Voldsomme geopolitiske forandringer, fortsat krig i Europa og konstante cyberangreb stiller helt nye krav til danske virksomheder. Trusselsbilledet ændrer sig fra uge til uge - og det kræver både politisk forståelse,...
