olav m.j. christiansen bloghoved olav christiansen

Tragedier i IT - del 1

I forbindelse med et af mine tidligere blogindlæg om Humor i IT var der nogen, der opfordrede mig til at lave et indlæg med tragedier i IT. Det blev langt, så her er del 1, mens del 2 kommer inden for de nærmeste dage.

Hvad forstår vi så ved en tragedie i IT? Det er ikke så ligetil, og minder mig om noget helt andet, så lad mig lige tage en afstikker, inden jeg går videre til hovedemnet.

Kuldsejlet eller havareret

Det har tidligere her på version2 været diskuteret om man burde have en form for havarikommission for IT-projekter, men hvad er egentlig problemet med det? Jo, se for at det skulle kunne lade sig gøre, skal man starte med at definere hvad vi egentlig forstår ved et havari, og det er faktisk ikke så nemt endda.

De andre steder, hvor man typisk anvender en havarikommission, er det meget enkelt at se at vi har et havari. Vi er ikke i tvivl, når f.eks. et fly er styrtet ned, et tog er kørt af sporet, eller et skib er sejlet ind i Storebæltsbroen. I de situationer er der ingen, der vil bestride at vi har et havari. Helt så enkelt er det desværre ikke, når vi taler om IT-projekter. Hvis det var, ville vi nok ikke have så mange forskellige måder at drive et IT-projekt på. Hvis vores branche kunne blive enige om at gøre tingene på én bestemt måde, så ville det måske være nemmere.

I forbindelse med mit indlæg om Bullshit-bingo var der nogen, der foreslog ordet 'proaktivt' som bullshit. Men faktisk kan man undgå mange problemer i projekterne, hvis man arbejder mere proaktivt end reaktivt. Mange agile metoder er desværre meget reaktive af natur, og derfor opdager man dér ofte først problemerne, når de rammer én. Men f.eks. PRINCE2 advokerer stærkt for at man arbejder aktivt med risikostyring. Det har jeg skrevet en smule om i et andet indlæg.

I private virksomheder må man jo helt selv om hvordan man styrer sine projekter, og man kan i princippet lave IT-udvikling helt uden noget formel proces eller metode. Men alle offentlige projekter i Danmark skal anvende PRINCE2 til styring (og MSP hvis det er programmer), så de er faktisk tvunget til bl.a. at anvende risikostyring og andre styringsmekanismer. Staten har endda etableret et IT-råd, som netop hjælper de offentlige myndigheder med at holde projekterne på ret kurs.

Version2 skriver jævnligt om IT-rådet og de offentlige projekter, og man kan se at statslige projekter vurderes med et trafiklys, så de er enten i grøn, gul eller rød.

https://www.version2.dk/artikel/status-statens-store-it-satsninger-roedt...

Illustration: Olav M.J. Christiansen (grafik)

Jeg har arbejdet steder, hvor man bruger en tilsvarende styring, men det er meget forskelligt hvordan man finder ud af om et givet projekt er i grøn, gul eller rød. Ofte er det subjektivt ud fra en fornemmelse, men det kan også f.eks. have med risikostatus at gøre, eller det kan være på grundlag af om man følger en bestemt plan (typisk en tidsplan), eller om man har for mange udeståender eller for mange fejl. Der er desværre ikke nogen universel måde at gøre dette på, som alle IT-projekter anvender uden videre, men det er under alle omstændigheder en god idé at gøre et eller andet, der gør én i stand til at følge den overordnede status på et projekt.

Business Case anvendes ofte i den sammenhæng, men ikke alle projekter har en egentlig formel business case, så man er ofte henvist til andre metoder. Foruden risikostyring kan jeg f.eks. anbefale at forstå og anvende projekttrekanten aktivt. Det vender jeg tilbage til i en senere artikel.

Vi kan altså se at det kan være lidt svært at se hvornår vi har et kuldsejlet eller havareret projekt. Det er ofte en subjektiv opfattelse, og tit havner den slags projekter i pressen (i hvert fald når de er offentlige). Når det først har været i pressen, er der nok mange der mener at vide at vi nu har et kuldsejlet projekt eller et havari. Men man bør have nogle objektive målemetoder for at lave en egentlig definition af et havareret projekt. Det interessante er at hvis man rent faktisk etablerer nogle formelle måder at måle et projekt på, kan man undgå at hele projektet havarerer, idet man jo løbende kan holde øje med de ting. Det kræver altså en meget aktiv og bevidst projektledelse og kan godt være en udfordring, hvis man tror at agile metoder kan stå alene.

