App-releaser er ikke som andre releaser

Apper er ikke bare apper.

Denne artikkelen tar kun for seg native apper. Release av web apper og hybrid apper behandles ikke her.

 

Det som er spesielt når man skal ha apper ut til folket, er at det ikke bare er ên release. 
Som oftest så er det flere, da de fleste apper har både iOS-versjoner (iPhone) og Android-versjoner (Samsung, LG, Sony og alle de andre). Noen har sågar også en WindowsPhone-versjon. Appene spiller sammen med baksystemene, altså de delene av funksjonaliteten som ligger på servere.

Man kan dermed få alle mulige kombinasjonene av koordinerte releaser av alt fra én til alle av disse:

Android iOS Baksystemer

 

Det varierer hvor tett baksystemutviklerne jobber med app-utviklerne. Og hvor tett app-utviklerne på ên plattform jobber med app-utviklerne på de andre app-plattformene. I noen tilfeller kan f.eks. Android-appen "stikke avgårde" og få inn ny funksjonalitet lenge før iPhone-appen. Eller omvendt.

Det betyr, at selv om avhengigheten mellom app-plattformene ikke er stor, så vil det som regel være avgjørende at release av apper og baksystemer koordineres.

Ved koordinerte releaser av både apper og baksystemer er det mest hensiktsmessig at baksystemene rulles ut før nyeste app-versjon fordi:

  • De nye appene kan ha avhengigheter til endringer eller ny funksjonalitet i baksystemene.
  • Det oppdaterte baksystemet skal fungere med de app-versjonene som allerede er i omløp. Skulle det dukke opp alvorlige problemer under eller rett etter prod-releasen av baksystemet, så kan man utsette app-releasene til baksystemene har nådd ønsket tilstand. Dette kan være problemer med baksystemet som sådan eller kompabilitetsproblemer mot en eller flere av de eldre versjonene av appene.
  • Appene testes mot den relevante versjonen av baksystemene. Det er avgjørende at den versjonen av baksystemet som appene er testet mot, ligger i prod når appene slippes. Man må derfor allerede når man planlegger testingen av appene, vite hvilke versjoner av baksystemene man skal forholde seg til.
  • Man får litt tid til å teste ut de nye versjonene av app'ene i prod mot det nyeste baksystemet før app'ene gjøres tilgjengelige i app-butikkene. Heri inkludert oppgraderingstester. Man kan bl.a. involvere betagrupper. Betagrupper er et antall frivillige brukere som får prodversjon av appene litt før planlagt release.

Native apper rulles ut gjennom Google Play Store og Apple's App Store. Dette kan gjøres gradvis:

  • For Android ved at man først f.eks. tilgjengeliggjør den nye appen for 10% av brukerne, deretter de neste 40% dagen etter osv. Man har dermed mulighet til å stoppe utrullingen før alle har tilgang, hvis det skulle vise seg å være nødvendig.
  • For iOS kan man ha gradvis utrulling i faser (phased release) til de som har på automatisk oppdatering. Det skjer etter et fast mønster, som starter på 1% første dag og via en tilnærmet dobling pr dag (1%-2%-5%-10%-20%-50%-100%) ender opp på 100% automatisk oppdatering i løpet av 7 dager. Den manuelle oppdateringen påvirkes ikke av dette, så alle vil kunne se den nye versjonen i App Store og kunne laste ned denne fra dag 1. Man kan sette den gradvise utrullingen på pause, men fortsatt vil manuell oppdatering være tilgjengelig.

For apper er det aldri snakk om tilbakerulling. Man kan i krisesituasjoner kun ta appen ut av app-butikken, og så fort som mulig komme med en ny og bedre versjon.

Når man planlegger releasedato så må man også ta høyde for at appen skal godkjennes av "butikksjefen" før den legges i Google Play Store og Apple's App Store. Apple er noe mer rigide og deres godkjenningsprosess tar lenger tid, i verste fall opp mot en uke. Mens det for Google vanligvis tar 2 minutter.

Retrospektiv på under timen

Retrospektiv i løpet av 1 time, er det mulig?


