För några veckor sedan var jag och två av Aftonbladets produktägare på en kurs om produktägarrollen i Scrum. Kursledare var Jeff Patton, Scrum coach och usability expert. Jag förväntade mig en djupdykning i Scrum och produktägar-rollen men det avhandlades ganska snabbt. Kursen handlade till största del om ett moment  som inte finns definierat  i Scrum, fasen innan man har user stories till en Product backlog. Denna fas, från ide till backlog, kallar Patton m.fl. för  Product Discovery och tanken är att på ett strukturerat sätt ta en ide om en produkt
och stegvis bryta ner och förädla iden till något som Scrum-teamet kan använda för att bygga produkten.

Idea backlog

Arbetet börjar med en ide om en produkt eller en produktförbättring eller ett problem som behöver lösas. Runt denna ide ställer man följande frågor:

• Vad är det? En kort beskrivning av produkten eller produktegenskapen.
• För vem? Vem är användaren/köparen?
• Varför? Vad finns det för fördel för vår organisation att bygga denna produkt?

Produktmål

För att formulera ett mål börjar man med nuläge och önskat läge samt vad som skiljer dessa åt. Tex kan nuläge vara att användarna är missnöjda med produkten för att det är för krångligt att göra det man vill. Önskat läge är då att användarna är nöjda och att de upplever det enkelt att göra det som de vill. Detta är mätbart och testbart genom tester/intervjuer.

Enkla personas

Genom att fördjupa sig i ”För vem” kan vi skapa enkla personas som beskriver användarna. Förmodligen finns stor kunskap och erfarenhet om användarna i den egna organisationen. Eventuellt behöver denna kunskap förädlas genom observationer, intervjuer, fokusgrupper och tester. Därefter kan enkla personas tas fram. De personas vi använde på kursen bestod av detta:

• En bild
• Kort beskrivning; namn, ålder, yrke osv
• Beteende; beskriv en situation som är typisk för personen
• Följder; vilka produktegenskaper är viktiga för att stötta personens beteende?

User story map

Personas är en viktig input till User stories. Vem, vad och varför finns i båda ”verktygen”. Med en user story map organiseras user stories runt en användare eller ett värde. Stories är ”sub-tasks” som grupperas under ”user-tasks”. User-tasks grupperas in under user-activity.

Planera produktreleaser

När man har en story map blir nästa steg att dela mängden av stories i olika releaser. Detta gör man genom att dra horisontella linjer över sin story map. Dessa linjer avgränsar innehållet i olika releaser av produkten. Hur ska man sedan avgöra vad som ska med i vilken release? Ett sätt är att sätta en eller flera personas vid varje release. Fyll sedan releasen med funktionalitet för dessa personas. Den första releasen blir speciell då uppgiften är att utveckla endast det viktigaste. Patton hänvisar till Marty Cagans ide om en minimal gångbar produkt (MVP-Minimal Viable Product). Vad är den minsta mängd funktionalitet som ska med för att vi ska kunna uppfylla ett delmål med produkten?

Resultatet av detta arbete blir en beskrivning av produkten på user-story nivå med en releaseplan. Samtidigt med detta arbete bör man arbeta med övergripande UI design, tex enkla pappersskisser på storyboards som sedan ligger till grund för mer detaljerad UI design. Med hjälp av denna plan skapas en product backlog och därefter kan det iterativa arbetet med sprintar börja.

Roller

Patton föreslår två grupper:

• Product Discovery Team – Detta är det team som genomför fasen product discovery. Teamet består av produktägare, utvecklare (tex. lead developer) samt user experience expert
• Delivery Team- Utvecklingsteamet, ett Scrum team där utvecklaren i product discovery team ingår.

Sammanfattning

Product discovery är en metod för att ta nya ideer och förbättringar av produkter till implementationsarbetet på ett strukturerat sätt. Genom att ”vem” är i fokus samt att man använder personas som ett stöd i prioriteringsarbetet får man användarfokus hela vägen. På Aftonbladet testar vi detta arbetssätt i redesign-projektet.

Länktips:

Jeff Patton’s Agile product design: http://www.agileproductdesign.com/

Jeff Patton twitter: https://twitter.com/#!/jeffpatton

Marty Cagan, Inspired – How to create products customers love: http://www.amazon.com/Inspired-Create-Products-Customers-Love/dp/0981690408/

Scrum: http://www.mountaingoatsoftware.com/topics/scrum

Personas: http://www.omwebb.se/personas-gor-webbplatsens-malgrupper-levande/

Dropbox som Minimal Viable Product: http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/

Users Come First
Det går inte att missa budskapet kring UX och API-design, att vi ska ställa oss frågan varför och vad innan vi går in på hur. Hur ser målgruppen ut och vad vill användaren ha?

”Design is the competivtive advantage, the question entrepreneurs and investors have to answer is no longer “can this be built and by who?” but, “should this be built and for who?”

DevOps, DevSec, DevTest…
Vi lämnar våra traditionella roller och avdelningar. Alla kompetenser, roller och områden närmar sig varandra och vi jobbar som bäst tillsammans och tar ansvar för helheten. Det innebär att vi skapar en miljö och kultur för att kunna tänka på alla delar i utvecklingprocessen och få kvalitet i arbetet. Nya roller skapas för att stötta i arbetet.

Agile
Det här året flyttades fokus från principerna Scrum och Kanban till hur man kan tänka Agile i större utsträckning i hela verksamheten. Hur gör man en upphandling och skriver avtal utan tydliga leverabler som ex. tid och scope? Och hur arbetar man med kompetens och distribuerade team utan tunga processer? Det märks också att man flyttar agile upp en nivå till affärsområdet där projektportföljen och organisationen bli en mer naturlig del. Agile inom testing är också hett och det är tydligt att resan, lärandet och de unika behoven är viktigare än målet oavsett om ämnet är utveckling eller testning.

Säkerhet
Nya mobila enheter öppnar upp för nya typer av säkerhetshot. Vi behöver bli bättre på att förstå de nya sårbarheterna och skapa strategier för ”Platform security” som berör både iOS och Android . Även applikationssäkerhet och säkerhettestning flyttar fram sina gränser för vad som är möjligt när vi går ifrån backend och använder oss mer av klientsidan med ex. javascript som tolkas av browsern. Vi behöver ställa krav på att hitta och utveckla fler färdiga ramverk som ger oss stöd i det arbetet.

Öredev 2011 har passerat oss på sin väg in i historiens dimmor.
Med lite tur har den gett mig lite ökad intellektuell massa.
Får hoppas det, för från hälsoperspektivet har den antagligen också gett mig ökad massa, ett inte lika önskvärt tillskott.
Tallriksmodellen à la Öredev:
God mat: 100, Kaffe: 100, Te: 100, Läsk: 100, Bullar: 100, Smågodis: 100, Motion: 0.

Javascript

Jag inriktade mig lite på Javascript. Och det var roligt att hur hela js-världen närmar sig den vanliga programmeringskulturen och anammar goda förebilder, som TDD och Clean Code i allmänhet.

Några punkter att fundera över:
Vilka dom-ramverk (jquery, yui etc) ska vi använda?
Vilka mvc-ramverk (sproutcore, angular, backbone m.fl.) ska vi använda?
Hur modulariserar vi våra javascript så att det blir logisk och lättunderhållet?
Vilka testramverk (js-test-driver m.fl.) ska vi använda?
I vilka lägen är det motiverat att skriva test- eller beteendedrivet?
Hur lär vi oss att skriva bättre js-kod?
Hur packar vi ihop våra javascript så att det blir få anrop och korta laddtider?
Hur ser vi till att den ökande mängden javascript inte ger upphov till säkerhetshål?
Med mera…

Agilt

De agila föreläsningarna jag var på gav mig också en del tankar.
Flera av dem pekade på risken att falla tillbaka i icke-agila metoder fast man formellt följer en agil metodik. Dan North gav en ganska trovärdig förklaring i sin keynote ”Embracing Uncertainty – the Hardest Pattern of All”.
Han menar att vi avskyr osäkerhet att vi hellre utfärdar en helt felaktig prognos än lever i ovisshet. Därav kommer krav på processer och rapporter (som den här) och med det ökar oflexibiliteten och det produktiva arbetet minskar.

Det passar ganska väl in i herr Norths fredagsdragning ”Patterns of Effective Deivery” där han pekade på tendensen att plocka tillbaka delar av vattenfallmetoden, med dess delvis illusoriska förutsägbarhet och framför allt en klar blame-chain.
Om du hamnar i en process med en tveksam prognos känns det bättre att ha en klar roll- och ansvarsfördelning så det syns vems fel det var…

UX

Slutligen var användarupplevelsen ett tema på Öredev.
Många pekade på hur viktigt det är att ha med användarupplevelsen från början av projekten.
Och en viktig poäng är att det inte räcker att lyssna på användaren.
Du måste bestämma dig vilka dina användare är och hur du vill att din sajt ska fungera. Det går inte att alltid lyssna på användare för då kan de förstöra din sajt.
Fundera på hur du vill att användaren ska agera och umuntra det i design och gränssnitt.
Fundera sedan på hur du INTE vill att dina användare ska agera och motarbeta detta.
Tänk också på att användaren ibland säger att de vill ha en sak men i själva verket gör en annan.
Men framför allt: Respektera dina användare och se till att de enkelt och utan irritation kan göra det du har lovat dem.

(Behaviour Driven Development är förlänging av Test Driven Development. Det viktigaste man mest justerat är att språket är rätt. Dels ska testerna formuleras på ett naturligt språk som är begripligt för alla stakeholders, även icke-programmerare. Dessutom försöker man inom BDD undvika att prata om testerna som ”tester” eftersom det inte är testerna i sig dom är det viktiga, utan beteende, hur systemet beter sig. Alltså behaviour driven i stället för test driven.)

David Evans pratade under en av de sista presentationerna om hur man får ut så mycket som möjligt av sina BDD artefakter.
Artefakter är helt enkelt de ”tester” man har som skapat. Anledningen till att han krånglar till det och inte kallar dem för tester är att de är mer än bara tester:

• Innan utvecklingen börjar har artefakten ett värde som specifikation,
• under utvecklingen fungerar den som test och
• efter att en feature är färdigutvecklad fungerar artefakten som dokumentation

Som en <stakeholder>

vill jag <funktion>

för att <affärsnytta>

För att uppnå <affärsnytta>

som <stakeholder>

vill jag <funktion>

Givet <tillstånd innan>

När <något som sker>

Så ska <resultat>

Med Rikard Edgren 11.11.11 kl 11:11.
I dagens testning ser vi bara binärt.
Mjukvarutest av mjukvara för människor handlar idag mycket om datorer. Pass/fail addiction vi anpassar testerna efter pass/fail paradigmen. Man kommunicerar hur många test som lyckas misslyckas men missar det som är viktigt (oklar vad det är dock). Verkligheten är inte binär.
Coverage obsession, 50% täckning kan betyda många olika saker, det kan vara bra eller dåligt.
Metrics tumour, vi ska ha t.ex 80% test täckning.
Om jag inte laddat telefonen under denna session så skulle jag bytt redan efter 5 men nu fick jag sitta och lyssna på denna hippi i 45minuter…
Rikard pushar även sin egna fria pdf bok ”The little black book on testing” om du mot förmmodan vill veta mer.

Intro till spring data med Olivier Gierke från spring.
NoSQL databaserna försöker lösa dom problemen som man ibland stöter på i en SQL databas. Och dom är ofta anpassade för att köra i molnet från början. Eftersom dom är så olika i sin uppbyggnad så är det svårt att göra en enhetlig Api till alla olika varianter. Och Spring har inte gjort generellt Api för dom olika nosql typerna eftersom dom har så stor skillnad och det skulle förstöra den styrka dom kommer med. Man använder sig av annoteringar när man mappar upp sin modell. Querydsl typsäkra frågor till databasen. Konfigurationen verkar enkel, det mesta är ”by default” och man anger bara om man har något undantag ifrån den. Test stödet är som vanligt bra när det kommer ifrån spring. Man får en tydlig känsla av att detta måste vi testa synd att det är skrivet i Java bara…

