Fredagstrist

Jeg bliver sådan lidt fredagstrist når jeg igen læser interviewet med professor Jan Stage og lektor Lene Pries-Heje.
under overskriften "Agile metoder bedst til usikre og simple projekter"

Jeg bliver trist, fordi kernen i agil udvikling åbenbart stadig er så ringe forstået og fordi opskriften på, hvad man så skal gøre med store komplekse projekter, er så deprimerende visionsløs: Big Design Up Front (BDUF) - Vi skal altså blive ved som vi hidtil har gjort. Det er jo også gået så godt med Rejsekortet, Digital Tinglysning og alle de andre.

Det er trist og næsten skammeligt at fastholde, at vi skal fortsætte som vi hidtil har gjort. Har man har sin gang i den danske software- og elektronikindustri, vil man se virksomheder under stort konkurrencemæssigt pres, og har man den naive forestilling, at vi nok skal klare os i Danmark, fordi vi er så godt til at få idéer og udvikle produkter, vil den hurtigt blive korrigeret af virkeligheden. Det er nemlig slet ikke kun håndens arbejdspladser der forsvinder fra Danmark i disse år.

Det er tvingende nødvendigt at vi bliver dygtigere og hurtigere til at udvikle nye og bedre produkter - software såvel som andre høj-teknologiske produkter

For nogen tid siden besøgte jeg en af de virksomheder som vi er så stolte af i Danmark: En elektronik virksomhed med en stor global markedsandel indenfor deres niche. For nogle år siden blev de opkøbt af et amerikansk firma, Sidste år flyttede produktionen ud af Danmark og nu går rygterne at det bare er et spørgsmål om tid, før også udvikling er en saga blot i Danmark.

Der var to ting der slog mig:

For det første fortalte de om deres veldokumenterede og gennemarbejdede proces, med faser, gates og masser af BDUF. De var stolte af processen men samtidig fortalte de om nogle konkrete projekter, hvor alt fulgte planen, lige indtil det punkt, hvor de integrerede de forskellige komponenter og startede på integrationstesten. Så røg kontrollen. Det var umuligt at sige hvor lang tid det ville tage før systemet var færdigt, og fra at være en velordnet proces, blev det nu kaotisk og arbejdet med at blive færdig oplevedes som at kæmpe fra tue til tue.

Det andet de fortalte var, at de deltog på en årlig messe sammen med alle deres konkurrenter. I mange år havde nogle vestlige firmaer delt markedet imellem sig. For nogle år siden havde der for første gang været en kinesisk virksomhed med et konkurrerende produkt. Efter at have set det kineserne diskede op med var der kun overbærende smil. Det mindede mest om en ombygget Nilfisk støvsuger. Men i de kommende år stivnede smilene. Kineserne mødte troligt op, hvert år med en ny model, der var mere smart at se på og som indeholdt stadig mere avanceret teknologi. Indtil den dag, hvor der ikke var væsentlig forskel på de danske og kinesiske produkter. Lige bortset fra prisen og det faktum at kineserne kunne lave en ny model hvert år, noget der tog betydeligt længere tid for vore danske venner og deres velstrukturerede BDUF.

Det er for mange danske virksomheder ikke et verdensfjert teoretisk spørgsmål om agil udvikling egner sig eller ej - det er pinedød nødvendigt at innovere og udvikle produkter hurtigere og her er agil udvikling et af de mest overbevisende bud.

Desværre tror mange at agil udvikling er det samme som, at nu får vi nogle sjove nye titler og siger til ledelsen at de skal blande sig udenom så vi rigtig kan være selvorganiserende team. Tilsyneladende er det også hovedbudskabet på nogle af de 2-dages Scrum-certificeringer der er så populære i softwareverdenen.

Men en ting er overflade og noget andet det væsen der ligger under overfladen af de mærkelige betegnelser: Scrum Master og Product Owner, Sprint, Chicken and Pigs. Under overfladen finder man nemlig de principper, som er dem det hele drejer sig om. Scrum og andre lean/agile metoder har alle det tilfælles, at de introducer korte lærings- og feedbackcykler i udviklingsprocessen. Følger man Scrum metoden, vil man helt naturligt få feedback og mulighed for at lære hver gang man har gennemløbet et sprint.

At være istand til at validere sine antagelser og lære af dem hurtigt, er måden at få produkter hurtigere på markedet. Vel at mærke produkter, hvor kvaliteten ikke er sat over styr på grund af en forceret udviklingsproces.

