Hej!

Nu har det gått två veckor sedan Simon sist skrev ett blogginlägg. På dessa två veckor har väldigt mycket hunnit hända. Förutom det dagliga arbetet som består av manuellt testande har vi fått ett autotest som ska skrivas som en början på nästa del av testblocket. I de manuella testerna får man oftast leta runt och utforska för att se om funktionaliteten är den man förväntar sig. I autotesterna däremot kontrollerar man gärna sådant man vet, t.ex. utdata mot känd indata vilket inte borde förändras bara för att man patchar något annat. Helt enkelt, ett relativt snabbt sätt att kontrollera att saker fortfarande fungerar när man gör förändringar.

En rolig grej som Simon berättade om i sitt inlägg var att vi hade Shipit. Shipit är en händelse på Cinnober som pågick från 12:00 på torsdagen till 12:00 på fredagen där alla på företaget hade möjlighet att göra/bygga vad de ville. Jag och Simon gick med i ett projekt där man skulle bygga ett testverktyg för SWIFT meddelanden. SWIFT är ett protokoll som används av banker för att genomföra transaktioner. I det system vi jobbar i används det bland annat för att bokföra pengar och värdepapper som pant på den handel man utför. Kort sagt åker SWIFT-meddelanden lite fram och tillbaka och när man vill lägga in pant för att testa detta behövde testaren manuellt redigera meddelandena efter mallar. Det testverktyget gör är att automatisera processen att godkänna meddelanden och skicka in svar vilket sparar otroligt mycket tid när man testar.

Själva Shipit dagen var mycket rolig och vi satt sent på torsdagsnatten och kodade på vårat lilla projekt drivna i äkta lan-anda på pizza och andra godsaker. Typen av projekt var väldigt blandade, allt från testverktyg och tidsrapporteringsprogram till spel, finansiell teori och nätverksanslutna arduino med olika sensorer. Bredden och kvalitén på shipit projekten var fantastisk och det var riktigt kul att vara en del av. Lite olika priser delades ut och vi vann faktiskt ett pris för bästa projekt då det blev ett riktigt bra resultat och halva gruppen bestod av rena nykomlingar. Det var en fantastiskt kul dag (och natt) och jag ser fram emot nästa tillfälle!

Prisutdelning efter Shipit, notera de magnifika tröjorna dagen till ära!

Avslutningsvis har scrum-teamen i projektet blandats om och jag och Simon sitter inte längre i vår egna lilla traineehörna. Vi började jobba här  mitt i en sprint och vi får nu möjlighet att vara med från början när vi nu går in i en ny utvecklingsfas, vilket känns  riktigt bra.

Sex veckor har nu flugit förbi i rasande fart. Tillfällena där vi går kurser och utbildningar blir mer och mer glest utspridda och vi blir istället mer och mer invävda i det daliga arbetet. Vi har såklart otroligt mycket kvar att lära men sakta men säkert smyger vår testledare på oss mer krävande arbetsuppgifter.

I början av vår tid här på Cinnober var det dagliga arbetet i projektet huvudsakligen centrerat kring supportarbete. Men, projekt förändras hela tiden och efter förra releasen som skedde för några veckor sedan så är det nu dags för utveckling av ny funktionalitet. Det ska bli intressant att se hur det förändrar arbetssättet och allt som det innebär. Framför allt så känns det bra att vara med och planera arbetet redan från början.

Vad har vi mer hunnit med under de här sex veckorna då? Tja… lite blandat faktiskt: karriärdag för studenter på Umeå universitet, firmafest, ett jubileum och löpträning under lunchen för att nämna några. Alltid händer det någonting.

Nu taggar vi inför ShipIt Day på torsdag/fredag. Ett hackaton-liknande event där alla som vill får 24 timmar på sig att vara kreativ och göra precis vad de känner för. Så t.ex. skriva det där fantastiska skriptet som underlättar din vardag, ta fram ett spel som förklarar trading på ett lätt sätt, eller som vi – skapa ett verktyg som underlättar testning av SWIFT-relaterad funktionalitet (SWIFT är en internationell standard som används vid penningtransaktioner mellan banker). Det bästa projektet vinner dessutom ett pris! Alla på kontoret har talat sig varma om tidigare ShipIt-event så förväntningarna är höga kan man nog säga.

Mer om hur det gick under ShipIt kommer nog Viktor skriva om i nästa blogginlägg.

Till dess, ha det bra

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

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