http.tv4.se

http.tv4.se

Hur vi fick (hygglig) ordning

Vi har ju många olika sajter (och viljor) på tv4, och prioritering av vad som är viktigast är därför sällan helt självklart. Här berskriver jag hur vi gjort för att få bättre ordning på webbutvecklingsarbetet och prioriteringen av vårt jobb de senaste åren.

Hur det var
För några år sedan när TV4 just lanserat nya sajter i Polopoly utgick mycket av utvecklingsarbetet från ett antal (ofta långa) listor. De här listorna var från början ”restlistor” med utvecklingspunkter som inte hunnits med till sajternas lansering.  Saker tog sällan bort från listorna vilket gjorde att de snabbt blev långa, inaktuella, dåligt prioriterade och ospecificerade. Beställarna var många och utvecklarna få, så för att få igenom just sina punkter fick beställarna tjata ihärdigt eller skrika högt. Prioriteringen mellan sajterna blev såklart inte optimal.

Ny metod – scrum eller nått annat?
Vi behövde jobba mer strukturerat, och den metod som var på modet för dagen var Scrum. Problemet var bara att vi inte var helpeppade på att ta in en scrum-guru för att införa fem-sex nya möten  i veckan som skulle äta av vår redan knappa tid. Vår metod-missionär Brian hade lösningen –  vi tog det ett steg i taget. Inga kurser och avstamp och ”nu-jädrar-kör-vi” utan mer en långsamt framväxande strukturering över ett år eller två. När en del var på plats och fungerade gick vi vidare till nästa. Inga lösningar infördes innan det fanns ett problem att lösa. Det gjorde att metoden aldrig åt upp all vår tid och inkörningssträckan blev visserligen lång men å andra sidan oproblematisk. Innan något nytt infördes visste vi tydligt vad vi ville få ut av det.

Vår väg till bättre ordning (kanske något rakare än vad den egentligen var)
Steg ett: Listorna i papperskorgen. Papperstickets blev nya hårdvalutan
Första steget mot ordning var att teknikavdelningen slutade att låtsas ta ansvar och bry sig om sajternas långa önskelistor. Vi satte upp en mötesstruktur där vi samlade in önskemål på utveckling kontinuerligt, och allt som togs med från mötet var ett par papperstickets med det som var hetast just nu.  ”Långa listorna” åkte i papperskorgen. De flesta saknade dem inte ens.

Steg två: Prioriteringsmöten och väl avgränsade sprintar
För att skapa lugn åt utvecklarna gick vi vidare med att skapa avgränsade sprintar och ett priomöte innan varje sprint. Utmaningen för oss var att få de beställare som var vana att skjuta från höften fem dagar i veckan att respektera att de behövde ha framförhållning. Det här kom vi inte i mål med förrän långt senare, i början sprack planeringen mer eller mindre varje vecka på grund av akuta fixar, men strukturen var ändå en förutsättning för att få koll på prioarbetet. Med en fast tidsram tvingades man inse att tiden inte räckte till allt, och när man nu pressade in något märkte man plötsligt att något annat föll ur.

Steg tre: Få in beställarna i prioriteringen
För att få ordning på prioriteringen släppte vi in beställarna på våra priomöten. En person från beställarsidan som hade övergripande ansvar för alla sajter fick sitta med på priomötet och sätta prioriteringen tillsammans med oss. Det var väldigt effektfullt när vi fyllde bordet i mötesrummet med papperstickets. Allt från pixelpet till stora strukturförändringar  låg på bordet och allt skulle in i en enda orm. Efter många ”Men… det här är ju också viktigt” (ofta följt av en lång suck) kom vi fram till ett tiotal tickets som prioriterats, och ett sextiotal som prioriterats bort.  Nu hade beställarna varit med och valt de tickets som skulle göras, och vi slapp spilla tid på att argumentera och planera om vår tid när arbetet väl pågick.

Steg fyra: Kommunicera vad beställarna kunde förvänta sig varje vecka
När vi såg att beställarna började förstå hur vår process fungerar började vi skicka tydliga mejl med vad som ingick i en release och vad som inte fick plats. Så ärliga som möjligt och gärna med en rad om vad vi tvingats välja bort. Ofta svarade de som inte fick med just sin viktiga punkt med vändande mejl, och då kunde vi på en gång tala om hur vi resonerat och varför den punkten inte hanns med. Om prioriteringen ifrågasattes kunde vi förstås hänvisa till den som hade det övergripande ansvaret. Det skedde i själva verket rätt sällan, för när valen synliggjordes förstod beställarna bättre varför deras saker inte hanns med.

Steg fem: Tidsuppskattning av tickets
Man kan tycka att vi började tidsuppskatta tickets sent, men det var först nu vi hade fått tillräckligt bra koll på processen för att kunna börja planera sprintarna mer exakt. Så länge saker pressades in från höger och vänster skulle en detaljerad uppskattning varit omöjlig. Vi var nu i ett läge där vi började kunna hålla ute störande snabbfixar och brandsläckningar och kunde därför tidsuppskatta arbetet på en rimlig nivå.

Steg sex: Sprintstatistik
För att få koll på hur många poäng vi skulle ta med i varje sprint behövde vi få koll på hur mycket vi klarade av. En enkel siffra på avklarade tickets per sprint hade räckt långt, men för att synliggöra hur arbetet gått ännu mer började vi göra Burn down charts. Jag vet fortfarande inte om vi har mer nytta av dem än vad vi hade haft av en enkel totalsumma, men de ser å andra sidan fina ut på väggen.

Steg sju: Retrospektiv
Ju mer metod och ju fler möten man kör, desto större anledning att finslipa metoden. Därför började vi köra retrospektiv efter varje sprint för att utvärdera sprinten och hur vi jobbat. Retrospektiven vi kör är oftast enkla, men det viktiga är att få diskutera några minuter varje vecka så att arbetet inte stelnar i sin form. Retrospektiven mynnar alltid ut i en åtgärdslista.

Steg åtta: Time boxing
När vi hållit ett par tidsuppskattningsmöten och retrospektiv som dragit iväg på tiden och vi började känna att mötena åt för mycket av vår tid införde vi time boxing. Morgonmöte 10  min, retrospektiv 15 min, tidsuppskattning 45 minuter och prioritering 30 minuter. Alla möten går fortare när man vet vilken tid man har att röra sig med, och med den här tidsåtgången kunde de fasta mötena begränsas till 190 minuter på en tvåveckorssprint, vilket blir ungefär 20 minuter om dagen.

Steg nio: Längre sprintar
När vi började att strukturera oss var en vecka per sprint allt vi kunde hinna med eftersom ingen i organisationen hade den framförhållning som krävdes för att planera längre perioder framåt. Efter att ha kört med veckorytmen ett år hade vi skapat oss rutiner och utrymme för att förlänga sprintarna till två veckor och därmed minska den tid som gick åt till möten.

Steg tio: Demos
När vi börjat få ordentlig snurr på utvecklingen och fått till en rytm och ett flyt införde vi demos efter varje sprint. Det här kändes rimligt först när vi kommit upp till tvåveckorssprintar (annars hade demoförberedelser stulit för mycket tid). Behovet kom av att vi kände att sprintarna flöt in i varandra och vi satt och småjobbade med förra veckans rester i nästa sprint vilket gjorde tiden svårare att uppskatta.

Vad vi har vunnit på att strukturera oss
Grundförutsättningarna för vårt utvecklingsarbete är på många sätt detsamma idag som tidigare – ett konstant inflöde av idéer och utvecklingsförslag och beställarna är till och med fler. Skillnaden är väl det här:
– Vi gör alltid det som är mest prioriterat för verksamheten som helhet just nu.
– Beställarna vet vad som gäller och slipper spilla energi på att tjata på att utvecklarna aldrig gör vad de vill
– Stressen minskar med synliga prioriteringar, ingen behöver ha dåligt samvete för att något inte hinns med

Nästa steg?
Det finns mycket vi skulle kunna göra för att gå vidare för att få strukturen ännu tydligare. Ordnad backlog, regelbundna releaser kopplade hårdare till sprintarna, parprogrammering och kanske en elektronisk tickettavla (mest för att göra prioriteringen än mer tydlig för de som inte sitter just på den plats där vi sitter) är några. Men det tar vi senare.

A different perspective on analytics

About a week ago Disqus – the commenting platform we use on all of our sites – rolled out a new Analytics feature. Besides that it gives us a good overview of number of comments, likes, reactions and people they also express the amount of comments to something you can relate to in a different way:

So now we know that our fiftysix thousand comments on TV4.se equals eight times the book Moby Dick if you read them from first to latest. Sites with fewer comments are compared to a smaller unit: number of SMS.

Three obvious things we missed in testing

This summer we released a new version of the weather site Väderkanalen.se (”The Weather Channel” in Swedish), this time built using the Ruby on Rails framework. Although we have a few tests in the test suite for the site it is far from complete. Three of the things that we have fixed since the release are results of phenomenons that shouldn’t come as a surprise. Three things that are not as certain as death and taxes but not far from it:
  1. There are months with 31 days.
  2. We actually have daylight saving time.
  3. It’s cold in the winter.

One: The first phenomenon was discovered in the end of  August when suddenly the forecasts for September 1st shown on the site was dated as October 1st. It took a while before we realized what happened. The code for setting the date looked something like this:


var forecastDay = new Date(2010,7,31);
undefined
forecastDay
Tue Aug 31 2010 00:00:00 GMT+0200 (CEST)
forecastDay.setMonth(9);
1288476000000
forecastDay.setDate(1);
1285884000000
forecastDay
Fri Oct 01 2010 00:00:00 GMT+0200 (CEST)

Since August have 31 days but September only 30 the 31st day of September really is October 1st. So when we set the day after setting the month we are suddenly in October. The easy fix? To set the day of month before setting the month. The correct fix? To set year, month, and date in the same method call.

Two: Around the end of October a few days before Europe goes back to normal time we see that a number of forecasts are missing. Since we have had trouble with our data supplier, SMHI – the Swedish national weather service, earlier on they are our prime suspect. But when we look at the data files they supply they look to have all data they should have. There is however one thing that look different. After the following Saturday all forecasts are given another timestamp. The forecasts are now for 1pm instead of 2pm. The Javascript code assumes however that the timestamp will be the same as first day of the ten-day forecast. So during transition between daylight saving time and standard time some forecasts will be missing. I guess the error partly can be blamed on our data supplier since the time zone used should have been documented. But mainly it is our fault since the transition shouldn’t have come as a surprise.

Three: When the Flash rendering of the ten-day forecast suddenly went blank for some places up north last week we had a number of theories on the cause. Once again the weather service was a prime suspect but the data was in order so we began to think that it was something different with the data that the Flash code couldn’t handle. And sure enough, it turns out that the code rendering the curve of temperatures didn’t work when all temperatures in the forthcoming ten days were in the sub-zeros (Celsius degrees that is).

Testing: One thing to learn from these errors is to setup a number of tests for all corner cases you can come up with. All three of these errors can be classified as such. All three are also errors in code that runs on the front-end. There are tools for unit testing Javascript code, e.g. Jasmine, but they are not used as much as unit tests for backend code and we have just recently begun to use such tools on our TV4 Play project. There is work on unit testing in Actionscript as well (such as AsUnit), but since the code in question was developed by a third-party we should start by having them better document the work they do. And make it possible for us to test.

Bädda in klipp från alla svenska TV-kanaler

Varje TV-kanal med självaktning har idag en egen play-tjänst med program och videoklipp från de egna programmen utlagda. Vi har förstås vår egen TV4 Play varmast om hjärtat men behovet att diskutera även andra kanalers material. Då vi inte hittade någon som täckte det behov vi hade smällde jag ihop en WordPress-plugin som ska fungera med de olika Play-tjänsterna. Det finns en överhängande risk att saker sluta fungera när de olika tjänsterna ändrar i sina tjänster men vi hoppas på bidrag från intresserade i vårt Github-repository.

Tjänster som stöds är:

Ett tydligt undantag är UR Play som inte stöder inbäddning överhuvudtaget. Upp-och-nedvända världen kan tyckas.

På grund av upphovsrättsliga skäl tillhandahåller inte UR Play möjligheten att bädda in UR:s program på andra webbplatser.

Så installerar du WordPress-pluginen Embed4Play:

  1. Ladda ner pluginen som ZIP-fil genom att trycka på Downloads på pluginens Github-sida.
  2. Packa upp filen och lägg embed4play.php under wp-content/plugins/
    Alternativt kan du använda WordPress’ admin-gränssnitt, klicka på ”Tillägg” -> ”Lägg till nytt” -> ”Ladda upp” och välja ZIP-filen du just laddat ner.
  3. Gå till pluginsidan i WordPress’ admin-gränssnitt och aktivera pluginen.
  4. Nu kan du lägga till videoklipp i bloggposter

Så lägger du till ett videoklipp med Embed4Play:

  1. I tjänsten som innehåller det aktuella klippet får du luska ut det aktuella id-numret för klippet. Det är oftast ett helt numeriskt id och du hittar det antingen i URL-en till klippet eller i embed-koden som videospelaren ger ifrån sig när man klickar ”Dela”, ”Bädda in” eller liknande.
  2. I ditt blogginlägg skriver du sedan in taggen för den aktuella tjänsten och id-numret:
    [svtplay id=2238016]
    I det här fallet läggs ett klipp med id-nummer 2238016 från SVT Play in. När du förhandsgranskar ska du kunna se klippet istället för denna kod. Resultatet bör bli detta:

Taggarnas namn:

  • tv4play
  • svtplay
  • kanal5play
  • tv3play
  • tv6play
  • tv8play
  • kanal9play
  • expressentv

Övriga parametrar:

size: Kan sättas till small, medium eller large för olika storlekar på videospelaren. (Kan även sättas på pixelnivå, se nedan)

width: Videospelarens bredd i antal pixlar

height: Videospelarens höjd i antal pixlar

Short summary in English: This blog post describes a WordPress plugin that allows users of WordPress.org blogs to embed video clips from the major media outlets in Sweden. By entering the shortcode [svtplay id=2238016] where svtplay is the name of the service (the other are listed above) and the number after id is the internal id of the clip within that service you get the correct Flash video player embedded. This plugin is available via our Github repository.

Svenska eller english?

Multilingual Scrabble
Multilingual Scrabble by urbanmkr

Ny blogg! Som vi antingen kör vi svenska – vilket är det mest naturliga – eller så blir det engelska. Kanske lite mer ansträngt men fördelar med att vi kan nå ut längre, bland annat till leverantörer, kollegor och partners som inte talar svenska. Det finns bra argument för båda alternativen.

Men språket behöver vi inte bestämma nu. Bättre köra igång, testa lite och känna oss för så att vi sen kan fatta ett beslut baserat på vad vi lärt oss. Vi kan kalla det ”beta”.

Välkomna hit!

Nyare21
 
NU
 
Visa hela tablån