fredag 31 oktober 2014

Blogg på utrikiska

Jag bloggar numera mest på engelska på
david.elbe.me om du undrar vart jag tagit vägen.

I övrigt mår jag fint och har hunnit skaffa hus och barn sedan jag bloggade senast. :)

onsdag 13 februari 2013

Ölglas för IPA - India Pale Ale

Jag är normalt ingen stor öldrickare, men när jag tar en öl eller två provar jag gärna någon ny IPA-sort. IPA är en variant av öl som är överjäst och därmed får mycket smak. Den är lite beskare än vanlig Svensson-öl, vilket gör att den inte riktigt passar alla.

Hur som helst, det anrika företaget Riedel som normalt specialiserar sig på vinglas har tagit fram ett ölglas speciellt för IPA-älskare. Det är logiskt eftersom många dricker IPA på ungefär samma sätt som de dricker vin, ofta som smakförstärkare till en god måltid eller vid lite speciella tillfällen.



Glaset har tagits fram i samarbete med ledande IPA-tillverkare och har en smal fot och en kupad topp och kan beställas på Riedels webbplats. Det återstår att se om det här blir en internationell standard för IPA-glas, men det kan mycket väl bli så eftersom tillverkarna verkar vara överförtjusta i konstruktionen.

torsdag 31 januari 2013

Vad är poängen?

Det verkar bli ett intressant år, 2013. Jag och Martin har jobbat mycket med att hitta rätt folk till rätt plats på jobbet, och det går framåt även om vi nog skulle må bra av någon mer senior webbutvecklare. Vi har börjat jobba i sprintar i ett av våra interna projekt, och vi lär oss mycket av det agila tänket varje dag som går.

För tydlighetens skull har vi alltså inte hoppat in i någon projektmodell såsom Scrum eller Kanban rakt av, utan fokuserar helt enkelt på att dela in arbetet i veckobaserade mini-sprintar där teamet tillsammans diskuterar igenom vad som ska göras, sätter poäng på de olika delarna och gemensamt ger ett löfte för vad som bör åstadkommas under den sagda tiden.

Att sätta poäng istället för att uppskatta tid verkade lite märkligt initialt. Vi satte 1 poäng = 3 timmar bara för att ha någon gemensam referenspunkt att utgå ifrån, men tanken är egentligen att komplexiteten på en uppgift ska ge poängen, inte hur lång tid den förväntas ta. Den stora fördelen som jag ser det med poängen är att kunna se att teamet tar sig framåt i förväntat tempo varje vecka. Att mäta hur många timmar som levererats eller hur beläggningsgraden ser ut är ju ganska irrelevant om det är produktivitet vi är ute efter. Vem som helst kan leverera 40 h/vecka, det är bara att låta tiden gå. Att rapportera in många genomförda poäng kräver däremot en insats och att det man gör dessutom har passerat någon som testar grejerna. Om teamet normalt sett brukar leverera 10 poäng på en sprint och vi plötsligt ser att det bara levereras 5 poäng under samma tid har vi ett problem. Hade vi bara sett till arbetade timmar hade kanske inte problemet upptäckts över huvud taget.

Vi började med ett mål att kunna leverera 15 poäng per vecka, och efter första avstämningen visade det sig att vi hann med ungefär 12 av de 15 poängen. Den största anledningen till att vi inte hann med allt var att ett par delar var för luddigt definierade och byggde på tycke och smak, vilket i sin tur gjorde att det blev svårt att passera testerna och klurigt för utvecklarna att veta exakt vad de skulle göra. Det försökte vi förbättra direkt till nästa sprint genom att dels ha mindre ärenden, och dels använda oss av skisser i de fall det fanns utrymme för tolkningar kring hur något skulle implementeras.

En annan svår del är at vi inte är vana vid att lägga så mycket tid på förarbetet. Redan efter 45 minuters sprintplanering börjar folk vrida på sig och undra när det är klart. Samtidigt känns det som planeringen tillsammans med testerna är de viktigaste delarna i sprinten. Slarvar vi där blir det inte bra till slut. Det är ungefär samma dilemma som jag har med att skriva offerter – ju mer tid jag lägger på dem, desto bättre blir de och desto lättare blir det att få kunden och teamet att förstå vad som ska göras. Men att lägga massor av tid på en offert som kanske aldrig blir genomförd är inte bra – och jag behövs ofta på andra platser i organisationen.

Det gick hur som helst ganska lätt att bli synkade i poänguppskattningarna. Alla är med och poänguppskattar, både projektledare och utvecklare. De som uppskattar lägst och de som uppskattar högst får förklara hur de tänker, och sedan enas gänget om en gemensam poäng. Det har hittills inte varit några större problem, och pricksäkerheten har varit förvånansvärt hög jämfört med hur det har sett ut i några av våra andra projekt.

Apropå andra projekt är det inte helt enkelt att sälja in agil utveckling mot kund. I alla fall inte att förklara upplägget och skriva offerter där vi kanske inte vet exakt vad som ska levereras. Det är sådant som gör kunden nervös. "Allt det där agila låter ju bra och så, men jag vill ha ett fastpris och veta vad jag får".

Parallellt med det här håller jag på att sätta mig in i de olika agila projektmodellerna lite mer på djupet. Boktips tas gärna emot.