« Hem

BizTalk Server – fem vanliga misstag

Jag har tidigare skrivit en del om BizTalk Server, som är Microsofts integrationsplattform och den vi på Integrationsbolaget använder mest, åtminstone i Örebro och Stockholm. När jag började jobba hade jag bara en vag aning om vad BizTalk var, ännu mindre om hur en faktiskt använder plattformen, och det var en hyfsat brant inlärningskurva under de första veckorna. Idag, nästan tio månader(!!!) senare, börjar jag känna mig bekväm med BizTalk. Jag kan snabbt sätta upp ett enkelt dataflöde och det har blivit betydligt lättare att förstå befintliga lösningar – så länge de är byggda på ett hyfsat vettigt sätt. Och detta leder mig in på ämnet för dagens blogginlägg:

Vanliga misstag inom BizTalk Server

1. Placera alla komponenter i samma VS-projekt

Det finns fem komponenter som du troligtvis kommer hantera i Visual Studio:

  • Orkestreringar
  • Pipelines
  • Mappningar
  • Scheman
  • Ev. hjälpklasser

I början har du kanske bara ett par instanser av varje komponent, och det är smidigt att lägga dessa i samma projekt. Men snart växer lösningen och plötsligt sitter du med ett projekt som innehåller massor av olika delar och när du behöver uppdatera en av dem får du genast problem, eftersom allt måste kompileras om även om du bara ändrar på en liten detalj i ett schema.

Tips: Ett projekt för varje typ komponent. Det kommer underlätta vid ändringar, plus att personen som bygger vidare på projektet lätt kan få en överblick över lösningen.

2. Placera alla integrationer i samma BizTalk applikation

I BizTalk Servers administrationsgränssnitt kan du dela upp integrationerna i olika applikationer. Det är ett misstag att inte göra detta! Visst är det enkelt att göra det till en början, men snart kommer applikationen att svämma över av logik som inte har något med varandra att göra, det blir svårt att separera flöden från varandra och plötsligt sitter du där med en spagetti-applikation som bara du förstår.

Tips: det kan vara svårt att göra avgränsningar, men ett generellt tips är en applikation per logisk enhet eller integrationsflöde. Är du ny? Fråga dina kollegor!

3. Dålig namnsättning

Det här är ett generellt problem för newbies inom programmering/systemutveckling, men jag tycker det är extra viktigt inom just systemintegration. Precis som i all programmering är det viktigt med rätt namn på metoder och klasser, men det blir ännu tydligare gällande portar, orkestreringar och mappningar. I en metod kan du oftast läsa dig till vad den gör, eller i värsta fall köra koden och debugga den för att förstå den. De olika delarna i en integration kan dock inte testas lika enkelt, och ordentlig namnsättning gör att flödet av data blir tydligare för den som ska underhålla applikationen efter dig.

Tips: namnkonventioner varierar mellan olika företag, så se till att kolla vad som gäller för just ditt projekt. Det finns en del generella guidelines, som du kan läsa om exempelvis här eller här.

4. Uppfinna hjulet på nytt

Såhär är det: det allra mesta har gjorts förut. Speciellt de förhållandevis ”enkla” uppgifter som nybörjare ofta får på en arbetsplats, så det finns ingen anledning att försöka göra egna varianter – speciellt när det gäller BizTalk och de adaptrar som finns out of the box. Integrationen blir lättare att förstå, underhålla och konfigurera genom de verktyg som finns, snarare än att skriva egen kod. Ny, egenskriven kod är dessutom betydligt mindre robust gentemot de färdiga lösningar som redan finns och används.

Tips: Läs på om de adaptrar som BizTalk har out of the box, och börja alltid med att leta färdiga lösningar på ditt problem, innan du försöker lösa det på egen hand. Se också till att du har koll på standardiserade sätt att göra saker, exempelvis hur du exponerar en orkestrering som en webbtjänst, eller konsumerar en webbtjänst från en sendport. BizTalk har metoder för att göra detta – följ dem istället för att försöka lösa det på egen hand.

5. Bygga alltför komplexa flöden

Det här är en riktigt svår fråga att besvara som nybörjare: vilken logik hör faktiskt hemma i BizTalk och vad hör hemma hos de olika systemen? När en kommit över den första inlärningskurvan så inser en ganska snabbt: du kan göra i stort sett vad som helst med BizTalk. Vilket problem du än har så går det med största sannolikhet att göra med BizTalk och ett par egenskrivna hjälpklasser. Men, bara för att det går att göra betyder det inte att du ska göra det.

Tips: Generellt sett brukar en säga att processlogik och konverteringar hör hemma i BizTalk, men att affärslogik ska hållas i respektive system. Det här är inte alltid möjligt, så är du osäker på om en viss logik bör ligga i en orkestrering eller någon annanstans – fråga en senior kollega!

Det var allt för den här gången! Midsommarveckan har precis börjat och semestern närmar sig med stormsteg för många av oss. En annan har några veckors jobb kvar innan det blir dags för ledighet, så räkna med ett par inlägg till innan bloggen tar sommarlov! 

BizTalk Server – de 4 största nybörjarmisstagen

Inför inledningen till det här blogginlägget satt jag och googlade på ”mistake quotes”, och jag hittade en hel del om relationer och livet i allmänhet, typ ”Det är mänskligt att göra misstag” och ”gör du inga misstag så har du inte försökt” . Ord som parafraserats alldeles för många gånger, ”memefierats” och helt dränerats på betydelse. Ändå ligger det något korn av sanning i dessa klyschor. Som någon sa: ”Your best teacher is your last mistake”, och visst är det så. Jag gjorde mitt senaste misstag för ungefär två timmar sedan nu, och oj vad jag lärde mig av det…

Det finns ju dock en viss mening i att inte göra alla misstag själv, utan lära sig av andras. Därför tänkte jag dela med mig av de, enligt mig, 4 största nybörjarmisstagen som nästan alla gör i början av BizTalk karriären. Eller ja, alla utom du, eftersom du nu lär dig av mina misstag och kan undvika dem. Förhoppningsvis.

Kolla vad som egentligen händer

Det största felet som nybörjare inom programmering gör generellt är nog att inte läsa felmeddelanden utan sitter och bara kliar sig i huvudet av förvirring när saker inte funkar. Samma gäller inom BizTalk – du måste ta reda på vad som händer när det verkar som att ingenting händer. Min process för att göra detta ser ut som följer:

1. Första steget är alltid att se om det finns några suspenderade meddelanden i BizTalk Group Hub. Meddelanden försvinner inte i tomma intet (även om det ibland känns så!) och vid de flesta felen så fastnar (suspenderas) det meddelande du försökte skicka och du kan kolla på innehållet samt det felmeddelande som.

capture2

2. Hittar du inget där, är nästa steg att ta en titt i eventloggen, där information, varningar och fel från bland annat BizTalk loggas.

capture

3. Om jag inte hittat något fel i eventloggen brukar jag använda tracking för att se om meddelandet tagit den vägen genom integrationen som jag har tänkt. Tracking visar helt enkelt hur meddelandet såg ut när det kom in till porten eller orkestrering och hur det ser ut när det bearbetats och skickats vidare till nästa instans. Ofta kan man på det här sättet spåra vad det är som händer i integrationen.

capture3

Den här processen sviker sällan – och om den gör det så beror det troligtvis på något av kommande vanliga misstag. En bonus för att felsöka orkestreringar är att använda debugviewer, ett verktyg som låter oss läsa meddelanden vi skriver i koden med hjälp av ex. System.Diagnostics.Trace.WriteLine(). Glöm inte heller bort att det går att attacha en debugprocess i Visual Studio till BizTalk, så du kan steppa igenom koden rad för rad, samtidigt som den körs.

Skit in, skit ut

När jag har bankat huvudet mot en vägg gällande ett problem i flera timmar och inte förstår vart i processen felet ligger, är det här ofta orsaken. Anledningen till att jag inte förstår felet är enkel – det finns inget fel. Det är meddelandet som jag försöker skicka igenom integrationen som inte är korrekt.

Bildresultat för shit in shit out

Glöm inte gaccen!

Jag har varit inne på ämnet GAC och att ”gacca” assemblys tidigare, troligtvis var det i samband med *saker som jag önskar att jag lärt mig i skolan*. ”Gaccen” är (mycket förenklat för min egen skull, klockan närmar sig 17 och det är fredag) en folder där alla assemblys måste ligga, för att BizTalk ska kunna komma åt dem. Alla scheman, orkestreringar, pipelines, hjälpklasser – allt måste ligga här för att integrationen ska rulla. Har du gjort en förändring i koden som inte verkar funka? Kolla så den nya versionen av assemblyn är gaccad ordentligt.

Har du startat om host instansen?

Det här är det överlägset största misstaget man gör som nybörjare, och jag kan nog inte ens räkna hur många gånger det hänt mig. En host är en logisk container för BizTalk objekt, och en host instans är dess fysiska representant, återigen väldigt förenklat.

capture4

Bildkälla

Vid varje ny deploy så måste berörda host instanser startas om för att förändringarna ska registreras av BizTalk. Host instanserna kan också vara förklaringen till att en receive location inte plockar upp meddelanden som den ska – är hosten stoppad, så kan inte BizTalk ta in meddeladet. Jag har blivit bättre på att komma ihåg det här numera, men det har tagit tid att få in rutinen att alltid kolla status och starta om dem vid behov.

Med detta önskar jag er alla en trevlig helg!

Ett år av systemintegration senare

Idag är det den femte oktober 2016. Det innebär att det är nästan exakt ett år sedan jag skrev mitt första inlägg på den här bloggen. Det låter nästan overkligt när jag skriver det – hur kan ett år gå så fort? Mycket har dock hunnit hända under den här tiden, och när jag tänker att jag ska försöka summera året i ett inlägg inser jag att det inte är möjligt. Jag får plocka ett par russin ur kakan helt enkelt.

Ett tråkigt besked

Jag har funderat en stund på frågan ”vad har varit bra och vad har varit mindre bra under året?” och kommit fram till att det bara är en enda sak som hamnar i den negativa kategorin. Oslokontoret  har avvecklats och min största idol och mentor har försvunnit från bolaget, nämligen Lena Padukova. Det var hon som lyckades övertyga mig om att integration var kul och tack vare henne jag började jobba på Integrationsbolaget, och det känns väldigt tråkigt att hon inte är kvar.

lena

Foto från tidigare bloggpresentation, av: lephoto.se

Men jag är ändå glad att jag hann vara kollega med henne i några månader, och jag kommer alltid vara tacksam för hennes råd och att hon styrde in mig på rätt väg när jag började se slutet på masteruppsatsen och början på arbetslivet. En cool kvinna helt enkelt!

Ett grymt roligt jobb

Även om Norgefilialen är borta så har vi växt både i Örebro och i Stockholm. Vi är fler än någonsin här på Örebrokontoret, och jag är glad över att kunna säga att det är ett riktigt bra gäng! De är extremt kunniga inom systemintegration och delar gärna med sig av sin kunskap, vilket är en av de största anledningarna till min utveckling det senaste året. De är dessutom trevliga att umgås med, och det är med ett litet leende på läpparna jag ser tillbaks på vår sommarfest med Fångarna på fortet och såklart kickoffen i Oslo förra året. När vi åkte dit i början på september hade jag jobbat på IB i bara några dagar och jag kommer ihåg att jag sa något i stil med att ”om jobbet är ett förhållande så skulle jag säga att jag är i nyförälskelsefasen just nu”.

Bildresultat för love job

Precis som i andra relationer lägger sig den fasen efter ett tag, och det utvecklas till något annat. Mindre hjärtklappning och mer vardag, och det är ju här många förhållanden dör (både till jobb och till människor). Det rosaskimrande täcket har bleknat och man ser mer objektivt på tillvaron. Jag har i det här fallet haft tur: även med en mer saklig blick tycker jag verkligen om mitt jobb. Problemlösning, programmering och de här speciella utmaningarna* som man ställs inför som systemintegratör, tillsammans med bra kollegor – det är mitt recept på ett drömjobb. Jag hade som mål att hitta ett jobb som inte gav söndagsångest, och det här första året har visat att ja, jag lyckades med det. Ärligt talat: jag älskar mitt jobb. Good for me.

*Dagens utmaning: hur garanterar vi FIFO när vi plockar meddelanden från en MQ och sedan anropar en webtjänst? o.O

Det går framåt!

Hela året har präglats av en känsla av att hela tiden utvecklas, framförallt min övergripande kunskap om systemintegration, min säkerhet i konsultrollen och tekniska kunnande. Jag lär mig saker varje dag och jag har kommit en bra bit under det här året, även om det alltid finns oändligt mycket mer att lära. Kul!

Bildresultat för progress icon

Det går inte bara framåt för mig, den allmänna känslan i företaget är att vi växer; vi får fler uppdrag och vi blir fler anställda. Nya projekt dras igång där vi har nyckelroller och det ramlar in arbetsuppgifter för alla. Jag förutspår en rolig och utmanande höst/vinter!

Är detta slutet för bloggen då?

Ja – för den här bloggen. Tanken med A Year of Integration var att den skulle ha studenter som främsta målgrupp och handla om första tiden som nyexad systemintegratör, med fokus på att komma ut i arbetslivet och lämna studierna bakom sig. Det första året är nu över. Studierna hamnar längre bak i mitt minne och jag kan inte riktigt se mig själv som nyexad längre, även om jag fortfarande är i början på karriären. Den här bloggen har nu gjort sitt.

Men.

Bildresultat för blog meme

Jag gillar ju att blogga. Och tanken på att sluta helt känns ganska främmande – den här bloggen må ha gjort sitt, men jag är inte klar med bloggandet. En ny blogg kommer ta A Year of Integrations plats, det här är bara en paus. På återseende!

Så fixar du konsultrollen

Jag vet inte om jag varit inne på detta förut, men något jag inte var beredd på när jag slutade skolan var att jobba som konsult. Eller, jag hade koll på att väldigt många systemutvecklare jobbar som konsulter snarare än anställda på en IT-avdelning, men vad det egentligen innebar hade jag inte tänkt på.

Det finns två huvudtyper av konsulter: antingen sitter du på plats hos kunden, eller så sitter du ”in-house”, dvs. tillsammans med dina konsultkollegor och jobbar på distans mot kunden. Hos oss på Integrationsbolaget har vi en blandning av dessa: vi är ett gäng som alltid sitter in-house här i Örebro och jobbar på distans mot kunderna, och sedan har vi ytterligare ett gäng som sitter ute hos kunder i längre uppdrag. Just nu har vi också några uppdrag där man varvar och sitter in-house ett par dagar i veckan och hos kund resten av tiden.

Som nyexad är det perfekt att sitta inhouse, eftersom du då har nära till dina kollegor och kan enkelt be om hjälp när du funderar på något. Du får långsamt vänja dig vid kundkontakten och hinner bli varm i kläderna innan du åker ut och sitter på plats hos en kund. Det är en ganska speciell känsla att lämna det trygga kontoret och åka på det första kundmötet, och jag kan absolut erkänna att jag var nervös första gången jag gjorde det. Därför tänkte jag dela med mig av mina bästa tips på hur du hanterar konsultrollen som ny på marknaden.

Klä upp dig, klä inte ut dig

En no-brainer för de flesta – i valet mellan luvtröja och kavaj, så välj kavajen, åtminstone till första mötet. Dock så tycker jag det är viktigt att ändå vara sig själv och inte försöka klä dig som någon annan. Har du aldrig kostym tycker inte jag att det finns någon anledning att slänga på sig en sådan ”bara för att”. Inventera garderoben och hitta en kombo som du både känner dig hyfsat bekväm i och som är aningen vardagsuppklädd. Jag kör typ alltid på t-shirt med crazy tryck + bekväm tröja när jag är på vårt eget kontor, och byter till diskret t-shirt och kavaj när jag ska på kundbesök (eller kunden kommer hit).

Var en kameleont, inte en kappvändare

Som konsult behöver du kunna smälta in överallt, likt en hemlig agent läsa av arbetsplatsen, kulturen och människorna, och på nästan ingen tid alls anpassa dig till kunden du arbetar hos för tillfället. Du måste direkt komma in i jargongen och lägga ditt språk och ditt beteende på samma nivå som kunden. Det handlar om att vara flexibel till det yttersta, eftersom du som konsult kommer jobba hos massor av olika kunder, ibland i kortare och ibland i längre uppdrag. Inse detta från början och lär dig att vara lyhörd för klimatet som råder.

Men! Givetvis ska du inte känna att du bryter mot dina grundläggande värderingar. Om jag hamnade hos en kund där det förekom mobbning, diskriminering, sexuella trakasserier eller bara en jävligt taskig attityd så skulle jag inte acceptera detta. Nu har det här inte hänt mig, och jag hoppas det är ovanligt, men om det ändå skulle ske så vill jag vara stark nog att sätta ner foten och säga: det här är inte okej! Inte vara den som blundar för att det är bekvämt, tänker att ”äsch, jag är bara här X veckor, jag behöver inte bry mig”.

Var dig själv, representera ditt företag

”Var dig själv!” Ja, vem skulle jag annars vara? Ett slitet uttryck, men det ligger ändå något i det. I skrivande stund sitter jag med trasiga mjukisbyxor framför datorn, hopsjunken som en säck potatis och kliar mig på magen, och visst är jag precis lika mycket mig själv som när jag tar på mig kavajen, det är bara en annan sida av mig. Skillnaden är att när jag är hemma behöver jag inte tänka på något annat än mig själv: på jobbet, ute hos en kund, så representerar jag inte längre bara mig, utan mitt företag. Om jag missköter mig hos en kund, så är det som att hela Integrationsbolaget missköter sig, i kundens ögon. För att ta exemplet ovan, med att sätta ner foten, så skulle jag i en diskussion utanför jobbet antagligen säga något i stil med ”du är ju helt jäkla dum i huvudet”. Jag skulle inte säga samma sak vid morgonfikat hos kunden, utan välja en strategi för att få fram min åsikt på ett mer proffsigt sätt.

Skapa goda relationer och nya arbetstillfällen

De mänskliga relationerna är alltid de viktigaste, även om jobbet handlar om teknik: att skapa goda relationer till kunden är det som ger mer jobb till företaget, det är den grund vi använder för att leverera tekniska lösningar. Utan goda relationer får vi inga uppdrag. Även om du som konsult inte jobbar med sälj direkt, är det viktigt att ha med sig – hur du pratar med dina (om än tillfälliga) kollegor skapar relationen till kunden, och är den god, ja då kommer resten att flyta på. En delikat balans är förstås när det finns konsulter från andra bolag ute hos samma kund, men enligt min åsikt ska man se dessa i första hand som kollegor, och i andra hand som konkurrenter. Ingen vinner på att du ser andra konsulter som rivaler, det skapar bara dålig stämning. Även om du såklart, med goda intentioner, ska försöka göra den vassaste leveransen.

För att summera det hela: det är som att gå på lina, där du hela tiden måste avväga din person för att bete dig på ett passande sätt. Varje gång du kommer till en ny kund är det en ny lina att balansera på, och du vet inte på förhand om linan kommer vara slak eller spänd som en stålfjäder. Att känna in situationen och rätta sig efter den är en otroligt viktig egenskap som konsult, och har du koll på det innan du börjar har du halva inne.

En helt vanlig vecka som integrationskonsult

Vafalls, inget blogginlägg förra veckan? Skäms på mig! Till mitt försvar kan jag säga att jag har haft fullt upp, och jag tänkte ägna dagens inlägg till att summera veckan, så ni läsare får en inblick i hur vardagen kan se ut för en integrationskonsult.

Måndag

Vi började veckan med ett förvaltningsmöte, något vi har varje måndag. Då sitter vi i förvaltningsteamet och berättar för varandra hur veckan ser ut för oss, vilka projekt vi sitter med just nu och hur stor arbetsbelastning vi har. Det finns då möjlighet att flagga för om vi har mycket eller lite att göra, och omfördela veckans jobb om det behövs. Vi började med dessa möten i våras och de har verkligen hjälpt till att strukturera upp arbetet och gjort oss mer effektiva.

Efter mötet satte jag mig direkt framför datorn och undersökte hur en integration som vi deployade i fredags mådde, då jag var lite orolig över att något hade gått fel under helgen. För att undersöka statusen på integrationen kollade jag BizTalk och något som kallas ”tracked messages”, vilket helt enkelt är BizTalks sätt att spara all information som skickas genom plattformen. Med hjälp av detta kontrollerade jag vad som skickats från ena systemet, hur det såg ut efter BizTalks bearbetning, vad som skickades till det andra systemet, och sedan vad som skickats tillbaks, för att verifiera att allt såg ut som det skulle.Bildresultat för deploy

Jag kunde tillslut konstatera att integrationen fungerade som tänkt, förutom en liten detalj som inte upptäckts i testmiljön. Jag rapporterade detta till min kollega och han kontaktade i sin tur IT-chefen hos kunden för att få ok på att fixa detta.

Tisdag

Dagen började med att vi fick ok på att göra fixen som upptäcktes på måndagen, men innan jag hann börja med detta fick jag mail om en ticket från en annan kund. En ticket innebär helt enkelt att en kund har ett behov som vi behöver åtgärda, och det kan vara allt från allvarliga incidenter, där produktionsmiljön på något sätt störts, och vi måste agera snabbt för att återställa normalläget, till små förändringar och önskemål. Den här gången var det något mitt emellan: en av våra tjänster som genererar filer hade slutat fungerat i testmiljön, och vi behövde manuellt skapa om dessa filer.

Bildresultat för ticket

Efter att jag åtgärdat detta, var jag tvungen att förbereda mig för nästa dag, eftersom den skulle bli lite annorlunda.

Onsdag

Dagen började med att jag satte mig på tåget klockan 07:00 och begav mig till en närliggande stad för att besöka en kund. De hade gjort en lite annorlunda beställning: de ville ha hjälp med att skapa en integration, men samtidigt använda den som ett case för att deras nya BizTalkansvarige skulle lära sig mer om plattformen. Så, istället för att bara leverera en färdig integration, gjorde jag en testversion av integrationen, sedan kodade vi den tillsammans under dagen.

Bildresultat för workshop icon

Dagen gick faktiskt över förväntan, och vi kom längre än jag trodde med integrationsarbetet. Vi hade en koppling mot en databas, som var lite småbesvärlig att få till, och sedan skulle integrationen skicka information från databasen via mail och sms, och fick till hela flödet under vår workshopsession, även om det inte blev helt klart.

Torsdag

På torsdagen var jag återigen tillbaks på kontoret och det blev en dag där jag gjorde lite av varje:

  • Fixade en incident där ett system saknade filer som skulle ha kommit in under natten
  • Undersökte vad som kan hända med en SQL Server om man byter tidszon på servern
  • Skapade en ny version av ett schema som används i flera av våra integrationer
  • Grejade med ett databasskript då vi behövde byta ut primärnyckeln i en databas

På eftermiddagen hade jag ett möte med HR-Therése, där hon informerade mig om hur det är att vara skyddsombud, ett ansvar jag precis axlat. Vi gjorde också en skyddsrond, vilket gick bra – inga större risker identifierade! Skapade även en ny mailsignatur för rollen som skyddsombud, och den blev jäkligt snygg om jag får säga det själv!

superman

Fredag

När jag vaknade på morgonen undrade jag vart veckan tagit vägen – redan fredag! På förmiddagen utnyttjade jag en av våra bästa jobbförmåner, nämligen att få massage. Otroligt gött, och SÅ lyxigt! Resten av dagen ägnade jag åt att göra den där fixen som upptäcktes på måndagen, vilket var aningen trixigt – men det löste sig till slut och jag kände mig nöjd med arbetsveckan när kollegan Douglas drog igång fredagslåten på eftermiddagen.

Bildresultat för weekend meme

I skrivande stund är det snart fredag igen, och jag ställer mig samma fråga som förra veckan – vart tog måndag till torsdag vägen? Tiden går fort när man har ett roligt jobb!

 

Ta ett steg tillbaks

Igår jobbade jag med en integration där jag hade följande scenario:

  1. En lagrad procedur i SQL Server levererar data till BizTalk
  2. BizTalk tar emot datan som XML via SQL adaptern och debatchar den, dvs. bryter ner datan i olika meddelanden
  3. Baserat på properties i meddelandet olika saker hända i en orkestrering

Jag började med att skapa ett schema för meddelandet i BizTalk, men fick genast problem med att få proceduren att leverera data enligt schemat. Jag testade alla möjliga varianter, men kom ingenstans. Det kändes ungefär som att dunka huvudet mot en betongvägg på olika ställen för att se om den skulle ge vika. Det gjorde den inte.

Till slut gav jag upp och lämnade datorn. Vilket såklart var det bästa jag kunde göra. Lite distans till skärmen och diskussion med kollegor gav mig en ny vinkling på problemet: jag ska såklart inte försöka tvinga in data från SQL i en struktur som jag skapat i BizTalk, utan låta SQL definiera schemat för den data som ska skickas. Jag tog då bort det gamla schemat och genererade ett nytt baserat på proceduren, vilket fungerade fint, och med hjälp av den här guiden lyckades jag få till hela flödet.

Jaha, och vad vill jag säga med detta?

Jo, jag vill påminna er (och kanske framförallt mig själv) om vad en bör göra när en kört fast i ett problem, nämligen att ta ett steg tillbaks. Lämna datorn, ta en promenad, gör något annat en stund. Du får då distans till problemet och kan se bortom det där hörnet som du har målat in dig i. Jag tycker det här gäller alla typer av problem, men det är extra tydligt när det gäller systemutveckling och integration. Ofta fastnar man i fel angreppssätt, som jag gjorde, och inser att problemet inte bör, eller ens kan, lösas på det sätt en tänkt från början, men att det inte alls är lika svårt från en annan infallsvinkel.

Bildresultat för step back

Best practices i Biztalk

BizTalk Server är en otroligt kraftfull integrationsplattform, men precis som med all mjukvara handlar mycket om hur man använder produkten. För att få ut det mesta av BizTalk, och för att skapa integrationer som är lätta att förstå och underhålla, finns det en del best practices som är bra att följa. Jag har sammanställt en lista av sådana som är viktiga för oss integrationsutvecklare i början på karriären. Enjoy!

Bildresultat för biztalk server

Sortera artefakter

Om du ska göra en mindre integration, med bara enstaka komponenter skapade i Visual Studio, kan du lägga alla filer i samma projekt. Så länge det handlar om ett fåtal filer är det enkelt att få överblick över integrationen, men när du börjar få flera olika pipelinekomponenter, orkestreringar och scheman och projektet växer, blir det lätt rörigt. Om du vet att det kommer tillkomma filer, lägg dem från början i olika projekt, baserat på vilken typ av artefakt det handlar om; ett projekt för scheman, ett för orkestreringar osv.

Namnstandard

Ofta finns det en namnstandard som antingen kunden eller ni själva har kommit överens om, så se till att följa den. Det här är förstås generellt för all utveckling och något jag tror de flesta har med sig detta från skolan, men det är faktiskt inte helt lätt i praktiken alla gånger. Jag sitter just nu med en integration där allt ska skrivas på svenska, vilket känns väldigt ovant, och jag har redan kommit på mig själv med att vilja bryta standarden flera gånger…

MSI

När du ska deploya integrationer och ändringar till BizTalk kan du göra på flera sätt, och det rekommenderade tillvägagångssättet är att använda en MSI, Microsoft Installer Package. Det gör installationen enkel och standardiserad och du minimerar risken missa något i installationen, eftersom MSIn innehåller alla dll-er du behöver.

Automatisera

Ytterligare ett steg i att minimera risker att något går fel i en deploy är att automatisera så många steg som möjligt. Ofta är det den mänskliga faktorn som ställer till det, och genom att skripta installationer standardiserar du tillvägagångssättet ytterligare och du behöver inte vara rädd att missa något steg i processen.

Visual Studio deploy

Om du har jobbat med BizTalk projekt i Visual Studio, har du säkert sett att det finns ett menyval som heter ”deploy”. Det här är jättesmidigt när du sitter på din egen utvecklingsmiljö och testar saker lokalt, men det alternativet ska aldrig användas i produktionsmiljö. Visual Studio stoppar nämligen portar och orkestreringar och du har ingen kontroll på hur det sker, och eventuella hjälp-klasser (dvs projekt i lösningen som inte är av typen BizTalk) följer inte med.

Kanoniska scheman

Väldigt många integrationer handlar om att konvertera ett meddelande till ett annat format för leverans mellan olika system, och vi använder då mappningar för att översätta dessa. En best practice är att alltid använda kanoniska scheman vid mappningar, dvs. att ha ett internt meddelandeformat som mellanhand, vilket gör att vi får en lösare koppling mellan systemen och att ändringar hos någon av parterna blir lättare att hantera.

Capture

Nu är det dags för mig att återgå till min integration! Det är fredag, och idag är vi många på kontoret: Magnus, Stefan, Micke och jag sitter här, tillsammans med Rikard som precis kommit tillbaks från sin föräldraledighet och sedan vår nya stjärna Stefan Rulli, som började här i mitten på augusti. Några av oss (eller okej, en av oss) kör på traditionen ”fancy friday” med slips och kavaj. Någon hade försökt lura Rulli att vi har ”pant-less friday”, men som tur är gick han inte på det…

Trevlig helg! :)

 

 

Back in business!

Jajemän, nu är både jag och bloggen tillbaks efter semestern! Jag jobbar första dagen idag efter en ledighet på drygt två veckor. Inte så mycket kan tyckas, men det känns som att jag varit borta länge! Så idag har jag gått runt lite såhär på kontoret:

Vad var det jag höll på med innan semestern? Vad skulle jag ta tag i nu? Och vad hade jag för lösenord nu igen?

Min semester i sommar har främst bestått av olika festivaler (Metallsvenskan, Sweden rock, Rockviken, Skogsröjet och Subkult för den som är nyfiken) och det har varit intensivt med att kolla på band och campa. Speciellt under sista festivalen nu i helgen, då temperaturen sjönk ner mot 6 grader på natten. BURR!

Det finns nog alltid en känsla av melankoli över skiftet mellan sommar och höst, semester och jobb, men i år känns det faktiskt inte speciellt jobbigt. Det tror jag är ett gott tecken, att även om det är lite tråkigt att semestern är över, så har jag ingen back-to-work-ångest. Jag minns ett tidigare jobb jag hade, då jag nästan grät första dagen på jobbet efter semestern eftersom det kändes så jobbigt och ångestfyllt. Inget sådant idag, bara som sagt en lätt förvirring över vad jag höll på med.

Något som underlättar är vi har otroligt mycket spännande projekt på gång under hösten, hos flera av våra kunder. Sommaren har varit ganska lugn på den fronten, men nu känns det att alla börjar vakna till liv. Sprintar planeras, projektplaner skapas, krav samlas in och möten genomförs. Det känns som att alla är taggade på att dra igång med en rivstart nu och det smittar av sig, vilket är en härlig känsla! Nu kör vi stenhårt fram till jul!

Åtta saker jag önskar att jag hade känt till innan jag började jobba

Pluggar du informatik och funderar vad du borde lära dig om du har tid över? Varsågod, här kommer en lista på verktyg och begrepp som jag verkligen önskar att jag hade varit mer bekant med innan jag började jobba!

SQL Server jobs

Det första jag grejade med som konsult på Integrationsbolaget var SQL Server, och jag kände mig hyfsat hemma på den planhalvan. (Hey, jag har ju faktiskt undervisat i ämnet..) Ändå satt jag som ett frågetecken när en kollega sa att det är ett ”SQL jobb” som sköter en viss funktionalitet. Det är alltså en aktivitet, ofta att exekvera en lagrad procedur, som körs enligt ett schema, allt ifrån var tredje minut till en gång i månaden. Så om du sitter med SQL Server, ta en titt på SQL Server Agent och Jobs i object explorern, då slipper du sitta som jag och se oförstående ut när du stöter på det på jobbet.

Capture kopiera

 

Virtuella maskiner

Jag var svagt bekant med begreppet virtuella maskiner tidigare, men jag hade absolut ingen praktisk erfarenhet av att använda det förrän jag började jobba. Och när jag gjorde det så insåg jag att det enda arbetsverktyget jag använder i min ”riktiga” dator är i princip mailen och skype, all utveckling sker i virtuella miljöer. Fördelen med dessa är att man kan förbereda och spara färdiga uppsättningar, ex en Windows 10 maskin med SQL Server och Visual studio förinstallerat, som man lätt kan sätta upp och sedan ta bort när den inte längre behövs.

Internet Information Services

Jag har svaga minnen av att vi använde IIS i C#-projektet nåt år för att skapa en web service, men jag minns också att det var jäkligt förvirrande, vilket det också fortsatte vara när jag sedan började jobba. IIS är en webserver som följer med Windows, och är du inte bekant med den eller begreppet web service så är det ett hett tips att läsa på lite om innan jobbet börjar.

Soap UI

Och när du ändå håller på och har satt upp en web service i IISen, så kan du passa på att använda det trevliga verktyget SoapUI för att testa tjänsten. Den genererar automatiskt ett request för webtjänsten och visar sedan responset snyggt och prydligt. (En parentes: det här programmet är bra, men ibland känns det lite ostabilt, så har du erfarenhet av liknande program får du gärna lämna en kommentar och tipsa mig!)

Scheduled tasks

På samma sätt som man kan schemalägga aktiviteter i SQL Server, kan man göra det i Windows. Det gör du enkelt genom att söka på Task Scheduler från startmenyn, och här kan du definiera saker som ska hända antingen vid en viss tidpunkt, eller kopplat till ett visst event. Vi använder detta på flera servrar för att ex. schemalägga triggers för olika integrationsflöden hos en av våra största kunder, men den absolut bästa användningen är den Douglas implementerade någon gång i våras, nämligen att fredagslåten drar igång automatiskt varje fredag kl 17.

Global Assembly Cache

När jag i början på karriären (jao, jag är fortfarande i början, men jag menar i början-början, typ första veckorna) så satt jag med en integration och skulle testa lite ändringar i den, men hur jag än gjorde så fick jag inte den nya funktionaliteten att fungera. Det var som att BizTalk inte fattade att jag hade gjort en uppdatering, och när jag frågade en kollega om råd så svarade han: ”Har du gaccat assemblyn?”. Jag gav då det intelligenta svaret ”Va?”, men har sedan dess bekantat mig lite mer med begreppet. GAC är, enkelt uttryckt, ett ställe där dll-er behöver ligga för att de ska vara åtkomliga från andra applikationer, ex BizTalk, och ibland måste man manuellt uppdatera dessa genom att använda kommandoverktyget gacutil. Jag vet inte hur mycket detta används utanför systemintegrationsområdet, men vi använder det dagligen och det är bra kunskap att ha med sig ut i arbetslivet tror jag.

Message Queue

Det här är en sak som jag inte har en aning om ifall det används i ”vanliga” system och applikationer, utanför området systemintegration, men återigen är detta något vi använder hela tiden. En message queue är precis som det låter en kö där man kan lägga meddelanden, dvs. data i olika format, ofta som xml. Det som gör kön speciell, till skillnad mot att bara lägga filerna i en folder någonstans, är att de garanterar FIFO, alltså First In First Out och används när man behöver garantera att filer skickas i rätt ordning.

DebugViewer

Sist, och kanske även minst på den här listan, kommer verktyget DebugViewer, som är otroligt trevligt när man vill debugga kod i en annan miljö än direkt i Visual Studio. Det är också väldigt enkelt att använda: i din C#-kod skriver du System.Diagnostics.Trace.WriteLine(”Valfri text”); och sedan kan du deploya koden till en server, och bara du har debugviewer installerat på servern så kommer dina meddelanden dyka upp i dess fönster.

dbgview

Det var allt för den här gången! Nu kommer jag och bloggen ta lite välbehövlig semester och återkommer i slutet på augusti. Önskar er alla en fortsatt trevlig sommar!

Lära sig programmera

Innan jag började på systemutvecklarbanan hade jag ingen tidigare erfarenhet av programmering. Det var ett helt nytt fält för mig, en undersköterska i hemvården som försökte komma på vad hon ville bli när hon blev stor. Det enda jag visste var att jag gillade att sitta framför datorn och göra de administrativa uppgifterna, så min första trevare gick mot rollen som läkarsekreterare och på ett bananskal halkade jag in på informatik.

Där öppnade sig fältet för systemutveckling först på en mer övergripande nivå (jag tror min första kurs gällde hur man skulle köpa in affärssystem eller nåt sånt, inte så intressant såhär i backspegeln…) och sedan började jag titta närmare på just rollen som programmerare. Ämnet programmering fascinerade mig väldigt, även om jag närmade mig det med oerhörd försiktighet. Jag vet inte hur många gånger jag googlade ”lära sig programmera” och ”lära sig koda”, både på svenska och engelska, och givetvis den stora frågan: vart ska jag börja någonstans? Vilket språk är bäst för nybörjare? Vilka kurser? Böcker eller videos?

Och jag fick såklart tusen olika svar, i tusen olika forumtrådar: Java är bäst att börja med, eftersom det är ett högnivåspråk. Det är också sämst att börja med, eftersom det inte är processornära programmering, det bästa för nybörjare är Assembler. Assembler är dock sämst för nybörjare eftersom det är ett lågnivåspråk, det bästa är C# eftersom det mer liknar våra naturliga språk. Men det suger också för att det snarare är ramverk och utvecklingsmiljö du lär dig, kör istället på C eller C++ – fast börja för allt i världen inte med de språken, för PEKARE är något otroligt svårt och du kommer gå in i väggen direkt och tröttna, börja istället med HTML, men det är inte programmering faktiskt, kör PHP, trots att det är sämst, Python är bäst, eller JavaScript, eller Ruby, eller Lisp, eller Haskell, osv osv i all oändlighet.

Alla dessa svaren fick mig att tveka och under lång tid gick jag bara fram och tillbaks framför inlärningströskeln, utan att våga ta ett steg mot den, för jag visste inte vilken ände jag skulle börja. Idag ser jag tillbaks och önskar att jag hade sagt till mig själv: det spelar ingen roll vart du börjar! Ta något! Vad som helst! Kom igång! För såhär är det: Programmering är svårt i början. Oavsett vilket språk du börjar med.

Det är ett nytt tankesätt och kräver en viss logik, men det är definitivt inte så svårt som en del vill få det att låta. Jag vill dock poängtera att det inte är så enkelt att lära sig. Det tar tid! Och i början kan det kännas helt omöjligt att förstå sig på, det är nya begrepp och en del saker verkar först helt ologiska. Alla som har suttit i lärositsen har nog slitit sitt hår och frågat: VARFÖR beter sig datorn på detta vis? It makes no sense!!

https://funixx.files.wordpress.com/2014/09/adn5xmm_460s.jpg?w=510

Bildkälla

Vad vill jag säga med det här då? Att programmering är frustrerande och svårt att lära sig? Jao, det är en del av poängen, men inte den största. Det jag vill är att ta dig som funderar på att lära dig programmering åt sidan och säga: kör på! Gör inte som jag, och fundera en evighet på i vilken ände du ska börja, utan kasta in dig i matchen direkt. Det kommer vara tufft i början, men när du väl kommer över den första tröskeln kommer det bli mycket, mycket enklare och ju snabbare du kastar upp dig på tröskeln, desto snabbare kommer du nå den där punkten när polletten trillar ner och allt börjar ”make sense”.

Om jag skulle komma med lite konkreta tips för hur du kommer igång så är nog mitt största att ta en strukturerad kurs och inte hoppa runt på måfå bland olika källor. Jag, som är en plugghäst av rang, rekommenderar definitivt universitetskurser eftersom dessa ofta går ganska djupt i ämnet, och för att du får ett kvitto på att du lärt dig något. Tro dock inte att du kommer lära dig programmering av en enda kurs, för så snabbt går det inte.

Min taktik när jag började plugga var att först läsa en grundkurs i programmering på 7,5 hp på distans, innan jag började på systemvetenskapliga programmet, som innehöll i princip samma kurs igen, fast med lite annan infallsvinkel. Detta gjorde att jag hade ett litet försprång under andra kursen, och kunde sätta grunderna ordentligt, vilket jag tror behövs om du aldrig programmerat tidigare.

Så, sluta fundera och sök en programmeringskurs! Var beredd på att det kommer vara tufft i början men att belöningen kommer, det blir lättare och det är också en otrolig tillfredsställande känsla att skriva kod som fungerar. Det ger en slags maktkänsla att faktiskt kunna få datorn att göra som man vill, även om det bara handlar om att skriva ut ”Hello World” på skärmen.

Och ett litet PS: låt inte tanken på matematik skrämma bort dig! För ärligt talat, även om många programmeringskurser kräver matte C (eller vad det heter numera, matte 3?) så är det faktiskt inte så mycket matte. Jag läste bara B-kursen på gymnasiet, och inte med några toppbetyg direkt, och jag har klarat mig bra ändå. Det fina med att läsa just informatik och systemvetenskapliga programmet är att de inte kräver någon högre matte innan.

Vad är det bästa med att jobba som integrationskonsult?

Jag har skrivit ett par inlägg om de mer besvärliga delarna i jobbet, som tidsuppskattning och kravhantering, så nu känner jag att det är dags för något mer positivt! Därför har jag knåpat ihop en lista med de topp fem största fördelarna med att jobba som IT-konsult. En del av dessa är generella för jobbet som IT-konsult, andra är mer specifika för just systemintegration och Integrationsbolaget. Enjoy!

5. Lönen

Nej, pengar gör inte en inte lycklig. Men jag kan lova att bristen på pengar gör en olycklig som fasen. Relationen mellan lycka och inkomst ser ut ungefär såhär:

Bildkälla

När vi bara har precis så vi klarar oss är vi inte tillfreds, men pengar i överflöd är inte heller nyckeln till ett bekymmersfritt liv. En stor fördel med yrket som IT-konsult är att löneläget är riktigt bra, och jag skulle säga att min ingångslön ligger ungefär i början på komfortzonen. Om några år tror jag att jag kommer närma mig lyxsektorn, även om det såklart är en definitionsfråga. Kanske kommer jag anse att jag fortfarande ligger i komfortzonen då på grund av ökade utgifter…

4. Variationen

Seriöst – den här veckan har jag jobbat med SQL (oftast trevligt), C# (välbekant), PowerShell (mysigt), bat-skript (kallt, hårt och kort), kryptering (sjukt intressant), BizTalk (nya polaren), WCF (äntligen börjar jag fatta!) och WebSphere MQ (va?). Massor av skilda tekniker, där jag känner att jag behärskar en del av dem, samtidigt som andra är helt nya, och jag tror det är få jobb som kan matcha den här variationen i arbetsuppgifter.

568a3553a0d3ed3657475829471cf07d-networking-technology-iconsTill viss del är det här ganska generellt för IT-konsulter, eftersom branschen helt enkelt är så bred, men det är nog speciellt sant för jobbet som integrationskonsult. Nu har jag ju bara jobbat som just det i  den här branschen, så rätta mig gärna om ni tycker jag har fel, men jag tror att som ”vanlig” IT-konsult blir du betydligt mer nischad, och arbetsuppgifterna är inte lika mångsidiga.

(En parentes här till den som funderar på att börja jobba som IT-konsult är att inte vara rädd för ordet förvaltning! Jag tyckte själv att det lät vansinnigt tråkigt när jag pluggande, men nu sitter jag som en del i en förvaltningsorganisation, och det är faktiskt här det finns mest variation! Fast nu när jag tänker efter gäller det här nog mest integrationsförvaltning, variationen blir säkert mindre när man förvaltar ett specifikt system. Å andra sidan finns det kanske chans att bli riktigt vass på det systemet och göra sig oumbärlig i företaget…)

3. Förmånerna

Det här är förstås väldigt olika beroende på vart du jobbar, men mitt intryck är att som IT-konsult har du ofta bra förmåner på arbetsplatsen. Kompetensen inom systemutveckling är eftertraktad, och företagen måste göra sig själva attraktiva för att locka till sig (och behålla) anställda.

benefits square icon for web-larger

Jag är väldigt nöjd med de förmåner som jag har här på Integrationsbolaget. Det bästa är nog att få gymkortet betalt, och att vi har möjlighet att få massage på arbetstid. Jag kan dessutom använda min jobbtelefon som min privata, och slipper därmed räkningen för mobilabonnemanget varje månad, samt en bra pensionsavsättning. Vi har också möjlighet att leasa bil via företaget, något jag tycker är väldigt smidigt eftersom alla kostnader dras direkt på lönen.

2. Utvecklingen

Det här med att utvecklas på jobbet kan vara svårt inom vissa yrkesroller. Ofta kräver det att man byter arbetsplats, eller roll inom företaget, vilket kan vara tufft att få till, och det kräver en del förändring. Som IT-konsult har jag förändring varje dag, och även om jag är kvar på samma arbetsplats så finns möjligheten att växa och förändras hela tiden där, speciellt i början på karriären.

progress-report_318-35789

Jag känner att jag har utvecklats väldigt mycket sedan jag började här på Integrationsbolaget, mest vad det gäller mitt kunnande teknikmässigt, men också när det gäller konsultrollen. Det går aldrig att bli fullärd i det här yrket, vilket kan vara en frustrerande tanke, men det garanterar också för att du hela tiden kan utvecklas och bli bättre.

1. Friheten!

Det som toppar min lista på fördelar med konsultrollen är friheten i jobbet, och hur lyxigt det är att ha kontroll över sin egen tid. Jag har ju tidigare jobbat som undersköterska, och skillnaderna är enorma. Om du som uska jobbar ett pass mellan 07 – 14, då måste du jobba exakt de timmarna, och (åtminstone om du jobbar i hemtjänsten) så är din dag planerad minut för minut, och du har små möjligheter att ändra detta. Flextid och kompledighet är moderna myter som du hört talas om men aldrig praktiserat.

I jobbet som IT-konsult så är dessa fenomen inte längre myter, utan en del av arbetsdagen. Jag älskar att kunna träna på lunchen, och om det drar ut på tiden så stannar jag bara lite längre på eftermiddagen, eller att kunna jobba senare en dag för att gå tidigare en annan. Möjligheten att jobba från vilken plats som helst så länge jag har min dator och internetuppkoppling är också fantastisk, även om jag är bekväm av mig och helst sitter på kontoret med mina två skärmar och mitt sköna tangentbord. Men bara att möjligheten finns är otroligt upplyftande!

a0278d6ebd9591c39e398b65ed9c5dd9d7d6ea7686578f1088d41908c6b92ca4

För mig, som tidigare varit van vid att någon annan planerar min dag i detalj, så uppskattar jag det här otroligt mycket. Visst blir det svårare om du klättrar i yrkesrollen och får större ansvar, vilket alltid brukar innebära fler möten = fler tider att passa, men förhoppningsvis kan du styra tiderna på dessa, åtminstone till viss del. Och även om det bara handlar om halvtimmar hit eller dit, så har du en känsla av frihet och kontroll över din arbetstid, vilket tror jag är en av de starkaste grundpelarna för att vara tillfreds med jobbet.

 

Det svåra med kravhantering

Jag har ju tidigare skrivit om att det är jäkligt svårt att tidsuppskatta arbetsuppgifter när det gäller IT, och ytterligare ett problem som relaterar till detta är att hantera de krav som finns på den lösning som ska byggas. Till skillnad från  tidsuppskattningen är det här något som faktiskt tas upp i informatikutbildningen, så har du läst systemvetenskapliga programmet är du antagligen medveten om problematiken.

dilbertProblematiken simuleras i åtminstone en kurs där lärare agerar ”kunder” som plötsligt ändrar sig under ett projekt, och jag minns att många studenter blev irriterade på detta. I skolan är man inte van att nya saker dyker upp mitt under ett projekt, allt brukar (och ska enligt regler kring betygssättning) vara specificerat från början, så studenten vet exakt vad som förväntas. I yrkeslivet är läget dock ett annat, vilket lärarna i informatik gör sitt bästa för att förbereda studenterna på.

Jag tycker att de gör ett bra jobb med detta, men det är ändå otroligt stor skillnad att vara med om det i verkligheten. Problemet med att nya krav dyker upp från kunden är dock inte så stort för mig, eftersom jag mest jobbar med mindre, ganska avgränsade uppgifter som redan definierats. Det största bekymret för mig är snarare att förstå de krav som redan finns. För det mesta går processen till såhär:

  1. Jag får en uppgift, ofta specificerad via mail
  2. Jag tänker: jag fattar. Det här fixar jag direkt.
  3. Jag startar Visual Studio, BizTalk eller vad det nu kan vara för programvara som krävs
  4. Och tänker: men vänta här nu. Vad exakt är det som ska hända här egentligen?

Det som verkar så lättfattligt i mailet blir plötsligt betydligt mer oklart när jag ska börja skriva koden, och jag måste ofta gå tillbaks och ställa mer frågor för att kunna lösa uppgiften. Ju mer detaljer jag grottar ner mig i, desto fler blir frågetecknen och ofta visar sig uppgiften vara betydligt större och mer komplicerad än jag trott från början.

Varför är detta så svårt egentligen?

Jag har en teori och det är att IT är så otroligt abstrakt, både för den som ska använda lösningen, men också för den som ska programmera, innan denne har verkligen börjat koda. Ska man bygga en bro är det betydligt enklare: vi ska från punkt A till punkt B och eventuella problem längs vägen är betydligt lättare att förutse. Alla kan direkt se att en promenadbro över en liten bäck kommer vara betydligt enklare än en bro för biltrafik över en stor älv.

1tower-bridge

I IT är det inte lika enkelt: det som från början kan se ut som en promenadbro visar sig vara en klaffbro över ett vattendrag med båttrafik när kraven börjar analyseras. Det som från utsidan, och kanske främst från en användares sida, ser enkelt ut, är bara toppen på ett isberg av kod och komplexa beroenden, som ofta är svåra att förutse. Och framför allt: ingen skulle föreslå att man skulle bygga över Mälaren på ett par veckor, men inom IT händer det ständigt.

Jag har själv försökt mig på det – jag trodde att jag skulle kunna bygga en hemsida med ett eget CMS på några veckor, utan att inse de många timmar som ligger bakom ett administratörsgränssnitt som ex. WordPress. För att göra en lång historia kort: det gick inte alls. Det blev bara en hemsida och administratören fick administrera i HTML istället… Här har vi ett praktexempel på när en inte tillräckligt tydlig kravbild totalt pajar den tidsuppskattning som gjorts, och jag hade egentligen två val: öka tiden eller minska på kraven, och jag valde det senare.

Men, precis som med tidsuppskattning så går det att bli bättre på det här också! Ju mer man jobbar med en viss typ av lösningar, desto mer förförståelse får man för de olika delar som kan bli besvärliga, och man lär sig också att ställa mer och bättre frågor kring vad som ska göras. Man ser helt enkelt tydligare om det är en liten träbro eller en järnvägsbro som ska byggas, och kan anpassa jobbet därefter.

Nu har klockan slagit fem denna fredag, och jag lämnar er med den här klassiska bilden kring kravhantering. Det är möjligt att den är en sliten klyscha i sammanhanget, men den illustrerar ändå problematiken väldigt bra.

business-requirements-management

Trevlig helg på er!

Varför är det så in i h… svårt att estimera?

Det finns saker som en önskar att de lärde ut på universitetet, och sedan finns det saker som en inser är omöjliga att lära ut. En av de senare sakerna är estimering, alltså att uppskatta hur lång tid en viss uppgift ska ta. Det kan vara allt från ett stort projekt, till en liten ändring i en kodsnutt någonstans. Oavsett vad det gäller så finns det en sak en lär sig som ny IT-konsult: det är svårt att estimera.

Det är inte bara svårt: det är riktigt svordomssvårt! Jag har gjort en del estimat hittills och vad dessa har gemensamt är: de är felaktiga. Och då menar jag way, waaaay off. Som tur är har jag kollegor som jag kan bolla med och som har styrt in mig i rätt riktning, men även de som är rutinerade håller med om att estimat är bland det svåraste som IT-konsult.

Svårast är det dock när man är ny, och jag har här listat ett gäng tips för att motverka några av de nybörjarmisstag som jag har gjort (och för all del, fortfarande gör):

  • Det är inte bara kodandet som ska estimeras. Du har garanterat inte hela bilden klar för dig, och du kommer behöva tid för att diskutera kraven med kunden, troligtvis genom möten och/eller mail. Detta tar tid. Mer tid än du tror.
  • När du har en lokal version klar, kommer du behöva tid för att deploya din kod i testmiljön, verifiera att den fungerar och sedan installera den i produktion. Beroende på hur miljön ser ut är det här mer eller mindre komplext, så se till att du har koll på den processen och lägger in tid för den i estimatet.
  • Ge inte ett fast estimat utan ha ett intervall av timmar, där den minsta änden är ”om allt går perfekt” och den större ”om det krånglar ordentligt”. Du har större chans att pricka intervallet än att klara ett fast tak.
  • Och det absolut viktigaste för dig som nybörjare: Bolla med dina kollegor innan du ger ett estimat till kunden. De kommer garanterat ställa frågor som visar på aspekter som du inte har tänkt på tidigare, visa på sådant som kan återanvändas från tidigare kod och potentiella risker.

När du tagit de här faktorerna i beräkning så vet du hur lång tid uppgiften kommer ta, och har ett korrekt estimat, right?

Kanske – men tänk på att ett estimat är bara en uppskattning, nya problem kan dyka upp längs vägen och göra uppgiften större än den verkade från början. Då gäller det att se estimatet för vad det är, en uppskattning och inte en deadline. Håll huvudet kallt och rusa inte på i panik för att hinna klart ändå – ta ett steg tillbaks och fundera: hur påverkar det här problemet mitt estimat? Om det gör att du behöver mer tid för uppgiften, flagga då för det direkt och ge kunden en möjlighet att avbryta arbetet.

Med alla dessa problem – är det då ens möjligt att bli bättre på att estimera?

Ja! Det absolut viktigaste är att lära sig av sina misstag: håll koll på dina estimat och bokför sedan hur lång tid det egentligen tog. I takt med att du blir bättre på att programmera och estimera, så kommer estimaten till slut att åtminstone börja närma sig verkligheten.

Bildkälla

Och kom ihåg: var optimist i livet när det gäller allt annat än tidsuppskattning.

 

 

Felsökning med hjälp av en badanka?

Ärligt talat, jag hade aldrig hört talas om uttrycket ”rubber duck debugging” innan jag läste det här inlägget på bloggen Coding Horror för några veckor sedan. Och jag måste säga att jag är ganska frälst i konceptet!

index

Bildkälla

Så vad är då ”rubber duck debugging”?

Idén kommer från boken The pragmatic programmer, och grundtanken är att när du har problem med din kod, så räcker det inte med att sitta och stirra på skärmen och tänka på problemet; det måste formuleras högt. Processen med ankan brukar beskrivas ungefär såhär:

  1. Köp, sno eller låna en badanka och placera ankan bredvid din skärm.
  2. Berätta för ankan om grundproblemet du försöker lösa och vad du vill uppnå.
  3. Gå sedan igenom din kod och berätta för ankan hur du försökt lösa problemet, och förklara rad för rad vad koden gör.
  4. Inse något av följande:
    1. Du hittar felet i koden, eller
    2. Felet ligger inte alls där du trodde, eller
    3. Din kod försöker inte alls lösa det problem du tänkt att den ska göra
  5. Tacka ankan för hjälpen och ändra koden.

Jag tycker det här är en klockren idé, och efter jag hörde talas om metoden har jag tänkt tillbaks på tillfällen då jag skulle ha behövt en badanka till hjälp!

Bildkälla

Jag tyckte det här fenomenet är extremt tydligt under skoltiden: när vi hade handledning räckte det ibland med att förklara för handledaren vad jag behövde hjälp med, för att komma på lösningen själv. Andra gånger var situationen omvänd: jag var handledare och satt bredvid en uppgiven student som suckar: ”Ingenting funkar! Jag blir tokig!”. Nej, då blir det inte lätt för mig att hjälpa dig. Förklara istället för mig vad du försöker göra och exakt vad som inte fungerar.

keep-calm-and-start-debugging-8

Det har även hänt mig nu när jag jobbar, och jag minns för några veckor sedan när jag behövde hjälp att förstå en grej, så jag ringde till en person som hade koll på detta, men under samtalet fick jag motfrågan: ”vad är det exakt du vill veta?”. Och jag insåg att fasen, jag visste inte riktigt vad jag ville veta! I mitt huvud trodde jag att jag hade formulerat mig klart och tydligt, men egentligen var själva grunden för frågan otydlig för mig. Då hade jag behövt en anka att prata med först!

Tanken slog mig igen igår: jag skulle skicka ut en fil till en mapp genom en integration, och det hände absolut ingenting. En superenkel grej, men ändå funkade den inte. Jag stirrade på skärmen och försökte på flera olika sätt, tänkte att vafasen, det här ska inte vara svårt! Till slut ringde jag en kollega och bad om hjälp, och när jag försökte förklara problemet för honom så förstod inte han heller vad problemet var. Han gav lite tips att testa, men när jag lade på luren så slog det uppenbara mig: felet ligger inte i den här enkla grejen. Det är något som går fel innan, vilket gör att exekveringen aldrig når den här punkten och försöker skicka ut filen – det finns ingen fil att skicka ut.

Nu ska jag forska i en incident som precis kom in, därefter drar vi till Stockholm för sommarfest med hela bolaget. Önskar er alla en trevlig fredag!

Integratören == Spindelmannen

God förmiddag!

Kommer ni ihåg att jag skrev att jag hade ett möte med folk från Finland, Indien, Tyskland och Ryssland för ett tag sedan? Då diskuterade vi en integration mellan företagets HR-system, där användaren knappar in data om anställda, och Active Directory, där datan lagras. Jag har utvecklat den här integrationen och implementerat den i testmiljön, så nu sitter jag i ett möte där flödet ska testas från början till slut. Eller möte är egentligen fel ord – vi har en testsession på ca 4h, där någon från varje ansvarsområde är tillgänglig.

Det är väldigt spännande, även om det såklart dyker upp nya problem som vi inte förutspådde innan. Det är ju anledningen till testerna, och jag tror att det är väldigt få IT-lösningar som fungerar perfekt på en gång. Hursomhelst, jag fick en ganska skum känsla när vi började testerna: jag kände mig helt plötsligt jäkligt viktig. Inte så att jag går runt och känner mig försumbar i vanliga fall, men i det här scenariot tyckte jag det blev extra tydligt att integrationen är hjärtat i det dataflöde vi vill skapa, och jag som integratör är en Very Important Person.

Visst, det här är min subjektiva åsikt, och de flesta tycker säkert ens egna område är det viktigaste. Typ som lärare i skolan: nå, det är väl bra att det finns andra ämnen, men det är just mitt ämne som du faktiskt behöver kunna. Men jag tycker ändå jag har en poäng här: utan integrationen kan inte systemen kommunicera med varandra, och då finns det liksom inget flöde, oavsett hur bra övriga system funkar. Integratören är också den som måste ha koll på hur de olika systemen kommunicerar: vilken typ av data skickar HR-systemet ut? Vad är det egentligen AD vill ha för att kunna lagra information om anställda? Vilka konverteringar behöver vi göra? Hur ska responset se ut? För att använda ett slitet uttryck: integratören är spindeln i nätet här. Som den här snubben.

spider-man

Typ.

Uttrycket är klyschigt, men det stämmer. Precis som vi skriver på vår infosida om att driva integrationsprojekt: ”Det är ofta en stor utmaning då [integrations-]projekten av naturen kräver kommunikation mellan fler parter (som ofta inte befinner sig på samma plats). Integratörens roll får alltid inslag av projektledning och kravställning eftersom man nästan alltid får en väldigt central roll i projektorganisationen.”

Nu ska jag inte gå så långt som att säga att jag varit inblandad i projektledningen i det här fallet, eftersom jag bara haft ansvar för just den här integrationen, men jag ser ändå utmaningarna. Som till exempel i den här testsessionen, då vi är folk från totalt sex länder i olika tidszoner. Visst är det lite svettigt med första testet av något jag har byggt, men jag tycker coolhetsfaktorn väger över. Här sitter jag och är internationell liksom!

Myter om jobbet som IT-konsult

Finns det myter om IT-konsulter? Jag hade ett par förutfattade meningar kring yrket innan jag började, och för att få ytterligare kött på benen ställde jag frågan i facebookforumet ”Kodapor OT” – stort tack till er som svarade! Detta är ett ihopkok av mina tankar och svaren jag fick där, och mina åsikter kring huruvida stereotyperna stämmer.

1. Vi är antisociala killar som gillar Joltcola

Ungefär som Dennis Nedry i Jurassic Park, han som kodat hela parkens IT-system alldeles själv och ser ut såhär:

thumbnailImage

Jag tror att alla rent logiskt fattar att det här inte längre stämmer: du behöver inte vara en lonely gamer som sitter i en källare och spelar WOW hela nätterna för att vara bra på programmering/IT. MEN. Det är fortfarande underskott på kvinnor i branschen och även om utvecklingen går framåt så tar det tid att bryta mansdominansen i yrket. Jag försöker dra mitt strå till stacken genom den här bloggen, där jag vill visa att du inte behöver tillhöra Dennis Nedry-normen för att jobba som IT-konsult.

2. Vi är gifta med våra jobb

Vi som jobbar med programmering/systemutveckling har det som ett kall och något vi gärna gör gratis på fritiden. Du förväntas kunna visa upp egna, spännande projekt som du skapat utanför studier/jobbet, för att bevisa att du inte bara är bra på ditt jobb – du är ett med jobbet, det är ditt jag och din identitet.

Den här är svår, och en av de största förutfattade meningarna jag hade innan jag började jobba, vilket jag nämnt tidigare.

Åh ena sidan: ett jobb är bara ett jobb, och det är faktiskt helt okej att ägna fritiden åt andra saker än programmering. En av de saker som jag hoppas jag har fått fram i den här bloggen är att du inte behöver vara underbarn som monterade datorer vid 3 års ålder för att vara en bra IT-konsult.

Åh andra sidan så kräver jobbet otroligt engagemang i hjärnan, det går inte att programmera och tänka på annat samtidigt. (Åtminstone kan inte jag det…) Det kräver dedikation och en vilja att lösa problem, ett sug efter att leverera lösningar, och den här dedikationen har en tendens att sprida sig utöver de där timmarna mellan åtta och fem. Risken är stor att om du är gift med något annat än jobbet, så kommer jobbet vara ett rätt så krävande vänsterprassel.

Här har jag dock en teori: det är lätt att gifta sig med jobbet, när allt som krävs är en dator och internetuppkoppling. Människor kan garanterat känna samma dedikation i alla yrken, men det är inte lika lätt att leva ut när jobbet kräver aktioner på plats. Till exempel: en undersköterska som stannar kvar efter sitt pass ses som konstig, men den IT-konsult som gör samma sak, det är bara vardag.

3. Vi kan allt.

När jag ställde frågan på facebookforumet om vilka fördomar folk upplevt som kodapor var första kommentaren detta:

Vad jobbar du med då?
 - Jag är programmerare.
 a) Jaha, kan du göra en hemsida åt mig?
 b) Du, min dator är långsam, kan du titta på den?

Med andra ord: många tror att vi kan när det gäller datorer, vare sig det gäller att göra grafik till en hemsida eller en trasig dator.

IT är ett väldigt, väldigt, väldigt stort ämne och för att bli riktigt bra behöver du välja ett område att bli bra inom, annars finns det helt enkelt inte tillräckligt med livstid för att lära sig allt. Dock så blir jag ständigt imponerad över de olika gurus som finns därute och som har samlat på sig så otroligt mycket kunskap kring olika aspekter av vårt jobb – en eloge till er!

4. Vi kan ingenting

Ytterligare en myt är motsatsen till ovanstående, nämligen illusionen av att det vi gör är jättelätt och inget som kräver någon direkt ansträngning. Citat från facebooktråden i Kodapor OT: ”Fan vad skönt att vara programmerare, då kan man bara sitta i en stol vid datorn hela dagen och dricka kaffe istället för att slita och vara stressad på ett riktigt jobb.”

Min fördom kring folk som har den här fördomen är att de har en liten inblick i kodning och hur det fungerar. De kanske har skrivit ett par rader i något programspråk, men har ingen djupare insikt om vilka problem som dyker upp, vilket leder till att de tror att allt är enkelt löst med en if-sats. Ytterligare en situation när den här mentaliteten dyker upp är vid prototypvisningar: för den som tittar ser det ut som att produkten är färdig, men egentligen är den bara ett tomt skal, och de inser inte att det är betydligt svårare att implementera animationer och snygga flöden i kod än att rita upp det i Photoshop.

Sanningen ligger någonstans mittemellan: ja, det är komplext och ingen barnlek att implementera en idé i kod, men det är samtidigt inte magi, och låt inte den här komplexiteten skrämma bort dig. Jag tror att alla som är motiverade till det kan lära sig koda, och när den första tröskeln är överstigen så kommer det kännas lättare. Det svåra är inte att skriva koden utan att veta vad som ska skrivas.

5. Vi hoppar på vilket projekt som helst

Det här är lite sammankopplat med illusionen om att programmering är ett kall som vi gärna gör gratis på fritiden, och jag tycker nedanstående bild illustrerar det här väldigt bra:

13083260_10153542473356981_2475047108041777606_n

Detta har nog hänt många programmerare, och som en i Kodapor OT formulerade det: ”- Du jag har en unik app/spel/webbsideidé som du kan hjälpa mig med! (jag berättar vad jag vill ha och du gör det faktiska jobbet.)” Gärna utan betalt, med motiveringen att ”det är ju något att sätta på CV-t” och att det är idén som är värd något, inte implementationen. Det hänger också ihop med illusionen om att programmering är enkelt. Och visst, att skriva en funktion som tar en en sak och returnerar en annan är enkelt, men det är vägen från ”jag vill ha en app som gör x och y” till enskilda klasser, attribut och funktioner som är det svåra, vilket jag tror många underskattar.

Bubblare

Det verkar också finnas en del myter från andra yrkesroller i branschen, så vi tar ett gäng bubblare också:

  • Att en kodare bara kan koda och inget annat
  • Att kodare bara ska koda och ingenting annat
  • Att konsulter tar överpris och har sjukligt höga löner, helt i onödan
  • Vi har ju nästan byggt ett sånt system, vi kan väl utgå från det och bara ändra lite, det är väl redan modultänk så det är lätt att lägga till och ändra moduler? Så sparar vi tid.
  • Att det är möjligt att följa exakt samma kodstandarder som i tidigare projekt, även om det är i olika språk
  • Att man vill hjälpa alla med deras datamaskin
  • Missuppfattningen att vi bygger bilen när vi i själva verket bygger ritningen till bilen. Datorn bygger bilen (maskinkoden) utifrån ritningen (källkoden).
  • Att man förväntas vara expert på allt som alla avdelningar jobbar och pratar om bara för att det råkar visas på deras skärm
  • Att teknisk skuld är detsamma som buggar.

För att summera: det finns en jäkla massa fördomar och myter kring det här jobbet! Och då har jag ändå begränsat mig i urvalet från svaren i facebookgruppen. Vad tycker du? Har du myter att krossa eller bekräfta? Lämna en kommentar!

 

Distans och skype

När jag pluggade så visste jag ju att mycket arbete sker i team som inte sitter geografiskt tillsammans, men jag tror inte jag anade vidden av det förrän jag började jobba. Idag har jag till exempel ett möte med folk från Finland, Indien, Tyskland och Ryssland (!!!).

Det som gör det möjligt för oss att ha sådana här möten, med folk från flera länder, är såklart tekniken. Skype är det som används mest, enligt min uppfattning, och när allt funkar så är det riktigt bra! Även om nedanstående graf stämmer in på väldigt många möten – tekniken har en tendens att strula när både ljud och bild ska synka, och ofta tar det en stund att komma igång…

skype

Vi använder dock inte Skype bara till möten, utan även som internkommunikation. Jag tycker det är grymt bra, då kan man kontakta alla kollegor snabbt och det syns direkt om någon inte vill bli störd eller sitter i möte. Såhär ser (en del av) min skypelista ut i skrivande stund:

 

Capture

För de som inte är online ser man hur länge de varit borta, och de flesta lägger till information om vart de befinner sig någonstans så det blir lätt att hålla koll på kollegorna.

Oftast använder vi snabbmeddelanden och skriver till varandra, men det är också möjligt att ringa videosamtal via skype. När någon ringer ser det ut såhär:

Capture

Eller ja, det ser ut såhär som Douglas ringer, men ni förstår vad jag menar – det dyker upp en ruta som det står att personen ringer dig. I början förstod jag inte det här, utan trodde att personen skrev ”ringer dig” i ett snabbmeddelande, så jag tänkte ”okej, ja gör det du!” och sen klickade jag på ignore och funderade på varför personen aldrig ringde…

Min dag i bilder.

Idag har jag jobbat hemma, för jag kände att en förkylning var på G. Jag tror att en jobbdag i pyjamas, i kombination med ingefärste och honung, motade bort den ganska effektivt, för nu känner jag mig helt okej! Förutom segheten som kommer av att sitta framför datorn hemma i pyjamas en hel dag då, utan längre promenader än de där fem metrarna in till köket…

Hursomhelst, jag har läst på andra bloggar att temat *min dag i bilder* är rätt populärt, och vem är jag att ifrågasätta andra bloggare?

Så, varsågoda: Min dag i bilder!

Började dagen med att koppla in hemmaskärmen, musen, tangentbordet och jobbdatorn i en liten dockningsstation jag hittade här hemma. Drack en kopp kaffe och kände lyxen i att kunna jobba hemifrån med en rejäl skärm. Lyckan varade dock inte länge, för när jag gick in på den virtuella maskin som jag utvecklar på just nu, så betedde sig allt helt vrickat.

image

Musen klickade liksom tio cm till höger och fem cm ovanför punkten som jag klickade på. Jag blev lite irriterad, men hade fortfarande hoppet kvar. Jag gjorde det alla gör (eller borde göra) vid datorproblem: jag startade om skiten.

72efeacfed77482640cb25816631daa3

Och igen. Och igen. Och… ja ni fattar. Jag gjorde några omstarter. Fortfarande samma fel. Testade att koppla in musen direkt i datorn. Ingen skillnad.

3b4

Funderade lite. Klickade runt lite random på olika ställen. Råkade klicka fel.

1709375

Fick lite panik. Ångrade både val av yrke och VM.

add

Gav upp totalt en stund, och bara stirrade på skärmen.

Då kom insikten:

avpzphd

Jag googlade mitt problem. Insåg att jag inte var ensam om det. Det handlade om att den virtuella maskinen inte hade samma storleksinställningar på skärmen som min ”riktiga” dator, därav offset i klick med musen. Blev jätteglad. Kollade inställningarna och insåg att de visst hade samma. Åkte ner i det mörka hålet igen.

Funny-facepalm-meme-computer

Insåg att det kan kanske var den där gamla dockningsstationens fel och provade att koppla in datorn direkt i skärmen. Då kunde jag se att storleksinställningarna skilde sig åt och när jag fixade detta funkade allt som det skulle igen. Gav givetvis datorn långfingret först, sedan kom den där glädjen av att ha löst ett problem, och jag avslutade dagen ungefär såhär:

images

(PS! Till min chef: nej, det tog inte precis hela dagen – jag hann jobba lite också!)

Scrum 4 real!

Det finns vissa saker vi gör i skolan som man liksom vet görs ute i *verkligheten*, men som det ändå är svårt att föreställa sig nyttan med. En sån sak är daily scrums. (Vet du inte vad detta är? Läs mer till exempel här.) Alla som läst informatik på Örebro universitet är nog mycket välbekanta med begreppet, och i åtminstone en av kurserna är daily scrums en viktig del av det projekt som genomförs. Daily scrums i teorin brukar beskrivas typ såhär:

daily-scrum-meetingBildkälla

Idealbilden är ett team som står framför sin Scrum board tillsammans med Scrummastern och kort går igenom status på sprinten, samma tid varje dag. Det ska inte ta mer än en kvart, därför är det viktigt att man står upp, och fokus ska inte vara på problemlösning. De klassiska frågorna som varje medlem i teamet ska besvara brukar vara:

  • Vad gjorde du igår?
  • Vad ska du göra idag?
  • Är det något som hindrar dig från att göra det du ska?

I den informatikkurs där de här mötena ingår som en obligatorisk del, tyckte åtminstone jag det kändes ganska… krystat.

Jag agerade scrummaster och ledde våra möten, men trots att jag då försökte motivera teamet att vi måste ses varje dag klockan nio, såg jag inte direkt nyttan med det. Vi satt ju liksom tillsammans hela dagen, och jobbade med ett väl avgränsat projekt där vi hade möten med ”kunden”, dvs. läraren en gång i veckan, och det fanns inga andra distraktioner som kunde störa projektet. Vi hade helt enkelt inte så mycket att säga till varandra under den där kvarten. Men under förra veckan fick jag faktiskt vara med på ”riktiga” scrummöten i det här nya projektet vi håller på med, och ärligt talat tycker jag det är superbra!

Hur kommer det sig då, att det helt plötsligt känns väldigt vettigt att köra daily scrums? Jag har funderat lite och jag tror dessa är de viktigaste faktorerna:

Geografiskt avstånd

Alla delar av teamet sitter inte i samma rum, eller ens i samma stad, vilket skapar ett mycket större behov av att synka arbetet regelbundet och se till så alla är på rätt spår och jobbar med rätt saker. Det blir också viktigt i och med att olika delar av projektet är beroende av varandra, och man måste stämma av så att ingen del av teamet sitter och väntar på att någon annan som i sin tur kört fast.

Storleken på projektet

I skolan har de utvecklingsprojekt man gör ett litet och väldigt avgränsat scope. Det handlar om att utveckla mindre applikationer som kan existera för sig själv utan direkta kopplingar till andra system. I verkligheten är projekten ofta mycket större. Projektet som jag sitter med just nu handlar om att plocka ut funktionalitet från ett fakturasystem till ett nytt CRM-system, då fakturasystemet har byggts ut med ytterligare funktioner under en lång tid. Nu ska fakturasystemet bytas ut, vilket gör att vi måste ”rensa” det först. Integrationsbolagets roll är givetvis att ha hand om integrationerna mellan CRM-systemet och andra system, och de dagliga mötena hjälper oss att få överblick över projektet.

Storleken på teamet

Det här hänger såklart ihop med storleken på projektet: för att genomföra ett stort projekt krävs mer resurser, och vad jag vet så har vi konsulter från minst tre olika bolag, förutom de som redan finns hos kunden. Ärligt talat har jag inte koll på exakt hur många vi är – vilket bara i sig skapar ett behov av att regelbundet stämma av med alla parter så vi är på samma spår.

Störningar

I skolan kunde vi sitta hela dagarna och fokusera endast på projektet, utan att andra saker kom i vägen. I verkligheten är det dock inte lika enkelt: de flesta har andra arbetsuppgifter som ibland måste gå före, och för oss som även har förvaltningsuppdrag hos kunden, kan få incidenter som måste fixas omgående, och då måste projektet vänta. De dagliga mötena blir då till hjälp när det gäller att prioritera och kanske framför allt informera om att man har andra saker som måste göras innan en viss uppgift i projektet.

Mentaliteten

Det här är kanske den viktigaste biten: vilken attityd har teamet till mötena? I mitt fall under skoltiden hade vi inga av ovanstående faktorer som påverkade projektet, vilket gjorde att mötena kändes onödiga. Det i sin tur leder såklart till att folk inte tar dem på allvar och börjar komma försent eller helt enkelt inte bry sig. Och det är en mentalitet som jag lovar är mycket svår att vända när den väl har satt sig i skallen hos folk! I vårt nuvarande projekt blir det tvärtom: det finns faktorer som gör att dagliga avstämningar blir viktiga, folk tar mötena på allvar och detta gör dem automatiskt mer givande.

Det var mina tankar om daily scrums och hur välbehövliga de kan vara, trots att de kan kännas mer som ett nödvändigt ont i skolan. Har du några tankar om Scrum? Håller du inte med mig? Dela gärna med dig i kommentarerna, jag är nyfiken på att höra vad du tycker!

I Helsingfors på besök!

För ett par veckor sedan var vi i Finland för att besöka vår kund Fortum under två dagar!

Det här energibolaget behöver ingen närmare presentation – jag tror de flesta känner igen eljättens namn och logga. Vi är alltså med och stöttar dem i integrationsarbetet, och för mig var det första gången som jag träffade resten av integrationsteamet. Första dagen började med en tidig flygtur till Helsingfors, och eftersom jag satt vid vingen så var jag tvungen att ta det klassiska kortet på vingen och marken nedanför. Tror marken nedanför tillhör Sverige, men är inte helt hundra.

20160316_084209

Och på tal om utsikt – detta är vad man ser från artonde våningen i Fortums byggnad:

IMG_0415

Douglas passade på att ta kort på oss när vi beundrade utsikten. Eller okej – jag sa åt honom att ta kort eftersom min kamera inte funkar som den ska…

IMG_0418Tyvärr blev det inga mer kort, och jag ångrar att jag inte förevigade middagen vi åt på kvällen! Efter ett långt och givande möte med fokus på samarbete gick hela teamet till en restaurang som heter Ragu, och det är en av de få restaurangerna i Norden som har en Michelinstjärna. Jag fick veta detta på vägen till restaurangen, och det höjde mina förväntningar ganska mycket, men helt ärligt – maten på Ragu överträffade dem ändå.

Det var en fyrarättersmeny och innehöll så mycket gott att det skulle ta mig resten av kvällen att räkna upp det, så jag nöjer mig med att nämna den större huvudrätten, som bestod av… just det, ragu, alltså långkok på kött. Men det var inte vilken ragu som helst: den kom in i en mystisk burk med stängt lock, och de sa åt oss att öppna dem direkt. När vi gjorde det strömmade rök ur burken och det luktade fantastiskt gott, som något slags träd, men nu kommer jag inte ihåg vilket. Ragun låg på en slags polentapudding, och smakerna gifte sig verkligen i munnen. Det är inget uttryck jag använder till vardags, men för den här smakupplevelsen är det verkligen passande!

Nu börjar jag bli riktigt hungrig, och klockan närmar sig 17, så jag vill avsluta med att tacka min finska kollega Artur för att han gav mig sin efterrätt. Den var fantastiskt god och jag njöt av varenda tugga av mina två portioner. Sedan fick alla i gänget praktisera teamwork när jag behövde rullas ut från restaurangen efter alltför mycket att äta… Närå, så illa var det inte. Men nästan.

Trevlig helg på er!

Language: