Archive for november, 2011

Nya webben, utvecklingsprocessen

torsdag, november 17th, 2011

I ett tidigare inlägg har vi skrivit om utvecklingsprocessen på Stockholms stadsbiblioteks virtuella enhet för mobilwebben. Det börjar dra ihop sig även för desktopwebben, då dagens biblioteket.se ska bytas ut mot beta.biblioteket.

Beta-versionen av desktopwebben släpptes till personalen i juni, och till allmänheten i augusti/september. Sedan dess har vi tagit in ett hundratal kommentarer, önskemål och buggrapporter. Vi har genomfört tre omgångar av användningstester, se separat blogginlägg.  Hela virtuella enheten, i synnerhet utvecklingsteamet och redaktionen har också listat utvecklingspotential, buggar och önskemål.

Redan under arbetet med mobilwebben hade vi en så kallad product backlog (vanligen kallad backlog) som i scrum och agil utveckling helt enkelt är en lista med funktioner som önskas och utveckling som ska göras. Dessutom har vi ett felrapporteringssystem kallat trac. Varje rapport, varje utvecklingsönskemål inifrån organisationen och från allmänheten hamnar i dessa listor.  Fel eller önskemål åtgärdas inte i ordning de kommer in, utan i en prioritetsordning. Listorna innehåller flera hundra punkter och tillägg kommer hela tiden. Backloggen ägs av beställargruppen och dess ledare och är styrande för hela utvecklingsprocessen.

Beställargruppen utgörs av hela virtuella enheten. Var och en har en egen specialkompetens och ett eget nätverk med kontakter inom och utom organisation där de fångar upp önskemål och strömningar. Gruppen träffas strax före varje sprint och bestämmer vilka funktioner som ska prioriteras och vad man vill ha ut av kommande sprint.

Sprinten är vanligtvis tre veckor (ibland två) och inleds med en sprintplanering. Då träffas utvecklingsteamet (scrumteamet) och beställargruppens ledare för att planera sprintens arbete. Den detaljerade sprintplaneringen syftar till att bryta ner arbetet inom sprintens tre veckor i hanterbara delar dag för dag för utvecklingsteamet. Genom att separera planeringen från utförandet, kan utvecklarna fokusera på att utföra i stället för att växla mellan planering och utförande vilket är mindre effektivt.  Förutom att detta är scrummetodik, är det också klassisk GTD-metodik från David Allen. Det man går igenom under sprintplaneringen är:

  • Vilka resurser har vi under denna sprint? Egna och konsulttimmar, hur används de bäst?
  • Backloggen gås igenom i detalj, punkt för punkt. Vad har ändrats, vilka punkter kan anses vara avklarade? Vilka kan föras nedåt i prioriteringen? Så kallade stoppers identifieras, dvs utan dem fungerar det inte alls. Vilka punkter i backloggen är kritiska, vilka är stora punkter och vilka är små?
  • Trac gås också igenom i detalj, punkt för punkt. Varje ärende (kallad ticket) finns med här. En del kan stängas, avklarade. Även här görs prioriteringar och kvarvarande tickets som är blockers (samma som stoppers) eller kritiska förs över till backloggen.

Därefter sker själva utvecklingen och åtgärderna under sprinten, av utvecklingsteamet.

Vid sprintens slut görs en sprintdemo för hela enheten då all utveckling, alla fixar som gjorts under sprinten visas upp. Sedan börjar nästa sprint…

Användningstester

fredag, november 11th, 2011

Biblioteket.se kommer fram emot årsskiftet att bytas ut mot det som idag är beta.biblioteket.stockholm.se. För att verkligen involvera användarna och  se hur det fungerar i praktiken har vi på virtuella enheten i flera omgångar genomfört användningstester. Först gjorde vår konsultbyrå InUse tester i maj, i samband med att vi internt utbildade oss inom området. Därefter gjordes det tester i samband med beta-lanseringen till personal i juni.  I slutet av oktober har vi själva genomfört tester inför de sista utvecklinggsprintarna.

