Er der problemer med agile metoder? Ja masser, heldigvis.

En lille test først: Bør du læse dette?

Bruger du idag noget andet end agile metoder og fungerer det godt' Har I styr på kvaliteten og overholder I jeres deadlines' Så behøver du ikke at læse mere. Istedet vil jeg forslå at du sætter dig ned og beskriver hvad I gør, så vi andre kan lære af det.

Forlanger du et videnskabeligt verificerbart bevis for agile metoders effekt, før du vil overveje at tage dem i brug? Det vil du ikke finde i det følgende, så du behøver heller ikke at læse mere. Istedet vil jeg foreslå at du bruger tiden på at finde det videnskabelige bevis, for din nuværende metodes effekt, og deler det med os andre. Jeg er nemlig aldrig stødt på sådan et, og vil meget gerne se det.

Da du endnu ikke er stået af, går jeg ud fra at du er reelt interesseret i lære mere om fordele og ulemper ved agil udvikling.

Kernen af agil udvikling er hastighed. Det er evnen til meget hurtigt at gennemløbe en udviklingscyklus, og med korte mellemrum (1-2 uger ) levere en 'produkt udvidelse', testet og potentielt klar til at give brugerne. Således skaber man inkrementel (små bidder) og iterativ (feedback og forfinelse) udvikling.

Værktøjer, praksis og teknikker tjener alle til understøttelse af dette.

Nogle værktøjer skaber den tekniske infrastruktur med Continuous Integration og automatiseret test, andre understøtter nedbrydningen i opgaver i små klumper af funktionalitet og igen andre tjener til at skabe den synlighed og effektive kommunikation som er nødvendig for at kunne bevæge sig hurtigt gennem udviklingsfaserne.

Det kan gå galt for et team der vil lave agil udvikling på rigtig mange måder, og de agile bannerførere er ikke altid gode til at påpege den udfordring, det kan være at tage agile metoder i brug i en udviklingsafdeling.

At indføre agil udvikling sætter et team under pres: Tekniske udfordringer, modenhed og personlig vilje og evne til at ændre på roller, arbejdsmåder og traditioner.

At det er svært, betyder på den anden side ikke at man skal lade være, men at man skal være klar over opgavens størrelse og være forberedt på at bruge tid og kræfter på at få det til at virke.

'Sweet Spot' for agil udvikling er det lille team på 5-7 kompetente, udadvendte personer tæt på hinanden (Srcums ideal team), der udvikler et nyt produkt i .NET eller Java til een inhouse kunde. Det er korrekt at sådan et team udemærket kan levere uden agile teknikker, men efter min erfaring kan indføring af agil udvikling medføre meget store forbedringer i sådan et team.

Hvornår skal man ikke lave agil udvikling?

Hvis det ikke vil gøre en forskel for jeres projekt, at levere i mindre bidder og være istand til at lære og korrigere kursen undervejs, hvis der ikke er et pres for at levere indenfor en stram deadline og I præcis ved, hvad kunden forventer, så er der nok ikke så meget vundet ved at indføre agil udvikling.

Hvis I derimod kan se fordelene ved agil udvikling, så skal I vurdere om det vil være besværet værd og om I ønsker at investere det arbejde forandringen kræver.

Jeg beskrev ovenfor 'Sweet Spot' for agil udvikling. Jo længere I er fra den, jo mere arbejde kræver det at indføre agil udvikling, og ROI kan potentielt blive negativ.

Sidder udviklerne over hele verden istedet for samme rum' Er der ikke nogen erfarne udviklere på holdet der har leveret tidligere' Bruger i Cobol eller C' Videreudvikler I på et gammelt produkt med masser af kode, der ikke har automatiske test eller sågar er testbar' Er jeres udviklere alle af den gamle skole, og har de i årtier siddet for sig selv og lavet deres arbejde?