Er projektet stort og komplekst, af den type de to interviewede universitetsfolk hævder ikke er egnet til agil udvikling, er der i høj grad brug for tidlig og fortløbende integration og konstant læring. Vejen dertil går over agil udvikling. Ikke nødvendigvis Scrum og bestemt ikke Scrum out-of-the-box og 2 dages certificering, men principperne kombineret med disciplin og hårdt arbejde. Det er vejen frem - den eneste vej - hvis vi stadig vil være borgere i et innovativt videnssamfund.

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Jeg tror, at store projekter generelt har gavn af BDUF af data: Man skal gøre datamodellen klar tidligt i forløbet. Sa kan man sagtens udvikle operationer på data agilt derefter.

Desværre tror mange, at datamodellering er klassediagrammer i UML. Men de er efter min mening en uheldig blanding af data og procedurer og leder til overspecifikation på et tidligt tidspunkt i processen. Kun de mest grundlæggende operationer på data skal specificeres samtidig med dataformaterne.

  • 0
  • 0
Morten Korsaa

Ja! - agile principper er noget af det mest lovende siden hjulet. Men at tro at det er løsningen på alle problemer er bundløst naivt. Der er typer af problemer der egner sig, og typer der ikke gør. Konstruktion af brugervendt funktionalitet er sædvanligvis meget egnet. Men hvis man skal lave en infrastruktur dims, som mange systemer er afhængige af, og som er fæl og dyr at skifte ud, så er det altså bare en god ide at tænke sig så godt om som man nu kan fra starten. Og der er andre parametre der kan gøre udfaldet.
En hver diskussion om hvorvidt agil er godt eller dårligt uden at fortælle hvad problemet er, er useriøst.

  • 0
  • 0
Bent Jensen

Hvor er det nu det står at man ikke må tænke sig godt fra starten, når man laver agil udvikling?

Og specielt for dit eksempel - der er rigtig mange eksempler på at godt tænkte infrastruktur dimser, som folk har nørklet med i lang tid, fejler når de skal integreres med resten af systemet. Agil udvikling giver mulighed for at integrere tidligt, og derved i den virkelige verden konstatere hvilke antagelser der holder og hvilke der ikke holder. Jo hurtigere man finder ud af, at man har taget fejl - jo billigere er det.

  • 1
  • 0
Fredrik Skeel Løkke

..at datamodellering er klassediagrammer i UML. Men de er efter min mening en uheldig blanding af data og procedurer og leder til overspecifikation på et tidligt tidspunkt i processen. Kun de mest grundlæggende operationer på data skal specificeres samtidig med dataformaterne.

Af ren videbegærlighed, findes der noget litteratur der beskriver denne metode? :)

  • 0
  • 0
Bent Jensen

De sidste afsnit i Stefano's blog:

Next time you spend energy writing the ontology, or the database schema, or the XML schema, or the software architecture, or the protocol, that ‘foresees’ problems that you don’t have right now think about “you ain’t gonna need it”, “do the simplest thing that can possibly work“, “keep it simple stupid“, “release early and often“, “if it ain’t broken don’t fix it” and all the various other suggestions that tell you not to trust design as the way to solve your problems.

But don’t forget to think about ways to make further structure emerge from the data, or you’ll be lost with a simple system that will fail to grow in complexity without deteriorating.

Er efter min mening god agil tænkning - UML diagrammer eller ej. Så er du enig i den, skal vi vist lede meget godt efter, for at finde noget at være uenige om.

  • 0
  • 0
Klaus Enevoldsen

Du har fuldstændigt ret, det er sjovt at se hvordan folk kan finde argumenter for holdningen:

"Det er fint nok med det der agile noget, men lad os nu lave hele datamodellen først, så ved vi hvad det drejer sig om..." :-)

  • 1
  • 0
Jeppe Boelsmand

Jeg er ikke sikker på at jeg forstår hvorfor datamodellen skal være en hellig urørlig størrelse. Hele pointen med at være agil er at man kan lave ting om så de passer til kravene.

UML er bare et sprog til at beskrive koncepter med; jeg er ikke sikker på at man kan give UML skylden for en diffus beskrivelse. Det ville være lidt som at sige at det er for let at gøre alting i maven på et perlscript og at det derfor giver en højere grad af binding at bruge perl.

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