Hej alla läsare!

Vi heter Viktor Jakobsson och Simon Agvik och är nya traineer hos Cinnober Financial Technology. Ni som har följt Traineebloggen under en längre tid har nog redan koll på vad Cinnober sysslar med men vi drar ändå den korta versionen här. Cinnober är ett svenskt finansiellt it-företag som bygger trading- och clearingsystem för börsmarknaden. Bolaget finns representerat i Stockholm, Umeå och London, med sammanlagt ungefär 250 medarbetare. Vi är båda placerade på Umeåkontoret där det sitter ett sextiotal glada och trevliga ”cinnoberiter”. Just nu är vi inne på vår fjärde vecka och än så länge känns allt toppen.

Vilka är vi och hur hamnade vi här? Vi har båda pluggat teknisk fysik här i Umeå och sökte under våren traineeplatserna här på Cinnober. Efter en lång ansökningsprocess så lyckades vi till slut knipa var sin plats och började programmet nu i september. Viktor är född och uppvuxen i lilla Sollefteå och flyttade till Umeå 2010 för att börja plugga. Simon följde en liknande bana och flyttade till Umeå från nordliga Luleå ungefär samtidigt. På fritiden tycker vi båda om att vistas i fjällen, slalom/snowboardåkning samt träning av olika slag.Traineeprogrammet hos Cinnober är uppbyggt av fyra block där vi kommer att testa på olika delar av utvecklingskedjan: testning, utveckling, krav och support/TAM (Technical Account Manager). Vi är båda placerade i projektet som arbetar mot LME Clear (London Metal Exchange) och just nu är vi inne i det första blocket, testning. Än så länge är allting nytt men efter ett par intensiva introduktionskurser och genomgångar så börjar vi sakta men säkert sätta oss in i det komplexa system som ett clearinghus är. Vi har redan från början släppts in i det dagliga arbetet mot kunden, vilket både är lite läskigt men också spännande. Det kommande året kommer bjuda på utmaningar av alla det slag och vi ser fram emot att lära oss så mycket som möjligt.

I och med att vi är två traineer tänker vi dela upp bloggandet, så bli inte förvånande om vi tar ungefär vartannat inlägg.

Ha det bra!

Simon & Viktor

Hej!

Det var länge sen jag skrev nåt på bloggen. Traineeprogrammet tog slut för drygt ett halvår sen. Det var ett riktigt lärorikt och spännande år. Vi hade många kurser i olika områden och fick prova alla viktiga roller inom företaget och lära oss om verksamheten.
Jag har jobbat som utvecklare sedan traineeprogrammet var slut i LMEClear projektet fram till början av mars men nu har lite mer spännande saker hänt på Cinnober!
Cinnober har en ny kund: Australian Stock eXchange (ASX) och jag har börjat jobba i det nya projektet. Vi ska bygga ett trading system åt dem. Det blir mycket nya saker att lära mig eftersom jag jobbade med ett clearing system hittills och nu blir det trading. Det ska vara lättare än clearing iaf!
Jag har flyttat till andra sidan av kontoret och sitter med det nya teamet. En utmaning i ASX är att vi måste hitta ett bra sätt att hantera tidsskillnaden som är 10 timmar. Vi är just nu i planeringsfasen av projektet så vi har ganska många kravare (Busineess Analyst) som har åkt till Sydney för att reda ut vad vi måste bygga.

Ni kan läsa mer om ASX och Cinnober här: Cinnober to provide ASX with new trading system

De senaste veckorna har varit intressanta. De har ägnats åt en fas av mjukvarutvecklingsprocessen som inte involverar något slags programmering överhuvudtaget. I det nya projektet ska Cinnobers grundplattform byggas ut med stöd för att skicka ut marknadsdata med multicast-teknologi över FIX-protokollet. Det går ut på att en sändare kan skicka ut marknadsdatan till ett stort antal mottagare på ett effektivt och rättvist sätt.

Förstudie och design

Eftersom detta är helt ny funktionalitet så går en stor del av projektet åt till att göra efterforskningar och ta reda på hur problemet kan lösas på bästa sätt. Vi har studerat existerande Cinnobersystem, existerande implementationer som redan finns på marknaden, vetenskapliga artiklar, m. m. Tillsammans diskuterar vi i teamet och andra experter på företaget igenom de många olika alternativa lösningar, deras för- och nackdelar och väger dem mot varandra.

