Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue. Ronny Roos, d04rr

Transkript

1 Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue Ronny Roos, d04rr Inlämnad: 16 januari 2008

2 1 Softhouse - Crossmedia Avenue Crossmedia Avenue, är ett svenskt företag som ingår i Softhouse Nordic-gruppen. De är specialiserade på mobil marknadsföring och använder sig av både inhouseutvecklare och konsulter placerade på andra företag. På deras kontor i Malmö tillbringade jag min tid i kursen Ingenjörsinriktad yrkesträning. Mitt uppdrag här var att konstruera ett system för att dynamiskt rendera webbsidor på mobila enheter, enligt Crossmedia Avenues specifikationer. Jag introducerades även för en ny agil arbetsmetod som jag inte använt tidagare, nämligen SCRUM. 1.1 SCRUM Utvecklingsmetoden SCRUM är, som tidigare nämnt, en agil utvecklingsmetod. Den bygger på att en SCRUM-master fungerar som projektledare, och har översikt över situationen och projektets utveckling. Uppgifterna som måste utföras för att kunna uppfylla de krav som kunden ställer på projektet sätts därefter in i en så kallad product backlog. Uppgifterna bryts sedan ner i så små delar att man kan göra en tidsuppskattning på dem. Dessa tidsuppskattningar infogas sedan för att kunna visas i ett så kallat burndown-chart där uppgifternas totala tid plottas mot återstående arbetstid i projektet. En viktig skillnad här jämfört med många andra metoder är att man under uppgifternas gång kontinuerligt uppdaterar kvarvarande tid på uppgifterna. Om man t.ex. märker att en uppgift kommer att ta längre eller kortare tid än planerat införs detta i backloggen. Detta ger sedan direkt återkoppling i burndown-chartet där man kan se hur projektet ligger till, tidsmässigt. SCRUM innebär också en nära kontakt med kunden till projektet. Kunden prioriterar vissa delar av projektet, och därefter följer utvecklarna denna prioritet så gott det går. Under projektets gång diskuteras framgången av projektdelarna med kunden, om denna finner att något tar för lång tid, eller att det finns tid över kan uppgifter lyftas in respektive tas bort ur backloggen för att kunna leverea en slutprodukt. Ett projekt i SCRUM består av flera så kallade sprints. Varje sprint har ett specifikt mål, dessa mål bestäms av kund och team och kan t.ex. bestå av ett körbart program som innehåller delar av den funktionalitet som ska ingå i slutprodukten. Vid planeringen av dessa sprints estimeras deluppgifternas svårighet av programmerarna i teamet, detta kan sedan översättas till tid för att kunna planerar projektet lättare. SCRUM-teamet ska sedan fungera mer eller mindre självständigt under utvecklingen, allt de behöver veta ska egentligen finnas tillgängligt i backloggen och övrig information given av kunden. Här är SCRUM mindre styrt än andra utvecklingsmetoder som explicit säger hur själva utvecklingsprocessen ska hanteras. I SCRUM väljer teamet själv hur det vill jobba och hantera situaioner. I många fall anser jag dock att det kunde vara vettigt att blanda in t.ex. parprogrammering då det ibland behövs ny input på vissa problem och det kan bli påfrestande att kontinuerligt fråga kollegor. Teamet kan ibland även behöva kontakt med kunden, det finns inget i SCRUM-metodiken som säger att kunden måste vara on-site, men det är alltid en fördel att ha någon möjlighet att kontakta kunden enkelt, och enligt egen erfarenhet så är on-site att föredra. 1

3 1.2 Produktutvecklingen på Softhouse Under projektets gång användes en modifierad version av SCRUM, teamet bestod endast av en programmerare, d.v.s. mig och en SCRUM-master som fungerade som projektledare. Utvecklingen var indelad i två olika sprints. Första sprinten hade som mål att leverera en exempelsite, som visade olika möjligheter med det uppbyggda systemet, med andra ord inget som skulle vara tillgängligt för allmänheten. Målet för sprint två var en skarp version av en mobil site till Crossmedia Avenue. Sprintplaneringarna lades upp tillsammans med både kund, SCRUM-master och utvecklaren. Kunden hade i förväg prioriterat de saker hon ville ha med i sprintarna, därefter var det upp till mig att sätta ut den svårighetsgrad jag trodde att de olika delmomenten innebar. Om kunden ansåg att något tog orimligt lång tid eller var orimligt svårt jämfört med den funktionalitet det gav i den slutgiltiga versionen kunde denne prioritera direkt. Första sprinten innehöll mest olika funktionalitetskrav, krav på stort stöd av enheter samt dynamisk rendering av sidorna för att anpassa innehållet efter den enhet som surfat in på sidan. Under sprintens gång insåg jag att det var mycket svårt att uppskatta svårighetsgraden på uppgifter. Detta visste jag dock sedan tidigare projekt, t.ex. XP-kursen. Därför hade jag valt att uppskatta en viss svårighetsgrad och flytta upp den ca 5-20% beroende av ingående osäkerhet i uppgiften, om detta (enligt min uppfattning), ledde till att uppgiften hamnade på en ny svårighetsgrad så blev det denna som blev den slutgiltiga. Detta beslut visade sig dock vara något väl tilltaget (om man ser det ur ett tidsperspektiv), eftersom många uppgifter blev klara tidigare än väntat, detta gav däremot mer så kallat slack till utrymme för vidare utredning av andra uppgifter, samt infogande av nya uppgifter som man förbisett i backloggen. Denna kunskap kan man ju naturligtvis använda för senare projekt som liknar detta. D.v.s. om ett projekt i sig innebär stor osäkerhet (om det t.ex. inte finns någon tidigare domänkunskap inom företaget för den typen av uppgifter man kommer att bearbeta är det en bra idé att antingen överskatta den tid uppgifter med stor osäkerhet kommer ha, eller lägga in planerad slack-tid för utveckling, testning och utredning på de områden som behövs. Sprint två innebar att en skarp site skulle produceras, uppgifterna i backloggen var inte lika krävande (rent utvecklingsmässigt) som i föregående sprint. Istället var man nu i många fall beroende på andra personer (t.ex. art designer, ansvarig utgivare för text på sidan samt serveradministratör). Detta skapade en helt ny sorts osäkerhet i uppgifterna, nämligen sådan som är svårare att uppskatta, därför valde jag att återigen göra ett pålägg på de ingående uppgifterna för att ha utrymme för denna osäkerhet. Även denna gången visade sig detta vara lönsamt, eftersom det ofta blev fördröjningar innan man fick det material som behövdes för att producera siten. Sprintmål två blev inte helt uppfyllt eftersom siten aldrig kopplades till Crossmedia Avenues DNS-server, då serveradministratören åkt på semester, men i övrigt var sprint två färdigt. Något som tål att funderas på här är hur mycket av detta pålägg man bör använda sig av vid uppskattning av uppgifter, men det är svårt att veta på förhand, då det till stor del bygger på erfarenhet. 2

4 1.3 Övriga uppgifter på Softhouse Som i de flesta andra projekt är det inte bara utveckling som ingår för att få färdigt produkten. Under projektets gång måste de inblandade kontinuerligt uppdateras på projektets nuvarande status, vilket innebär en hel del möten. Mötena under projektets gång på Softhouse innefattade oftast bara mig själv och kunden, ibland närvarade SCRUM-mastern för projektet, men då han hade många samtidiga projekt hade han ofta svårt att närvara. Under mötena diskuterades ofta kraven på produkten, mer specifika detaljer för hur kunden ville ha vissa delar av systemet utformat och dylika aspekter av projektet. Mötena, då alla parter närvarade, diskuterade oftare projektets gång och om det fanns några problem och eller hinder för det hela. De så kallade daily-scrum mötena skötte jag oftast själv med kunden. Under tiden på Softhouse fick jag också arbeta på olika sidospår som kunde vara till nytta för företaget vid senare utveckling, dock antar jag att jag blev mindre utsatt för dessa sidospår än man blir om man är inblandad i flera projekt. 2 Reflektioner kring civilingenjörsrollen För mig är en civilingenjör någon som har mycket bred kunskap, ett djup inom matematik och till slut en specialisering inom något område. Denna specialisering, eller fördjupning, trodde jag spelade stor roll för vilken bransch man kunde arbeta inom. Min tid på Softhouse har dock visat att detta inte riktigt stämmer, som civilingenjör har man stora möjligheter att arbeta inom områden som inte ens ligger i närheten av det man har sin grundutbildning i. Detta tack vare att arbetsgivaren kan vara säker på att när han/hon har anställt en civilingenjör kan denna lära sig och utvecklas inom en stor mängd områden tack vare den breda grund man får i utbildningen, detta enligt egen uppfattning. 2.1 Civilingenjörens roll på Softhouse I detta fallet kan titeln på kapitlet nog vara lite missvisande, men mina egna reflektioner kring civilingenjörsrollen är baserade på de erfarenheter jag fått under praktiktiden på Softhouse, därmed är det inte sagt att dessa erfarenheter inte stämmer överens med hur det fungerar på andra företag. Innan jag kom till Softhouse var jag ganska säker på att man som civilingenjör hade en bred arbetsmarknad, vad jag inte visste var att den i själva verket var mycket bredare än jag kunnat föreställa mig. På Softhouse fanns det civilingenjörer som arbetade som konsulter marknadsansvariga, kundkontakter, SCRUM-masters, projektledare och även vice direktören var civilingenjör. Jag hade egentligen förväntat mig att man var något begränsad inom områden som t.ex. kundkontakter, visst hade jag förväntat mig att civilingenjörerna hade kontakt med kunderna, men i så fall som egenskap av exempelvis projektledare som hade kontakt med kunderna för projektet i fråga, här fanns det däremot personer som enbart arbetade med kundkontakterna, att ta fram och pitcha förslag till nya respektive gamla kunder som t.ex. skulle köra en ny kampanj. Så, med andra ord, en civilingenjör kan arbeta som i stort sett vad som helst som inte kräver alltför stor specialisering. 3

5 Det jag senare försökte komma fram till under mina funderingar angående civilingenjörens roll är vilka av de kurser jag läst på LTH som varit mig mest till hjälp, samt vilka som skulle kunna vara bra för andra typer av arbetsuppgifter än den jag själv haft. Resultatet av dessa funderingar finns nedan. 2.2 LTHs påverkan Då projektet innebar att jag skulle arbeta med ett helt nytt språk, ett helt nytt programmeringsramverk och ett område som jag inte sysslat med så mycket tidigare, var det av största vikt att man snabbt kunde lära sig att behärska det nya området och hantera det på ett sådant sätt att man kan producera en produkt som går att använda skarpt. Detta är det man, enligt mig, ägnar mest tid åt på LTH, sätta sig in i och förstå nya områden till den nivå att man behärskar dem tillräckligt bra för att kunna använda dem för att tillverka något. De kurser som jag anser är viktigast för att lära sig detta är till stor del de matematikkurser man läser i början av utbildningen, här tvingas man ständigt sätta sig in i nya problem som behandlar nya områden. Dessa kurser tillför dock inte så mycket om de inte effektivt kombineras med kurser som innehåller mer praktisk kunskap, så som t.ex. programmeringskurser. Så, beroende på vilket område man kommer att arbeta med så kommer man ha olika nytta av vissa sorters kurser, t.ex. så kommer inte alla programmeringskurser jag läst på LTH vara särskilt givande om jag väljer att jobba uteslutande med kunder, medan om man har den rollen som jag hade, kommer man att ha mycket stor nytta av att tidigare ha provat ett flertal språk och kunskap om hur dessa fungerar i grund och botten för att lättare kunna sätta sig in i nya språk. Om man sedan ska se detta ur andra perspektiv än det jag själv upplevt, så finns det fler kurser som jag anser har varit mycket bra från LTHs sida, t.ex. så har kompilatortekniken hjälpt en förstå ett programmeringsspråk underliggande funktioner, algoritmer och datastrukturer har hjälpt en använda effektiva sökalgoritmer för att t.ex. sortera datastrukturer. Kort sagt, så har mer eller mindre alla kurser som jag läst varit nyttiga på ett eller annat sätt under praktiken, man kanske inte har använt någon avancerad matematik, elektronik eller fysik, men kurserna inom de områdena har hjälpt en lära sig hur man effektivare hanterar problem som man tidigare inte behandlat. Som jag ser det, så är en nyutexaminerad civilingenjör inte färdiglärd på något sätt, de allra flesta som är nyutexaminerade ingenjörer står inför sin allra största utmaning, nämligen att omsätta allt det man lärt sig under sin tid på universitetet till något som ens framtida arbetsgivare kan ha nytta av. Därmed inte sagt att det är lika för alla ingengjörer, vissa väljer att specialisera sig mycket, och skaffar sig en mycket djup kunskap inom särskilda områden, medan andra studenter väljer att bredda sin kunskap. Studenten som har valt att arbeta på djupet, har troligen (i många fall), en lite mindre arbetsmarknad att välja på, samtidigt som man egentligen är mer redo för arbetsmarknaden eftersom man har en djupare kunskap inom ett visst område. Studenten med ett brett kunskapsområde har däremot en större arbetsmarknad att välja på och förmodligen en ganska lång inlärningsperiod på det han/hon kommer att arbeta med sedan. 4

6 3 Slutsats För att summera min upplevelse, både från kursen, praktiken och LTHs påverkan skulle jag vilja säga att det i mitt tycke fungerat mycket bra. Under praktiken var man tvungen att vara till stor del självgående, och fick nu ännu mer ansvar än man haft på universitetet, skillnaden som enligt mig kändes störst var att här var det någon som tänkte använda det jag producerade på riktigt, vilket, bara det, ingav mig med en stor känsla av ansvar. Finns det då något LTH kan göra för att inflika denna känslan hos sina studenter tidigare i utbildningen? Det är inget trivialt problem att lösa, och jag tror redan det till viss del är löst, men tyvärr har jag inte läst den kursen så jag kan inte uttala mig om det. Men enligt mig, så skulle man kunna designa en kurs där studenterna tillsammans ska utveckla ett större system, under tidspress och verkliga krav på resultat på sig, och i mitt tycke liknar detta kursen Programvaruutveckling i stora system. I övrigt så anser jag att, om man tagit sin utbildning vid LTH på allvar, och faktiskt tagit det ansvar för sina studier som det är tänkt att man ska, så är man väl förberedd för att hantera verkligheten. Jag tycker även att kursen har givit mig ett perspektiv på min utbildning som tidigare saknades, jag anser att jag nu har fått sätta mina kunskaper från LTH på prov, och sett att de håller, vilket inger en hel del självförtroende. Jag har även fått mer förståelse för ett flertal av de kurser som generellt anses onödiga av många studenter. Man hör ofta att man läser kurser för att lära sig att sätta sig in i nya problemområden, men det är en helt annan sak att faktiskt komma ut och se att det är så på en riktig arbetsplats också. Så, då är frågan, anser jag att en praktikkurs ska vara obligatorisk på LTH? - Nej det gör jag inte. Jag tror att resultatet av det blir att kvaliteten på de platser som erbjuds studenter sjunker eftersom det då krävs en oerhörd mängd praktikplatser. Och om så är fallet kommer många inte uppskatta upplevelsen. Men framförallt anser jag att många studenter inte är intresserade eller rentav redo för att ta den mängden ansvar som krävs för att kunna sköta en praktikplats. Därför, är det i mina ögon bättre att hålla kursen valfri och utöka antalet platser och låta studenter söka platser. Jag tycker att kursen har givit mig ett nytt perspektiv på min framtid som civilingenjör och skulle varmt rekommendera den till alla som känner att de är redo att ta steget ut i verkligheten under en läsperiod och prova sina kunskaper. 5