RAD Procesmodel eller metode?

Rapid Application Development, hvad er det egentlig?

Jeg kan huske på studiet, hvor jeg i starten troede at RAD var en ren udviklingsmetode, hvor man så valgte en dertilhørende procesmodel, indtil det gik op for mig, at RAD som sådan godt kunne stå alene,  så kunne jeg godt se at den ikke helt holdte. Hvor skal man så placere RAD... er det en procesmodel ala waterfall og agile? Eller er det en arbejdsmetode? James Martin er manden der har udviklet RAD, og han beskriver det som en overordnet tilgang til software udvikling. Jeg syntes personligt RAD er en procesmodel (agile)... men kan godt følge andre der mener, at det er en generel softwaremetode der bruges.

Jeg går måske lidt for hurtigt frem. Hvorfor mener jeg at vi bruger RAD? Det er ikke noget vi har snakket om, men der er et par ting i vores workflow der passer utroligt godt sammen med RAD.

  • Vi arbejder iterativt.
  • Vores planlægning foregår i samme iteration som selve udviklingen.
  • Vi udvikler prototyper, så vi hele tiden har et fungerende produkt.
  • Vi har brugerne af produktet med i udviklingen fra dag et.


Hvis man tager de 4 steps, og smider dem i et flow chart, giver det god mening. Vi starter med at planlægge og udvikle en prototype, som vi tester løbende med både med unit tests og user tests, derefter forbedres prototypen i næste iteration, koden bliver flyttet ud i egne klasser, logik bliver afkoblet... til sidst står man med et fungerende produkt, som er skalerbart, let at vedligeholde samt moduler og komponenter der er lette at genbruge.

Kun RAD, eller andre metodologier?

Man kan så sige at vi også har en forkærlighed for Extreme Programming, da vi ofte bruger pair programming og vi har korte iterative sprints. Noget som egentlig ikke har med RAD at gøre... men betyder det så at vi arbejder "forkert"?

I mine øjne er det fedt, at have lært en masse forskellige metoder på studiet, men jeg føler aldrig at jeg fandt én metode der var helt perfekt til den måde jeg arbejder på. 
Jeg kan godt lide aspekter fra extreme programming... det samme med continuous integration... men især fra RAD, da jeg syntes at udvikling af prototyper iterativt, er vejen frem, og selvfølgelig skal det hele spices up med en omgang KanbanScrum... hvad kalder man alt det her? Extreme Continuous Rapid Scrumban?

Hver iteration forbedrer koden markant

Jeg har ikke før fået "lov" til at bruge tid på at forbedre koden over flere iterationer, det er faktisk noget jeg lærer utroligt meget af. Jeg er slet ikke i tvivl om, at det betyder jeg i fremtiden får en bedre arkitektur i min kode, tidligere i forløbet. Måske får jeg kun "lov", fordi jeg er i praktik, men på en kommende arbejdsplads, er det noget jeg vil påpege er en uvurderlig proces at have for at udvikle sig som udvikler.

Næste gang man laver et lignende projekt, ved man jo allerede hurtigere, hvordan man kom frem til at strukturen i ens kode skulle være, og så begynder man selvfølgelig med det. Det giver god mening, og når man tænker over det, vil den tid man bruger, efter bare kort tid, have betalt for sig selv. Medmindre man selvfølgelig er ligeglad, og bare vil have et statisk produkt, som bare skal virke... og som aldrig skal opdateres igen... men vil man det?

Ugens arbejde kort

Jeg har arbejdet med endnu en iteration af settings/plugin, hvor settings nu skal afkobles fuldstændig fra plugin. Nu skal man som operatør kunne vælge via drag and drop, eller form choices, hvordan ens plugin skal opbygges. Skal ens plugin have en Dropdown setting... check, skal det have knapper, check... hvilke kommander fra serveren skal dit plugin tilgå (hvis det skal kommunikere med ROS) osv.

I starten udbygger jeg min json fil, så den nu også indeholder settings... til settings, her har jeg dog kaldt den ComponentSettings... håber det er en lidt bedre navngivning.

Det gør faktisk at alt den kode, som der før blev skrevet i ens plugin komponent, nu er fjernet, og smidt over i json filen som variabler... super lækkert. Så når jeg får kodet logikken der gør at en operatør-admin kan begynde at oprette egne komponenter med dertilhørende indstillinger, uden at behøves kode noget selv... uha... det bliver lækkert, der er dog et stykke vej endnu vil jeg mene.

Jeg har også brugt lidt tid på at forbedre UX på en af de andre moduler (process designer), da den trængte lidt til det, og skal vises frem i løbet af uge 7 (af min praktik)... det er en af de arbejdsopgaver jeg er bedst til, og helt klart en af de opgaver jeg også finder utrolig vigtigt, hvad nytter det man har jordens mest avancerede værktøj, hvis det er for kompliceret og besværligt at bruge?

Ugens rapport blev lidt kort... men nu skal der kodes.

Kommentar / Feedback