Jesper Forslund

Brus är vår fiende och vi måste gemensamt arbeta för att minska bruset. Den är ett störande moment i arbetet och det tar fokusen från de verkliga problemen. Jag försöker minska bruset för mig själv men jag undrar om jag minskar bruset för andra. Det är inte alltid helt lätt.

Jag försöker hålla mig till mottot att: “Mail is for traceability and IM for productivity.” Än så länge fungerar det bra. Till att börja med så har jag har deklarerat krig mot mail. Så fort jag läser ett mail som är ”just nu” information så tar jag bort det, jag kan alltid hitta det i mailboxen om det var ett felaktigt beslut. Om det är viktig information så sparar jag det i en relevant undermapp. Om det är ett mail som jag behöver göra något åt så sätter jag en flagga på det och lämnar det i inboxen.

Skulle det vara en fråga som jag snabbt kan svara på så svarar jag dem, via msn eller office communicator, för att uppmuntra den kanalen. Om det inte räcker får man ses och eller ringas. Snabba frågor via IM är för mig riktigt bra eftersom man inte behöver invänta ett svar. En av de värsta tjuvarna när det gäller produktivitet kommer från att hoppa mellan arbetsuppgifter, IM löser det till stor del för mig.

Undra om man skickar mail i tron om att fler läser det? Handen på hjärtat, läser ni alla mail? Svarar ni på alla mail? Kulturen sitter i vägarna på varje arbetsplats. Hur som helst, som Elvis skulle han säga om han levde i dag: “A little less mail, a little more conversation please.” Hur gör ni för att hantera bruset?

(Skrev det här för något år sedan men efter en föreläsning i veckan så kändes det som att det passade bra att posta det på nytt).

Logica och Chalmers bjuder in till ett kostnadsfritt seminarium där vi delar med oss av våra erfarenheter inom nya tekniker som ger nya möjligheter för dig! Välkommen till ett seminarium om mobila plattformar, integration med Molnet och alternativa kommunikationssätt.

Efter ett mycket välbesökt seminarium förra året arrangeras nu det femtonde IT-seminariet i serien. Chalmers studenter har i samarbete med näringslivet jobbat med att utforska nya plattformar och kommunikationssätt. Studenterna kommer att presentera sina arbeten inom områden som iPhone, Android, Cloud Integration, Ramverk för rapid web development samt kommunikation, med laser, Zigbee-kretsar (Hauto) med flera.

Mer information om Pomodoro projektet finns på www.pomodoroproject.net eller läs den korta introduktionen på tinyurl.com/pomodoro-intro
.  Information om seminariet och anmälan registreras påwww.pomodoroproject.net

Hade en riktigt rolig vecka med presentationer kring Agile för både kund och internt – först i Frankrike och sen i Sundsvall. En återkommande fråga var kring mängden dokumentation som skapas under ett agilt projekt. Det är en mycket bra fråga som förtjänar mer än ett kort svar.

Dokumentation ska tillföra ett värde på ett effektivt sätt. För mycket dokumentation är slöseri med resurser. Tänk den tid som det tar att skriva, läsa och uppdatera 100 dokument på 20 sidor. Dokument ska ge ett värde för någon men det är en kostnad nu och i framtiden förknippad med att producera dokumentation. I slutändan är det en fråga om att ta kostnaden för att tillföra värde för någon annan.

En av många myter kring Agile är att dokumentation inte produceras. Många gör revolt mot omfattande dokumentation som vi genom tradition producerar. De tar helt enkelt tillfället i akt och struntar i att dokumentera när de går över till ett agilt arbetssätt och skyller på metodiken. Det är såklart ingen hållbar lösning.

Agila projekt producerar mindre dokumentation innan utvecklingen startar och eftersom kommunikation mellan individer driver fram detaljerna under projektet försvinner stor del av incitamentet för att göra omfattande dokumentation. Det är i sig bra men det finns en lägsta nivå på vad som ska dokumenteras, det är en disciplin som behöver upprätthållas.