Alt efter svaret på ovenstående, vil der være tekniske, organisatoriske og/eller kulturelle barrierer for at indføre agil udvikling. Det vil sige, at det ikke bare er et Scrum kursus, eller opsætning af en byggeserver der skal til, og nogen gange må man kapitulere og sige at det ikke er umagen værd, at forsøge at lave agil udvikling i dette tilfælde.

Det er dog min erfaring, at det i mange tilfælde alligevel er muligt at opnå resultater, ved at anvende tankegangen bag agil og lean udvikling, til at fjerne noget af spildet i processerne og skabe lidt mere flow, uden at det af den grund, kan kaldes agil udvikling.

Endelig er der masser af svagheder i de agile metoder i sig selv. Lad mig bare nævne nogle få:

  • Kravsstyring. I agil udvikling arbejder vi med det løse begreb User Stories, som er en meget lidt detaljeret beskrivelse af funktionalitet. Det kan være svært at lære at arbejde med User Stories, og jeg tror personlig der kommer kommer et nyt og bedre koncept, sikkert mere visuelt i løbet af de kommende år
  • Innovation. Agile metoder giver ikke nogen garanti for et innovativt produkt. Agil udvikling er efter min mening alt for lineær, og mangler rum til innovation og eksperimenter. Så er der virkelig brug for innovation, må man lave om på den agile metode, så det er mindre maskinelt og mere kreativt.
  • Scrum certificeringer kan være et problem. Jeg ser ofte folk komme hjem fra certificeringskurser med en noget firkantet opfattelse af agil udvikling og en masse regler i rygsækken, som de tror de skal overholde alle sammen. Certificerings systemet og lukketheden i Scrum lejren er desværre med til at gøre en del af den agile verden mindre agil end godt er.
Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jacob Christensen

... er det "heldigvis" at der er masser af problemer med Agil software udvikling? Hvad er fordelen?

Jeg synes i øvrigt ikke de tre svagheder du specifikt nævner er specielt specille for Agile metoder, ud over at ordet "Agil" er blevet flettet ind.... og kunne man forestille sig andre artikler om Agil udvikling, som netop ville fremstille de tre udnævnte områder som områder hvor Agil udvikling ville kunne afhjælpe/understøtte processen?

  • 0
  • 0
#2 Anonym

Du kzn snakke nok så meget om værktøjer og metoder, men "it simply boils down to": "En god EDB mand er en, der evner at omsætte (optimerede) forretningsgange til _brugbar EDB"!

Værktøjer løser ingen problemer - tænk f.eks. på en gammel garvet tømrer, der skal lave et snit på 45 grader, og den nyudlærte, der får en DeWalt sav, men ikke aner hvad 45 grader betyder.

Hvem af de to fuldfører opgaven?

Teamwork er godt, men man må forholde sig til, at performancefaktor sagtens kan være 1:100 i denne verden.

Jeg synes dit indlæg bærer præg agf trial'n'error, hvilket er den absolut dyreste, og mest ineffektive metode.

(Og nej, jeg har gennem 30+ år aldrig forfejlet et mål, eller overskredet budget/tid)

Det kræver lidt mod, og selvsikkerhed, men mine aftaler har altid været baseret på 'jysk håndtryk' samt 'no cure no pay', altså hvis løsningen ikke passer, så er der 0 omkostning.

Jeg har vist været inde på, at det virkelige Y2K problem er, at man effektivt har aflivet gamle kundskaber/discipliner, og starter forfra.

Men det er kendetegnet for EDB branchen - ingen discipliner/viden dúr, hellere genopfinde den dybe tallerken/krudtet osv.

Fred være med det, jeg betragter dog EDB verdenen som en 'devolutation' og ikke en 'evolution'.

  • 0
  • 0
#3 Nikolaj Brinch Jørgensen

@Stig Jeg tror du har misforstået hvad Bent skriver i sit indlæg:

Værktøjer løser ingen problemer - tænk f.eks. på en gammel garvet tømrer, der skal lave et snit på 45 grader, og den nyudlærte, der får en DeWalt sav, men ikke aner hvad 45 grader betyder.