En inspirerande keynote av Jeff Atwood, en av grundarna till den fantastiska StackOverflow.com, fick mig att tänka kring gamification. Stackoverflow använder gamification i stor utsträckning. Tanken är att användandet av siten är som att spela ett slags spel och spelar man spelet bra får man utmärkelser. I fallet SO är det helt enkelt så att om man på olika sätt bidrar positivt  (svarar på frågor, uppmärksammar moderatorer på opassande kommentarer etc., så får man utmärkelser, ”badges”, som återspeglar karaktären av ens beteende. T ex kan någon som är väldigt bra på att hålla efter opassande kommentarer få en badge ”ranger”.

Det tjusiga med detta är att det blir roligare för användare att använda tjänsten, användare blir mer motiverade att använda tjänsten på ett ”positivt” sätt och användare blir mer lojala till tjänsten. Om man framgångsrikt har byggt upp en status, har fått åtråvärda badges, så uppstår ett motstånd till att sluta använda tjänsten.

I mina ögon är detta en klassisk win-win. Bra både för den som använder och den som driver tjänsten. Vi driver tjänster där vissa är klockkerna att införa gamification på. Let´s do it.

Talare: Shuel Gershon, Experience report on Exploratory testing and leadership

Det märks att ämnet test är hett och att man börjar få upp intresset för testning i en agil miljö. Det beror mycket på att man ser fördelar i kvaliteten när testning blir en del av utvecklingen istället för att traditionellt ha ett utvecklingsteam, en testare eller ett testteam. Liksom tidigare talare David Evans(agile testning) så pratar även Shuel om hur man kan väva in testning i utvecklingsprocessen.

Här kommer några råd som vi kan ta med oss på resan
* Testning är en resa! Planera inte i detalj vad som ska göras vid testning, hitta istället guidelines utifrån arbetssätten i teamen.
* Exploatory testing based- Utforska snarare än att sätta hårda krav
* Personal view of system – Aktuell status, hur upplever vi våra system och vad vet vi om dem?
* Berätta din egen ”quality story” – Spåra och simulera mekanismen, finns brister och flaskhalsar?
* Undvik en person som har rollen som testare, kvalitet och testning har alla i teamen ansvar för
* Investigate, lär, undervisa, analysera rapport(notes, bugs, questions)

För att lyckas med det som Shuel sammanfattar som ”Test management” behöver vi flytta fokus och arbetet från testrollen och över till teamen.

* Skapa en failsafe miljö, visulalisera data och problemen (Sonar) och följ upp med testrapporter
* Designa teamen utifrån tänket att alla har ansvar för test och kvalitet
* Optimera kvalitet – som utvecklare har man bättre förutsättningar än som testare att påverka kvaliteten

Känns verkligen som vi är på rätt väg! Det påminner mig om att vi behöver fortsätta utifrån vår workshop med tänket att automatisera det som är möjligt i våra miljöer och experimentera mer för att hitta ett sätt som passar oss utifrån olika behov i teamen och vår utvecklingsprocess.

En konkret sak vi kan börja med i alla team är att avsätta tid och få in test i en sprint. Vi gör testning redan idag men på lite olika vis. Syftet är att vi lär oss mer för varje review och kan resonera och samla kunskap kontinuerligt.

Testning: ”Ett ostört moment i sprinten av analys, review och testförsök”

Dan North pekar i ”Embracing Uncertainty – the Hardest Pattern of All” på ett riskbeteende hos oss människor, nämligen att vi är så förbaskat rädda för ovisshet.

Ungefär så här:
– Ovisshet kan innehålla risker.
– Hur stora är dom?
– Det är ovisst!
– Usch, känns inte bra, nu blir jag lite orolig. Det skulle kännas bättre om vi hade en väldefinierad process med klara roller.

Kan vara bra att gå tillbaka till http://agilemanifesto.org/ och http://agilemanifesto.org/principles.html. Det är kärnan i agila metoder. Allt annat är bara försök till implementationer. Och vi ska enligt Dan akta oss för att göra om hjälpmedel till religiösa dogmer.

Jeff Patton är i sin session ”Why common agile practice isn’t agile” inne på lite samma område som Dan.
Han menar att vi gärna drar tillbaka mot den gamla goda vattenfallsmodellen.
Den ger en känsla av förutsägbarhet. Och är enkel att begripa.
Den tilldelar också klara roller och har ett enkelt tidsflöde från vänster till höger.
Och inte minst: Den ger oss en supertydlig blame-chain så vi alla kan pusta ut när vi åker i diket. För det var ju i alla fall inte vårt fel!

Intressant att lägga märke till är att Winston W. Royce, som först presenterade modellen, var mycket väl medveten om att den inte fungerade i praktiken (http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf).

Så här såg hans slutgiltiga förslag ut:

Jeff kommenterar syrligt: ”I wonder why THAT didn’t catch on?”