Eftersom detta kommer vara del av grundplattformen som alla kundprojekt bygger på måste lösningen vara tillräckligt flexibelt för att fungera för alla kundprojekt. Samtidigt vill man minimera mängden arbete kundprojekten själva behöver göra för att anpassa systemet till deras behov. Dessutom måste systemet vara tillräckligt effektivt för att möta förväntningarna hos användare på moderna elektroniska marknadsplatser. Dessa hänsynstaganden står ofta i konflikt med varandra, vilket utgör intressanta problem.

Projektplanering med Scrum och story points

När vi anser att vi har en tillräckligt bra bild av problemställningen måste projektet planeras. I Scrum-modellen, vilken är praxis på Cinnober, delas projekt upp i så kallade sprintar, som varar i 2-4 veckor. Problemet som ska lösas delas upp i “stories”, som var och en täcker in en arbetsuppgift som ska passa in i en enda sprint. Samtidigt ska varje story prioriteras, efter två hänsynstaganden. Å ena sidan kan vissa stories helt enkelt inte utföras förrän andra är klara, och de måste naturligtvis prioriteras lägre. Dessutom prioriteras stories efter hur kritiska de är för projektets framgång, med central kärnfunktionalitet på topp och bonusfunktionalitet som lösningen i teorin skulle klara sig utan längst ner.

När väl detta är gjort tidsestimerar vi varje story, i ett format som kallas story points. En story point kan ses som ett storleksmått snarare än ett tidsmått. Detta för att tiden det tar att slutföra en uppgift kan variera beroende på vem som utför den, medan story points är tänkta att vara konstanta. En story point representerar samtidigt ingen specifik enhet, utan det viktiga är att poängmåttet är korrekt relativt andra estimat. Dvs, en story med tre story points ska vara ungefär tre gånger så stor som en story med en story point.

När väl alla stories fått ett estimat uppskattar teamet tillsammans hur många story points vi klarar av på en sprint, och de stories med högst prioritet plockas in i första sprinten tills poänggränsen är nådd. Detta har dessutom fördelen att man omedelbart får ett långsiktigt tidsestimat för hela projektet, genom att dela det totala poängantalet med poänggränsen för en sprint.

En annan finess med det här systemet är att efter varje sprint kan teamets prestanda jämföras med den estimerade. Det är mycket troligt att bedömningen av antalet poäng som kan avklaras på en sprint inte överensstämmer med verkligheten. Då kan man inför nästa sprint utnyttja antalet poäng som avklarades i föregående sprintar för att estimera nästa. På så vis kommer tidsplanen att konstant uppdateras och komma närmare sanningen allteftersom att projektet fortgår och teamet får tillgång till mer information och bättre förståelse för problemet och lösningen.

Medan jag skriver detta har vi precis avslutat den första tidsestimeringen och imorgon ska vi påbörja planeringen av den första sprinten. Det är fascinerande hur sofistikerad modern projektplanering inom mjukvara kan vara och det ska bli intressant att se hur bra systemet fungerar i praktiken de närmaste månaderna. När jag skriver nästa gång kommer vi förmodligen kommit in på andra sprinten och jag kan rapportera mer om hur det gått. Hörs då!

Hej!

Nu är vi ett par veckor in i utvecklingsblocket, och även om det är en del problem som spökar från den förra releasen har utvecklingskurserna kommit igång för fullt. Eftersom jag redan har en rätt stark bakgrund i utveckling var jag rädd att kurserna under den här fasen av traineeutbildningen skulle bli lite överflödiga, men jag blev positivt överraskad av att det handlar mer om ett Cinnober-centriskt perspektiv på utveckling än någon grundkurs i programmering.

Under den första kursen gick vi igenom riktlinjerna för koden som skrivs på Cinnober. Detta handlar om att vi följer ett visst mönster när vi strukturerar koden, namnger variabler och metoder, dokumenterar koden med kommentarer, etc. Det är värdefullt eftersom det gör det enklare för andra utvecklare att läsa och sätta sig in i koden, vilket sparar tid och frustration för alla.

