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.

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!

Nu har go-live kommit och gått i LME Clear, vi har varit med och lanserat LMEmercury, europas modernaste clearingsystem, vi har firat och svettats om vartannat. Men projektet är såklart inte över för den sakens skull – nu är det fokus på ny funktionalitet, alltså nya saker som kunden kommit på att de vill ha av en eller annan anledning, och som vi ska implementera.

Ett exempel är renminbi, den kinesiska valutan, som nu ska få användas som säkerhet i systemet. Renminbi har blivit populär i samband med Kinas framgång finansiellt i världen, och LME är inte sena med att lansera den funktionalitet som medlemmarna vill ha. Man kan läsa mer om just detta på följande sida:

http://usa.chinadaily.com.cn/business/2014-09/23/content_18644730.htm

Det är då vårt jobb att implementera det hela. Men det är självklart också en hel del kravarbete (som jag jobbar med nu) involverat från vår sida – hur ska säkerheten egentligen fungera – finns det speciella regler – vad kommer att bli påverkat?

För att ta hand om ny funktionalitet så måste vi som kravare gå genom en process där vi för varje förändring förstår och nedtecknar verksamhetens behov (varför gör vi det?), processerna som påverkas (när gör vi det?), detaljer kring vem eller vad som ska få utnyttja funktionaliteten (vem eller vad gör det?), och slutligen detaljerna kring vad funktionaliteten egentligen innebär (hur gör vi det?).

Det krävs en helhetsbild för att kunna förstå och formulera vad som ska göras för att systemet ska bli så nära det som kunden vill ha och för att utvecklare ska förstå vad de ska implementera.

Nu ska jag återgå till mitt kravarbete, så hörs vi i december!

Den 22 september gick vårat clearinghus live och alla positioner från metallbörsen LME som tidigare clearades på London Clearing House, LCH, migrerades över till vårat nybyggda clearinghus LME Clear. Nu har det gått lite över en månad sedan produktionssättningen och det är dags att börja blicka framåt. LME har många nya funktioner de vill ha in i sitt clearinghus. När vi planerar arbetet framåt måste jag som kravare försöka ligga 1 sprint före utvecklarna på den nya funktionaliteten då vi försöker vara klara med alla eventuella missförstånd med vad kunden vill ha och vad vi kommer att leverera innan utvecklarna börjar koda.

Både VD och CTO från LME Clear har varit i Umeå i veckan och igår firade vi produktionssättningen med god mat och dryck på kontoret. LME Clear’s VD berättade resan från början av 2011 fram till idag om hur man sjösätter ett nytt clearinghus. Det är inte bara systemutveckling utan mycket annat som ingår som t.ex godkännande från övervakande myndigheter som Bank of England och EMIR som är nya EU regler för övervakning av derivatmarknaden i Europa. Han berättade också om planerna framöver för clearinghuset och det verkar som vi har mycket nyutveckling att se fram emot.

Här kan ni läsa ett pressmeddelande som övergripande beskriver LME Clear vid produktionssättningen.

http://www.cinnober.com/news/paradigm-shift-real-time-clearing-becomes-reality-europe

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!

Nu har det gått en stund sedan jag sist postade. Vi har gått över i krav efter att ha gjort och presenterat en ”slutuppgift” inom utveckling, nämligen en design på en ny ”fee server”, alltså en komponent som kan räkna ut avgifter i ett clearingsystem.

Det är en intressant utmaning som kräver att man tänker på flera nivåer – vår uppgift var att på en gansk abstrakt nivå visa fördelarna och nackdelarna med några olika modeller.

Några saker vi blev tvungna att tänka på: vad är lätt med just den här designen? Vad är svårt? Vilka är intressenterna i just den här modellen? Vad vill de, och varför?

Lite sådana tankar ledde till att vi presenterade fyra olika modeller av servern med olika möjligheter att ta hand om avgifter och olika styrkor och svagheter. Ungefär såhär såg det ut när vi presenterade:

En av de stora anledningarna till att vi har tittat på det är såklart att det finns stor efterfrågan bland clearinghus att automatiskt hantera avgifter (t.ex. medlems- och transaktionsavgifter) på ett pålitligt och konfigurerbart sätt.

Nu är dock designtankarna utflugna i mitt huvud (men kanske har de landat hos någon annan på företaget) och istället finns där kravtankar.

Ses i kravrollen!

Nu har jag påbörjat det tredje blocket på Traineeprogrammet här på Cinnober, det så kallade kravblocket. Krav innebär i stora drag att man lyssnar på kundens behov, försöker förstå dem och sedan tillsammans med kunden kommer överens om vilken IT lösning man ska leverera. Det här är förstås väldigt viktigt för att säkerställa att man levererar exakt det som kunden vill ha och inte slösar bort tid på att utveckla felaktiga lösningar och antaganden. Kravrollen på Cinnober innebär för det mesta att man arbetar som en så kallad Requirement analyst. En Requirement analyst har som uppgift att fånga krav från kunden och dokumentera dessa genom att skriva t.ex. use cases som sedan en utvecklare kan programmera utifrån. Våra testare använder sedan ofta de use cases som ingår i kraven för att testa att systemet beter sig så som kraven säger.
En annan typ av kravroll är Business analyst (BA). En BA har som uppgift att förstå verksamheten och dess behov. I projektet jag arbetar i nu så är det en grupp med BA’s hos kunden som har stenkoll på deras behov och tillsammans med kravare hos oss kommer överens om IT-lösningens utformning. Jag tycker det ska bli jätteroligt att få prova på mer kundkontakt och även att förhandla och komma överens med kunden om hur systemet ska fungera. Vi får in ganska många så kallade Change Requests från kunden som är ny funktionalitet dom vill ha implementerat och dessa ska vi som kravare tidsuppskatta och sedan omvandla till krav.

Många nya utmaningar framför mig alltså, känner på mig att det kommer bli en rolig och utmanande höst!

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!

Och så har även jag återvänt från en lärorik vecka hos Service Desk precis som Maryam och Oskar. Som dom beskrev så testade vi samtliga av dom 5-shift som Service Desk använder sig av, under dem 5 dagarna vi var där. Resultatet blev ett par spännande dagar där vi fick uppleva hur dem olika tidszonerna runt om jorden påverkar finansmarknaden då marknaden i östra USA och Asien går lite omlott.

Hur som helst så har mycket hunnit hända under det året jag varit här på Cinnober. Projektet LMEClear som jag varit del av under hela perioden har här om dagarna blivit klar och gått live, och vi har hunnit med en otrolig mängd kurser och olika aktiviteter under traineeprogrammets gång.

Ett år som passerat betyder också att Traineeprogrammet nu är slut för oss i första trainee-kullen, så för min del betyder det att jag byter till ett nytt projekt och fortsätter som utvecklare på heltid. Så jag lämnar nu över bloggen till Rasmus och Johan, samt till vår nya trainee som kommer presentera sig inom kort.

Tack för mig!

På måndag ska LMEClear go live. Nästa vecka är vi på kontoret från kl 7 fm till 1 fm. Vi är uppdelade i 3 grupper: AM skift 7-17, PM skift 15-1 och och de som jobbar under vanliga arbetstider och är On Call dagen runt. Jag jobbar PM skift. Det kommer bli spännande och jag får sova till typ 12 i en hel vecka! 😀

På måndag kommer LMEClear, deras medlemmar och regulatorer bestämma sig tillsammans om vi skulle Go live eller inte, det är ett Go-No Go möte. Men efter att ha testat systemet på olika nivåer då är vi säkra att vi går live utan stora problem!

Vi har den här skärmen på kontoret som räknar ner hur lång tid är kvar till Go-Live!

Cheerios!