Service desk och TAM


No Comments

Nu är jag nyligen återvänd från en vecka i Stockholm på Cinnober Service Desk, som initierar det sista traineeblocket. Denna avdelning har i uppgift att övervaka både interna system och kundsystem, hantera supporttickets från kunder och administrera stödsystem som alla utvecklingsprojekt utnyttjar. Man skulle kunna likna det vid ett nervsystem som dirigerar kritisk information mellan övriga organ i företaget. Service Desk är aktiv 24 timmar om dygnet, vilket innebär att personalen arbetar i roterande 8-timmarsskift, och under min tid där fick jag sitta på morgonskiften, från kl 06.00 till 14.00 på eftermiddagen.
 
Överlag kan man säga att det var både roligt och lärorikt. Det är svårt att komma in i rutinen på en ny avdelning på bara en vecka, men det är alltid nyttigt att få en insikt i hur andra delar av företaget arbetar, vad deras roll är och hur de påverkas av vad som händer i resten av företaget. Service Desk är en avdelning vars dagliga arbete styrs i hög grad av regelbundna rutiner. En stor del av arbetet består i att konstant förbättra och effektivisera rutinerna för att frigöra tid, minimera risken för misstag och göra responstiden vid incidenter snabbare. Det finns något mycket tillfredställande med att kunna göra punktinsatser som sparar tid i allt framtida rutinarbete. Speciellt roligt var det för mig att kunna bidra med mina utvecklingskunskaper för att skripta upp en del rutiner, trots min brist på Service Desk-erfarenhet.
 
Denna vecka, och i tre veckor framåt, kommer jag istället arbeta som TAM, Technical Account Manager, hos LME Clear. Man skulle kunna säga att en TAM hanterar alla tekniska arbetsuppgifter på ett projekt som inte är direkt knutet till utveckling. En TAM sätter upp testmiljöer, hjälper kunder installera och konfigurera produktionsmiljöer samt lösa hårdvaru- och nätverksproblem. Även här finns det ett stort värde i att kunna hitta metoder för att automatisera och effektivisera rutinarbeten, och jag har nästan omedelbart kunnat dra nytta av mina tidigare färdigheter för att bidra, även om man naturligtvis aldrig riktigt kan arbeta med maximal produktivitet när man precis kommit in i en helt ny roll. Ett stort plus är att den här rollen ger mig en djupare teknisk insikt i Cinnobers system som jag med största säkerhet kommer ha stor nytta av i framtida projekt.
 
På återseende!

No Comments - Click here to be the first to comment!





Bookmark and Share

Please leave a comment - click here!

Design och projektplanering


No Comments

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å!

No Comments - Click here to be the first to comment!





Bookmark and Share

Please leave a comment - click here!

Kurs i utveckling


No Comments

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!

No Comments - Click here to be the first to comment!





Bookmark and Share

Please leave a comment - click here!

Från test till utveckling


No Comments

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!

No Comments - Click here to be the first to comment!





Bookmark and Share

Please leave a comment - click here!

Slutspurten inför leverans!


No Comments

Nu börjar det dra ihop sig till leverans! Imorgon ska allt vara klart och igår hade vi kodfrys. Detta innebär att vi slutar checka in ny funktionalitet och istället fokuserar på att bekräfta att den existerande funktionaliteten fungerar som den ska. Hela teamet, inklusive projektledare, kravare och utvecklare ägnar sig åt manuell testning, och kodfixar får endast checkas in efter överenskommelse, för att minimera risken att nya buggar introduceras i det här sena stadiet.

Man hör ofta skräckhistorier om hur utvecklingsteam får jobba långa veckor och sena kvällar just innan leverans för att hinna med att möta sin deadline, men så har inte fallet varit på det här projektet. Visst har det varit någon enstaka kväll här och där, men överlag är det business as usual häromkring.

Mjukvara blir, generellt sett, aldrig färdig. Det finns alltid mer användbar funktionalitet att implementera, fler buggar att fixa, stabiliteten och prestandan kan alltid förbättras, osv. Eftersom tiden ändock är begränsad uppstår behovet av att prioritera bland de många vägar man kan gå. Detta är speciellt sant precis innan en leverans. Målet är att leverera så mycket som möjligt, men det är omöjligt att hinna med allt, och då krävs att man identifierar det som är kritiskt för att projektet ska betraktas som framgångsrikt från kundens perspektiv och det som är acceptabelt att förskjutas till en senare patch. Vi har dock hunnit med den stora majoriteten av det som planerats, så det är god stämning och vi förväntar oss en nöjd kund.

Hörs igen snart!

No Comments - Click here to be the first to comment!





Bookmark and Share

Please leave a comment - click here!

Automattest


No Comments

Nu har det automattestats i några veckor och det har varit riktigt kul, så jag tänkte relatera lite grann av vad jag lärt mig  om att skriva automattester den senaste tiden.

Automattestning skiljer sig åt från manuell testning på några nyckelpunkter. Den stora fördelen med automattester är naturligtvis att det inte krävs en mänsklig testare för att exekvera testerna, och att det därmed går betydligt snabbare. Detta innebär att man kan sätta upp automattester som körs varje gång ny kod blir incheckad och kan upplysa teamet om potentiella problem med förändringen tidigt. Tar det för lång tid att köra igenom den totala testuppsättningen kan man välja ut nyckeltester som körs kontinuerligt och enbart köra alla tester över natten eller på ännu längre sikt. Dessutom garanterar automattester att de körs exakt enligt specifikationen varje gång, medan en människa lätt kan glömma att testa vissa detaljer.

Automattester har dock svagheter, och den sista punkten är båda en styrka och en svaghet. Nackdelen med att ha ett test som följer specifikationen exakt är att det inte lämnas något utrymme för variation och kreativitet i testprocessen. Testet garanterar att funktionaliteten som testet täcker fungerar, men existerar en bugg som triggas av att man varierar indatan lite grann kommer testet inte detektera den. En mänsklig testare skulle å andra sidan kanske naturligt variera indatan varje gång, och därmed ha större chans att trigga problemet. Manuell testning tillåter dessutom större flexibilitet, testaren är medveten om vilka förändringar som introducerats till systemet över tid och kan ta hänsyn till det i testproceduren. Ett automattest kan däremot snabbt bli obsolet, och i bästa fall innebär det att testet fallerar trots att systemet fungerar och i värsta fall passerar det och döljer faktiska problem. Tillsammans med den relativt höga tidskostnaden för att skriva testerna till att börja med kan utveckling och underhållning av automattester ta betydligt mer tid än de är värda, såvida testerna inte har hög “impact”, dvs att de har stor chans att detektera buggar om de uppstår.

Detta gör uppgiften att skriva bra automattester både utmanande och rolig. Att fundera ut vilka typer av tester man ska investera sin dyrbara tid i att skriva är en i allra högsta grad kreativ process. Det kräver att man är både djupt insatt i hur produkten man bygger är tänkt att fungera och att man har förståelse för vilka tekniska faktorer som tenderar att leda till felkällor.

Vi hörs!

No Comments - Click here to be the first to comment!





Bookmark and Share

Please leave a comment - click here!

Ny start


No Comments

Hej!

Jag heter Lucas Lindström och är ny trainee här på Cinnober. Jag är född och uppvuxen här i Umeå där jag läst på civilingenjörsprogrammet i teknisk datavetenskap. Jag tog examen vid nyår och har varit projektanställd som utvecklare under de första åtta månaderna av 2014. Jag hörde talas om Cinnober och cinCube av en kompis från universitetet, Oskar Janson, som också var trainee. Det verkade som en intressant och utmanande arbetsplats i en industri jag inte visste så mycket om men kände mig driven att lära mig mer om.

Nästan fyra veckor har gått sen jag började och det har varit full fart från dag ett. Det är alltid en utmaning att börja på ett nytt ställe och lära sig alla rutiner och processer, och även om jag hunnit arbeta på några olika ställen under och efter utbildningen är jag fortfarande väldigt ny på arbetsmarknaden. Cinnober är dessutom den största organisation jag arbetat hos hittills med ganska stor marginal, men trots det tycker jag att det varit en väldigt mjuk landning hittills. Större delen av första veckan bestod i en intensivkurs i allt från företagets historia och verksamhet i stora drag till systemarkitektur och arbetsmetodik i de olika projekten. Detta gjorde det mycket lättare att komma igång och förstå hur min roll passar in i den större bilden. En annan sak som gjort det så mycket lättare att komma in i tänket är den öppna och vänliga sociala atmosfären på företaget. Folk är alltid beredda att hjälpa till och svara på frågor när man kör fast eller inte förstår någonting.

De första tre månaderna av traineeprogrammet består av det så kallade testblocket, där man får pröva på rollen som mjukvarutestare. Att lära mig mer om test och kvalitetssäkring är något jag sett fram emot, eftersom det känns som nyttig erfarenhet oavsett vilken roll i utvecklingsprocessen man har, och något som jag saknat från universitetet.  Arbetet har hittills bestått framförallt i manuell testning av den grafiska klienten till LME Select (börsmotorn till London Metal Exchange, Cinnobers äldsta kund), blandat med halvdagskurser i mjukvarutest på Cinnober och i allmänhet. Det har gått snabbt att komma igång och kunna bidra till projektet och det känns mycket motiverande. Det är dessutom ett utmärkt sätt att bekanta sig med produkten och kundens förväntningar, liksom finansiell IT i allmänhet, vilket jag kan föreställa mig är viktigt även i andra roller. Nästa vecka ska jag börja skriva automatiserade tester, och det känns riktigt kul också.

Förhoppningsvis kommer den här bloggen ge insikt i hur cinCube-programmet fungerar och hur det är att börja arbeta på Cinnober, och jag är alltid öppen för frågor. Vi ses!

No Comments - Click here to be the first to comment!





Bookmark and Share

Please leave a comment - click here!