Process
Processen att bygga en app

Vi skapar er app med några enkla steg i nära samarbete där du hålls informerad och kan prioritera arbetet.

Omfång
OmfångVi bestämmer tillsammans vilket omfång (scope); vilka features vi ska ta fram. Detta blir vår backlog
Prototyp
PrototypEn klickbar prototyp skapas för de features som ingår in MVP:n. När ni godkänt denna går vi vidare
1 vecka iteration
1 vecka iterationFörsta veckan utveckling med fokus på er viktigaste funktion. Utan databas eller inloggning.
Leverans POC
Leverans POCVi presenterar en fungerande app Proof of Concept
Projektet
ProjektetVi fortsätter att utveckla nya features tills vi nått dem uppsatta målen, Nu tar vi fram appen tillsammans!
Nedan följer en detaljerad beskrivning av processen som Crossplatform (CPS) åtar sig när vi bygger er app / webb.

Kravställning och omfång

Vid slutet av första iterationen (sprint review) presenteras appen för Klienten via t.ex. via skärmdelning. Klienten får möjlighet att prioritera om kraven.

Grafisk prototyp

Vid slutet av första iterationen (sprint review) presenteras appen för er via t.ex. via skärmdelning. Ni får möjlighet att prioritera om kraven.

1 vecka iteration

En första iteration (sprint) genomförs där appens bas sätts upp, som navigation, tema, dokumentation och tester. Sedan påbörjar CPS utvecklingen av de första funktionerna i prioriteringsordning.

Första leveransen

Vid slutet av första iterationen (sprint review) presenteras appen för Klienten via t.ex. via skärmdelning. Klienten får möjlighet att prioritera om kraven.

Projektet

CPS fullföljer kraven för att uppnå MVP och leverera till butik / moln. Klienten blir uppdaterad veckovis och kan påverka prioriteringen under hela kontraktstiden.

Publicering

Appen byggs för Android och iOS och publiceras för testning (Play Store Beta / Test Flight). För att kunna leverera appen ska Klienten ha förberett konton i App / Play Store där appen kan laddas upp. CPS kan hjälpa klienten skapa dessa konton. När Klienten testat och godkänt appens funktionalitet kan appen publiceras publikt i respektive butik. I detta läge anses CPS uppdrag fullföljt.

Backend - databas

Backend – databas CPS kopplar appen mot ett databaslager, som CPS äger. Om det är CPS som utvecklar databas och webbtjänster för appen att kommunicera med så tillhandahåller CPS molntjänster för dessa under kontraktstiden. Efter kontraktstiden kan CPS fortsätta leverera molntjänster om detta etableras i avtalet. Annars förväntas Klienten tillhandhålla konton för detta som kan användas i produktion. CPS assisterar i processen att skapa dessa konton.

HI-FI design

Om Klienten tillhandahåller appens grafiska utseende förväntas detta levereras i tid som användbara resurser, typsnitt och färgkartor, så att CPS utvecklare kan implementera detta.

Kvalitet och produktivitet

Digitalisering sker snabbt och ofta med flera risker. Dessa kan minskas genom att påtvinga rutiner hos alla medlemmar i projektet. Dessa rutiner ett krav för att alla utvecklare ska vara utbytbara och för att en PM eller produktägare ska kunna utvärdera implementationen.

DevOps

När projektet skapas sätts även DevOps-relaterade system upp för att skapa ett säkert och kvalitativt flöde.
  • Kodprinciper – starkt GIT-flöde, unifierad stil, arkitektur och verktyg. Dokumenteras i ReadMe-dokumentet.
  • Kodserver (source control) – all kod lagras säkert med versionshistorik (GIT), branch protection och analys av säkerhetsrisker som utdaterade paket. o
    • Kodrecension (code reviews) – all ny kod recenseras av en senior utvecklare / manager för att säkerställa att alla principer följs. Ingen kod kan föras in i huvudkoden (master) utan kodrecension.
  • Testning – automatiska tester i byggsteg (CI) och testdriven utveckling.
  • Dokumentation – alla förändringar, som nya funktioner, integrationer och tredjepartsbibliotek dokumenteras i ReadMe-dokumentet och/eller kod-dokumentation..
  • Förändringar (change management) – förändringar i produkten verifieras mot kravspecifikation, användarbarhet och prestandakrav. Påverkan på befintlig funktionalitet utvärderas.
  • Leverans – byggsystemen (CD) paketerar produkten oberoende utvecklarnas miljöer och levererar till moln / butiker automatiskt om alla tester passerar.
    • Testmiljö (staging) – nya versioner testas i en säker miljö utan att påverka produktionsanvändare eller databaser.
    • Release: när en testmiljö verifierats kan den släppas mot produktion.
      För en app användes ofta stegvis utrullning för att inte påverka alla användare samtidigt.

Agile & Scrum

Genom att dela upp kraven i features och arbetet i iterationer är projektet öppet för förändring och produkten levereras i tid med högst prioriterade kraven först.

Backlog

När kraven har prioriterats kan de organiseras upp, som mappar, i nivåer;
  • Epic: globala krav som är för stora för en Feature.
  • Feature: större funktioner som är för stora för en User Story.
  • User Story: beskrivning av användarens behov (otekniskt), med krav på acceptans.
  • Task: uppgift som ska utföras. Kan avse tester, kodning, design, krav, eller dokumentation.

Sprint-planering och iterationer

Under sprint-planering klargör projektägaren mål för iterationen (1-2 veckor) och projektledaren (scrum master) skapar uppgifter (task, ovan). Dessa ska vara estimerade, så antalet uppgifter inte överstiger kapaciteten i teamet för perioden.

Standup

En daglig genomgång där man ”står upp” för att inte dra ut på tiden. Här ska inte detaljerade frågor tas upp eller ifrågasätta kraven. Istället redovisar varje medlem kort:
  • Vad arbetade jag med igår?
  • Vad ska jag göra idag?
  • Vad blockerar eventuellt mitt arbete?

Sprint recension och retrospektiv

I slutet av en sprint utvärderas resultatet;
  • Förstod utvecklarna uppgifterna? Var Tasks och Stories väl beskrivna?
  • Gick det att utföra uppgifterna i tid? Borde uppgiften ha brutits ned i mindre delar?
  • Förstår alla projektets värderingar och principer? Går de att efterfölja?
  • Upprätthöll koden kvalitet, recenserades den ordentligt? Eventuella nya krav har förts in i backlog och kan prioriteras in i nästa sprint om lämpligt.

Testning

Alla nya funktioner utvärderas i en säker testmiljö innan de förs in produktion. Tester kan innefatta automatiska kodtester och automatiska eller manuella testprotokoll där systemets funktionalitet verifieras. Detta försäkrar att ingen ny funktionalitet har sönder befintlig funktionalitet.