Hvordan laver man et snit på 45 grader uden værktøj?

Er vi enige om at to lige så gode tømrer ikke arbejde ligeså effektivt, hvis den ene bruger en gammel håndsav, og den anden bruger f.eks. en Festool dyksav? Det er nemlig det Bent påstår. Din analogi mellem en garvet og en nyudlært, kan ikke bruges, for den har intet med emnet at gøre.

  • 0
  • 0
#4 Anonym

Hvordan laver man et snit på 45 grader uden værktøj?

Skide keyboard... :-)

Jeg mente naturligvis, at den 'gamle' tømrer har en fukssvans, hvorimod den nyudlærte har en kap/geringssav.

Er vi enige om at to lige så gode tømrer ikke arbejde ligeså effektivt, hvis den ene bruger en gammel håndsav, og den anden bruger f.eks. en Festool dyksav?

Ja, det er vi enige om, men at finde 2 ligegode tømrere(EDB folk) er en til vished grænsende usandsynlighed. (jeg har endnu ikke gennem 30+ år, samt 1.000+ kendskaber, kunnet finde to 'ligestillede').

EDB-folk er ikke 'robotter', man kan sætte matematik på.

  • 0
  • 0
#5 Thomas Ammitzbøll-Bach

Jeg er enig med en stor del af indlægget, men det med C kontra Java/.Net er decideret noget vrøvl, som er vand på værktøjsfetichisterne mølle.

Der kan siges en masse for og imod forskellige programmeringssprog ud fra forskellige kriterier, men hvis vi isoleret ser på et programmeringssprog med agile briller, så er det et spørgsmål om følgende:

1) I hvor høj grad understøtter det pågældende sprog en modulær struktur, hvor de enkelte moduler har en klar, veldefineret snitflade mod andre moduler, og hver modul kan designes, compiles, testes og integreres mest afkoblet fra resten af modulerne?

2) Hvor let er det at refaktorisere de enkelte moduler såvel som hele strukturen af de enkelte moduler med de værktøjer, som eksisterer til det pågældende sprog/udviklingsmiljø?

3) Hvor gode er de testværktøjer, som eksisterer til det pågældende sprog/udviklingsmiljø/afviklingsmiljø, og hvor let er det at videreudvikle/nyudvikle test frameworks?

Til alle tre spørgsmål kan jeg positivt bekræfte, at C er et godt, agilt sprog. En meget stor del af den softwarebase, som findes i Open Source verdenen, er udviklet i C og under en eller anden agil facon. Derfor er der et væld af værktøjer og design patterns rettet mod C.

Det er også en myte, at C ikke understøtter objektorienteret udvikling. Det er korrekt, at der ikke i sproget er syntaktisk sukker for erklæring af klasser og instantiering af objekter, men hele X Window System er skrevet i C og er fuldt objektorienteret.

Thomas

  • 0
  • 0
#6 Bent Jensen

Nu skal mit indlæg ses konteksten af den debat om agile metoder der har udspillet sig i den seneste måneds tid. Her er jeg, blandt meget andet blevet beskyldt for at være en blå-øjet jubelidiot, der meder at agil udvikling er kuren mod alt.

Så det jeg mener med "heldigvis" er, at agil udvikling ikke er ikke en færdig metode mejslet i sten, men derimod en bevægelse der konstant arbejder på at finde bedre måder at udvikle software på. I den proces er mange problemer overvundet, men der står stadig nogen tilbage.

Formulering af krav og Innovation er et problem i softwareudvikling generelt, mens Scrum certificeringen er helt sin egen.

Bent

  • 0
  • 0
#7 Nikolaj Brinch Jørgensen

Man kan lave det meste i alle sprog, men C er ikke særlig fedt at lave objekt orienteret udvikling i. Bla. stinker det, når man skal lave polymorfisme og den slags. Det er vel lidt bedre at så gå med C++, som dog har support for dette.

Objekt orienteret udvikling kan også laves i Perl, men det er sgu ikke særlig pænt eller venligt for vedligeholdelse og læsning.