Et systemhavari er noget helt andet, men kan ikke sammenlignes med et projekthavari.

Tragedie

Hvornår er noget så en tragedie? Vi kan prøve at starte med Den Store Danske, som indleder sin artikel om emnet med denne passus: "tragedie, europæisk dramaform, grundlagt af de tre store græske forfattere Aischylos, Sofokles og Euripides i 400-tallet f.Kr., med efterfølgende betragtning i Aristoteles' Poetik (300-t. f.Kr.). Det drejer sig her om skuespil i høj stil, på vers, oftest med en katastrofal eller ulykkelig slutning."

I moderne sammenhæng bruger man dog også ordet om en serie af begivenheder, og der kan man så kigge på wikipedia for denne definition:
"A tragedy is an event of great loss, usually of human life. Such an event is said to be tragic. Traditionally the event would require "some element of moral failure, some flaw in character, or some extraordinary combination of elements" to be tragic. "

Ok. Der skal altså være tale om at der sker noget ekstraordinært negativt, typisk associeret med dårlig moral eller lignende, som afstedkommer en eller anden form for katastrofe, ofte med tab af liv til følge.

Jeg har dog på fornemmelsen at udtrykket - lige som så mange andre - bliver udvandet, sådan at man ikke behøver tab af menneskeliv for at kalde det en tragedie. Vi kan sagtens på et personligt plan sænke tærsklen for hvad vi selv opfatter som en tragedie. På den måde kan det være meget subjektivt, hvad den enkelte opfatter som en tragedie.

De historier, jeg har udvalgt til denne artikel, er altså ikke nødvendigvis af den meget grimme slags tragedier, men er mere udtryk for noget, der er foregået, som principielt kunne udvikle sig til en 'rigtig' tragedie.

Ikke mere udenomssnak. Lad os få svesken på disken og kigge på nogle eksempler.

Eksempel nr. 1

Det første eksempel er den artikel, som egentlig er grunden til dette blogindlæg. Den blev bragt på version2 for ikke så længe siden, og fortalte om at Japans nyudnævnte minister for cybersikkerhed indrømmer at han aldrig nogensinde har brugt en computer.
https://www.version2.dk/artikel/japans-minister-cybersikkerhed-jeg-har-a...

Er det så reelt en tragedie? Måske - det kommer an på ...

Men kan det udvikle sig til en rigtig tragedie, dvs. hvor der sker noget katastrofalt? Der må vi sige ja. Hvis man gerne vil have bedre cybersikkerhed i Japan kan det være en rigtig dårlig idé at den øverste ansvarlige beslutningstager ikke ved noget som helst om emnet. Han bliver jo nu nødt til enten at sætte sig ind i en masse ting eller stole ret meget på sine rådgivere. Og hvordan ved han om de rådgivere egentlig er gode nok, hvis han ikke selv har en snus forstand på emnet. Svaret blæser i vinden ...

Det pudsige er at man ofte i store projekter af den slags, der kuldsejler (se indledningen af denne artikel) tit ser noget lignende. De øverste ansvarlige i et projekt mangler ofte basale kompetencer og risikerer derfor at tage uheldige beslutninger. Og hvis man så heller ikke læner sig op af kompetente rådgivere eller støttefunktioner, ender det desværre ofte galt. En gang imellem går der ganske enkelt politik i tingene, så "mig-alene-vide" eller "ikke-opfundet-her" konceptet gør at der bliver truffet usaglige og ufaglige beslutninger.

Det skyldes ikke altid uvilje. Der kan være mange årsager. Jeg ser f.eks. ofte at folk helt misforstår de forskellige projekt- og udviklingsmodeller, der findes. Jeg hører skrøner om at man altid kan køre agile projekter helt uden projektledelse, eller at PRINCE2 er det samme som vandfald. Begge dele må siges at være lidt af en misforståelse. Jeg har også hørt højtuddannede mennesker postulere at det ville være forkert at anvende en projekt- eller udviklingsmodel med lokale tilpasninger (folk taler f.eks. om "PRINCE light" eller at det skulle være et problem at man ikke gennemfører hele SAFe-modellen). Ude i virkelighedens verden møder jeg jævnligt nyuddannede IT-folk, der kommer næsten lige fra universiteterne. Dér er man åbenbart også begyndt at uddanne folk indenfor det agile, men vist desværre uden helt at forstå hvad det går ud på. Jeg kan henvise interesserede til et tidligere blogindlæg, jeg skrev, hvor jeg netop forsøgte at beskrive forskellen på top- og bundstyrede projekter. Det er et emne, jeg interesserer mig meget for, så jeg vil garantere at jeg vender tilbage om det i nogle senere indlæg. Stay tuned :-)