Jeg skulle fasilitere et retrospektivmøte for en prosjektfase hos en kunde.
Retrospektivet skulle omhandle et tidsrom på 3 uker, og vi skulle være 7 deltagere.
Etter at jeg hadde sendt ut innkallingene oppdaget jeg at jeg hadde booket bare 1 time. Min første reaksjon var å forlenge møtet, men hvorfor ikke ta det som en utfordring? Tross alt så har vi vel alle vært med på retrospektivmøter som drar ut i det lange og breie uten at resultatet blir så mye bedre av den grunn.
Målet med retrospektiv er som kjent å gi innspill til kontinuerlig forbedring. Det var viktig å ikke miste det av syne i iveren etter å presse møtet inn på 1 time.

Jeg skjønte raskt at for at dette skulle lykkes måtte forberedelsene være gode.

Forberedelser:

I innkallingen hadde jeg lagt ved en veldig kort tekstlig versjon av tidslinjen for å få i gang tankeprosessene allerede før møtet.
Jeg googlet litt for å finne inspirasjon, men fant ingen som promoterte én-times retrospektiver. De fleste oppskriftene var relativt tidskrevende. Dog så fant jeg en oppskrift som Johannes Brodwall hadde prøvd ut på Smidig 2010. Og da spesielt noe han kalte "Tenke og svare", "3x3 spørsmål", "Snakke og lytte". Jeg så jo fort at dette ville ta altfor lang tid, men hva om vi tok ut deler av disse og gjorde alt på en gang?
 
Ofte har jeg opplevd at man har gruppert i "Hva var bra?" og "Hva var ikke så bra?" og "Forberdinger". Jeg ønsket et annet fokus enn dette, så der valgte jeg "Høydepunkter" og "Overraskelser", som skulle gi observasjoner fra deltagerne uten at de trengte å sette pluss eller minus foran. Jeg ønsket også at deltagerne skulle se framover, og da ble "Erfaringer" en fin kategori.

Så da puttet jeg alt dette i gryta og gjorde det kokkene kaller for reduksjon, og det hele kokte ned til en tabell med disse overskriftene:

 

Med Høydepunkter/Overraskelser/Erfaringer blir tankeprosessen litt annerledes og ikke nødvendigvis så polarisert.
 
For ytterligere å hjelpe tankeprosessene i gang forberedte jeg en ikke utfyllende stikkordliste som inneholdt temaer som:

  • Ressurssituasjon
  • Rapportering
  • Kommunikasjon
  • Avhengigheter
  • Samarbeid
  • Oppstart
  • Avslutning
  • Arbeidsbelastning
  • Arbeidsfordeling
  • Utstyr/verktøy
  • Oppfølging
  • Trivsel

I tillegg listet jeg opp noen stikkord som var spesifikke for dette retrospektivet.
 
Jeg plukket med meg skrivesaker og gule lapper og møtte opp på møterommet 10 minutter før start. (Jeg hadde passet på å booke rommet fra 15 minutter før selve møtet).

Whiteboard:
Jeg tegnet opp en tidslinje og skrev på start og stoppdatoer.
Jeg skrev opp de 3 kategoriene i et "skjema" der man kunne henge lappene.
 
Flipover:
Skrev opp stikkordeksemplene på et ark.

 

Gjennomføring

Da deltagerne var på plass ønsket jeg velkommen, og siden ikke alle hadde vært med på retrospektivmøter før, så forklarte jeg hensikten med møtet. Vi hadde en liten dialog rundt dette, slik at alle forstod og var enige om opplegget.
Så forklarte jeg konseptet med tidslinjen og fikk med alle på den. Tidslinjen er ei rett linje, som tegnes opp på tavla/flipoveren, for å illustrere den tidsperioden som retrospektivmøtet behandler. En kalender der viktige hendelser plottes inn. Hensikten er å få opp et visuelt bilde av forløpet, til hjelp i tankeprosessene med å hente fram innspill.

Når så tidslinjen var på plass og vi alle var enige om innholdet, forklarte jeg opplegget med å bruke lapper for å komme med innspill. Jeg forklarte så de tre kategoriene og gikk fort gjennom stikkordlista på flipover.
Så fikk alle 10 minutter til å komme med lapper. Når alle var ferdige med å skrive lapper etter en 7-8 minutter, så var det tid for få disse opp på tavla. Det ble gjort slik at man gikk opp etter tur, plasserte én og én lapp i en av de tre kategoriene, og framførte en kort forklaring og begrunnelse.

