OmfångVi bestämmer tillsammans vilket omfång (scope); vilka features vi ska ta fram. Detta blir vår backlog. 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.
PrototypEn klickbar prototyp skapas för de features som ingår in MVP:n. När ni godkänt denna går vi vidare. 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.
1 vecka iterationFörsta veckan utveckling med fokus på er viktigaste funktion. Utan databas eller inloggning. 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. 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.
Leverans POCVi presenterar en fungerande app Proof of Concept. 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.
Backend och publiceringBackend – 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.
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.
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.
- 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 och 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 recenstion och retroperspektiv
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.
Låter det intressant?
Kontakta oss för aktuellt pris på kravställning av app så hjälper vi dig påbörja din app-resa!
