Cecilia Beck-Friis, chef för Digitala medier på TV4-Gruppen, talar om den närmaste framtiden för rörligt material och vad som händer med TV4 Play under 2011 i Spotlight, som är presentationsprogrammet för våra annonsörer.
Tyvärr finns ingen direktlänk utan ni får följa länken och klicka på “Webb & mobil” och sedan på den första bilden. Klickar man på den tredje bilden får man höra Tommy Jarnemark berätta om tankarna bakom TV4 Play.
När vi för några veckor sedan möblerade om på avdelningen fick vi en tom vägg (tre gånger tre meter) bredvid oss. En bra yta för att sammanställa och visualisera information som vi alla har nytta av. Den ursprungliga skissen såg ut så här:
Väggen ska ge oss själva eller vem som helst som kommer förbi en överblick över situationen just nu.
Det här finns på väggen (eller är på väg upp):
Tid
En klocka. Visar tiden från husets centrala tidsstyrning. Det är en studioklocka av märket Evertz. Den är väldigt tydlig och ser till att vi hela tiden kommer ihåg att hålla nere mötestider (timeboxing, #8) och att vi kommer i tid.
Kvalitet/Status
En skärm som visar olika statusflöden. Visar bland annat resultatet av Continuous Integration-servern som Brian skrev om. Om vi slarvar med kvaliteten (till exempel checkar in kod som inte fungerar eller som har sönder några tester) eller något går ner (driftstörningar) så ska det visas här.
Vi kanske också lägger in lite trafik- eller andra visualiseringar. Eftersom det är en vanlig webbläsare räcker det med att presentera innehållet på en webbsida för att det ska kunna visas upp här. Just nu visar den också senaste publicerade klipp på TV4Play. Konstant ”work in progress” förhoppningsvis.
Idéer och skisser
En stor rit-tavla där vi kan skissa, rita, anteckna och brainstorma. Började användas redan någon timme efter att den monterats så det verkar som vi haft ett behov av en sån här. I glas.
Hastighet
Syns inte i skissen men vi har också plats för ett Burn Down Chart som visar hur vi ligger till i förhållande till arbetet vi åtagit oss. Den visar hur många poäng/enheter arbete vi betar av dag för dag under en sprint i förhållande till en idealkurva och totala åtagandet.
Prioriteringen
Det vi arbetar med just nu. Vi prioriterar i sprintar och varje ärende ska röra sig från vänster till höger (att göra, under arbete och Done!) och helst ska allt vara i högerkolumnen när sprinten är klar.
Så en person som kommer fram och undrar hur det går kommer genom väggen få en tydlig uppfattning om:
1. Vad vi håller på med.
2. Hur det går (och hur sprinten flyter på).
3. Status på drift och kvalitetsläget just nu.
4. Ifall vi har några nya idéer eller koncept på gång.
….vad klockan är.
Jag följer upp det här med några foton när allt sitter uppe.
on a java project using ant
one of the most critical pieces of our infrastructure is our continuous integration server. we use hudson to build all of our projects and run our tests. setting up a new project that uses java or ruby takes about 10 minutes. to get to the point of it taking only 10 minutes to configure a new job took a few weeks. the following is how we got ci up and running for one of our large java projects that had no tests. this probably took 10 8 hour days to get this working but those days were spread out over a year and a half as we were working on other things. if you looking for more details on how to set up set up hudson this is not the place to get started this is more of the general approach we took.
this seems simple but don’t take it as a given. one of the first reasons i installed hudson was to make sure that our large code base would compile. this was a challenge as we had developers from different projects working in pretty much the same areas of the code. we use ant and have a target called compile but not everybody ran them and sometimes files were not properly checked in. it took a couple of hours getting this to work as there was at some special set up that was required to get it to run at all locally. finally got to the point where running:
ant compile
was all it took to compile the our code.
next step is to download and start hudson on my machine and get it up and running. don’t get overly ambitious here. as long as you have java installed running:
java -jar hudson.war
should get hudson up and running and you can begin to configure hudson to checkout your code from your version control system. one tip is to create a special user in your version control system that only has read access.
in hudson under build steps -> target add compile this is the target that will be run when you trigger a build.
now is when hudson starts paying off. adding unit tests to a large code base can be frustrating. it can be done and it will seem like a monumental task if you have never used junit/testng before. even if you are familiar with junit/testng it will not be easy. but the pay off is more than worth it. if you have work with unit testing before remember that the goal now is to get
ant test
to work. start off by creating a directory by your java src code called test this will be the root of your test hierarchy. add a new target to ant that includes the your build classpath (ie the classpath used to run ant compile) you might at this point need to refactor your classpath from the compile target so your can use it as a part of the test classpath target. next add one test that passes and one test that fails. by this i mean something like this:
running ant test should now give you something like this:
if you get Tests run: 2, Failures: 1, Errors: 0. you can remove test file and start writing unit tests.
change the build step from compile to test.
I ran hudson for almost a year on my local machine with little trouble. the hardest part was remembering to leave my machine on during vacation. the next step is to get a new home for hudson. the requirements are pretty low. one computer, power and network. the computer doesn’t have to have be anything special. 40Gig hard disk and 1G ram should do in the beginning. install your operating system of choice and install and configure hudson. now that it’s not local anymore you can make it poll version control for you. under build triggers -> PollSCM add */2 * * * *. this will make hudson check your version control every 2 minutes. if anything is checked in it will start a new build.
Having hudson up and build every thing the next step i do is add an email notification task. using hudson’s default email notification plugin hudson will send an email everytime the build fails. to make this as visible as possible we created a special mail group that includes everyone that has access to our version control systems. to make it even more visible we use the email-ext plugin and configure it to send mail even when the build is successful. i know what you are omg! not more mail. my response is zomg it’s almost 2011 use a mail filter.
it’s now that hudson is becoming more and more relevant to you organization. especially if
once hudson is up and running it’s time to get some metrics. why? well without measuring anything it’s really hard to know if it’s getting any better. it’s good to reflect on how the code base is shaping up now that more and more tests are being written. metrics are good points to see if the code that is being tested most is easiest to work with or how well the code that is used the most is tested. there’s tons of observations that can be made but only if you have some metrics. we use emma. cause it’s free and not too hard to get working. it’s basically the same as ant test target except it excludes some classes that are generated and needs both the build classpath and the test classpath. but once you can ant emma-run-tests it’s a small matter to get hudson hooked make it pretty.
here you will need to add the ‘hudson emma plugin’. and configure the emma section of you hudson job to find where the emma output is located. (ie build/emma/report/coverage.xml)
the next step was to get our jsp’s to compile. this came out of the need to upgrade our servlet container froim one version av resin to another. we have 500+ jsp pages and no real practical way to navigate to all of them but compiling them gave a bunch of benifits. we got rid of all the pages that had jsp scriptlets that did not compile whcih gave 503 errors every time some one navigated to them. there was not many of them as any jsp’s that werew surfed to often enough were kept in ok shape but the getting the few that did not work ended solving a couple of really low prioritized bugs.
the other benefit was we when we started to move from one version of resin to another (3.0 to 3.1) we found that resin 3.1 was much more strict in the way it interpreted of jstl and el syntax. this script should work for bother resin 3.0 and 3.1.
once that was in place it was a matter of running that script and correcting the errors. took about 3 hours to get everything clean. the amount of time and money this has saved not small. finding out that a jsp doesn’t work until it’s live causes a chain of patches, redeploys and testing that really eat time. now this is not an issue as hudson screams way before the code is deployed becuase it’s run every time hudson builds this job. fail early, fail fast.
The last configuration we have added is to make hudson run emma-run-tests and compile-jsp to hudson.
is it worth it? yes the further i get down the list of testing our code the better i sleep 
. is there more to do ? always. we could add integration tests but in just this project we have reached a point of diminishing returns. this project has probably the worst test coverage of any of the project we have right now all the other have more than 50% and all ruby projects have at least 80%.
The amount of meta data available for the video clips used on our sites, such as TV4Play, is often very limited. Often the video clip have just a title and belong to a category. It has no description and no keyword. When the amount of videos is large it isn’t feasible to manually annotate all of them with more meta data despite it being critical if you want to find a certain video or videos on a certain topic.
When it comes to text there are a large number of maturing techniques for extracting useful information. Latent semantic indexing (PDF) and inverse document frequency (PDF) has become standard tools in systems that operate on text. To extract information from image and video data is however a more complicated feat. The research on image analysis and face recognition has led to software and services offering some basic support for browsing and cataloging objects and people in media but we are still far from functions that are reliable enough not to confuse unprepared users.
For some of our programs we actually have meta data that aren’t used in our search system so far. We have every word spoken recorded, not from using speech recognition but typed in by humans. Yes, it is the captioning/subtitling that we have for some of our programs, e.g. our home improvement show Äntligen hemma, the comedy panel game show Parlamentet, and Emmerdale (Sw. Hem till gården). By adding the texts from the shows to our Solr index it would be possible to find episodes on building your own sauna, that discusses the mishaps of the Swedish king or the episode where one of the characters is drunk.
Another use for this data is to visualize i. Word clouds for some of our shows looks like this when entered into Wordle (and being careful not getting too horrendous font choices):
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.