Vi har även haft en kurs som gått igenom de primära verktygen som används vid utveckling hos Cinnober, som versionshanteringssystem och byggsystem. Versionshanteringssystem används för att organisera och lagra olika versioner koden över tid, vilket tillåter att alla tidigare tillstånd kodbasen befunnit sig i kan återställas om det skulle bli nödvändigt, och att man kan utröna syftet med alla förändringar som skett. Byggsystemet är en uppsättning skript och verktyg som används för att förändra och översätta kodbasen och relaterade resurser till ett fungerande system, i ett antal olika steg. En annan kurs täckte de interna databaserna vi använder på Cinnober, hur de är uppbyggda internt och hur de används i de olika kundprojekten.

Den senaste kursen beskrev FIX-protokollet, ett standardiserat protokoll för utbyte av finansiell data internationellt och hur Cinnobers system utnyttjar det. Framöver kommer det kurser som ska täcka grundplattformen som varje kundprojekt bygger på och de olika servrarna som den består av, Cinnobers officiella tradingklient, systemadministrationsklienten och generering av programkod från en datamall.

Även om vi inte kommit igång på riktigt har vi börjat med några mindre uppstartsmöten inför det nya utvecklingsprojektet som majoriteten av utvecklingsblocket ska bestå av. Ser fram emot det eftersom det involverar nyutveckling av en relativt oberoende modul av grundprodukten, med intressanta utmaningar av både teknisk och teoretisk karaktär. Förhoppningsvis har vi kommit igång på riktigt nästa gång så jag kan berätta mer om det.

Vi hörs!

Nu har julen kommit och det innebär såklart den mörkaste tiden på året. Det är också tiden då jag ska sluta vara kravare. Planen är att jag, som Johan, ska vara utvecklare en period (några veckor) i projektet igen innan vi går vidare till nästa block. Jag kommer att jobba med nyutveckling, som det ser ut just nu.

Nu när det är ajöss till krav så tänkte jag ta tillfället i akt att presentera en kort reflektion av hur det har varit att arbeta som ’business analyst’ i LMEC-projektet på Cinnober:

Jag har lärt mig om verksamhetsbehov, systemkrav (främst), och analys och design, samt verktyg för att beskriva och konkretisera dessa. Jag har lärt mig hantera kunder – frågor och krav, och samarbeta för att förstå och analysera systemet.

Jag har alltid varit ganska tekniskt/vetenskapligt inriktad och har aldrig reflekterat över behovet av krav (enligt den ganska naiva föreställningen ”man vet ju när det är bra). Kravblocket har varit lite av en ögonöppnare för mig.

Det är kul att krava. Man får ett helt annat perspektiv på saker när man inte grottar ner sig i tekniska detaljer (som i och för sig också är roligt) – man kan se saker i ett lite större sammanhang.

För mig känns det som att det vore nyttigt för utvecklare i allmänhet att bekanta sig lite närmre med krav. De flesta här har såklart både bra koll på kraven, systemet i helhet och förståelse för kravarbetet.

Jag har också lärt mig en del om kravare och agila metoder (specifikt Scrum), som har fått mig att tänka en del på vilken roll en kravare ska ha i ett team. Här är några länkar till information om agila metoder och om kravare i Scrum, för de som inte har koll.

Agila metoder: http://www.agilealliance.org/the-alliance/what-is-agile/

Kravare i scrum: http://www.romanpichler.com/blog/business-analysts-in-scrum/

God jul och gott nytt år!

Rasmus

Ett projekt kan man se som en levande organism. Den föds, förändras ständigt under dess livstid och till slut så dör den. Projektet jag jobbar i förändras hela tiden. En bra projektledare är ständigt uppdaterad på förändringar i projektet och försöker hela tiden korrigera för dess behov och på vilka ställen specifika resurser uttnytjas bäst.

I.o.m detta byter jag idag team inom projektet. Vi har för tillfället två permanenta team, ett för ny funktionalitet och ett för support & maintenance som har till uppgift att stabilisera systemet och laga alla buggar som hittas genom reggressionstestning, oftast något som kunden upptäcker som vi kanske inte trodde var en bug men som i deras ögon är en bug.
Jag kommer att byta ifrån nyfunktionalitets teamet till support & maintenance teamet för att stärka upp deras behov av personal då våran projektledare sett att vi kommer att vinna lite i längden på att finfördela våra resurser på det sättet. Jag ställer så klart upp och tycker det ska bli roligt att anta nya utmaningar.