Det ble produsert 35 lapper fordelt på

  • 17 høydepunkter
  • 8 overraskelser
  • 9 erfaringer.

Det ble så gjennomført en kort diskusjon som munnet ut i forslag til tiltak. Forslagene ble gruppert i 6 temaer. Det var viktig å komme fram til temaer alle var enige om.

Eksempel: Gruppering i temaer:

Tema

Beskrivelse

Kravsporbarhet

Kravene ligger for det meste i Excel-filer. Har man kravene på plass i Jira kan man koble de sammen med testcaser og feilrapporter og med det få full spobarhet mellom disse, og en oversikt/indikasjon på hvordan testene dekker kravene.

Testdekning

Det er trolig noe redundans i testomfanget. Det vil trolig være nyttig å gå gjennom testene for å luke ut "duplikater".

Organisering av testcaser, testsykluser og prosjekter i Jira/Zephyr

Prisendringer bør trolig være egne prosjekter, med egne testsykluser. Testcasene bør i utgangspunktet være prosjektløse (og også egentlig produktløse), men knyttes mot kravene de tester, og legges i testsykluser for eksekvering.

Det trengs en utredning av dette.

Involvering av kundestøtte

Kundestøtte syntes det var veldig nyttig å være med, de bidro med ekstra kompetanse på flere områder, og de var en viktig suksessfaktor for å komme i mål med testingen. Bør gjentas.

Testmiljøer

Vi opplevde lite problemer med testmiljøene, men det var på håret at fluxkondensatoren hadde blitt en show stopper. Man bør etterstrebe at utstyret på lab'en til en hver tid er i orden. Pr i dag er det betalingsterminalen på fluxkondensatoren som ikke fungerer for test.

Testdata

Billettene ble organisert vha "skruebokser". Man bør ta en vurdering av hvilke billetter man ønsker å beholde for testing i andre sammenhenger. Man trenger isåfall en hylle eller plass i et skap for disse.

 

Jeg avsluttet møtet ved å gi alle sjansen til å komme med en sluttkommentar for å kvalitetssikre at vi var kommet i mål.
 
Det hele klokket inn på 55 minutter.

Photo by Gerome Viavant on Unsplash

Etterarbeid

Referatet ble gjort så enkelt som mulig med data om deltagere, tidspunkt og kort beskrivelse av gjennomføringen. Innholdet på lappene ble ført inn i "Høydepunkter/Overraskelser/Erfaringer"-tabellen.
Forbedringsforslagene (inkludert ting som var bra og som burde bevares) ble skrevet inn i en tabell med Tema og Beskrivelse.
Alt dette ble dokumentert i en wiki-side på intranettet. Alle deltagerne fikk så anledning til å kommentere på denne.
Så ble e-mail med link til wiki-siden sendt ut til alle interessentene.

Så, hva er det som er bra med dette?

Vi klarte å gjennomføre selve møtet på under én time, det er flere årsaker til det:

  1. Formen på møtet var klart definert på forhånd
  2. Forberedt og aktiv møteleder
  3. Gruppas sammensetning. Gruppa var jo ikke satt sammen for å fungere på retrospektivmøtet, men dette var en gruppe som jobbet effektivt gjennom hele prosjektperioden og uten de store fakter. Det ble lagt vekt på effektiv kommunikasjon og det preget også retrospektivmøtet.
  4. Prosjektet i seg selv var en suksess, noe som i seg selv bidro til å redusere omfanget på retrospektivet.

Punkt 3 og 4 er man ikke herre over, men jeg tror det først fremst er punkt 1 og 2 som danner grunnlaget for å lykkes med denne type retrospektiv.

Retrospektivmøtet resulterte  i forslag til tiltak gruppert innenfor områder som man ble enige om i løpet av møtet. Disse dannet i neste omgang et bra grunnlag for å definere og tildele konkrete forbedringsoppgaver.

Så hva er det med formen som gjør dette effektivt?