För att sätta rätt ambitionsnivå på dokumentationen så finns det tre viktiga delar:
•    ”Document for the future you”
•    Förvaltningen måste ställa krav, redan när projektet starar, på vilken dokumentation som ska levereras
•    Dokumentera det som är viktigt.

Den första är hur mycket dokumentation som ska göras under själva projektet. Där finns det en bra formulering (som jag hörde på Öredev men minns tyvärr inte vem som sa det) som lyder: ”document for the future you”. Då jag utvecklar en del på fritiden så kan det gå lite tid mellan gångerna. Om jag inte har kommenterat koden så kan det hända att jag tittar på min kod och undrar hur jag tänkte förra gången. Samma reaktion kan jag få när jag har suttit uppe sent och kodat och nästa dag så läser jag koden och kan inte komma ihåg hur jag hade tänkt. Dokumentera för ditt framtida jag är att hjälpa dig själv.

Även om agila projekt producerar mindre dokumentation under tiden som utveckling sker så behöver fortfarande relevant dokumentation levereras till förvaltningen. Förvaltningen vill ofta ha all dokumentation som beskriver exakt hur systemet fungerar så att man har snabba svarstider och lösa problem snabbt. Eftersom det är andra resurser i förvaltningen så måste man överföra kunskapen genom dokument. Fel!

Vad händer om ett agilt projekt kan leverera funktionalitet som faktiskt ger värde för användaren på ett effektivt sätt får en kostnadsökning med 200 % för att de måste dokumentera i detalj hur systemet fungerar. Att producera den dokumentationen, för förvaltningen att läsa den och att administrera den under systemets levnadstid är inget annat än slöseri! Total Cost of Owenrship kommer äta upp budgeten för att utveckla nya system och leverera mer värde till kunden.

Så hur hittar man rätt nivå? Det finns ingen silverkulla (en lösning för alla varianter). Mitt tips är att redan i uppstarten av projektet få med kraven på dokumentationen som ska levereras till förvaltningen. Förvaltningen får ställa krav och sen får man diskutera sig fram till vad som är minsta nivå av dokumentation och hur kompetensöverföring sker på bästa sätt. Tänk på att all dokumentation har en kostnad och måste kunna motiveras av ett värde.

För att summera så handlar det om en sak – dokumentera det som är viktigt. Välj dina dokument och se till att de är uppdaterade och stämmer. För många projekt har för många dokument med gammal information som vilseleder. För er som fortfarande dokumenterar projektet i faktiska dokument, word-filer eller liknande, sluta med det. Använd en Wiki för att göra det enkelt att ändra. Det finns versionshantering på (nästan) samtliga så var inte rädd för att låta alla skriva i dokumenten, man förstör inget.

Finns mer att säga men ska av tåget nu. Det här får räcka som ett längre svar på en bra fråga. Bara att höra av sig med frågor eller skriv en kommentarer.

För alla er som är intresserade av att utveckla applikationer för de mobila plattformarna så lanserar Logica ett unikt projekt, Pomodoro Project, där vi delar med oss av vår erfarenhet med er. I projektet kommer vi att fördjupa oss i applikationsutveckling inom Android och iPhone. Vi kommer även att utvärdera ramverk för rapid web development och skapa ett REST API för att lagra informationen centralt i molnet.

Projektet genomförs under våren 2010 och i början av juni kommer vi att bjuda in till ett öppet seminarium för att dela med oss av våra erfarenheter. På vår blogg kommer vi kontinuerligt att dela med oss av vår erfarenhet och berätta mer om de olika ämnena.

Pomodoro projektet 2010 har valt ut fyra områden att utforska:

• Android, applikationsutveckling med fokus på kvalité.
• IPhone, applikationsutveckling med fokus på user experience
• Webbramverk, hitta nästa ramverk för rapid web development
• Cloud, ett REST API för att lagra informationen i molnet

Projektet är en satsning från Logica tillsammans med Chalmers på initiativ från Jesper Forslund. Läs mer på www.pomodoroproject.net och följ oss på vår blogg.

Kontaktperson för projektet är Jesper Forslund, jesper.forslund@logica.com.

 

Mer om projektet

Pomodoro projektet kombinerar ambitiösa studenter och företagens intresse att skapa något lysande. Vi kommer att utforska nya plattformar och tekniker och dela våra erfarenheter med er. Bäst av allt, resultatet av detta projekt kommer att gå till välgörenhet. Detta är en win-win-win-projektet, så håll dig uppdaterad!

Pomodoro projektet är ett koncept för att öka kunskap och kompetens inom ny teknik med fokus på mjukvaruutveckling. Ett Pomodoro projekt utvärderar nya områden och konstruerar en referensprodukt - ett verktyg för att arbeta enligt Pomodoro-tekniken. Det applikationer som vi tar fram släpper vi gratis till privata användare med uppmuntran att donera till välgörenhet med web2aid.

Tester i Agila projekt är inte alltid enkelt. Logica driver många Agila projekt där det finns mycket erfarenhet att hämta. Följande inlägg tar upp tester i Agila projekt på en övergripande nivå.

Agile är ett steg bort från hur man normallt driver projekt - det är ett snabbare och mer pragmatiskt angreppssätt i motsättning till de mer formella och dokumentdrivna projektmetodikerna. Med Agile levereras fungerande mjukvara iterativt och inkrementellt. Det innebär att arbetet delas in i fasta tidboxar och i slutet på varje period levereras den funktionalitet som är klar. Även om definitionen av klar kan variera över ett projekts levnadstid så handlar det fortfarande om utvecklad och testad funktionalitet.

 

Att arbeta med tester i ett projekt där mjukvaran hela tiden är levande, växer och förändras, med tiden är en utmaning. Att arbeta med testerna precis som i traditionella projekt medför ofta att stora delar av det manuella arbetet måste göras om vid varje ny leverans. För att hantera frekvent testande tillämpar Agila projekt automatiska tester i olika nivåer.

 

Utvecklare i Agile projekt ska leverera fungerande kod och för att uppnå det används automatiska enhetstester. De testramverk som används har med tiden blivit allt mer komplexa och avancerade vilket gör att man kan testa allt från affärslogik till integrationer till gränssnitt, ja i princip allt.

 

Så om utvecklingsteamen skriver sina egna tester – behöver man testare? Självklart, men rollen som testare ser annorlunda ut i Agila projekt. Det bästa är om en testare är med i utvecklingsteamet och jobbar nära utveckling för att höja kvalitén på de automatiska tester som produceras – än bättre om de är med i koden och skriver testfall. Beroende på vad för sorts produkt som utvecklas kan testaren även ansvara för andra testramverk för att testa på olika nivåer, så som integration eller systemtest.

 

En stor fördel med att arbeta med automatiska tester är när man kombinerar det med continuous integration, CI. Med hjälp av en byggserver så integreras koden kontinuerligt, oftast vid varje incheckning, där de automatiska testerna kan köras. Om något i den nya koden skulle medföra att ett test misslyckas så märker man det direkt, byggservern varnar och mailar ut till berörda personer.

 

Syftet med automatiska tester och continuous integration är att man etablerar en feedback loop på att mjukvaran fungerar. Under en arbetsdag så byggs koden flera gånger och tack vare testerna så vet man att koden fortfarande fungerar. Det gör det möjligt att leverera fungerande kod som kontinuerligt växer.

 

Målsättningen med det Agila arbetssättet är att minimera waste, slöseri, och maximera värdet för kundens investering. Defekter, överlämning av arbete, delvis klar funktionalitet är några exempel på waste – vilket vi strävar efter att minimera. Ett väl fungerande Agila projekt levererar frekvent och med en hög kvalité.

 

Ofta används mock-objekt för att representera externa system när de automatiska testerna körs. Anledningen är att minska beroendet till andra system samt säkerställa att resultat blir rätt. Ett automatisk test kan misslyckas på grund av att det förväntade värdet är fel – det betyder inte att koden i sig är fel.

 

Systemtester i Agila projekt sker lite olika men i regel använder man byggservern för att testa, bygga och distribuera den senaste versionen. Genom att distribuera till en målmiljö där systemtester genomförs gör det enkelt att genomföra system eller acceptanstester. Detta ger projektet en möjlighet att testa systemet i rätt miljö utan mock-objekt.

 

Tänk på att testa det som är viktigt. Att bygga automatiska tester för all del av koden innebär i teorin dubbelt så stor kodmassa som ska underhållas och utvecklas. Det är mycket viktigt att balansera vilken funktionalitet som kräver automatiska tester och på vilken nivå som testerna är skrivna på.

 

Det finns mycket mer att skriva och kommentera kring automatiska tester, testdriven utveckling (TDD), continuous integration, tester i Agila projekt och hur man hanterar defekter. Det vi kan konstatera är att Agile projekt fokuserar på att leverera fungerande, utvecklas och testad, mjukvara.

 

Funderingar eller frågor? Bara att kommentera inlägget eller kontakta mig.

Affärsnyttan flyttar in i mobilen och det finns allt större vinster med att skapa specialanpassade applikationer till mobilen istället för att använda webbläsaren, eftersom det ofta blir svårt att navigera på en liten skärm. 3 tum är fortfarande långt från 17 tum, hur man än gör.

Jag har några projekt inom mobila plattformar och Android sen så har Logica en växande kompetens på området, eftersom det blir mer och mer intressant för våra kunder. Att utveckla för mobiltelefoner är såklart mycket roligt men det är lite av en ny värld. För er som vill utforska Android så kommer här lite tips. Hör av er om ni har frågor eller vill ha mer information. Kan även tipsa om Daniels introduktion till Android.

Delar av materialet kommer från Erik Hellman från Sony Ericsson som på Øredev pratade om deras erfarenheter från att utveckla med och mot Android, som är Googles operativsystem för mobiler. Det bygger på Java och har en egen SDK som man använder samt en emulator (virtuell telefon). Bra dokumentation och exempel gör det enkelt att komma igång.

Huvudregeln som Erik är återkommer till är att utveckla runt Androids SDK för att slippa problem med framtida versioner. SDK är bakåtkompatibel men om du går in i källkoden och ändrar i den och kompilerar om, vilket kan vara lockande ibland, innebär en härlig risk att du måste göra om de ändringarna i samband med alla uppgraderingar från Google = tidskrävande.

När det gäller förvaltningsbarhet ska man även tänka på exempelvis på att databasen är en Lite version. De har bland annat lärt sig att det är bättre att lägga till en ny tabell och koppla den till den gamla än att uppdatera den befintliga när man gör nya releaser.

Kring verktyg finns det en hel del roligt som även kan användas för andra projekt

• Eclipse för utveckling
• PowerMock för testning
• Hudson för Continuous Integration
• Find Bugs, för Eclipse
• Git för versionshantering
• Gerrit för kodgranskning tillsammans med Hudson och Git
• Monkey för slumpmässiga tester

Ett sista råd från Erik var att se till att hålla sig uppdaterad kring vad andra har gjort. Android är en ny plattform och det händer mycket på kort tid. För er som vill följa honom så bloggar han för Sony Ericsson.

Hur lång tid är lagom för en första intervju? Det vanligaste jag har sett, varit med om och använt är ett man bokar en timma men själva mötet tar egentligen 45 minuter. I dag testade jag 15 minuter.

När jag rekryterade till mitt gamla företag så bokade jag möten på en timma. Totalt var det cirka 8 interjuver som skulle göras utifrån ett underlag på cirka 40 personer. De flesta ansökningarna var från personer med erfarenhet så det fanns möjlighet att särskilja dem åt och välja ut några som man trodde på. Det funkade rätt bra förutom när man hade missbedömt en ansökan och efter fem minuter insåg man att det här skulle bli en lång och meningslös intervju.

Jag håller precis på med ett studentrelaterat projekt. I det här fallet söker jag 10 studenter och hade 17 ansökningar. Till skillnad från sist så var varje ansökan hyfsat lika och det var svårt att särskilja dem. Dels för att de över lag hade mindre erfarenheter och dels för att det var väldigt varierade kvalité på ansökningarna. Så för att inte missa någon talang som gömmer sig bakom en tvivelaktig ansökan så bokade jag in möten med alla 17. De fick 15 minuter var.

Så hur funkade det? Ja, jag hittade ett riktigt guldägg bakom en platt ansökan. Jag kunde se några med riktigt bra ansökan som inte skulle passa. På 15 minuter hade jag tid att komplettera med information utöver det jag redan hade skickat ut, de kunde ställa frågor om projektet och vi kunde avsluta med att prata om deras eventuella roll i projektet. På den tiden fick jag en magkänsla som troligen inte hade blivit bättre på ytterligare 30 minuter.

Fördelen med 15 minuter för varje möte är att alla kommer i tid och är förberedda. Även om det inte var stressigt så kändes det ibland lite som att artigheterna, prat om väder och sånt, fick stryka på foten. Men vad gör de när man kan ha fyra möten per timma och göra klart alla intervjuerna på en dag (inklusive skriva ett blogg inlägg).

Det där med mingel som en del i rekryteringen är inte helt dumt. Hur brukar ni göra?

In response to: Bug reporting

Good post! There are several good tips on how to address tester-developer communication.

A comment regarding “ignored by the developers so they can make their milestones”. I considered that to be the main source of bugs. Management and pressured timeline often stress the developers (and testers). Managers and customers often believe that short development time equals more delivered value when it in fact pushes the team to deliver with poor quality which leads to increased work due to fixing all the bugs – and in the end a higher total cost of ownership. If you rush the development you will get bugs. If you have committed and motivated developers, and testers, you do not need to rush them to get results. They make the most and deliver with quality and making sure that the customer gets the business value to the smartest investment.

In my heaven there are no bugs.

Vad är skillnaden mellan reklam som företag ger dig och tips som du får via social software?

Många håller inte med men jag tycker reklam är bra. Reklam ger mig information om saker som jag kan vara intresserad av. När jag får reklam hem i brevlådan, eller via annonser på nätet eller mellan TV-program så noterat jag budskapet men om det inte är något som jag just nu är intresserad av så ignorerar jag det. Jag filtrerar informationen. Många tycker det är jobbigt och försöker hindra inflödet genom att sätta upp lappar.

 














Källa: www.argalappen.se

Med social software ger mina vänner, bekanta eller helt enkelt intressanta personer mig tips om saker de tycker är intressant. Om jag har valt mitt nätverk, eller skapar automatiska filter, rätt så är sannolikheten att de förser mig med bara intressanta länkar hög. Det fungerar ungefär som att sätta en skylt på ens brevinkast med texten ”Bara bra reklam tack!”.Att sprida intressant information skapar värde för andra. Sharing knowledge är ett sätt att vara konkurrenskraftig för företag och ett sätt för individer att följa utvecklingen inom sitt område. Det är inte reklam utan information, om man nu vill göra skillnad på dem.

Så om det nu finns många som vill marknadsföra dig så ska det såklart vara enkelt för dem. Satt själv och skapade lite nya siter för egna projekt och ville lägga till möjligheten för användare att enkelt tipsa om min nya, grymma, site för andra via deras sociala nätverk. Som utvecklare så började jag direkt fundera på implementation men så hejdade jag mig och frågade allsmäktiga Google om det fanns ett svar på mitt problem. Det gjorde det och det tog 1 minut att lägga in på siten.

Här är ett exempel:














AddThis löser det åt dig med bara en enkel länk. Om du registrerar dig, kostnadsfritt, erbjuder de även statistik för hur knappen används.

Så se till att den information som du sprider är enkel för andra att sprida vidare. Låt andra hjälpa till i din marknadsföring. Om du har något bra kommer folk gilla det, annars kanske man ska lägga sin tid på något annat eller fundera över sin målgrupp.

Mer från Øredev kring teamet efficiency och en summering av Scott Hanselman som jobbar på Microsoft och är en aktiv bloggare. Förutom att han är väldigt underhållande så gick han igenom ytterligare en del nyttiga tips för hur man ska prioritera sitt arbete och informationsflödet.
 
Han inleder tidigt med att presentera en undersökning som visar att 28% av arbetsdagen försvinner, i rent slöseri, på grund av avbrott. Även om det ökade informationsflödet skapar många möjligheter så är det också ett störande moment. Att lära sig hantera informationsflödet och prioritera sitt arbete för att vara fokuserad är en nödvändighet som alla behöver lära sig hantera.

Prioritera med hjälp av: Four D's for Decision Making
Ditt informationsflöde, så som din inbox, kan prioriteras i en av följande kategorier
•    Ta bort
•    Gör, om det tar mindre än 2 minuter
•    Delegera, delegera det direkt om det tar mindre än 2 minuter
•    Planera, men flytta det till en annan mapp än din inbox

Hur viktigt och akut är saker och ting? Det är första frågan.
 



















Samma sätt gäller olika informationsflöden. Tro det eller ej, men man måste inte följa allt som händer på Yammer och Twitter i realtid. På samma sätt så måste man inte läsa alla mail när man får dem, det räcker med att prioritera dem när man har gjort klart det man jobbade med.

Genom att fokusera på det man gör, jobba med det i 25 minuter och sen ta 5 minuters paus så finns det ett naturligt tillfälle att läsa mail och andra informationsflöden. Mer om den tekniken kommer senare.

Scott Hanselman pratade även om organisera dina aktiviteter med hjälp av 43 Folders, och använda Evernote för att hantera din informationsmängd. Mer om det i kommande inlägg.

I början av november var jag på utvecklarkonferensen Øredev i Malmö. Temat var efficiency och Mark Lessner öppnade med en intressant keynote på ämnet Less is More. Läs mer om det konceptet i hans bok.

Många av föreläsarna spelade vidare på temat och särskilt tankvärd var Neal Ford som bland annat deklarerade krig mot musen, eftersom det är ofantligt mycket långsammare sätt att interagera med datorn än med tangentbordet. Han skickade med oss några konkreta tips.

Utöka ditt clipboard
Trött på att det bara finns ett objekt som du kan klippa ut åt gången? Är du en av många som använder en textfil som jag mellanlagrar text som du har klippt ut? Då kan CLCL rekommenderas som sparar allt du kopierar och klipper ut (Ctrl+C och Ctrl+X) i en historik. Om du vill klistra in något från historiken trycker du bara Alt+C så får du upp en meny att välja ifrån.

Lär dig kortkommandon
Ett annat bra exempel är mousefeed for Eclipse (utvecklingsmiljön som väldigt många använder). När användaren klickar på en knapp eller i menyn så kommer mousefeed att påminna dig om vilket kortkommandon som du kan använda istället. Den tränar helt enkelt upp dig i kortkommandon så att du inte behöver använda musen mer.

Jag kommer att återkomma med fler tips längre fram, bland annat kring test. Har ni några egna får ni gärna dela med er genom en kommentar.

Då var det dags att ge sig in i matchen igen. Det var ett tag sedan jag bloggade nu men det är skönt att ge sig ut i den publika och som vanligt något skrämmande världen. Jag menar, vad ska man skriva om?

Ja, det blir ju helt enkelt om saker som jag tycker är intressant och som jag tror kan intressera andra. Mitt problem och lycka har alltid varit att jag är intresserad av allt möjligt från affärsnytta till teknik och allt som får plats mellan det och lite till. Så räkna med spridda skurar från teknik till metodik till reflektioner.

Jag är såklart en Logican och tillhör Java och arkitektur grupperingen samt WebSphere Center of Excellence. Jag arbetar främst som utvecklingsledare eller teknisk projektledare med mycket fokus på Agila metoder. Utöver det så är jag en entreprenör som driver en del projekt och är handledare inom bland annat Venture Cup. Om ni tycker att jag låter väldigt intressant så kan ni läsa mer om mig och mina projekt på  www.jesperforslund.se annars får ni göra som de flesta andra och följa min blogg här på Logica Live.