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. 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 är en förutsättning för att alla utvecklare ska vara i fas och för att en PM eller produktägare ska kunna utvärdera implementationen. I dem många projekt aggerar du som kund produktägare. Vi rekommenderar att ni läser på om dem agila rollerna 🙌.
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.