Så vi kan vist konkludere at denne ministerudnævnelse godt kunne gå hen og blive til en tragedie - også selv om den måske ikke helt er det endnu ifølge ordbogens definition.

Tak for i år

Det blev et lidt langt indlæg, og bl.a. derfor har det også været lidt længere tid undervejs. Til gengæld bliver det det sidste for i år.

Godt nytår til jer alle.

Læs med i i det nye år, hvor jeg bringer flere eksempler på tragedier i IT.

PS: Husk at fortælle os hvad du mener er en tragedie i IT.

Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Yoel Caspersen Blogger

I går aftes skulle jeg forklare min 5-årige søn, hvordan et klassisk orkester fungerer - og vi tog udgangspunkt i en glimrende udgave af Jacques Offenbachs Orfeus i Underverdenen.

I et klassisk orkester har alle deltagerne en vital funktion - dirigenten leder forestillingen og koordinerer de forskellige grupper, herunder strygere og blæsere, og typisk agerer 1. violinen en slags næstkommanderende.

Ingen kan undværes - selv ham, der slår på trianglen, tilføjer stykket magi. Og samtlige deltagere i orkestret er suveræne musikere med adskillige års opsparet øvelse på kontoen - der er ikke plads til middelmådige, umotiverede 8-16-medarbejdere her.

En sådan samling talenter kan kun ledes af en, der selv ved, hvad det handler om. Dirigenten har som regel selv en baggrund som musiker, og der er endda eksempler på dirigenter, der gerne selv spiller aktivt i orkestret. Mange musikere spiller i øvrigt flere instrumenter.

Kammermusik spilles af en lille gruppe af musikere, typisk piano, cello og violin, og her er der ikke behov for en dirigent - gruppen arbejder tæt sammen og behøver pga. størrelsen ikke en egentlig leder.

Parallellen til software-udvikling burde være åbenlys - små projekter skal løses af små selvstyrende grupper, og store projekter kræver talentfulde deltagere, en projektleder, der ved, hvad det handler om, og frem for alt, en hård og nådesløs tilskæring, hvor overflødige deltagere og features skæres væk, så man står tilbage med det rene, ufortyndede produkt.

Nu efterspørger du en tragedie at slutte året af på.

Da tragedier ofte opstår på baggrund af flere uafhængige faktorer, er antallet af tragedier, hvor man uden at ryste på hånden kan udnævne dårlig software som en root cause, ganske givet ikke så stort.

Men en klassiker er Therac-25, som var en stråleterapi-maskine, der grillede et antal patienter med alt for høje doser pga. programmeringsfejl.

Hvis man udvider definitionen til at omfatte cases, hvor god software kunne have reddet en kritisk situation, men ikke gjorde det, fordi softwaren ikke var god nok, stiger antallet af tragedier væsentligt - det gælder fx de fleste nyere flystyrt, der skyldes menneskelige fejl, herunder Air France Flight 447, hvor en række pilotfejl kombineret med misvisende hastighedsmålere medførte et stall over midten af Atlanterhavet.

Man kan også argumentere for, at samtlige offentlige IT-skandaler er tragedier, idet de spildte penge kunne have reddet liv andre steder - men det er nok at strække definitionen for vidt.

Du ønskes et godt og tragedie-frit nytår :)

  • 12
  • 0
Ivo Santos

Om det er en tragedie at den japanske minister ikke ved noget om computer kan vel også vendes til han faktisk er klogere end de fleste.

Cybersikkerhed kan vel også handle om at den bedste måde at sikre sig mod cyberangreb er at man som minimum dropper internettet, og når man ligeledes også tænker på dele at den amerikanske militær stadig bruger floppy diske og gamle computer så er der vist ikke tvivl om at spørgmålet om cybersikkerhed og at en minister ikke ved noget om it kan vendes til noget positivt, hvis man benytter den rigtige vinkling.

  • 0
  • 0
