mboost-dp1
KMD
kblood (43) skrev: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.
Sådan er det når man kigger på enkelte stykker kode. Less is more.
Men når man kigger på større projekter og tæller i 100 KLOC eller MLOC, så er der så mange udviklerere inde som leverer kode af forskellige kvalitet, at den effekt udjævnes og projekter bliver "tæt på gennemsnittet". Det er helt normalt at sammenligne LOC/man-month mellem projekter.
kblood (43) skrev: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.
Sådan er det når man kigger på enkelte stykker kode. Less is more.
Men når man kigger på større projekter og tæller i 100 KLOC eller MLOC, så er der så mange udviklerere inde som leverer kode af forskellige kvalitet, at den effekt udjævnes og projekter bliver "tæt på gennemsnittet". Det er helt normalt at sammenligne LOC/man-month mellem projekter.
kblood (43) skrev:De er nød til at arbejde mere agilt uanset. Som det er nu, så stopper lovgivningen dem dog fra det.
kblood (23) skrev: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...
Det offentlige kan skam gøre brug af agil udvikling.
Standard kontrakt:
https://www.digst.dk/Styring/Standardkontrakter/K0...
Vejledningen:
https://digitaliser.dk/resource/454065/artefact/Ve...
@Arne_v
Det sidste link med vejledning giver en 404 fejl. Men lyder da lovende at de i det mindste har forberedt at kunne arbejde agilt.
Du skriver at det vil være det samme at implementere agilt som med vandfaldsmodel? Jeg syntes altså at dine svar for det til at lyde til at du ikke kender de to modeller specielt godt. Jeg vil mene at bruges begge modeller optimalt, så er agilt billigere, for ja, det er samme mængde kode og der skal tages højde for det som er lavet tidligere, men det du så helt har set bort fra ved det er forskellen. Nemlig at med vandfalds-modellen, der skal de sikre at alle de gamle kravspecifikationer stadigt kan bruges og at en hel række nye kravspecifikationer bliver dokumenteret.
Du siger at "de starter jo ikke forfra", nej, men jeg skrev også kun at de stort set skal starte forfra. Med vandfalds-modellen kræver det langt mere dokumentation. Selvfølgelig, hvis den agile metode du prøver at sammenligne med er SCRUM, så er det nok begrænset hvor stor forskellen er, men prøv at sammenligne med KANBAN eller noget lignende.
Men ja, så er problemet stadigt at de agile metode nok endnu mere end vandfalds-modellen stiller høje krav til at folk ved hvad de laver. I hvert fald i udviklings gruppen og for den person som leder den, jeg vil nok argumentere at det stiller mindre krav til dem som skal give opgaven, for teamet skulle jo hurtigere kunne tilpasse sig hvis der er noget som skal laves om.
Du prøver jo praktisk talt at sige at det er pointless om man vælger agil model eller vandfalds-model... og jeg vil sige at der er en lang liste af grunde til at industrien er ret så dybt uenig med dig.
Dine argumenter angående NASA virker heller ikke så godt begrundede. Sådan lidt, "jamen hvad nu hvis". Jo, men alt andet lige, så er det da nemmere at udvikle til et lukket system hvor NASA selv bestemmer hvor meget der internt skal ændre sig. Hvis det fucker op, så er det dem der fucker op, og det er ikke fordi de har været uheldig med at omverdenen har ændret sig for dem.
Det sidste link med vejledning giver en 404 fejl. Men lyder da lovende at de i det mindste har forberedt at kunne arbejde agilt.
Du skriver at det vil være det samme at implementere agilt som med vandfaldsmodel? Jeg syntes altså at dine svar for det til at lyde til at du ikke kender de to modeller specielt godt. Jeg vil mene at bruges begge modeller optimalt, så er agilt billigere, for ja, det er samme mængde kode og der skal tages højde for det som er lavet tidligere, men det du så helt har set bort fra ved det er forskellen. Nemlig at med vandfalds-modellen, der skal de sikre at alle de gamle kravspecifikationer stadigt kan bruges og at en hel række nye kravspecifikationer bliver dokumenteret.
Du siger at "de starter jo ikke forfra", nej, men jeg skrev også kun at de stort set skal starte forfra. Med vandfalds-modellen kræver det langt mere dokumentation. Selvfølgelig, hvis den agile metode du prøver at sammenligne med er SCRUM, så er det nok begrænset hvor stor forskellen er, men prøv at sammenligne med KANBAN eller noget lignende.
Men ja, så er problemet stadigt at de agile metode nok endnu mere end vandfalds-modellen stiller høje krav til at folk ved hvad de laver. I hvert fald i udviklings gruppen og for den person som leder den, jeg vil nok argumentere at det stiller mindre krav til dem som skal give opgaven, for teamet skulle jo hurtigere kunne tilpasse sig hvis der er noget som skal laves om.
Du prøver jo praktisk talt at sige at det er pointless om man vælger agil model eller vandfalds-model... og jeg vil sige at der er en lang liste af grunde til at industrien er ret så dybt uenig med dig.
Dine argumenter angående NASA virker heller ikke så godt begrundede. Sådan lidt, "jamen hvad nu hvis". Jo, men alt andet lige, så er det da nemmere at udvikle til et lukket system hvor NASA selv bestemmer hvor meget der internt skal ændre sig. Hvis det fucker op, så er det dem der fucker op, og det er ikke fordi de har været uheldig med at omverdenen har ændret sig for dem.
kblood (54) skrev:men det du så helt har set bort fra ved det er forskellen. Nemlig at med vandfalds-modellen, der skal de sikre at alle de gamle kravspecifikationer stadigt kan bruges og at en hel række nye kravspecifikationer bliver dokumenteret.
Ved vandfald opdaterer man eksisterende dokumentationen med ændringerne.
Ved agile tilføjer man ny dokumentation.
Igen er det lidt sat på spidsen samme mængde tekst der skal skrives og forskellen er om den skrives i et eksisterende dokument eller et nyt dokument.
Detalje.
kblood (54) skrev:Med vandfalds-modellen kræver det langt mere dokumentation. Selvfølgelig, hvis den agile metode du prøver at sammenligne med er SCRUM, så er det nok begrænset hvor stor forskellen er, men prøv at sammenligne med KANBAN eller noget lignende.
Der er ikke givet at vandfald kræver mere dokumentation. Det er ikke noget som kræves af vandfalds princippet.
Agile kan laves med forskellige niveauer af dokumentation. Det kan vandfald også.
Forskellige projektstørrelser kræver forskellige niveauer af dokumentation. Kommer man op i POLSAG størrelsen, så kræves der meget dokumentation.
kblood (54) skrev:Du prøver jo praktisk talt at sige at det er pointless om man vælger agil model eller vandfalds-model... og jeg vil sige at der er en lang liste af grunde til at industrien er ret så dybt uenig med dig.
Er industrien det?
Det er rigtigt at der er millioner af unge udviklere som har fået en kort intro til agile herunder en karikeret beskrivelse af vandfald som er vildt uenige med mig.
Billedet er noget mere blandet hos dem med erfaring med både agil og vandfald.
kblood (54) skrev:Du prøver jo praktisk talt at sige at det er pointless om man vælger agil model eller vandfalds-model... og jeg vil sige at der er en lang liste af grunde til at industrien er ret så dybt uenig med dig.
Pointless er nok lidt mere end jeg kan stå inde for.
Men ideen om at brug af agile er løsningen på problematiske IT projekter er fundamental forkert.
Agile er ikke en mirakel løsning på et vanskeligt problem.
Det er ikke det samme at agile ikke kan være godt.
arne_v (49) skrev: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
Det er jo ikke så ringe endda at levere løsninger som bedre matcher brugernes behov.
Derudover er der også forskel på projekter.
Generelt:
usikkerhed omkring krav => bedre med mere agil tilgang
stort projekt => bedre med mindre agil tilgang (*)
*) Der er lavet forskellige agile varianter med det formål bedre at håndtere store projekter f.eks. "Disciplined Agile".
Men den grundliggende præmis om at katastrofal vandfaldsprojekt X ville have endt bedre hvis der var brugt agile er yderst tvivlsom.
I USA lavede man healthcare.gov agile og det var sent, langt dyrere end forventet og fuld af fejl.
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.
arne_v (50) skrev: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
kblood (54) skrev:Jo, men alt andet lige, så er det da nemmere at udvikle til et lukket system hvor NASA selv bestemmer hvor meget der internt skal ændre sig. Hvis det fucker op, så er det dem der fucker op, og det er ikke fordi de har været uheldig med at omverdenen har ændret sig for dem.
Hvis NASA var en lille biks, hvor man lavede et nyt stort projekt af gangen og alle havde et rimeligt overblik over hvad alle lavede, så var det nemmere.
Men NASA er en stor biks. Der kører flere projekter samtidigt. De projekter har forskellige deadlines og målsætninger. Teams ved ikke meget om hvad andre teams laver. Bare fordi noget foregår inden for samme organisation, så betyder det ikke god transparens.
UP bliver stadigt nævnt en del. Kan så ikke huske det som at det blev prioriteret.
@Arne_v
De problemer som de jo netop har med de store projekter synes jeg nu er af den type som burde kunne være løst hvis de netop havde arbejdet agilt. Agilt er da ikke nogen garanti, da det stiller en del større krav til udviklerne, men agilt giver en meget kortere feedback loop, og det er da oftest det som de projekter har manglet. At de generelt arbejdede noget tættere med dem som rent faktisk skulle bruge systemet, hvilket er et område hvor de ofte fejler fordi vandfaldsmodellen er så firkantet.
@Arne_v
De problemer som de jo netop har med de store projekter synes jeg nu er af den type som burde kunne være løst hvis de netop havde arbejdet agilt. Agilt er da ikke nogen garanti, da det stiller en del større krav til udviklerne, men agilt giver en meget kortere feedback loop, og det er da oftest det som de projekter har manglet. At de generelt arbejdede noget tættere med dem som rent faktisk skulle bruge systemet, hvilket er et område hvor de ofte fejler fordi vandfaldsmodellen er så firkantet.
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