Jag har jobbat med att laga buggar tidigare under året så det är egentligen inget nytt för mig och eftersom jag har haft rollen som business analyst i 3 månader nu som trainee så känner jag att jag fått mycket bättre koll på hur systemet ska fungera, vilket så klart kommer att hjälpa till mycket när man vill laga buggar.

Ett kort inlägg från mig denna gång. Ha en bra fortsatt vecka!

Nu är testblocket, den första fasen av traineeprogrammet, över, så jag tänkte summera mina upplevelser under min första tid här på Cinnober. I breda ordalag har mina förväntningar överträffats: Arbetet är utmanande, intressant och variationsrikt, medarbetarna är trevliga, kompetenta och positiva och arbetsmiljön känns sund. Företaget visar stort förtroende för de anställda genom frihet under ansvar. Det finns få restriktioner på vilka verktyg, miljöer och system man använder (bortsett från de som projektet kräver) och det finns möjligheter att arbeta hemifrån när privatlivet ställer krav. I utbyte förväntas vi själva visa disciplin och se till att vara produktiva och det får jag intrycket av att folk gladeligen gör. Förtroendet betalar sig flera gånger om genom hög moral och större möjligheter till innovation och kreativitet.

Releasen på LME Trade har gått bra hittills. Vi arbetar flitigt med att åtgärda de mindre buggar som kvarstår, även om kärnfunktionaliteten är på plats och är i stort sett stabil. Dessa levereras i mindre patchreleaser med några veckors mellanrum. Det återstår dock en lång fas på ett flertal månader där kunden utför egna tester innan systemet sätts i produktion, så med stor sannolikhet återstår en hel del detaljarbete. När systemet väl sätts i produktion kommer det dessutom behöva underhållas då det alltid finns verkliga situationer som man inte kunnat planerat för. Parallelt med detta börjar nästa version av systemet planeras.

Nästa vecka börjar utvecklarblocket. Utveckling av mjukvara utgör huvuddelen av min akademiska och professionella bakgrund och har varit min stora passion sedan många år tillbaka, så det ska bli spännande att börja jobba med på allvar här på Cinnober. Jag har redan fått en hel del insikt i hur systemen och miljöerna fungerar under testblocket, tack vare alla automattester som skrivits, och det kommer vara mycket nyttigt framöver. Som jag konstaterat i tidigare inlägg är det startsträckan som är tyngst i den här branschen, och genom traineeprogrammets upplägg har den förkortats avsevärt. Hur det går berättar jag om nästa gång!

Vi hörs!

Snart är det jul! Det förbereder vi oss på här på kontoret genom att tända lite ljus, dekorera med gran och äta saffransklipp. Alla är lediga för det är röd dag. Förutom jag, då!

Den 24e kommer jag att vara on call, d.v.s. jag kommer att vara tillgänglig hela dygnet för LME Clear, utifall någonting dåligt mot förmodan händer i deras system under julafton. Det råkar nämligen vara så att den 24e inte är en helgdag i London, eftersom de firar jul dagen efter, och då är börsen stängd. Det betyder såklart att jag kommer att sitta och dricka glögg med telefonen redo utifall någon ringer.

