Med lidt over 20 app-projekter i bagagen begynder vi nu at have et klart billede af processen og best-practice for app-udvikling.

Vi har delt processen op i 11 faser. Størstelen af de apps vi har udviklet har fulgt nedenstående forløb.

1) Indledende møde(r)

Her mødes vi med kunden og kortlægger behovet og designer app’en. Det afgørende er her, at få skåret konceptet til og fokusere på hvad der er helt afgørende for app’en. I nogle projekter ligger konceptet helt fast når kunden tager fat i os, i andre projekter er vi med i denne fase.

2) Prototype

Som en del af tilbuddet laver vi typisk en prototype i form af en wireframe og en beskrivelse af app’en. Formålet er forventningsafstemning – så kunden ved præcist hvad de får og så vi som leverandør ved præcist hvad vi skal levere. Wireframen er også god til at teste konceptet. Selvfølgelig bliver man klogere i løbet af selve udviklingen, og vil ofte variere en smule i forhold til den første prototype. Men, dette er langt mindre end ved f.eks. webprojekter, fordi app-projekter er langt mindre og skal skæres meget mere til.

I lidt større projekter sender vi prototypen frem til kunden et par gange og korrigerer denne i forhold til feedbacken fra kunden.

3) Test af API/WebServices

De fleste apps trækker på data fra et eksisterende IT-system. Rent teknisk forudsætter dette et API – typisk i form af en eller flere WebServices. API eller WebServices giver et IT-system adgang til at hente eller gemme data i et andet system.

Ofte findes API’erne ikke og skal udvikles som del af app-projektet.

4) Tilbud

På baggrund af de første tre faser sender vi et samlet tilbud.

5) Go eller No-Go

Kunden vurderer om business casen er god og giver et Go eller et No-Go.

6) Grafisk design

Herefter starter den faktiske udvikling. Første fase er typisk det grafiske design. Dette er igen en forfinelse af prototypen – og kunden vil altid skulle godkende det grafiske design.

7) Programmering

Vi programmerer app’en. De fleste apps består af helt adskilte dele – typisk forskellige faneblade – og disse laves et for et. Er projektet et større projekt plejer vi at lave møder hvor de enkelte del-resultater præsenteres.

Koden laves ud fra vores “Coding Conventions”. Da vi næsten altid er to programmører på projektet laves der løbende code review. Der er mange fordele ved at programmere ud fra et fast sæt retningslinjer – koden bliver homogen, nemmere at dele, kommenteret og dokumenteret og kvaliteten bliver højere.

8) Præsentation

Når app’en er stort set klar foretrækker vi at præsenterer app’en for kunden på et møde. Her gennemgåes alle detaljer i app’en og app’en præsenteres både på de forskellige devices og i en simulator.

Dette møder munder typisk ud i en række småjusteringer.

9) Beta

På baggrund af præsentationsmødet justerer vi app’en til og sender derefter en beta-version til udvalgte betatestere hos kunden. Her skal app’en testes i den virkelige verden og i den kontekst hvor app’en skal bruges.

Dette fører typisk også til en række småjusteringer, som så rettes.

10) Release

App’en er nu klar til release. Til denne release skal der udarbejdes en beskrivelse og billeder til AppStore – og derefter sendes app’en til godkendelse hos Apple. Godkendelsen tager typisk en til to uger. Vi har endnu ikke fået en app afvist.

11) Markedsføring

Når app’en er uploadet til AppStore skal den markedsføres. Markedsføringen skal selvfølgelig tilpasses målgruppen og er forskellig fra app til app. I nogle projekter deltager vi ikke i markedsføringen – i andre projekter hjælper vi bl.a. til med PR og rådgivning.

Milepæle

Processen beskrevet ovenfor har fem milespæle, hvor kunden præsenteres for et delresultat som skal godkendes:

A. Wireframe
B. Tilbud
C. Grafisk design
D. Præsentation af alpha-version
E. Beta-version

Det er vigtigt at kunden prioriterer disse milepæle og tager sig tid til gå ind i processen. Som I alle andre IT-projekter, er det mest effektivt at korrigere retningen for projektet tidligt i forløbet.

Så, hvis der skal være en morale i dette blog-indlæg, så er det at tid brugt på disse fem milepæle eller “gates” er givet godt ud for kunden. Især ved wireframe og grafisk design. Vis wireframen til kollegaer eller til mulige brugere, brug tid på at tænke brugssituationen helt igennem ud fra kravspecifikationen i tilbuddet eller ud fra det grafiske design. Det betaler sig.