Magnus Jørgensen

Tragedie er måske ikke det rette ord at bruge til beskrivelse af fænomenet. Lad os bare kalde det et havari.

Definitionen kan være:
* Projektet er skrottet før eller kort efter at det er sat i produktion (lang tid før den planlagte livstid).
* Der er brugt mere en 100 mio. kr på projektet
* Projektet har ikke kunne løse de problem stillinger det er sat i verden for at løse, eller har løst problem stillingerne så ringe, at omkostningerne ved brugen af løsningen, har pålagt driften af [Tjeneste] et så stor en ekstra udgift at den forrige løsning var bedre.

Når disse betingelser er opnået bør der laves en analyse af projektet. Når man har fundet årsagen til IT-havariet skal der udarbejdes en rapport som publiceres offentligt.
Derefter kan der laves en analyse, hvis formål er at tilføje generiske råd(ingen navne på personer, firmaer eller produkter nævnt) til et kompendie som også publiceres offentligt.

  • 0
  • 0
Magnus Jørgensen

Den bedste måde vi kan undgå disse problemer i fremtiden, er ved at lære af vores fejl. Hvis disse ting ikke bliver dokumenteret, har vi ikke muligheden for at lære af dem. Navnet er ikke så vigtigt. Hvis du ikke kan lide navnet "IT havari kommission", så kald det noget andet, fordi ideen er god nok. Den er blevet brugt til at lave omfattende litteratur til alle de andre Ingeniørfag, være det sig litteratur til undervisning på universiteter eller litteratur til opslag for professionelle i den givne branche.

IT branchen har generelt et problem med dokumentation efter min mening. Alt for ofte ser man projekter der kører helt uden basal dokumentation af deres løsninger. Både konceptuel dokumentation for projektet før det går i gang og også "As built" dokumentation efter at projektet er afsluttet, lader ofte til at være manglende eller totalt fraværende.
Kvalitets kontrollen er ofte efterladt til slutbrugeren og hvis der er kvalitets kontrol er den oftest ikke dokumenteret. Der findes et hav af "project manager" værktøjer, som oftest er rigtigt gode til at registrere og følge fejl der er opdaget, men som ofte ikke har værktøjerne eller standarder for at de enkelte ændringer bliver testet, tjecket og godkendt.

Her er et eksempel på et side hovede til en mekanisk ingeniør tegning:

Tegnings hovede til mekanisk ingeniør tegning

På dette eksempel kan man se en masse nyttig information om den givne tegning. Det vigtige er at kvalitets kontrol felterne. Det er dokumenteret hvem der har lavet ændringer, hvem der har tjecket ændringer og til sidst hvem der har godkendt det. De fleste firmaer har strenge regler for at checker, maker og approver ikke er den samme person. Ved større konceptuelle ændringer er der review processer hvor flere teknisk kompetente folk er involveret.

Når der sker en fejl kan man derefter spørge de involverede hvorfor ændringerne var lavet og hvorfor man ikke opdagede fejlen. Det lægger også et pres på de involverede således at de gør deres bedste.

I de software projekter som jeg har arbejdet på har der ofte været brugt JIRA, Trello, TFS eller blot de indbyggede tools i github.
Disse værktøjer er oftest gode til at dokumentere "issues" som ændringer eller bugs. Men er oftest dårlige til at dokumentere kvalitets processen. Jeg mange gange oplevet at en hel bunke issues er trukket fra testing til done efter at en overfladisk test af er udført.
Det er ikke registreret hvem der har testet de enkelte ændringer og hvem der har godkendt at maker og checker har gjort deres arbejde.

Disse ting kan ikke have været udført på Sundhedsplatformen eller POLSAG for den sags skyld.

  • 0
  • 0
Magnus Jørgensen

Når der så er fundet en fejl, så er der næsten aldrig en opfølgning på hvorfor man ikke fandt fejlen, og hvad man gør for at undgå den i fremtiden.

Man registrerer en bug i sit PM tool og hvis man er heldig er det den samme udvikler der retter fejlen som også lavede den.

I analogien med den mekaniske tegning kan det føre til en ændring af hvordan den tekniske dokumentation er udført, således at denne fejl er nemmere at opdage.

I IT verdenen bliver buggen løst og hvis man er heldig er der en tester foruden programmøren der ser at fejlen nu er væk.

