mboost-dp1
KMD
Damn... De testede 300 krav, og 100 af dem fejlede. En fejl procent på 33.3%.
Jeg ved ikke engang hvad jeg skal sige... Det er helt utroligt.
Kun godt det blev lukket ned med det samme.
Håber for KMD, at der er sket seriøse ændringer i kravspecifikation, som kan forklare den store fejlprocent. Eller at kravspecifikation har været utrolig dårlig.
Jeg ved ikke engang hvad jeg skal sige... Det er helt utroligt.
Kun godt det blev lukket ned med det samme.
Håber for KMD, at der er sket seriøse ændringer i kravspecifikation, som kan forklare den store fejlprocent. Eller at kravspecifikation har været utrolig dårlig.
utroligt! et eksempel på at firmaer som KMD, CSC o.l.
IKKE slipper afsted med hvad som helst for en gangs skyld...
så en fejl procent på 33% ift kravs spec KAN udløse en reaktion!
Derimod er gentagne forsinkelser og 10 dobling af den oprindelige pris IKKE noget der reageres på!
IKKE slipper afsted med hvad som helst for en gangs skyld...
så en fejl procent på 33% ift kravs spec KAN udløse en reaktion!
Derimod er gentagne forsinkelser og 10 dobling af den oprindelige pris IKKE noget der reageres på!
#3
Nej, et eksempel på at KMD ikke kan finde ud af noget.
Ifølge afdelingschef for overenskomst og løn i Region Syddanmark Simon L. Kristensen har regionen testet cirka 300 ud af de 600 krav og fandt altså fejl og mangler ved omkring en tredjedel af de testede krav på tværs af systemet.
Det er krav, som KMD i forbindelse med udbuddet lovede at leve op til.
- De har skrevet ved mange af kravene, at de levede op til dem allerede på tilbudsgivningstidspunktet, men nu her et år efter har det vist sig, at systemet ikke lever op til det, de har budt ind med. Så man kan godt síge, at de har lovet noget, de ikke kunne holde, siger Simon L. Kristensen.
Via http://www.fyens.dk/indland/Ny-mulig-udbudsfadaese...
Nej, et eksempel på at KMD ikke kan finde ud af noget.
Ifølge afdelingschef for overenskomst og løn i Region Syddanmark Simon L. Kristensen har regionen testet cirka 300 ud af de 600 krav og fandt altså fejl og mangler ved omkring en tredjedel af de testede krav på tværs af systemet.
Det er krav, som KMD i forbindelse med udbuddet lovede at leve op til.
- De har skrevet ved mange af kravene, at de levede op til dem allerede på tilbudsgivningstidspunktet, men nu her et år efter har det vist sig, at systemet ikke lever op til det, de har budt ind med. Så man kan godt síge, at de har lovet noget, de ikke kunne holde, siger Simon L. Kristensen.
Via http://www.fyens.dk/indland/Ny-mulig-udbudsfadaese...
Jeg synes, den første udfordring er, at bruger ikke forstår, at man ikke kan får et 'one system to rule them all'
Virksomhederne bliver nødt til at italesætte, at mange opgaver, specielt hvis der også er en fagspredning, kræver flere applikationer.
Excel kan ikke alt, et bi system kan ikke alt, et økonomisystem kan ikke alt, word kan ikke alt osv, men jeg skal bruge alle samme for at få et færdigt stykke arbejde.
En cykel kan heller ikke samles med samme skruetype hele vejen igennem, og der giver det god mening for alle, at der skal en værktøjskasse til, men på software fronten er det en forbudt tanke.
Jeg sidder næsten og skammer mig, når jeg siger, at det vil jeg ikke bruge vores bi system til, fordi det er næsten en religion for sælgerne og udviklerne og det er netop dem som har til opgave at fortælle, at de aldrig slipper af med excel.
Virksomhederne bliver nødt til at italesætte, at mange opgaver, specielt hvis der også er en fagspredning, kræver flere applikationer.
Excel kan ikke alt, et bi system kan ikke alt, et økonomisystem kan ikke alt, word kan ikke alt osv, men jeg skal bruge alle samme for at få et færdigt stykke arbejde.
En cykel kan heller ikke samles med samme skruetype hele vejen igennem, og der giver det god mening for alle, at der skal en værktøjskasse til, men på software fronten er det en forbudt tanke.
Jeg sidder næsten og skammer mig, når jeg siger, at det vil jeg ikke bruge vores bi system til, fordi det er næsten en religion for sælgerne og udviklerne og det er netop dem som har til opgave at fortælle, at de aldrig slipper af med excel.
Jeg har ikke mere end ganske overfladisk erfaring med lønsystemer, men 600 individuelle krav til udviklingen af et lønsystem?
Det lyder .. voldsomt.
Det lyder faktisk som om de allerede har udviklet systemet og bare skal have det programmeret (i den tro, at det er da bare lige noget man gør; alt kan lade sig gøre indenfor de rammer, som bliver sat).
Det lyder .. voldsomt.
Det lyder faktisk som om de allerede har udviklet systemet og bare skal have det programmeret (i den tro, at det er da bare lige noget man gør; alt kan lade sig gøre indenfor de rammer, som bliver sat).
graynote (6) skrev:Jeg har ikke mere end ganske overfladisk erfaring med lønsystemer, men 600 individuelle krav til udviklingen af et lønsystem?
Det lyder .. voldsomt.
Det lyder mystisk lavt. Jeg vil have gættet på adskillige tusinder.
Hvor mange forskellige overenskomster og individuelle ansættelseskontrakter er de ansatte i en region under. Hvor mange regler om anciennitets bestemt lænstigning, overtids betaling, individuelle tillæg, rådighedstillæg, pensionsordninger, orlov, bonus ordninger (for top ledelsen), kantineordninger etc. er der for hver? Og så er der det lovgivningsmæssige omkring bl.a. ferier (timelønneded, funktionær lønnede, ny ansatte, fratrådte).
Ni (5) skrev:Virksomhederne bliver nødt til at italesætte, at mange opgaver, specielt hvis der også er en fagspredning, kræver flere applikationer.
Nu er et dedikeret lønsystem ikke ligefrem et altomfattende.
Jeg har svært ved at tro på at tre lønsystemer ville være billigere end et lønsystem.
Chucara (3) skrev:Nærmere et eksempel på at hele den måde at lave IT projekter på er tåbelig. Der er ingen, der kan prioritere 600 krav 5 år før produktet skal leveres. Meget kan ændre sig undervejs
Nu fremgår det jo at der kun er gået 1 år fra tildeling af kontrakt til systemet fejlede acceptance test.
Så ...
Det er ikke så svært at sætte 600 krav inden når de krav sikkert mest af alt dækker at det nye system skal kunne det samme som det gamle, måske være bagud kompatibelt med nogen ting og der er måske nogle nye features som man vil have med.
Men det er et generelt problem i det offentlige at man har det med at bruge det som man kalder vandfalds modellen, hvilket betyder at man laver disse specifikationer i starten af et forløb og at de så IKKE må ændres, uden at hele aftalen skal omskrives og projektet dermed stort set skal startes forfra, for det vil betyde alle de første faser af projektet skal gøres om igen. Derfor sker det stort set ikke, medmindre det hele bliver skrottet.
Når det gælder IT så er det ikke specielt smart, for det betyder jo at der kan komme uforudsete ændringer i IT verdenen. Ofte er det nu ændringer der ville kunne tilbyde nye, smartere og måske billigere måder at gøre noget på, eller måske bare gøre det mere fremtids sikret, men det betyder jo at systemet sådan set er forældet inden det er færdigudviklet, og det må man leve med når man får udviklet sine programmer på denne måde.
Det bliver ofte også dyrt, fordi det er ikke til at rette fejl hvis nu der er krav som skulle have været med, men ikke kom med.
Men det er et generelt problem i det offentlige at man har det med at bruge det som man kalder vandfalds modellen, hvilket betyder at man laver disse specifikationer i starten af et forløb og at de så IKKE må ændres, uden at hele aftalen skal omskrives og projektet dermed stort set skal startes forfra, for det vil betyde alle de første faser af projektet skal gøres om igen. Derfor sker det stort set ikke, medmindre det hele bliver skrottet.
Når det gælder IT så er det ikke specielt smart, for det betyder jo at der kan komme uforudsete ændringer i IT verdenen. Ofte er det nu ændringer der ville kunne tilbyde nye, smartere og måske billigere måder at gøre noget på, eller måske bare gøre det mere fremtids sikret, men det betyder jo at systemet sådan set er forældet inden det er færdigudviklet, og det må man leve med når man får udviklet sine programmer på denne måde.
Det bliver ofte også dyrt, fordi det er ikke til at rette fejl hvis nu der er krav som skulle have været med, men ikke kom med.
arne_v (7) skrev:graynote (6) skrev:Jeg har ikke mere end ganske overfladisk erfaring med lønsystemer, men 600 individuelle krav til udviklingen af et lønsystem?
Det lyder .. voldsomt.
Det lyder mystisk lavt. Jeg vil have gættet på adskillige tusinder.
Hvor mange forskellige overenskomster og individuelle ansættelseskontrakter er de ansatte i en region under. Hvor mange regler om anciennitets bestemt lænstigning, overtids betaling, individuelle tillæg, rådighedstillæg, pensionsordninger, orlov, bonus ordninger (for top ledelsen), kantineordninger etc. er der for hver? Og så er der det lovgivningsmæssige omkring bl.a. ferier (timelønneded, funktionær lønnede, ny ansatte, fratrådte).
Ah, så du tænker at vi er ude i sådan noget, som at de forskellige satser udgør hvert deres krav? Ja, ok, så kan jeg godt se, at det kan løbe op.
Jeg så "det skal kunne håndtere de forskellige satser" som ét krav og "det skal kunne spille sammen med vores vagt/planlægningssystem" som et andet.
Det er stadigvæk langt tidarne_v (9) skrev:Chucara (3) skrev:Nærmere et eksempel på at hele den måde at lave IT projekter på er tåbelig. Der er ingen, der kan prioritere 600 krav 5 år før produktet skal leveres. Meget kan ændre sig undervejs
Nu fremgår det jo at der kun er gået 1 år fra tildeling af kontrakt til systemet fejlede acceptance test.
Så ...
Jeg har leveret langt større systemer på 1 år med flere krav der ændrede sig mere eller mindre hver uge. (Og det har du vel også).
Med at fejle 1/3 af alle de specificerede krav ved første test. Det er næsten uforståeligt. Altså umiddelbart lyder det som en omgang konsulenter der kun laver hvad de blev bedt om, og nogle PMs der kun kiggede på den orginale kravspecifikation.
Software Udvikling fungere virkeligt virkeligt ikke ordenligt når folk arbejder på den måde. Jeg forstår virkelig ikke de udviklere som går på arbejde bare for at udvikle *præcist* hvad der er blevet skrevet ned, og ikke bekymre sig om slutproduktet.
Altså, hvis det var i Indien gav det måske lidt mening. Men danskere? Jeg ville forvente mere.
100 mio. kr over 6 år virker også som en dråbe i havet. Det er 16 mio kr. om året, eller $2.2 mio USD om året.
Best case scenario dækker det over et hold på 20 personer (chefter, PMs, designere, udviklere, og testere), hvilket er tæt på absolut minimum for at udviklet noget (enterprisy) som helst nu om dage.
Altså vi brugte mindst 20 millioner DKK om året på at udvikle den seneste udgave af Skype for Business til Mac. I lønomkostninger....
(~750k i gennemsnitsløn per person, you do the math)
... og jeg tvivler på at konsulenterne hos KMD er billigere!
Best case scenario dækker det over et hold på 20 personer (chefter, PMs, designere, udviklere, og testere), hvilket er tæt på absolut minimum for at udviklet noget (enterprisy) som helst nu om dage.
Altså vi brugte mindst 20 millioner DKK om året på at udvikle den seneste udgave af Skype for Business til Mac. I lønomkostninger....
(~750k i gennemsnitsløn per person, you do the math)
... og jeg tvivler på at konsulenterne hos KMD er billigere!
600 overordnede krav efter 12 måneder lyder vel rimeligt, når man tænker over detarne_v (7) skrev:Det lyder mystisk lavt. Jeg vil have gættet på adskillige tusinder.
Det er ~3600 krav over hele projektet, dvs. nok nærmere 5-6000 med ændringer (hvilket lyder mere naturligt).
Nu skal jeg ikke gøre mig klog på hvad de 100 fejl og mangler dækker over og hvor lang en stabiliseringsfase de allerede har været igennem, men hvis der er tale om en første gennemgang af det udviklede system så vil jeg sige 66% krav implementeret så de fuldt lever op til specifikationerne bestemt ikke er dårligt.
Jeg tror problemet her i højere grad ligger hos kunden, som har meget lidt forståelse for den her process. Samtidig med at det jo er en naturlig konsekvens af de her kæmpe vandfaldsprojekter at den udviklede løsning er nød til at gå igennem en meget lang stabiliseringsfase til sidst før man har et fungerende system der lever op til alle krav.
Og så er der jo nok gået politik i den på et eller andet tidspunkt som er årsagen til man har valgt at skiltes fremfor at få løsningen færdiggjort. Den slags sker konstant i store organisationer.
Det helt grundlæggende problem her er at det offentlige stadig tror på store kontrakter indeholdende samtlige krav og hellere vil lege ping-pong med advokater, fremfor at indgå i en agil udviklingsprocess.
Jeg tror problemet her i højere grad ligger hos kunden, som har meget lidt forståelse for den her process. Samtidig med at det jo er en naturlig konsekvens af de her kæmpe vandfaldsprojekter at den udviklede løsning er nød til at gå igennem en meget lang stabiliseringsfase til sidst før man har et fungerende system der lever op til alle krav.
Og så er der jo nok gået politik i den på et eller andet tidspunkt som er årsagen til man har valgt at skiltes fremfor at få løsningen færdiggjort. Den slags sker konstant i store organisationer.
Det helt grundlæggende problem her er at det offentlige stadig tror på store kontrakter indeholdende samtlige krav og hellere vil lege ping-pong med advokater, fremfor at indgå i en agil udviklingsprocess.
graynote (11) skrev:Ah, så du tænker at vi er ude i sådan noget, som at de forskellige satser udgør hvert deres krav? Ja, ok, så kan jeg godt se, at det kan løbe op.
Satserne bliver forhåbentligt konfigurerbare.
Men hver konfigurerbar ting er et krav.
graynote (11) skrev:Jeg så "det skal kunne håndtere de forskellige satser" som ét krav og "det skal kunne spille sammen med vores vagt/planlægningssystem" som et andet.
Den slags krav er ubrugelige. De ses desværre ofte, men er aldeles ubrugelige.
Krav skal være veldefinerede og testbare.
#18
Lad mig give et eksempel på hvor detaljeret krav skal være.
Vi antager at man har en overenskomst som for N niveuaer giver Xi i løn og at der på tidspunkt T skal gives Y% i lønforhøjelse.
Er det nok?
Nej. Man er nødt til at have et krav som angiver afrunding.
Nærmeste hele øre, ned til hele øre, nærmeste 25 øre, ned til 25 øre, nærmeste hele krone, ned til hele krone.
Hvis det ikke er specificeret så kan man ikke teste om systemets udregning er korrekt.
Når alt skal angives på dette niveau så bliver der hurtigt rigtigt mange krav.
Lad mig give et eksempel på hvor detaljeret krav skal være.
Vi antager at man har en overenskomst som for N niveuaer giver Xi i løn og at der på tidspunkt T skal gives Y% i lønforhøjelse.
Er det nok?
Nej. Man er nødt til at have et krav som angiver afrunding.
Nærmeste hele øre, ned til hele øre, nærmeste 25 øre, ned til 25 øre, nærmeste hele krone, ned til hele krone.
Hvis det ikke er specificeret så kan man ikke teste om systemets udregning er korrekt.
Når alt skal angives på dette niveau så bliver der hurtigt rigtigt mange krav.
kblood (10) skrev:Men det er et generelt problem i det offentlige at man har det med at bruge det som man kalder vandfalds modellen, hvilket betyder at man laver disse specifikationer i starten af et forløb og at de så IKKE må ændres, uden at hele aftalen skal omskrives og projektet dermed stort set skal startes forfra, for det vil betyde alle de første faser af projektet skal gøres om igen. Derfor sker det stort set ikke, medmindre det hele bliver skrottet.
Det lyder jo meget slemt.
Men den form for vandfaldsmodel findes vist kun i bøger om agile - ikke ude i den virkelige verden.
I den virkelige verden bliver der lavet en CR, den bliver estimeret og det kommer enten med eller ikke med.
Claus Jørgensen (12) skrev:Altså umiddelbart lyder det som en omgang konsulenter der kun laver hvad de blev bedt om, og nogle PMs der kun kiggede på den orginale kravspecifikation.
Software Udvikling fungere virkeligt virkeligt ikke ordenligt når folk arbejder på den måde. Jeg forstår virkelig ikke de udviklere som går på arbejde bare for at udvikle *præcist* hvad der er blevet skrevet ned, og ikke bekymre sig om slutproduktet.
Det du taler for der kan være en meget farlig glidebane.
Der er nogen områder hvor mange udviklere har en rimelig domæne ekspertise, men der er også type hvor det ikke er tilfældet. Det er meget risikabelt hvis nogle gode udviklere som er amatører indenfor området laver ændringer i forhold til de angivne krav.
Generelt ved store systemer hvor der er nogen som har overblikket og andre der fokuserer på specifikke områder kan det være risikabelt hvis nogen af de sidste ændrer på noget som kræver det store overblik.
Claus Jørgensen (13) skrev:100 mio. kr over 6 år virker også som en dråbe i havet. Det er 16 mio kr. om året,
Claus Jørgensen (14) skrev:600 overordnede krav efter 12 måneder lyder vel rimeligt, når man tænker over det
Det er ~3600 krav over hele projektet,
Jeg tror at vi har læst:
Værdien af kontrakten skulle være lidt over 100 millioner kroner over en seksårig periode
lidt forskelligt.
Du har læst det som 6 års udvikling nogenlunde jævnt fordelt.
Jeg har læst det som 1 års udvikling og 5 års drift og vedligehold.
arne_v (20) skrev:kblood (10) skrev:Men det er et generelt problem i det offentlige at man har det med at bruge det som man kalder vandfalds modellen, hvilket betyder at man laver disse specifikationer i starten af et forløb og at de så IKKE må ændres, uden at hele aftalen skal omskrives og projektet dermed stort set skal startes forfra, for det vil betyde alle de første faser af projektet skal gøres om igen. Derfor sker det stort set ikke, medmindre det hele bliver skrottet.
Det lyder jo meget slemt.
Men den form for vandfaldsmodel findes vist kun i bøger om agile - ikke ude i den virkelige verden.
I den virkelige verden bliver der lavet en CR, den bliver estimeret og det kommer enten med eller ikke med.
Desværre så ser kommuner og regeringen det som den eneste måde man rigtigt kan fastlægge et budget. Selvom det sjældent holder:
https://da.wikipedia.org/wiki/Vandfaldsmodellen
Den er ikke kun teori, mange har brugt den og den var endda stort set standard i noget tid.
https://www.version2.dk/artikel/arkitekt-paa-skats...
Hvorfor kan de finde på at bruge så forældet en model? Fordi det er et lovkrav der gør det svært ikke at bruge den:
http://www.digst.dk/Styring/Projektmodel/Lovkrav-t...
Så hvad er det for en model der er krav om at bruge?
https://www.digst.dk/Styring/Projektmodel
Denne, og som man kan se så passer den ret præcist på vandfalds modellen.
arne_v (24) skrev:#23
Jeg ved godt at vandfaldsmodellen bruges.
Men den beskrivelse af vandfaldsmodellen jeg opponerer imod er ikke sådan vandfaldsmodellen ser ud i den virkelige verden.
Så du mener ikke at man fastlægger en bunke krav i starten af projektet og ikke må ændre i dem før projektet er slut?
kblood (25) skrev:Så du mener ikke at man fastlægger en bunke krav i starten af projektet og ikke må ændre i dem før projektet er slut?
Krav kan og bliver ændret undervejs via CR.
Men det var også lidt mere jeg kommenterede på:
kblood (10) skrev:vandfalds modellen, hvilket betyder at man laver disse specifikationer i starten af et forløb og at de så IKKE må ændres, uden at hele aftalen skal omskrives og projektet dermed stort set skal startes forfra, for det vil betyde alle de første faser af projektet skal gøres om igen. Derfor sker det stort set ikke, medmindre det hele bliver skrottet.
Det med fed markerede har intet med virkeligheden at gøre.
arne_v (26) skrev:kblood (25) skrev:Så du mener ikke at man fastlægger en bunke krav i starten af projektet og ikke må ændre i dem før projektet er slut?
Krav kan og bliver ændret undervejs via CR.
Men det var også lidt mere jeg kommenterede på:kblood (10) skrev:vandfalds modellen, hvilket betyder at man laver disse specifikationer i starten af et forløb og at de så IKKE må ændres, uden at hele aftalen skal omskrives og projektet dermed stort set skal startes forfra, for det vil betyde alle de første faser af projektet skal gøres om igen. Derfor sker det stort set ikke, medmindre det hele bliver skrottet.
Det med fed markerede har intet med virkeligheden at gøre.
Har du eksempler på det? At de rent faktisk går tilbage til design fasen og sådan hvis de opdager det er nødvendigt?
#27
Jeg vil anslå at det 99.95% af alle såkaldte vandfalds model projekter som får etr antal CR og et antal som accepteres.
Antallet varierer naturligvis, men en 10-50 CR lyder normalt i mine ører. Hvoraf de fleste accepteres.
Det er jo ret indlysende at man ikke starter helt forfra 10-50 gange i løbet af et projekt.
Kunden kommer med et ændringsønske, leverandøreren estimerer påvirkning på pris færdiggørelsestidspunkt og risiko, kunden beslutter sig for om de vil have det eller ej.
På mange måder er CR processen helt ekvivalent med mange af de mere agile metodikker - der har man også et antal opgaver som estimeres af leverandøren og kunden så bestemmer om det skal med i næste fase eller ej.
Sat helt på spidsen så er forskellen på virkelighedens vandfaldsmodel og en agil model at man med den første diskuterer arbejdet som ændringer til den oprindelige plan mens man med den anden diskueter arbejdet uden nogen basis.
Jeg vil anslå at det 99.95% af alle såkaldte vandfalds model projekter som får etr antal CR og et antal som accepteres.
Antallet varierer naturligvis, men en 10-50 CR lyder normalt i mine ører. Hvoraf de fleste accepteres.
Det er jo ret indlysende at man ikke starter helt forfra 10-50 gange i løbet af et projekt.
Kunden kommer med et ændringsønske, leverandøreren estimerer påvirkning på pris færdiggørelsestidspunkt og risiko, kunden beslutter sig for om de vil have det eller ej.
På mange måder er CR processen helt ekvivalent med mange af de mere agile metodikker - der har man også et antal opgaver som estimeres af leverandøren og kunden så bestemmer om det skal med i næste fase eller ej.
Sat helt på spidsen så er forskellen på virkelighedens vandfaldsmodel og en agil model at man med den første diskuterer arbejdet som ændringer til den oprindelige plan mens man med den anden diskueter arbejdet uden nogen basis.
#27
Jeg vil anslå at 99.95% af alle såkaldte vandfaldsmodel projekter får et antal CR og et antal af disse accepteres.
Antallet varierer naturligvis, men en 10-50 CR lyder normalt i mine ører. Hvoraf de fleste accepteres.
Det er jo ret indlysende at man ikke starter helt forfra 10-50 gange i løbet af et projekt.
Kunden kommer med et ændringsønske, leverandøreren estimerer påvirkning på pris færdiggørelsestidspunkt og risiko, kunden beslutter sig for om de vil have det eller ej, leverandøren laver ændringen.
På mange måder er CR processen helt ekvivalent med mange af de mere agile metodikker - der har man også et antal opgaver som estimeres af leverandøren og kunden så bestemmer om det skal med i næste fase eller ej.
Sat helt på spidsen så er forskellen på virkelighedens vandfaldsmodel og en agil model at man med den første diskuterer arbejdet som ændringer til den oprindelige plan mens man med den anden diskueter arbejdet uden nogen basis.
Jeg vil anslå at 99.95% af alle såkaldte vandfaldsmodel projekter får et antal CR og et antal af disse accepteres.
Antallet varierer naturligvis, men en 10-50 CR lyder normalt i mine ører. Hvoraf de fleste accepteres.
Det er jo ret indlysende at man ikke starter helt forfra 10-50 gange i løbet af et projekt.
Kunden kommer med et ændringsønske, leverandøreren estimerer påvirkning på pris færdiggørelsestidspunkt og risiko, kunden beslutter sig for om de vil have det eller ej, leverandøren laver ændringen.
På mange måder er CR processen helt ekvivalent med mange af de mere agile metodikker - der har man også et antal opgaver som estimeres af leverandøren og kunden så bestemmer om det skal med i næste fase eller ej.
Sat helt på spidsen så er forskellen på virkelighedens vandfaldsmodel og en agil model at man med den første diskuterer arbejdet som ændringer til den oprindelige plan mens man med den anden diskueter arbejdet uden nogen basis.
#31
Den slags bliver jo sjældent offentliggjordt.
Det sker mest hvis projektet er endt katastrofalt.
Men indenfor den kategori er der vel POLSAG som fik 2 store bundter af change requests kaldet "udviklingspakke 1" og "udviklingspakke 2" til henholdsvis 34 og 29 mio. kroner.
Den slags bliver jo sjældent offentliggjordt.
Det sker mest hvis projektet er endt katastrofalt.
Men indenfor den kategori er der vel POLSAG som fik 2 store bundter af change requests kaldet "udviklingspakke 1" og "udviklingspakke 2" til henholdsvis 34 og 29 mio. kroner.
arne_v (32) skrev:#31
Den slags bliver jo sjældent offentliggjordt.
Det sker mest hvis projektet er endt katastrofalt.
Men indenfor den kategori er der vel POLSAG som fik 2 store bundter af change requests kaldet "udviklingspakke 1" og "udviklingspakke 2" til henholdsvis 34 og 29 mio. kroner.
Regeringens udviklings opgaver bliver bare altid brugt som eksempler på vandfalds modellen og hvorfor den er så dårlig, med de mange eksempler på at det fejler.
Hvis at POLSAG havde været kørt agilt, så havde der jo ikke engang været nogen "udviklingspakke 1" og "udviklingspakke 2". Så vidt jeg kan se så viser prisen på de udviklingspakker netop at de jo var nød til at gennemgå det hele igen på ny, for at sikre at de nye krav nu kunne passe med alle de tidligere krav osv. Var det agilt ville man ikke engang have set på det som en ekstra udgift, det ville bare være en standard iteration at der nu var nye krav til dette forløb.
Det er så også netop det som er grunden til at EU og regeringen, og så vidt jeg ved også andre regeringen, helst ikke køre agilt, for det er svært at prissætte det på forhånd. Til gengæld vil der så netop være et feedback loop, som nok ville kunne undgå næsten alle de store katastrofer vi har haft med udvikling af nye systemer.
Advarsler om at man burde gå væk fra vandfaldsmodellen:
http://www.computerworld.dk/art/55073/udbudsregler...
Peger på vandfaldsmodellen som problemet med mange fejlede projekter, bla POLSAG:
https://www.version2.dk/blog/laeren-fra-polsag-433...
#20 Udfordringen er vel ikke vandfaldsmetoden, men at man koder software som man bygger huse, hvor der ikke er et økonomiske råderum til ændringer og leverandøren krydser fingre for fejl i kravsspek, så de kan tjene lidt ekstra.
Med andre ord, udfordringen er, at interessen ikke ligger i at levere et stykke software, men at skumme fløden mest muligt. KMD ved at det offentlige ikke går andre steder hen, så hvorfor skal de være en god leverandør? - Det har ikke en konsekvens at være en elendig leverandør som tjener halve og hele milliarder på noget bras, for de får alligevel den næste ordre fra samme kunde.
At en offentlig instans kan finde på at bruge KMD i dag er jo forrykt.
Derudover er det lidt naivt at tro, at det private ikke har samme problemer, selv med relativt små implementeringer.
Derudover, når man læser et stillingsopslag til en it projektleder, så ligger fokus på it kundskaber og kodekendskab, hvor styring og metode er relevant. Man bliver ikke en god projektleder af at være superkoder, langt fra.
Med andre ord, udfordringen er, at interessen ikke ligger i at levere et stykke software, men at skumme fløden mest muligt. KMD ved at det offentlige ikke går andre steder hen, så hvorfor skal de være en god leverandør? - Det har ikke en konsekvens at være en elendig leverandør som tjener halve og hele milliarder på noget bras, for de får alligevel den næste ordre fra samme kunde.
At en offentlig instans kan finde på at bruge KMD i dag er jo forrykt.
Derudover er det lidt naivt at tro, at det private ikke har samme problemer, selv med relativt små implementeringer.
Derudover, når man læser et stillingsopslag til en it projektleder, så ligger fokus på it kundskaber og kodekendskab, hvor styring og metode er relevant. Man bliver ikke en god projektleder af at være superkoder, langt fra.
#34 Det private har da netop ikke samme problemer fordi de ofte kører agilt, det private marked er jo netop ikke så tilgivende. Men jeg er da enig i at de store virksomheder som KMD har for nemt ved at få disse opgaver, men synes så også at det igen peger på at problemet er at de ikke kører agilt, for hvis de gjorde så kunne de jo sådan set have 10 udviklere på et projekt i stedet for 1.
Som jeg ser det er det største problem derfor at dem som leder disse projekter sutter røv til at forstå IT og udvikling af software... men samtidigt er der jo også en række krav der gør at det er ret umuligt lige nu at ændre på hvordan disse projekter bliver udviklet.
Som jeg ser det er det største problem derfor at dem som leder disse projekter sutter røv til at forstå IT og udvikling af software... men samtidigt er der jo også en række krav der gør at det er ret umuligt lige nu at ændre på hvordan disse projekter bliver udviklet.
@kblood: det er ikke populært at sige det, men jeg ved at andre virksomheder ikke har en chance med at få disse store opgaver
"80% af værdien ligger i 20% af arbejdet". Udvikl 20%, løb kravspec igennem igen. Udvikl de næste 20%, gennemgå kravspec påny etc. etc. - dét kunne de projekter drage nytte af. Det ville bare kræve at staten er involveret i udviklingen løbende, hvilket jeg tror på er udfordringen her.
Se evt. "The Expert (Short Comedy Sketch)" på YouTube for lidt god underholdning.
Se evt. "The Expert (Short Comedy Sketch)" på YouTube for lidt god underholdning.
Ang. vandfaldsmodellen:
Problemet med den er, at den er pissehamrende dyr hvis man skal gøre det rigtigt, men hvis man gør det rigtigt virker det perfekt: https://www.fastcompany.com/28121/they-write-right...
Problemet med den er, at den er pissehamrende dyr hvis man skal gøre det rigtigt, men hvis man gør det rigtigt virker det perfekt: https://www.fastcompany.com/28121/they-write-right...
CBM (36) skrev:@kblood: det er ikke populært at sige det, men jeg ved at andre virksomheder ikke har en chance med at få disse store opgaver
Det har de ikke, men tror også noget af det som gør det umuligt, er de krav der er, for jeg mener der er krav om hvor stor en virksomhed er før de overhovedet må få de opgaver her.
gramps2 (38) skrev:Ang. vandfaldsmodellen:
Problemet med den er, at den er pissehamrende dyr hvis man skal gøre det rigtigt, men hvis man gør det rigtigt virker det perfekt: https://www.fastcompany.com/28121/they-write-right...
Men dette er så også under helt andre forudsætninger. Når NASA laver noget, så skal det jo primært fungere sammen med andre NASA systemer. Så det er noget mere lukket end SKAT, POLSAG osv. som jo gerne skal arbejde sammen med en længere række andre systemer i kommuner og i det offentlige. Det giver en langt større risiko for fejl og at det man udvikler bliver forældet før det er udviklet færdigt.
Så i den slags lukkede systemer kan det da give mening, og samtidigt hjælper det nok også en hel del at det bliver udført af kvalificerede folk, specielt den del med at sætte kravs specifikationer, for når det sker inden for det offentlige så lyder det ikke til at det er eksperter på områder der rent faktisk udføre dybdegående undersøgelser for at sikre at de krav er specificeret korrekt.
#39: Det er umuligt at sikre at kravene er specificeret korrekt, selv hvis du har nok så mange eksperter på opgaven. Det er ligeledes umuligt for leverandøren at kunne garantere at de kan levere på dem alle. Ingen har det overblik, det er utopi.
Det som sker i praksis er at det er mere en slags forhandling. Ja man udformer det som en kontrakt med juridiske forpligtelser osv. men i sidste ende skal der 2 parter til at få de her kæmpe projekter til at gå op i en højere enhed og det kræver altid noget flexibilitet undervejs efterhånden som realiteterne indtræffer.
Hvis ikke man er indforstået med det både som kunde og som leverandør, så kan man lige så godt lade være fra starten. Men det er selvfølgelig svært at sige nej til 100 mio kr, så der sker ofte det at man anyway går med på legen og så enten håber man at det hele går godt eller at man kan finde ud af tingene sammen når det går galt.
Det som sker i praksis er at det er mere en slags forhandling. Ja man udformer det som en kontrakt med juridiske forpligtelser osv. men i sidste ende skal der 2 parter til at få de her kæmpe projekter til at gå op i en højere enhed og det kræver altid noget flexibilitet undervejs efterhånden som realiteterne indtræffer.
Hvis ikke man er indforstået med det både som kunde og som leverandør, så kan man lige så godt lade være fra starten. Men det er selvfølgelig svært at sige nej til 100 mio kr, så der sker ofte det at man anyway går med på legen og så enten håber man at det hele går godt eller at man kan finde ud af tingene sammen når det går galt.
#40 Ja, men det er også min pointe. Mangel på kvalificerede folk til at udforme kravs specifikationerne er kun et problem, men når systemet ikke er et nogen lunde lukket system som hos NASA, så er det ikke nok, jeg vil stadig mene det er nødvendigt med at bruge en mere agil fremgangs metode, hvor man netop laver brugertests løbende og fremsætter kravene løbende.
gramps2 (42) skrev:#39
Har du læst artiklen? Den er voldsomt lang, så jeg bebrejder dig ikke, men skim den igennem og prøv at beregne hvad hver linje kode kostede NASA.
Jeg vil nu ikke mene at det er specielt sigende at udregne hvor meget hver linje kode har kostet. Hvis det var kodet dårligt kunne det sikkert have 1000 gange så meget kode og kun være ringere på grund af det. Min pointe er at problemet staten har ikke kan løses bare ved at smide flere penge efter det. De er nød til at arbejde mere agilt uanset. Som det er nu, så stopper lovgivningen dem dog fra det.
kblood (43) skrev:De er nød til at arbejde mere agilt uanset.
Det er i hvert fald billigere at arbejde agilt.
gramps2 (44) skrev:kblood (43) skrev:De er nød til at arbejde mere agilt uanset.
Det er i hvert fald billigere at arbejde agilt.
Jo, men syntes lidt at man kan påpege at hvis de ikke arbejder agilt så står de overfor at smide penge efter noget som alligevel ikke kan bruges i sidste ende. Det er sket hvor mange gange nu? Mener det er mindst 3 gange med større systemer, og har været ret tæt på at det kunne være sket flere gange. F.eks. er der RejskeKort systemet... det kunne vi da have købt LANGT billigere af lande som allerede havde sådan et system. Lugter faktisk lidt af korruption at man valgte at ville udvikle det i Danmark når det ikke var nødvendigt.
Men der var jo ikke andre systemer som kunne det, som Rejsekortet kan; stig på en bus, fortsæt med tog, slut med metro og få en samlet regning.kblood (45) skrev:det kunne vi da have købt LANGT billigere af lande som allerede havde sådan et system.
FynBus indkøbte Kvikkort som fungerede ganske fint - så længe du enten kun kørte på samme strækning eller fortalte chaufføren hvor langt du skulle. Man kunne sagtens køre længere væk end kortet gjaldt til, men man kunne ikke komme tilbage uden at købe en kontantbillet som tillægsbillet. I kid you not.
Kvikkortet var meget mere simpelt og meget billigere end Rejsekortet og kom hurtigere i drift (http://www.computerworld.dk/art/52160/fynsk-kvikkort-overhaler-rejsek..) - men Kvikkortet kunne ikke udvides til at dække både tog, bus, metro (, letbane). Det samme gælder for stort set alle andre elektroniske løsninger som fandtes da udvikling af Rejsekortet blev igangsat. Husk at idéen startede i 90'erne, mens Rejsekort A/S har forsøgt at få udviklet den tekniske løsning siden 2003 (hvor selskabet blev oprettet).
I 2003 var den teknikken slet ikke hvor den er i dag. I 2003 var den bedst solgte telefon Nokia 1100 (jeg havde endda en).
I øvrigt kan den agile metode sagtens kvæle et produkt. Lumigon forsøgte konstant at implementere nyeste hardware i deres T1 hvilket gjorde den meget forsinket. Det var agilt, men det var ikke den bedste løsning.
kblood (33) skrev:Regeringens udviklings opgaver bliver bare altid brugt som eksempler på vandfalds modellen og hvorfor den er så dårlig, med de mange eksempler på at det fejler.
Ja. Men jeg er ikke altid overbevist om at dem som fremfører det har den rigtige forståelse for tingene.
kblood (33) skrev:Så vidt jeg kan se så viser prisen på de udviklingspakker netop at de jo var nød til at gennemgå det hele igen på ny,
Hvis du kigger på hvor lille en andel de er af den samlede udgift, så viser det netop at man ikke er startet forfra.
kblood (33) skrev:Hvis at POLSAG havde været kørt agilt, så havde der jo ikke engang været nogen "udviklingspakke 1" og "udviklingspakke 2".
kblood (33) skrev:Var det agilt ville man ikke engang have set på det som en ekstra udgift, det ville bare være en standard iteration at der nu var nye krav til dette forløb.
Hvis man havde arbejdet agilt så ville der ikke have været nogle CR bundter kaldet udviklingspakke 1 og 2. Der ville kun have været en fase 4 og 5 eller sprint 31-36 og 37-43 eller hvad man nu ville kalde det i den brugte form for agil. Og man ville ikke betragte det som en budgetoverskridelse.
Men man skulle have implementeret den samme funktionalitet, skrevet den samme kode, lavet de samme tests, taget den samme tid og kostet det samme beløb. Sådan cirka.
Samme vare men nye etiketter.
Det er en en pseudo-løsning på problemet.
kblood (33) skrev:gennemgå det hele igen på ny, for at sikre at de nye krav nu kunne passe med alle de tidligere krav osv.
Selvfølgelig er man nødt til at checke ændringernes indflydelse på det tidligere lavet.
Men fordi man bruger agil terminologi så forsvinder det problem jo ikke. Uanset hvor agilt man arbejder, så vil man også der skulle ind og checke de nye iterationer/sprints/whatever med de tidligere.
Samme arbejde. Bare andre etiketter.
Ni (34) skrev:Derudover, når man læser et stillingsopslag til en it projektleder, så ligger fokus på it kundskaber og kodekendskab, hvor styring og metode er relevant. Man bliver ikke en god projektleder af at være superkoder, langt fra.
Jeg synes nu ofte at man ser det modsatte. Projekledere som har PMP, PRINCE2, Scrum Master, alt muligt men som ikke ved noget om software udvikling og derfor har meget svært ved at få projekt-planen til at matche med virkeligheden.
DrHouseDK (37) skrev:"80% af værdien ligger i 20% af arbejdet". Udvikl 20%, løb kravspec igennem igen. Udvikl de næste 20%, gennemgå kravspec påny etc. etc.
Ja.
Mange tror at agil er løsningen på alt med software udvikling.
Men jeg synes at al erfaring viser at agil i.s.f vandfald:
- ikke reducerer omkostninger
- ikke reducerer leveringstid
- ikke reducerer fejl
Det eneste som det rent fakrisk gør er:
- reducerer omfanget af at løsningen ikke matcher det relle behov
kblood (39) skrev:Men dette er så også under helt andre forudsætninger. Når NASA laver noget, så skal det jo primært fungere sammen med andre NASA systemer. Så det er noget mere lukket end SKAT, POLSAG osv. som jo gerne skal arbejde sammen med en længere række andre systemer i kommuner og i det offentlige. Det giver en langt større risiko for fejl og at det man udvikler bliver forældet før det er udviklet færdigt.
Jeg har lidt svært ved at se logikken i at fordi de systemer man integrerer med er indenfor samme organisation så får man:
- mindre risiko for fejl
- mindre risiko for forældelse
Antal fejl afhænger vel mest af kvaliteten af udviklerne, den tid de har til rådighed og de processer som de bruger.
Forældelse afhænger vel primært af hvor lang tid projektet tager.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund