Användbarhet

Hur man enkelt testar användbarhet

Vid mjukvaruutveckling kan man lätt bli hemmablind, man kan inte bedöma om applikationen är användarvänlig eller inte. Man har jobbat med den länge och lärt sig alla tillkortakommanden. Då är det bra att användbarhetstesta den på nya användare. Jag har provat en metod användbarhetstestning med lyckat resultat och vill dela med mig av mina erfarenheter för att du också ska kunna leverera mer användbara applikationer.

Metoden består av fyra faser, Förberedelse, Utförande, Utvärdering och Återkoppling.

Testa användbarhet

Förberedelse

Planera utvärderingstidpunkt. Välj ut ett antal försökspersoner, användare. Under utförandet vill man att varje användare skall kunna observeras av minst en observatör så välj inte för många.

Prova att utföra scenarierna själva, förstår ni dem? Fungerar mjukvaran eller måste man göra någon work-around någonstans? Tänk på att kommunicera det sedan.Tänk ut och skriv ned ett antal scenarion eller uppgifter som användarna skall utföra. Tänk på att de skall vara målformulerade, beskriv inte i detalj hur användaren ska göra, utan vilket resultat hon ska nå. Ni vill utvärdera om hon förstår hur man når resultatet.

Utförande

När användarna kommer, förklara metoden för dem. Om det behövs, ge dem en kort utbildning i systemet eller applikationen.

Låt nu varje försöksperson utföra scenarierna eller uppgifterna. Observatören ska nu sitta bredvid och observera personen. Användaren ska tänka högt, detta kan kännas lite pinsamt i början. Förklara syftet och påminn om hon glömmer, det är vanligt.

Notera nu var användaren tvekar, vad verkar svårt? Var hakar hon upp sig? Var gör hon fel?

Bit dig (om du är observatör) i tungan och svara inte på frågor eller hjälp till. Gör det enbart i nödfall, då användaren har kört fast helt och hållet. Notera då detta.

Utvärdering

När alla par, eller grupper har kört klart är det dags för utvärdering. Observatören går då igenom sina anteckningar med användaren och de skriver upp de viktigaste problemen på gula klisterlappar. Om de har lösning på problemen skriver de upp dem också men det är inte ett krav.

När grupperna är klara med denna fas, får varje grupp gå fram och sätta upp sina lappar, maximera antalet så att det inte tar för lång tid. De presenterar varje problem för de övriga i prioritetsordning.

Återkoppling

Produktägarna eller motsvarande tar nu åt sig av de prioriterade problem-listorna och förbättringsförslag. Vissa lappar blir till nya User Stories och buggar medans andra kanske kasseras.

Det är viktigt att återkoppla till användarna vad man kommer göra åt deras synpunkter, antingen direkt eller visa på resultat i nästa användarträff.

Lycka till och hör av dig om du har frågor eller kommentarer.

 

Bild med tillstånd av  ”hyena reality” / FreeDigitalPhotos.net

Uncategorized

Tips vid övergång från Jira till TFS – använd History för omappade fält

jira_logo_landing

När man ska byta från ett ärendehanteringssystem till ett annat uppstår alltid problem hur datat ska konverteras. I mitt fall skulle jag konvertera knappt hundra User Stories från Jira till Team Foundation Server 2012 (TFS). Jag stötte på problem då vissa fält som finns i Jira inte fanns i TFS, till saken hör att vi inte vill lägga till extra fält i TFS:en utan hålla den så ren som möjligt med avseende på anpassningar. Allt för att underlätta uppgraderingar och homogent arbete mellan projekt.

För att konvertera data använde jag mig av Excel som mellanlagringsplats. Jira kan nämligen exportera till Excel och TFS kan importera från Excel. Ett problem är dock att vissa fält i TFS excel är read-only. MEN, det går att lägga till data till dessa fält från excel, inte att ändra det senare. Då måste man in i web-gränssnittet eller Visual Studio.

I mitt fall vill jag konvertera vem som skrivit storyn från början, vilket ID den hade i Jira, och vilken Component den hade i Jira. Då gjorde jag helt enkelt så att när jag mappade mina kolumner i excel så lät jag Jira-ID:et skrivas i TFS History kolumn. Sedan publicerade jag datat till TFS. Nu hade ärendet skapats, andra relevanta fält hade jag givetvis också kopierat in, titel, beskrivning osv men dessa var triviala då de fanns i båda systemen.

Visual-Studio-Team-Foundation-ServerFör att få över nästa fält, tex vem som skapat Jira-ärendet, kopierar jag detta data till History-kolumnen i excel, som nu är tömd, och publicerar datat igen. Nu visar det sig att vem som skapat ärendet läggs till ärendet som en kommentar, under History. Fullt acceptabelt och användbart.

Scrum

Behövs projektledaren i Scrum? Och vilken roll ska hon i så fall ha?

Jag får ofta frågan: Vilken roll ska projektledaren ha i Scrum? Jag brukar svara: Det beror på (det vanliga konsultsvaret).

I en blog på Info-Q ställer Shane Hastie sig frågan om en projektledare kan vara SrumMaster? Här är mina egna reflektioner i frågan:

I den perfekta världen med Agile och Scrum så behövs inte projektledaren. Då har vi team som levererar produkter efter varje sprint. Produktägaren jobbar med backloggen och ScrumMastern förbättrar processen, en projektledare behövs således inte. Tyvärr går det inte alltid att komma dit med detsamma när man inför Scrum i en organisation, man har en befintlig organisation med befintliga roller och befintliga processer. Ofta ser jag att man ”bara” inför Scrum på produktutvecklingssidan. Leverans och driftorganisationen är kanske andra avdelningar med andra chefer och förändringsarbetet har inte kommit lika långt där.

Jag uppmuntrar Kanbans synsätt: respektera roller och processer initialt och förbättra sedan. Därför kommer det finnas aktiviteter som en projektledare behöver göra, planera driftsättning, äska pengar till aktiviteter, osv.

Så, en projektledare kan behövas, trots att organisationen har börjat använda Scrum. Dock ska man jobba kontinuerligt för att ta bort behovet av projektledaren genom att göra hela organisationen agil och scrum-orienterad men fram tills dess så kan rollen behövas. Organisationen skall hela tiden sträva efter att kunna leverera ny mjukvara så ofta kunden/marknaden är beredd att ta emot den (output kadens i Kanban).

Men vilken av rollerna Produktägare eller ScrumMaster ska projektledaren ta då, om han måste ta en av dem? Det är då jag svarar att det beror på och det beror på följande:

Projektledare bör vara Produktägare om:

  • Hon är kunnig om produkten och verkar som en proxy-produktägare genom att samla in krav från övriga stakeholders. Det kanske är hennes uppgift redan som projektledare att samla in och dokumentera kraven.
  • Är en auktoritär projektledare som helst vill detaljstyra teamet. Då passar hon inte som ScrumMaster utan teamet behöver en annan ScrumMaster som skyddar teamet från denna person.

Projektledaren bör vara ScrumMaster om:

  • Hon gillar metoder och processer. Hon vill hela tiden hitta bättre och smartare sätt att jobba.
  • Som projekledare är hon av den ”tjänande typen” dvs hon såg till att undanröja hinder för att teamet skulle kunna göra sitt jobb.
  • Hon är inte speciellt insatt i produktens funktioner eller prestanda, dvs hon är mer intresserad av Hur än Vad.

Min erfarenhet är att garvade projektledare som jobbat länge på företaget passar bäst som Produktägare medans nya projektledare som inte jobbat länge eller är konsulter passar bäst som ScrumMaster, om de har intresse av det förstås. Det är oftast lättare att hitta en utvecklare eller testare i teamet som kan vara en bra ScrumMaster.

 

 

Lean

Vad är Lean? Egentligen? Presentation från Agila Sverige 2012.

Jag fick förmånen att hålla en presentation på Agila Sverige 2012 med titeln ”Vad är lean? Egentligen?”. Presentationen bygger på boken Vad är lean? av Niklas Modig och Pär Åhlström.

Slutsatsen är att lean är en verksamhetsstrategi som syftar till att fokusera på flödeseffektivitet (istället för resurseffektivitet) och att kontinuerligt förbättra denna.

Presentationen finns här.

Agile

Facebooks releaseteam klickar Ogilla för klantiga utvecklare

Ryan Paul på Ars Technica har gjort ett studiebesök hos Facebooks release team. Det är fascinerande att läsa hur de driftsätter mindre uppdateringar varje dag och större uppdateringar varje vecka. En av framgångsfaktorerna är att de har ett helt team för att bara driftsätta.

I artikeln beskrivs att Facebook-systemet huvudsakligen är skrivet i PHP som sedan kompileras till C++ och sedan till en 1.5 GB stor binär. Denna binär trycks sedan succesivt ut till alla servrar med hjälp av BitTorrent-teknik.

När det är dags för driftsättning ser teamledaren Chuck Rossi till att alla (!) utvecklare är stand-by på IRC. Om något går fel rättar man till det med detsamma. Man gör roll-back ytterst sällan, ”Reverting is for losers” säger Rossi.


Unlike

En annan intressant sak är att varje utvecklare har karma. Om man gör något bra stiger ens karma men gör man något dåligt sjunker den. Rossi klickar på sin ogilla-knapp när en utvecklare har ställt till det. ”Jag är den enda som har en ogilla-knapp”, säger han.

Scrum

Ron Jeffries skriver en Agil Encyklopedi

Den hedervärde XP-grundaren Ron Jeffries har påbörjat ett gediget arbete att skriva en Agil Encyklopedi. Projektet verkar väldigt lovande och idag finns det en bra beskrivning av Scrum. Sidan heter Agile Atlas och hittas på http://agileatlas.org.