Man kan godt påstå om C at det understøtter dine opstillede 3 punkter, men man kan også argumentere at Java (specielt med OSGi) understøtter punkterne bedre. Så det med checkmarks er jeg ikke meget for, jeg vil hellere have en modhedsskala, og der synes jeg C ligger længere nede end Java/C# (hvornår finder fold ud af at .NET ikke er et sprog?).

  • 0
  • 0
#9 Nikolaj Brinch Jørgensen

Jeg mente naturligvis, at den 'gamle' tømrer har en fukssvans, hvorimod den nyudlærte har en kap/geringssav.

Det var nu mere sætningen

Værktøjer løser ingen problemer

jeg var ude efter.

Ja, det er vi enige om, men at finde 2 ligegode tømrere(EDB folk) er en til vished grænsende usandsynlighed.

Nej men så tager vi den ene og samme garvede, og lader ham udføre arbejdet med at skær 10 45 graders snit med en fukssvans og derefter 10 45 graders snit med Festool saven. Jeg ved godt hvor jeg vil smide mine penge på, at han er mest effektiv.

Jeg siger ovenstående for at illustrere, at jeg er meget uenig i at værktøjer ikke løser nogen problemer. Dog skal det være de rigtige. Det som du nok vil frem til er, at "a fool with a tool...". Her er vi helt enige.

  • 0
  • 0
#11 Thomas Ammitzbøll-Bach

Man kan lave det meste i alle sprog, men C er ikke særlig fedt at lave objekt orienteret udvikling i. Bla. stinker det, når man skal lave polymorfisme og den slags. Det er vel lidt bedre at så gå med C++, som dog har support for dette.

Er det noget du ved, fordi du har arbejdet med det, eller er det noget du har hørt? Jeg har arbejdet mere end 15 år med C, og det er pærelet at lave polymorfisme i C. Enten lader man konstruktøren installere en funktionspointer i struct'en eller, hvad man oftere gør, laver en handler med call-back funktion.

Objekt orienteret udvikling kan også laves i Perl, men det er sgu ikke særlig pænt eller venligt for vedligeholdelse og læsning.

Det er heller ikke pænt at skrive dokumentation på fransk, med mindre det netop er frankmænd, man henvender sig til. Perl OO er en helt naturlig del af Perl, og igen har jeg mistanke om, at det mere er din attitude, der er problemet.

Jeg har skrevet rigtig mange linier kode i både Perl, Python, PHP og Tcl/tk. Hvert sprog har sine fordele og ulemper, men jeg skriver bare koden i det, der giver mest mening i sammenhængen, og det er ikke altid mine præferencer, der er det mest udslagsgivende.

Man kan godt påstå om C at det understøtter dine opstillede 3 punkter, men man kan også argumentere at Java (specielt med OSGi) understøtter punkterne bedre. Så det med checkmarks er jeg ikke meget for, jeg vil hellere have en modhedsskala, og der synes jeg C ligger længere nede end Java/C# (hvornår finder fold ud af at .NET ikke er et sprog?).

Igen er det noget vrøvl. Java eller .Net er ikke et naturligt valg, når man udvikler til indlejrede systemer med begrænsede ressourcer. Jeg kan ikke bruge dine skalaer til noget som helst! Det kan være i din primadonnaverden, at du bare kan vælge på alle hylder, men os, som udvikler software i den virkelige verden, har ikke råd til den form for kræsenhed.

Nej, .Net er ikke et sprog, og det er netop pointen: .Net er et afviklingsmiljø, som er knyttet til et isoleret hjørne af hele den verden, der der hedder platforme. Jeg har intet imod C# eller Java, det er fine sprog, men jeg kan skrive programmer, der kan køre i en chip med 4k ROM, bare ikke i dem.

Agile metoders største fjender er: Umodenhed, Uærlighed og metode/værktøjs-dyrkelse. Netop de ting, du nævner, viser tydeligt, hvor sårbar agile metoder er.