Att testa användningen av webbplatsen på riktiga användare är nödvändigt för att få reda på hur det fungerar vid normal användning. Målet är att användarna och deras upplevelse ska driva utvecklingen. Det är givetvis inte användarna som testas utan användning av webbplatsen, vilket vi också påpekar för testpersonerna.

Rekrytering av testpersoner, testpiloter som vi kallade dem, skedde i huvudsak via vanliga webbplatsen, biblioteket.se, genom en notis där man ombads anmäla sig om man var intresserad. Tidigare försök att rekrytera via affischer i biblioteken har varit helt resultatlösa, men genom notisen på webben har vi fått fler intresserade än vi behöver och har kunnat välja ut så att våra olika målgrupper har varit representerade. Några specialkompetenser har rekryterats genom handikapporganisationer.

Vi rekryterade totalt 7 personer till detta test. Av dessa hade en person  syn-funktionshinder, en var dyslektiker och övriga kom från våra andra  vanliga användargrupper: yngre, äldre, män, kvinnor, studerande etc.

Vi har genomfört testen i våra egna lokaler dagtid. Ett rum med en vanlig standarddator (PC) och lite plats för deltagarna är det enda som behövs. Har man personer med funktionshinder och de vanligen har något hjälpmedel underlättar det om de får använda sin egen dator med sina program. Våra hade till exempel egna datorer med skärmläsaren Jaws installerad. Eftersom den kostar cirka 1000$ har vi på biblioteket tyvärr inte den.

1 timme har vi beräknat för testerna, utom för de med funktionshinder där deras hjälpmedel har gjort att det tagit längre tid: uppåt två timmar.

Testet inleds lite socialt, med att man hämtar upp testpersonen vid överenskommen plats (man kommer inte in i våra lokaler själv utan problem) och installerar dem framför datorn med en kopp kaffe eller motsvarande. Handledaren är den som förklarar hur allt går till och driver testet framåt, och avbryter också övningar vid behov. Observatör och vittne presenteras, men sitter tysta. Efter testets slut får de möjlighet att kommentera eller ställa frågor.

Ett manus med scenarier och uppgifter har tagits fram i förväg och handledaren lotsar testpersonen vidare i detta. Frågorna kan vara av typen:

  • Du vill läsa en e-bok exempelvis Kinesen med Henning Mankell. Hitta rätt format för datorn
  • Du har hört att barn kan få hjälp med läxorna på biblioteket. Hitta ett bibliotek i närheten (av där du bor) som kan hjälpa till med detta och vilken tid denna service finns

Handledaren leder testet, men hjälper som sagt inte till att lösa frågorna. Om någon skulle köra fast totalt, kan man i vissa fall ställa ledande frågor (speciellt om man vill utforska en speciell funktion). Annars kan man också bryta om testpersonen kört fast och gå vidare till nästa fråga. När tiden är ute, efter en timme, avslutas testet även om alla frågor inte hunnits med. Testpersonen får ställa frågor och kan få en del svar. Vittne och observatör får här möjlighet att också komma med förtydligande frågor.

Direkt efter testet samlas handledare, observatör och vittne och går igenom vad som hände under testet Vilka var huvudpunkterna, var körde de speciellt fast etc. Observatören skriver snarast ut anteckningarna och alla i gruppen ser till att allt kommit med.

Efter alla tester gjorts samlas alla erfarenheter ihop i ett meningsfullt dokument. Vi har gjort helt vanliga google docs-anteckningar kring varje test som delats ut till alla i testgruppen och sedan har en sammanfattning gjorts i textformat. Dessutom har det sammantagna resultatet också presenterats i keynote-presentation (motsvarande powerpoint) bestående av skärmdumpar med pratbubblor, se bild överst på denna sida. Detta gör det enklare för personer som inte alls är insatta i själva testandet att förstå vilka användningsproblemen är.