Det här för mig naturligt till det jag egentligen tänkte berätta om i det här inlägget, nämligen varför är börser stängda på juldagen? Det är ju egentligen ganska konstigt tycker många, eftersom moderna börser är elektroniska och många skulle nog kunna vara öppna dygnet runt. På samma sätt finns det fortfarande en ”ring” på LME (och ett tradinggolv på NYSE –https://gemsonwallstreet.files.wordpress.com/2013/02/each-bank-has-its-own-booth.jpg), som Johan berättade om tidigare.

Börser och clearinghus, har jag lärt mig, är både väldigt intresserade av modernisering (nya, snabbare och stabilare system för att möta efterfrågan och konkurrens) och av traditioner. Ett exempel på traditioner som fortfarande är viktiga för LME är ringen, och något som kallas för 3M-kontrakt (forwards som expirerar om tre månader). Anledningen till att 3M är viktigt är att det tog så lång tid år 1877 för koppar att levereras till England från Chile.

De här traditionerna tillsammans med den moderna tekniken gör finansbranschen väldigt intressant: det är mycket maskiner, high frequency trading, blixtsnabb matchning och avancerade riskberäkningar – samtidigt är det mycket människor, magkänsla och traditioner som leder till hög likviditet, god prissättning och bra övervakning.

Blandningen är spännande, inte minst för matematiker som jag, som tycker om komplicerade och oväntade samband. Nog för mig för idag, men jag lämnar er med en liten artikel om NYSE, en både modern och traditionell börs: http://www.investopedia.com/articles/basics/03/103103.asp

07:21 vaknar lite sent, bestämmer mig för att skippa frukost hemma och äta frukost på kontoret
07:58 tar bussen till jobbet
08.15 Anländer till kontoret. Börjar med att kolla mailen för att kolla om något viktigt kommit in och borde prioriteras upp
08.25 Äter frukost. Cinnober tillhandahåller fil, yoghurt, musli, nötter osv för de anställda
08.35 Det bestäms lite snabbt med de andra Business Analyst’s att vi ska ha ett möte fram till 09.15 för att få översikt över de change items som ska in i denna utvecklingssprint. Vi går igenom samtlig nyfunktionalitet som ska in i systemet fram till Q1 leverans som ska ske någon gång i januari.
09.15 En av fem BA:s går på support-teamets scrum som pågår en kvart. Support-teamet har hand om alla buggar som kunden rapporterar in. Jag går tillbaka till datorn och kollar mail och vilka uppgifter jag borde ta tag i under dagen.
09.30 Scrum för nyutvecklingsteamet. I vanliga fall har vi 15 minuters scrummöte per dag då man säger vad man jobbar på och om man behöver hjälp med något. Vi bestämmer oss för att gå igenom alla change items för att kolla status och vilka som kommer att komma med i den code-drop vi lämna över till kunden om två veckor. Denna code-drop räknar vi inte som en riktig release utan används bara för att kunden ska få lite early visibility och hjälpa oss med testningen.
09.50 tillbaka vid skrivbordet och arbetar med ett change item jag jobbar på som har att göra med att inkludera en bank identifieringskod på ett SWIFT meddelande som vi skickar ut från systemet.
10.10 En kollega kommer med lite frågor ang. olika bokföringskonton vi har i systemet. Detta mynnar ut i att vi sitter vid hennes dator en längre tid och undersöker hur pengar och obligationer bokförs i systemet. Vi tror att vi har en möjlig bug som måste undersökas vidare.
11.11 Jobbar vidare på min change item. En utvecklare som just nu implementerar en change item som jag kravade färdigt igår kommer med lite frågor.
12.00 Lunch. Jag har tagit med en matlåda; kyckling med curry, champinjoner, lök och lite riven ost i ugn. Riktigt gott
12.50 Fortsätter jobba efter lunchrasten. Jag och en till BA har bestämt möte för att göra klart tidsestimat för fyra change items vi fick in tidigare i veckan från kund. Vi ska estimera tid för krav, utveckling och testning och tar hjälp av de experter inom motsvarande område vi tror kan göra en så bra tidsuppskattning som möjligt för aktuell nyfunktionalitet.
13.50 En kollega som sitter bredvid jobbar lite på en bug i produktion som har med riskberäkningar att göra. Vi brainstormar lite tillsammans möjliga fel, ett tag tror vi att det kan ha att göra med räntekurvor som vi prenumererar på från reuters. En del av de derivat som vi clearar i clearinghuset räknar risk justerat med en räntekurva. Tanken med det är att pengar idag är värt lite mer än pengar imorgon på grund av b.la inflation.
15.00 Vi har schemalagt en kvarts fikapaus en gång per dag på initiativ av en kollega. Tidigare har vi varit dåliga på att ta en kafferast och bara prata lite grann.
15.15 Fikat är över och fortsätter med kravarbetet
16.05 Får accept fyra krav jag skrivit som hör till en change item från kund. Detta innebär att vi kan börja utvecklingen på tillhörande change item. Jag kontaktar projektledaren och meddelar att vi har en change item som vi kan börja utveckla på varpå en lämplig utvecklare får uppgiften. Efter en kort överlämning börjar implementeringsarbetet.
17.20 Slut för dagen, dags för hemgång.