Thomas

  • 0
  • 0
#12 Nikolaj Brinch Jørgensen

Hej Thomas,

Det var dog en besynderlig svada du kommer med. Dine personlige angreb er da helt hen i vejret, hvor vil du hen med dem. Det er da helt sært at dine argumenter bygger på tilsvining af andre her på version 2 (men sådan har disse agile blog indlæg nu een gang udviklet sig).

Er det noget du ved, fordi du har arbejdet med det, eller er det noget du har hørt?

Nu er denne særning vist ved at være list slidt, kunne du ikke være lidt original og finde på en ny sviner?

Jeg har arbejdet mere end 15 år med C, og det er pærelet at lave polymorfisme i C. Enten lader man konstruktøren installere en funktionspointer i struct'en eller, hvad man oftere gør, laver en handler med call-back funktion.

Det gør bare ikke C til et objektorienteret sprog. Fik du den? Desuden synes du vel ikke det er super pænt?

Det er heller ikke pænt at skrive dokumentation på fransk, med mindre det netop er frankmænd, man henvender sig til. Perl OO er en helt naturlig del af Perl, og igen har jeg mistanke om, at det mere er din attitude, der er problemet.

Moden kommentar - den lader vi stå. Jeg har skrevet hele systemer i Perl (så jeg har den jord under neglene her som der er brug for - Perl OO, er ikke en naturlig del af Perl, det er en ting som blev sat på bagefter).

Jeg har skrevet rigtig mange linier kode i både Perl, Python, PHP og Tcl/tk. Hvert sprog har sine fordele og ulemper, men jeg skriver bare koden i det, der giver mest mening i sammenhængen, og det er ikke altid mine præferencer, der er det mest udslagsgivende.

Det tror jeg desværre de fleste ikke kan, da præferencerne på en del projekter er Java eller .NET.

Igen er det noget vrøvl. Java eller .Net er ikke et naturligt valg, når man udvikler til indlejrede systemer med begrænsede ressourcer. Jeg kan ikke bruge dine skalaer til noget som helst!

Hvem snakker om indlejdede systemer? Desuden tror jeg du tager meget fejl. Java var netop designet som et sprog til indlejrede systemer og til at afløse C.

Det kan være i din primadonnaverden, at du bare kan vælge på alle hylder, men os, som udvikler software i den virkelige verden, har ikke råd til den form for kræsenhed.

Nu er du blot sur (på mig?). Du opstiller nogle punkter for om et sprog er agilt. Det er ikke ja eller nej i min verden (for min verden er ikke sort hvid), men mere et spørgsmål om, hvor agilt et sprog er. C er ikke specielt agilt i min verden, hvorimod f.eks. Ruby er meget agilt. Java og C# befinder sig et sted derimellem. Men det er en jo din definition, og du kan jo have ment noget andet end du skrev? Men igen din kommentar er nok på grænsen til barnlig. Primadonna? Virkelige verden? Det er vel som i alle andre sammenhænge - kan man ikke vinde på ærlig vis (med argumentation), kan man altid gå efter manden.

Nej, .Net er ikke et sprog, og det er netop pointen: .Net er et afviklingsmiljø, som er knyttet til et isoleret hjørne af hele den verden, der der hedder platforme. Jeg har intet imod C# eller Java, det er fine sprog, men jeg kan skrive programmer, der kan køre i en chip med 4k ROM, bare ikke i dem.

Jamen det er fint du udvikler sådan nogle små programmer. Jeg er bare ikke sikker på at det er den udvikling som 5-7 mand er sammen om at lave, og som Bent skriver sit indlæg om?

Agile metoders største fjender er: Umodenhed, Uærlighed og metode/værktøjs-dyrkelse. Netop de ting, du nævner, viser tydeligt, hvor sårbar agile metoder er.

