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?”

Inte mycket OOP i titlarna för årets föredrag.
Tänker på detta när jag lyssnar på ”Event Sourcing explained” med Rickard Öberg.
Känns som Rickard har kämpat många år med att komma runt Javas modell av objektorientering.
http://www.qi4j.org/ är ett ganska kraftfullt försök till utbrytning som han måste lagt ner en väldig massa tid på.
Eventsourcing, som dagens dragning handlar om, går ut på att bygga applikationen runt en sekvens av händelser som man sparar i en event-logg.
Inte mycket OO i den skissen.
Jag får mer vibbar till gamla tiders sekventiella kommandoprogram.
Och skälet, om jag förstår det rätt, är att det är svårt att ändra (eller få flexibilitet) i en domänmodell modellerad som javaklasser.
Så då är det enklare att säga: Här är alla händelser, gör vad du vill med dem, bygg din egen modell som passar dina syften.
Det ger total flexibilitet och dessutom enkel interoperabilitet, eftersom eventloggen kan publiceras som en atom-feed t.ex.
Och det blir också relativt enkelt att hålla alla system med duplicerad data i synk eftersom alla event finns sparade och kan spelas upp om och om igen, bara varje system håller koll på när det senast hämtada information från loggen.
Undrar bara varför Rickard inte hoppat över till något annat språk. Måste vara nån slags kärlek.