Så har jeg glemt at nævne unit testing.
Unit testing kan fange nogle af disse fejl, men i essensen er unit testing problematisk fordi den bliver udført af programmøren selv. Selve ansvaret ved check og godkendelse ligger hos den samme person.
Unit testing virker oftes godt, når en ny udvikler overtager arbejdet.
Hvis Unit testing skal virke godt, bør den være udført af en anden programmør. Desuden skal ændringen og unit testen godkendes af en tredie part.

  • 1
  • 0
Jarnis Bertelsen

IT branchen har generelt et problem med dokumentation efter min mening. Alt for ofte ser man projekter der kører helt uden basal dokumentation af deres løsninger. Både konceptuel dokumentation for projektet før det går i gang og også "As built" dokumentation efter at projektet er afsluttet, lader ofte til at være manglende eller totalt fraværende.


Jeg har det med dokumentation som med kommentarer i kode: Det gælder om at bruge det til det rigtige og i det rigtige omfang.

Ligesom med kodekommentarer skal man vurdere om indsatsen med at skrive dokumentatioinen står mål med gevinsten. Jeg har skrevet adskillige dokumentationsdokumenter med en til-vished-grænsende formodning om at de næppe nogensinde bliver læst.

Samtidig skal man indregne dokumentationen som en del af kodebasen, og rette begge ting sammen. Hvis man glemmer dette ender man med forældet dokumentation der i bedste fald ikke helt virker, og i værste fald er direkte misvisende. Samtidig skal den være nemt tilgængelig på en struktureret og søgbar måde. Hvis du ikke nemt og hurtigt kan finde den relevante information i dokumentationen, bliver den kun brugt i nødstilfælde, og mister dermed sin plads i bevidstheden på både dem, der skal bruge og vedligeholde den.

Jeg tror ikke der findes en perfekt formel for at vurdere, i hvilken grad et IT projekt skal dokumenteres, men man kan komme langt med sund fornuft og ved at stille sig spørgsmålet: Hvem skriver du dokumentationen for og hvad skal de bruge den til.

  • 0
  • 0
Olav M.j. Christiansen Blogger

IT branchen har generelt et problem med dokumentation efter min mening.

Du har nogle gode pointer, og det er helt generelt noget af dette, min blog overordnet handler om.

Problemet med at skabe ordentlig dokumentation, er at det som regel koster penge, og mange organisationer vil ikke betale det, det koster at producere dokumentation (der ofte anses for unødvendigt).

Jeg har både været i projekter, hvor kunden bevidst fravalgte dokumentation for at spare penge og andre projekter, hvor man senere skulle frembringe dokumentation for et kørende system. Man kan jo overveje hvilken dokumentation, der er dyrest at frembringe: Den man laver undervejs eller den man laver med 'reverse engineering' mange år senere.

De mange nye 'agile' tanker gør at også ideen om solid dokumentation ofte må ofres for at kunne levere hurtigere. Projekter, der kører efter en mere vandfaldsagtig tilgang vil ofte have lidt bedre dokumentation, men alting har sin pris.

Jeg vil prøve at samle op om det med dokumenation i nogle senere blogindlæg, for det er ret centralt i diskussionen om hvor agilt et projekt egentlig skal være.

  • 0
  • 0
Magnus Jørgensen

Hej Olav og Jarnis.

Jeg synes at i begge overser pointen.
Jeg nævner dokumentation og bruger tid på at forklare hvordan manglen på kvalitets kontrol er længt være en den generelle dokumentation. Jeg viser endda en teknisk ingeniør tegning, hvor man kan se at det er forskellige individer der laver arbejdet, tjecker arbejdet og godkender arbejdet.

Humlen er at når fejlene dukker op i produktion har man ikke en ærlig chance for at finde ud af hvor man fejlede og hvordan man undgår det i fremtiden.

De fleste projekter skynder sig bare videre fordi man har så fandens travlt.

  • 0
  • 0
Olav M.j. Christiansen Blogger

Jeg synes at i begge overser pointen.
Jeg nævner dokumentation og bruger tid på at forklare hvordan manglen på kvalitets kontrol er længt være en den generelle dokumentation. Jeg viser endda en teknisk ingeniør tegning, hvor man kan se at det er forskellige individer der laver arbejdet, tjecker arbejdet og godkender arbejdet.