Så gå dog i seng, og stå op igen i morgen.Så er du nok lidt gladere. Jeg er uenig i din verdensanskuelse, og at dit favoritsprog C, som du jo kan alt i, ikke er min kop te, men at jeg derimod går ind for pluralisme, og gerne ser flere forskellige værktøjer (deriblandt flere programmeringssprog - specielt nye og moderne sprog) klare opgaven, går dig åbenbart vældigt meget på. Men forsvar gerne dit C igen, og prøv gerne at overbevise folk om at det er objektorienteret (det er det ikke - og det bliver det heller ikke af at du siger det, og sviner modstanderne til).

Pøj pøj med det Thomas.

  • 0
  • 0
#14 Thomas Ammitzbøll-Bach

På Nikolajs opfordring har jeg fået en dejlig nats søvn. Med friske øjne har jeg nu læst igen, det jeg skrev i går.

Jeg vil gerne begynde med at give Nikolaj en uforbeholden undskyldning. Hvis vi er uenige, så skal der være plads til at udveksle synspunkter, men jeg vil bede Nikolaj om lov til t trække mine ord tilbage om hans persons modenhed, attituder og faglige erfaring. Det var både unødvendigt, ufrugtbart og umodent, og hvis Nikolaj er mere såret over mine ord, end han giver udtryk for, er det helt forståeligt.

Det skader ingen at sige undskyld. Og i denne sammenhæng underbygger jeg med min dårlige opførsel, hvor vigtigt det er, at en agil arbejdsgruppe kan fungere uden personfnidder og territorieafpisning. Hvis jeg arbejdede sammen med Nikolaj, kunne vi have brugt 2x2 arbejdsdage på først at kaste med sten og bagefter glatte ud.

Min oprindelige pointe om, at C ligger fint i "sweet spot" står jeg fast på, men Nikolaj er i sin gode ret til at mene noget andet. Der er mange situationer, hvor C ikke er det rette valg, og der kunne Java eller C#/.Net så være et godt valg. Om scriptsprog kan siges det samme: Hvis man skal begynde et nyt projekt helt fra grunden, så kan der være forskellige grunde til at vølge Perl, Python, Ruby eller PHP afhængig af opgave. Bygger man videre på noget eksisterende, så skal der være rigtig gode grunde til at refaktorisere over i et andet sprog/miljø.

Nikolaj har ret i sine pointer. Derfor er det helt tosset, at det endte i mudderkastning, for ført på et mere sagligt grundlag illustrerer det ganske godt, hvad agile metoder kan: Lad os lave et minimalt system i det sprog, vi formoder er bedst, og lad os evaluere tidligt, ærligt og målbart, om vi skal bruge noget andet i stedet, hvis der er grund til det.

Thomas

  • 0
  • 0
#15 Nikolaj Brinch Jørgensen

Tak for det Thomas!

Dit nye indlæg har i mine øjne meget mere værdi end det tidligere. Jeg er ikke såret over dit indlæg, jeg var bare - skal vi sige - uforstående. Jeg forstod simpelthen ikke hvordan mit indlæg kunne provokere dig til at skrive hvad du skrev?

C er et godt sprog med rigtig mange anvendelser, det viser både brugen heraf og udbredelsen.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Og så skal vi lige have med at en del sprog (C++, Java, C# osv. har rødder tilbage i C).

  • 0
  • 0
#17 Carsten Sonne

C har sine styrker og svagheder præcis som de fleste andre sprog. Den maskinnære natur i C er netop sproget helt store styrke:

Jeg har intet imod C# eller Java, det er fine sprog, men jeg kan skrive programmer, der kan køre i en chip med 4k ROM, bare ikke i dem.

Garbage collection og heap strukturer til håndtering af hukommelsesallokering ved instansering af objekter har sin pris. Specielt i indlejrede systemer er det en pris der ikke lader sig betale.

Til platform og server software er situationen omvendt. Prisen er uforholdsmæssig høj for den ekstra tid det tager selv at håndtere hukommelses allokering sammenlignet med udvikling i f.eks. .Net eller Java.

Vedr. brugen af C til objektorienteret udvikling i henhold til OOAD principper, må man sige at det i udgangspunktet er et uhensigtsmæssigt valg. Her er man bedre hjulpet fra start ved at benytte et sprog med direkte understøttelse af OOP. Selvfølgelig kan der være særlige situationer hvor C, OOP og OOAD med fordel kan kombineres.

Dermed ikke sagt at C ikke egner sig til agil udvikling. Jeg er bekendt med flere leverandøre/producenter af indlejrede systemer, også low-end, som benytter netop agil udvikling.

  • 0
  • 0
#20 Thomas Ammitzbøll-Bach

OK? Der er dog en hel del der bruger netop Java til embedded systems - Har de helt taget fejl?

Nej, begge dele er korrekt.

Indlejrede systemer er to (flere?) ting: Minioperativsystemer med husholdning og processkift, og software, som kører helt nede på "metallet". Ofte vil et moderne indlejret system have en CPU med minioperativsystem og en række supportchips med dedikerede opgaver.

Jeg efterlyste engang et veldefineret pragma til at lave en busywait-løkke i C på en GCC-liste. Det tog lang tid for visse folk at forstå, at der ikke altid er et OS til at tage sig af den slags.

Ja, da Java var spædt og hed Oak, var ideen, at det skulle bruges i indlejrede systemer. Der blev designet en fysisk platform (picojava) i en chip til afvikling af JBC uden en virtuel maskine i mellem.

Thomas

  • 0
  • 0
#21 Thomas Ammitzbøll-Bach

For lige at gøre spørgsmålet om indlejrede systemer relevant i forhold til emnet, så er det en udfordring at bevare det agile i et projekt, hvor hardwaredesign er en del af opgaven. Man kan ikke tåle alt for mange refaktoriseringer i hardwaren, man kan ikke undgå at designe et par iterationer frem, og man skal (når de første systemer er i drift) forholde sig til, at man har hardware, man ikke kan lave om på og stadig skal understøttes.

Min erfaring er: 1) Lyt nøje til hardwarefolk, især tidligt i projektet. 2) "A simple design is not a stupid design". Selvom man kun implementerer fetures, vi skal bruge i dag, så er det klogt at lade designet være klar til næste itertion. 3) Inkludér altid en eller anden form for identifikation af versionen af en grænseflade. Før eller siden har du brug for at vide, om en dims er denne eller forrige generation. 4) Drik masser af kaffe (just kidding)

Thomas

  • 0
  • 0
#22 Carsten Sonne

Indlejrede systemer er to (flere?) ting...

Som jeg har forstået det er der 3 kategorier. RTOS, enten out-the-box eller egenudviklet. RTOS har mere karakter af et bibliotek. De har ingen kerne eller fuld understøttelse af tråde og hukommelse. I den anden ende findes de såkaldte full-blown OS med en egentlig monolitisk kerne, f.eks. Linux eller Windows CE. Midt imellem findes OS baseret på en mikrokerne med trådhåndtering og hukommelsesallokering. Derudover findes nogle lidt mere eksotiske tilgange som MIT's exokernel og hybrid kerner. Sidstnævnte er knap så relevante for indlejrede systemer.

For lige at gøre spørgsmålet om indlejrede systemer relevant i forhold til emnet, så er det en udfordring at bevare det agile i et projekt, hvor hardwaredesign er en del af opgaven.

Netop de høje omkostninger ved at ændre på kravene og forudsætningerne sent i processen har gjort den såkaldte vandfaldsmodel til defakto standard inden for udviklingen indlejrede systemer. Her er dog en bevægelse i gang motiveret af de samme gevinster ved agil udvikling som findes på platform og server markedet.

Elektronikbranchen er meget forsigtige. Umodenhed kan nærmest slå en virksomhed i ihjel hvis den ikke håndteres med omhu ift. agil udvikling. Bevægelsen er tydeligvis i gang. På E-10 messen i Odense var en del præsentationer om agil udvikling netop inden for indlejrede systemer.

  • 0
  • 0
Log ind eller Opret konto for at kommentere