Jeg tror at "Høydepunkter/Overraskelser/Erfaringer"-kategoriene løser opp og gir retrospektivet et mer positivt preg. Legg merke til at ingen av kategoriene er negativt ladet i utgangspunktet:

  • Høydepunkter er den mest positive kategorien, her kom det innspill på ting som fungerte etter forventningene fordi noen hadde gjort en bra innsats.
  • Overraskelser: Her kom det både negative og positive overraskelser. Det mest tydelige skillet på overraskelser og erfaringer er at overraskelsene er hendelser som vil kunne overraske også neste gang de skjer. Det vil si at man kanskje ikke helt skjønner hva som er årsaken.
  • Erfaringer er hendelser som man har mer innsikt i. Både at ting fungerte fordi man gjorde det på en spesiell måte, eller at noe ikke fungerte fordi man hadde gjort slik og slik, eller fordi at man ikke hadde gjort noe for at det skulle fungere i det hele tatt.

 

Her snakker vi altså om nyanser, noe som dette eksempelet illustrerer:

Høydepunkter Overraskelser Erfaringer

"Godt planlagt med ressurser og nødvendig utstyr."

(Her synes en tester at det er gjort gode forberedelser.)

"Lite problemer med testmiljøene."

(Her er testleder overrasket over hvor lite trøbbel man hadde med miljøene.)

"Sikre at testmiljøer er 100% oppe før testing."

(Her ønsker en tester å videreføre og ytterligere forbedre forberedelsesaktivitetene.)

 Testmiljøer pekte seg ut som ett av temaene og munnet ut i følgende forslag til tiltak:
 "Vi opplevde lite problemer med testmiljøene, men det var på håret at fluxkondesatoren hadde blitt en showstopper. Man bør etterstrebe at utstyret på lab'en til en hver tid er i orden. Pr i dag er det fluxkondesatoren som ikke fungerer for test."

Møteledelse: Kontekst:
Sparte totaltid ved å ha møterommet og tavlene klare når møtedeltagerne møtte opp. I en setting der prosjektgjennomføringen har mange utfordringer, eller en setting der det er flere motstridende interesser, vil det være mer utfordrende og heller ikke hensiktsmessig å gjennomføre et retrospektivmøte på tider ned mot en time.
Hadde klar og konsis sesjon med innledende informasjon. Ved å forberede seg godt kan man i en velfungerende organisasjon  kunne gjennomføre retrospektivmøtet i et litt høyere tempo, noe som vil  kunne heve kvaliteten. Høyere tempo fører til mer engasjement, som igjen kan føre til ærligere tilbakemeldinger.
Satte av 10 minutter til å skrive lapper og overholdt tiden.  
Passet på at tempoet ikke dabbet av  under plasseringen av lappene på tavla.  
Hadde ingen lappeflytting på tavla under diskusjonen og seansen med å komme opp med temaer for tiltak.  
Lot deltagerne få diskutere fritt, men hjalp til med å komme opp med navn på temaer som materialiserte seg, og var med på å formulere tiltak.     
Hadde ingen egen agenda som måtte landes i løpet av møtet, men brukte litt spissformuleringer for å provosere på en forsiktig måte.  

 

Epilog - gjennomføring av forslag til tiltak

For dette retrospektivarbeidet fikk jeg ikke mulighet til å følge opp forbedringsarbeidet, men den måten jeg liker å gjøre det på er å legge ut forbedringsforslagene som oppgaver i Jira. Oppgavene tildeles så personer som identifiseres som rett adressat for de forskjellige tiltakene. Referatet fra retrospektivmøtet legges i Confluence og lages slik at Jira-sakene synes i tabellen over tiltak. Status på sakene oppdateres da dynamisk etter hvert som det er progress i sakene.
Etter hvert som det gjennomføres flere retrospektivmøter, kan man samle alle sakene derfra på en Confluence-side koblet mot Jira.
Lista følges deretter opp i et dertil egnet forum som har ansvaret for kontinuerlig forbedring i teamet/prosjektet/organisasjonen.
 
Som alle vet så er det det å få gjennomført tiltakene som er den vanskelige delen. Derfor er det viktig at oppgavene delegeres og følges opp. Og at de som har vært med på å identifisere problemene og tiltakene både involveres og får informasjon om progresjonen i forbedringsarbeidet.

 

Karriere

Brenner du for fagområdet test? Verdsetter du fleksibilitet, faglig fellesskap og utvikling? Promis Qualify er på jakt etter flere dyktige senior testledere.

 

Les mer om jobb i Promis Qualify