Jeg tror ikke jeg har overset noget. Det er skam en god praktis - også i IT-projekter - at det er forskellige personer, der kontrollerer ting undervejs. Jeg er selv bl.a. certificeret indenfor ISTQB, og har arbejdet en del med kvalitetsstyring- og kontrol. De metoder og teknikker, der advokeres i ISTQB, bruges ofte i IT-projekter. Men der er jo ikke noget krav om at man skal gøre det, så forretningen (kunden) kan i en given situation vælge at bruge mindre stringente metoder til kvalitetskontrol. I f.eks. den finansielle sektor, hvor jeg har bevæget mig en del, er der typisk de samme krav til kvalitetsstyring, som du efterlyser.

Men du nævnte dokumentation, og det er i princippet to helt forskellige ting. Man behøver ikke nødvendigvis at anvende principperne fra din tekniske ingeniørtegning for at få et fornuftigt test- og kvalitetsniveau. Det kommer helt an på projektet.

  • 0
  • 0
Magnus Jørgensen

Men du nævnte dokumentation, og det er i princippet to helt forskellige ting.

Du kan sagtens bygge en mekanisk gismo uden dokumentation og på samme måde kan du også teste din gismo uden dokumentation.

Dokumentationen af en gismo kan være en tegning eller en anden form for spec. Dokumentationen af kvalitets kontrollen kan være en tabel som den på tegnings hovedet. Det er to forskellige former for dokumentation. Kvalitets testen og kontrollen er vigtig for at man undgår fejl. Dokumentationen af kvalitets testen er vigtig for at man kan undgå fejlen i fremtiden.

Men jeg kan godt se hvad du mener.
Har du et bud på hvorfor at IT branchen er ramt af dette fænomen?
Er det blot fordi branchen er så ung?

  • 0
  • 0
Olav M.j. Christiansen Blogger

Har du et bud på hvorfor at IT branchen er ramt af dette fænomen?

Tja, det må jeg vel sige at jeg har, da det er en væsentlig del af emnet for min blog :-)

I 'de gode gamle dag' var f.eks. vandfaldsmodellen god latin - senere suppleret med V-modellen, som principielt bare er vandfald suppleret med kvalitetstiltag, sådan at man netop har meget fokus på kvalitet.

Men nogle af problemerne med en ren vandfaldsmodel, er at man bruger ret meget tid på at skrive dokumentationen inden man går i gang med at fremstille systemet. I mellemtiden kan verden have ændret sig ret meget. Endvidere kan man jo godt have lavet forkerte antagelser eller decideret fejl, da man lavede den oprindelige dokumentation, f.eks. kravspecifikationen.

Det betyder lidt kort fortalt at en stringent vandfaldsmodel med meget fokus på dokumentation og kvalitet risikerer at løbe ind i en eller flere af følgende problemer:

  • Kravene er skrevet for dårligt, så de skal genvisiteres
  • Der går for lang tid fra man har udtænkt systemet til det kan tages i brug
  • Det kan vise sig at systemet bliver helt anderledes end man havde regnet med, og slet ikke kommer til at løse det, der egentlig var planen
  • Man bruger for meget fokus på det formelle (dvs. dokumentationskrav og det at følge processerne) og glemmer helt kernen, nemlig at udvikle det som kunden efterspørger og har behov for

Der har igennem historien været masser af forslag til hvordan man kan løse det, og jeg vil herunder linke til nogle af mine egne blogindlæg, hvor jeg for nylig har skrevet lidt om det.

Det, der er mest oppe i tiden lige nu, er de agile metoder, som har til formål at få udviklet løsninger så hurtigt som muligt med mindre fokus på processer og dokumentation.

Så ja: Det er nok fordi IT-brancen er så ung som den er.

Jeg opgiver desværre at linke til mine tidligere blogindlæg om dette, da version2's system ikke altid kan lide links, men du burde kunne finde dem via min profil.

  • 0
  • 0
Olav M.j. Christiansen Blogger

Men Amanda, POLSAG, SP og Skat's EFI system er vel næppe bygget med agile metoder.

Det kan de sagtens være. Man kan godt bruge f.eks. PRINCE2 til den overordnede styring af projekterne, men så arbejde mere agilt i udviklingsdelen. Jeg har tidligere skrevet lidt om forskellen på top- og bundstyring. Du må selv fremsøge indlægget, for version2 lader mig lige for tiden slet ikke linke - ikke engang til egne artikler.

  • 0
  • 0
Magnus Jørgensen

Det kan de sagtens være.

Ok. Men er de så det?
Kan det dokumenteres?
Hvilken indflydelse på projektet har det, i givet fald, haft?
Har du arbejdes på et projekt med en komplet og fastlåst krav specifikation, hvor du har brugt agile metoder i udviklingen?
Hvis så, hvilken gavn har det haft?
Hvis du ville dokumentere det, hvilke data ville du bruge til at bevis føre det?

  • 0
  • 0
Magnus Jørgensen

I bund og grund tror jeg vi er ret enige. IT branchen er fyldt af fikse ideer og buzzwords. Der er ikke ret meget der er baseret på en videnskabelig tilgang. ITIL og Prince2 virker som koncepter der er baseret på fornuft fra erfaring, men hvordan ville man overhovedet dokumentere at de virker?

To udviklings projekter er sjældent ens, så hvordan kan man videnskabeligt vise at det ene udviklings koncept er bedre end det andet?

Jeg har flere gange oplevet at et IT projekt er sat i søen, hvor platformen til projektet er valgt før en eneste projekt leder eller udvikler har haft indflydelse.

Eks.: Her har i et projekt, i skal lave X og det skal leve op til denne krav spec. I skal bruge denne platform. Udviklere og projektledere er allerede bundet på hænder og fødder. Alle de design beslutninger der er værd at nævne er allerede truffet da man valgte, SAP eller EPIC eller Sharepoint eller Lotus Notes eller lignende som platform. Du kan have de bedste udviklere i verden på sådan et projekt, men de kan ikke gøre noget ved at de er låst til et specifikt sæt af værktøjer. Hvis krav spec befaler at man skal levere en ting som X platform er virkeligt dårlig til, så skal de slå knuder på sig selv for at levere en B løsning af rang.

Så er det jo lige gyldigt om man bruger et super hyper elastoplastisk agilt Prince2 koncept i udviklings processen.

  • 1
  • 0
Olav M.j. Christiansen Blogger

Ok. Men er de så det?
Kan det dokumenteres?
Hvilken indflydelse på projektet har det, i givet fald, haft?
Har du arbejdes på et projekt med en komplet og fastlåst krav specifikation, hvor du har brugt agile metoder i udviklingen?
Hvis så, hvilken gavn har det haft?
Hvis du ville dokumentere det, hvilke data ville du bruge til at bevis føre det?

Du har mange spørgsmål :-)

De fleste af dem er desværre lidt for store til at besvare i en kommentar til et blogindlæg, men jeg skal prøve at vende tilbage til noget af det ved en senere lejlighed. Og ellers vil jeg opfordre dig til at læse nogle af mine andre indlæg, hvor jeg rent faktisk kommer ind på noget af dette.

Der er masser af projekter, der arbejder på den måde som du omtaler, altså hvor man bruger PRINCE2 eller lignende til styringen af projektet og derefter udvikler efter mere agile metoder. Men jeg kan se at du misforstår noget, PRINCE2 betyder ikke at man har en fastlåst kravspecifikation. PRINCE2 er ikke det samme som vandfald. Der findes endda en ny variant af PRINCE2, der hedder 'PRINCE2 Agile'.

Jeg har arbejdet som selvstændig konsulent i over 19 år for både store private virksomheder og offentlige myndigheder, så jeg vil vove at påstå at jeg nok har prøvet det hele efterhånden - også at køre udvikling agilt med en ret låst kravspecifikation :-)

  • 0
  • 0
Olav M.j. Christiansen Blogger

I bund og grund tror jeg vi er ret enige. IT branchen er fyldt af fikse ideer og buzzwords. Der er ikke ret meget der er baseret på en videnskabelig tilgang. ITIL og Prince2 virker som koncepter der er baseret på fornuft fra erfaring, men hvordan ville man overhovedet dokumentere at de virker?

To udviklings projekter er sjældent ens, så hvordan kan man videnskabeligt vise at det ene udviklings koncept er bedre end det andet?

Store organisationer har typisk mange forskellige projekter, hvor nogle af dem ligner hinanden - i hvert fald nok til at man kan sammenligne dem.

Der findes mange gode måder at evaluere projekter på, men jeg er ikke sikker på at man ligefrem kan bevise det videnskabeligt. Hvis man kunne det, sad vi nok ikke i den suppedas vi gør nu.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize