onsdag den 27. februar 2013

Rapid development – det bløde ler og den hårde sten

I spændingsfeltet mellem total frihed og total begrænsning.












Som beskrevet i et tidligere indlæg omkring rapidbegrebet, kan man udover at tale om rapid content (hurtig udvikling af indhold) og rapid learning (hurtig indlæring) også tale om rapid development.  Det vil sige hurtig og effektiv implementering af kurset, når først manuskriptet ligger klar. Det kan også sagtens lade sig gøre, men inden jeg vil beskrive forudsætningerne herfor, er der behov for en lille begrebsafklaring. Mange associerer nemlig rapid development med de såkaldte nemme udviklingsværktøjer – dem som har en lav indlæringskurve. Det sker ud fra en logikken, at hvis det er nemt at sætte op, må det også være hurtigt. Det er desværre ikke rigtigt, fordi der snydes på vægten. For at forstå, hvorfor det hænger sådan sammen, må man kigge på det bløde ler og den hårde sten.

Alle udviklingsværktøjer befinder sig et sted mellem det bløde ler og den hårde sten – mellem stor frihed og meget begrænset udfoldelsesmuligheder. Begge former giver hver sine fordele som beskrives i nedenstående skema.










Når man betragter skemaet virker situationen uløselig. I en ideel verden ville ønsket være, at man både kunne få stor fleksibilitet og hurtig udvikling på samme tid. Målet må jo altid være, at få så stor en grad af rapid learning ind i produktet som muligt. Derfor er det at give køb på funktionalitet sjældent vejen frem. Tilsvarende er ressourcerne aldrig uendelige, så man bliver nødt til at finde en måde, hvorved processen kan effektiviseres. Min påstand er, at dette godt kan lade sig gøre, hvis man følger to grundlæggende råd.

Anvend altid skabeloner – formidlingsformer der kan genbruges og udvides efter behov. 

Værktøjet til udvikling af disse kan være mange, men det skal have en sådan fleksibilitet, at du kan få løst de læringsmæssige udfordringer, du står overfor. I den forbindelse betyder det mindre, at der bruges ekstra tid på arbejdet. Den kommer igen senere.  Det er en fordel, hvis værktøjet har en skarp adskillelse mellem data og kode, således at processen med at implementere storyboardet senere bliver enkel. Det betyder, at der ALTID skal udvikles en prototype inden storyboardprocessen påbegyndes. 

Sørg for, at der altid er overensstemmelse mellem skabeloner og storyboard.

Forholdet mellem prototype og storybord må aldrig være abstrakt. Ideen er, at gøre vejen fra indhold til produkt konkret og direkte. Det gør det enkelt for indholdsudvikleren at skrive og enkelt for programmøren at udvikle. 

Ingen kommentarer:

Send en kommentar