Posts Tagged ‘beställargrupp’

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…