Hvor får man mindst våde bukser: Vandfald eller prototyping?

Nu blev jeg færdig med det projekt, jeg har arbejdet på de sidste tre måneder sammen med en kollega, nemlig at lave typesystemet til vores nye studio, som jeg har blogget lidt om tidligere. Der går dog en del tid, inden vores kode bliver sluppet ud i virkeligheden, da det er en del af et større release, der er berammet til foråret næste år.
 
Vi kørte det rimelig meget efter vandfaldsmodellen denne gang - det var et projekt, der var ret velegnet til, at vi analyserede længe og grundigt, inden vi satte os til tasterne. "Brainstorm" er egentlig et meget beskrivende ord: Man kan godt føle sig temmeligt blæst i hovedet, når man kommer hjem efter en hel dags intense tanker og diskussioner! Til gengæld er det som om, man bliver helt høj, når man så endelig kommer i gang med at kode, og ser sine tanker blive til virkelighed og føler, at nu får man produceret noget (selvom man jo godt med sin logiske sans ved, at det absolut ikke er uproduktivt at bruge tid på at tænke sig om, før man koder).
 
Det nye projekt, jeg arbejer på, har vi valgt at køre en del anderledes. Vi har en tredjepartskomponent, en Firefox-browser, som man tilgår fra Java via JNI (Java Native Interface), der skal embeddes i det nye studio. Vi har allerede brugt den i en tidligere version, men der er rigtig mange ting, som skal tænkes forfra, og vi to udviklere, der står for det projekt, har ikke arbejdet med komponenten før. Så her har vi valgt at arbejde meget mere iterativt og prototype-ud-over-stepperne-agtigt. Først få verdens simpleste "hello world"-side vist i Firefox-browseren inde i vores studio, og så bygge videre derfra.
 
Især fordi projektet er baseret på en tredjepartskomponent, virker det farligt med en tilgang, hvor man tror, at man kan sætte sig ned og analysere sig ud af de potentielle problemer på forhånd. Indtil videre har det f.eks. vist sig, at det ikke er lige til at få Swing til at tegne ovenpå en komponent, der er hevet ind ved hjælp af JNI, så vi bliver nødt til at tegne ekstra ting direkte i browseren vha. JavaScript. Og der er også nogle sære performanceproblemer på Windows Vista, vi skal have kigget på. Men det er den slags problemer, man nemmest lokaliserer ved at få et simpelt setup op at køre i en fart - og det er rart at finde dem her i starten af projektet, og ikke til sidst, når man troede, at man næsten var færdig.

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Favrholdt

Du skriver Firefox - jeg tænker på om XUL måske var noget for jeres projekt?

XUL er et GUI-toolkit der tilbyder mere avancerede "Widgets" end hvad der er muligt i HTML.

Faktisk er XUL+javascript teknologien bag ved firefox og thunderbird - Selve menuerne og knapperne i Firefox og mail-listen i thunderbird er lavet i XUL. Når du klikker på noget køres lidt javascript. Har man brug for mere avancerede widgets end dem der er standard kan man skrive disse i f.eks. C++.

mvh. Peter

  • 0
  • 0
Martin Falck-Hansen

Det gamle ordsprog om at hvis alt man har er en hammer så skal man helst også have søm synes at illustrere problemet meget godt. Der er mange steder hvor man slavisk følger den ene eller den anden udviklingsproces - uden at tage hensyn til opgaverne. Udviklingsprocessen bør nærmere være en Schweitzer kniv hvor man kan folde det "rigtige" værktøj ud som nu engang passer bedst til opgaven.

  • 0
  • 0
Peter Juhl Christiansen

Vil mene at man, så vidt det er muligt altid har fordel af at lave en prototype.

Få hul igennem, lav en mini app som så kan vokse, og ikke nok med det det skulle være så modrene at gøre det sådan :-)

Uden at kende detaljerne, så vil jeg da anbefale at I kikker på Google web toolkit.

Har ikke selv leget med det endnu, men ideen bag finder jeg interesant (kort fortalt. det er nemmerer at udvlike i Java end i Javascript)

  • 0
  • 0
Jørgen Henningsen

Det er godt med lidt forskelligt værktøj i projektstyrings kassen. Jeg synes der er en generel tendens til at vi er er ret gode til dele erfaring med kollegaerne når det drejer sig om viden og teknik, men ret dårlige til at udveksle erfaringer når det kommer til projektstyring.
Der er iøvrigt et andet gammelt ordsprog:
For den som har en ny hammer ligner alt et søm:-)
-Jørgen

  • 0
  • 0
Chrisitan Petersen

Har alle dage været et stort problem. Har selv prøvet mange forskellige modeller - lige fra JEditorPane eller hjemmekodede browser komponenter (don't go there :-) ) til den tilgang du beskriver. Senest har jeg dog rettet blikket imod 3. parts komponenter og sværger lige for tiden til WebRenderer. Det er en ren swing komponent baseret på Mozilla (http://www.webrenderer.com/). Der er blandt andet fuld Javascript og applet support.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det er det vi plejde at kalde "Trial and Error", ikke ? :-)

Jeg tror man nemmest får våde bukser hvis man lader dogmatik styre sin udvikling.

Det er lige slemt ikke at have plads til en prototype i sin vandfaldsmodel som det er at lave sine prototyper i en ørken.

Men den farligste dogmatik er nok at man ikke må skifte design, metode, mål, strategi eller mening undervejs hvis man bliver klogere.

Uden at det af den årsag skal udvikle sig til principløshed, eller som det hedder nu om dage: "agil software udvikling".

Poul-Henning

  • 0
  • 0
Anne-Sofie Nielsen

Tak for alle de gode kommentarer :-)

Det kan i øvrigt være, jeg lige skulle skrive et par ord mere om, hvad projektet går ud på:
- Givet en HTML DOM at få den renderet som i en browser inde i et Swing-studio -

Der skal altså i princippet ikke eksekveres JavaScript eller noget (bortset fra at vi selv genererer noget script til at tegne ovenpå browseren, da vi ikke kunne komme til at tegne direkte på komponenten).

  • 0
  • 0
Jakob Veje Hansen

Hej Anne-Sofie,

Det er godt at se at I vælger jeres tilgang til projektet ud fra jeres vurdering af karakteriska ved det. I jeres tilfælde har I tidligt identificeret en usikkerhed ved et teknisk komponent, og I vælger at afdække denne usikkerhed ved at lave en prototype. Jeg antager at I har vurderet at den tekniske usikkerhed er, i alt fald på linie med usikkerheden ved scopet? Der kan prototypen jo i virkeligheden også hjælpe til, hvis den vel at mærke er velegnet til demonstration overfor kravstillerne.

For mig at se er det een af grundstenene ved agile metoder: Man angriber de største usikkerheder først. Vandfaldsmodellen har udgangspunkt i at den største usikkerhed er knyttet til kravene. Det er ikke nødvendigvis altid tilfældene.

Tillad mig iøvrigt at henvise til min blog, hvor jeg har beskrevet de forskelle jeg ser på iterative metoder og vandfaldsmodellen: http://mombo.motime.com/post/650881/Optimizing+performance+with+agility

Venlig hilsen,
Jakob

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